As it appear in the current version of the ECMA-376 Office Open XML specification this accept any value, but assign no directions. This could lead to significant interoperability and upgrade nightmares, since there is no way to ensure, that would-be implementers is using the same notation and interpretation. If every application developer describe this as "myHashAlgoritm" then there will be a potential break of the interoperability goal of the specification.
It also open up for the suggested future expansion of the definition could be in direct conflict with existing implementation, and in this way break the goal of backwards compatibility
It also open up for the suggested future expansion of the definition could be in direct conflict with existing implementation, and in this way break the goal of backwards compatibility
Suggest (if a list exists) list of possible known types and possibility for extension.
Page 1629
line 27-28 Part 4
section 2.18.2
Ed
Proposed Disposition of DIS 29500 Comment DK-0131 (Modified: 2008-01-03) Agreed; there is a requirement for a normative set of interoperable hash algorithms for the assurance of interoperability. To meet this goal, the specification contains a list of interoperable formats in the cryptAlgorithmSid attribute on pages 1,1661,167: Value Algorithm 1 MD2 2 MD4 3 MD5 4 SHA-1 5 MAC 6 RIPEMD 7 RIPEMD-160 8 Undefined. Shall not be used. 9 HMAC 10 Undefined. Shall not be used. 11 Undefined. Shall not be used. 12 SHA-256 13 SHA-384 14 SHA-512 Any other value Undefined. Shall not be used. As well, it should be noted that based on multiple national body comments, the current hashing mechanism and all of its attributes will be deprecated in favor of a new mechanism which utilizes only well-accepted hashing algorithms. Accordingly, we will remove the existing mechanisms from their current location in the specification (Part 4, §2.18.2, pages 1,630-1,631 and Part 4, §4.8.2, pages 3,166-3,167), and place them into a new annex for deprecated features. Following the precedent set by other ISO standards (such as SQL’s ISO 9075:2003 Part 1 and C++’s ISO/IEC 14882:1998), we will make use of a new Annex that contains normative descriptions of all deprecated features. The intent of this Annex is to enable a transitional period during which existing binary documents being migrated to DIS 29500 can make use of those deprecated features to preserve their fidelity, while noting that new documents should not use them. Accordingly, the Conformance clause will also be changed to state that newly created documents (those not created by migrating existing binary documents) should not use deprecated features. All deprecated features will be removed from their current locations in the standard, but will be fully defined in this new Annex. Within the deprecated hashing mechanism, the language in Part 4, §2.18.2 appears to (inappropriately) allow any value. To clarify this, the following change will be made to Part 4, §2.18.2, page 1,630, line 11: Enumeration Value Description typeAny (Any Predefined Type) Specifies that any one of the predefined type of cryptographic algorithm s, specified by the parent element’s cryptAlgorithmSid attribute, generated the hash value type may be used .
