Table Protection: Specifying table:protection-key-digest-algorithm

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I have proposed that providing a clean specification of table:protection-key-digest-algorithm is not particularly profitable when the most successful protection against unauthorized authorization of a table is by appropriate use of digital signatures:
http://lists.oasis-open.org/archives/office/200901/msg00002.html

It might be seen as essential to provide table:protection-key-digest-algorithm for minimum satisfaction of existing custom and situations where sharing the key is not required for interoperability and interchange.  

Here's my sketch of what is necessary to have a minimal well-defined specification for table:protection-key-digest algorithm so that the trade-off and specification burden is understood.  I acknowledge that a common use of tables with protected cells is forms that only the author of the form will ever alter the protection on, usually for deriving a new version of the form.  In that case there is no need for a shared secret, but we do want that author to work with different implementations that support the feature.  (By the way, if we didn't want to assure the last part, we could simply do without table:protection-key-digest-algorithm altogether.)

I agree that there should be a caveat about this provision only protecting the key.  There should also be warning that the protection is a weak form that, if compromised, might present a security threat to assets other than the document containing the protected table.  (See 3.4-3.5, below.)

		1. Concurrence on the Key Format for Digest Input
		2. Agreement on the Encoding of the Digest Value
		3. Limiting Choice of Digest Algorithms

1. CONCURRENCE ON THE KEY FORMAT FOR DIGEST INPUT

1.1 The Message Digest algorithms all work on fields of binary bits.  To be able to match the digest-resulting hash code, it is necessary to deliver the key as the exact same string of bits across implementations.  

1.2 This means, most of all, that there must be an agreement on the character set and its encoding for the key that is to be encrypted.  I suggest that we want to affirm that the key will be in Unicode and that UTF-8 encoding is used.  This eliminates code-page dependencies and byte-order dependencies.  I am ignoring Unicode normalization issues and it may be necessary to say something about that too lest differences in system input methods lead to different internal representations of what should be considered the same key.

1.3 Although the capability of the Message Digest algorithms far exceeds what one would ever enter as an useful key, there might need to be some SHOULD about the lowest value that an implementation might set as a maximum key value.  The "open" case would be to allow an arbitrary length key, since the key can be hashed incrementally (in blocks of 64 octets in the case of SHA-1).  I assume that the open case is the implication of not explicitly specifying a limitation on key length, since there is actually no technical reason to limit the length of the key (although a key of 55 or fewer octets can be hashed using a single SHA-1 message block).

1.4 Having an octet-sequence character-set encoding solves all problems but for the order in which the bits of an octet are mapped to bits in the pure binary string that is submitted to the digest algorithm.  FIPS PUB 180-2 specifies and illustrates hashing in terms of big-endian bit order and big-endian words that leads to the results shown for the worked examples of the US FIPS PUB 180-2 (or 180-3) specification.  It is not necessary to specify this, but the resulting Base64 encoding will intrinsically reflect the this understood ordering of octet bits.

1.5 It is probably necessary to make a normative reference directly to the SHA-1 portion of FIPS PUB 180-3 (the current one in force).  That seems to be essential because the W3C Recommendation for XML Signature Syntax and Processing does not address any setup requirement for mapping an user-provided key to a bit-string message that is submitted to the Message Digest algorithm. 

2. AGREEMENT ON THE ENCODING OF THE DIGEST VALUE

2.1 Section 6.2 of the W3C Recommendation for XML Signature Syntax and Processing specifies how the output of the Message Digest Algorithm is to be encoded in the attribute value (using Base64 encoding) when the method is identified as "http://www.w3.org/2000/09/xmldsig#sha1";.

2.2 Section 6.2 should be referenced specifically and the SHA-1 digest method should also be singled out.  

2.3 Either the 2002-02-12 W3C recommendation or the current latest, the Second Edition of 2008-06-10 (http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/) can be referenced.  The Second Edition is preferable for its having a working reference and link to FIPS PUB 180-2.  I wouldn't refer to the first edition unless it is important to keep that one for the digital signature proposal.

2.4 It might be valuable to over-ride the W3C Recommendation and identify that the SHA-1 definition in FIPS PUB 180-3 be used (it is not changed, but this latest edition replaced its predecessor).

3. LIMITING CHOICE OF DIGEST ALGORITHMS

3.1 The SHA-1 digest algorithm should be a required value.  The absence of the attribute, if it is allowed to be optional, should be to "implementation-determined" for compatibility with existing implementations.

3.2 I see no reason to worry about other digest algorithms.  The discovery of and the cost of creating hash collisions in order to subvert a table's protection is a meaningless risk, since table protection is broken without requiring any knowledge of a key whatsoever.

3.3 In interchange the only way the key can be known is as a shared secret.  There are therefore more threats to compromise of the key than the negligible risk of a hash collision for it. 

3.4 However, to ensure that the key chosen and used to lock the protection on a table is not one that, if compromised, would provide a threat against other assets, a caveat is important.  I would suggest a warning that says keys SHOULD be ones that have no security value other than their use in protecting table cells and that having it be specific to the particular document in some way is an useful way to accomplish that.  I support Bob Joliffe's observation about this:
http://lists.oasis-open.org/archives/office/200901/msg00004.html  

3.5 Finally, I suggest that bothering to ever increase the cryptographic strength of the message digest used is far less meaningful than ensuring that a hash collision does not expose assets that are more valuable than the minor protection of table cells.  (In that regard, MD5 would be perfectly tolerable in this weak application, but going with SHA1 seems reasonable enough because of its continued FIPS PUB 180 support.)
 

 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org