XMLDSIG Working Group Richard D. Brown GlobeSet, Inc. Expires December 1999 June 1999 Digital Signatures for XML - Comments ------- ---------- --- --- - -------- Richard D. Brown GlobeSet, Inc. Document Status This document, file name is intended to become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the XMLDSIG mailing list or to the author. Additional information can be found on the web sites maintained by the working group. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This specification consists of a series of comments and suggestions with regard to the Internet-Draft XMLDSIG main specification. It constitutes the primary source of information for forthcoming revisions of the main specification. The main specification can be accessed at http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-signature- 00.txt Richard D. Brown [Page 1] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments Contacts Chair(s): Donald Eastlake 3rd Joseph Reagle Jr. Author: Richard D. Brown Mailing List: Discussion: w3c-ietf-xmldsig@w3.org Archive: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig Subscription: w3c-ietf-xmldsig-request@w3.org specify (un)subscribe in SUBJECT line with an empty body. Web Sites: IETF: http://www.ietf.org/html.charters/xmldsig-charter.html W3C: http://www.w3.org/Signature Revision History 18-June-99: Create independent document, Create an index per status, Add entry #99061601, Add entry #99061602, Add entry #99061603. 04-April-99: Initial draft in main specification. Richard D. Brown [Page 2] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments Table of Contents Document Status............................................1 Abstract...................................................1 Contacts...................................................2 Revision History...........................................2 Table of Contents..........................................3 1. Comments and Suggestions................................4 2. Index per Reference Number.............................22 3. Index per Status.......................................23 Richard D. Brown [Page 3] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments 1. Comments and Suggestions This chapter consists of a central repository for all the comments and suggestions that have been received with regard to the XMLDSIG main specification. #98072901 - Syntax too verbose Origin: General Status: Superceded by 98091001, 98091002 Comments: "The syntax is far too much verbose." Author Notes: There are multiple optimizations that could be envisioned: - Promote syntax compactness instead of element reusability. - Adopt syntax that enables shared algorithm definitions. - Adopt default attribute and parameter values. #98091001 - Enable shared algorithm definitions Origin: Richard D. Brown Status: Opened Comments: "Considering that in most circumstances the digest of authenticate resources will be computed by means of a common digest algorithm, it seems preferable to define a syntax that allows shared algorithm definitions. Several approaches might be considered. The first one consists of adding a DigestAlgorithms element in every signature Manifest and using some linking mechanism (i.e. IDREF) to bind a digest value with a digest algorithm. Another approach is to allow definitions throughout the document and requiring the canonicalizer to inline the algorithm definition in the Digest elements." Richard D. Brown [Page 4] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments Author Notes: The first approach does not prevent replication of algorithm definitions in the header of the document and the different signature Manifests. On the other hand, the second approach requires particular behaviors in the canonicalizers and therefore cannot suffice with a surface string digest algorithm. #98091002 - Promote compactness over reusability Origin: Richard D. Brown Status: Opened Comments: "The current specification makes use of reusable element types. This approach obviously increases the "verbosity" of the syntax. It might be preferable to promote compactness instead of reusability." For example, the following optimizations might be considered: - Collapsing Locator into Resource. - Collapsing ContentInfo into Package. - Replacing basic data types (i.e. Integer, Date, etc...) by a DCD attribute and a PCDATA contents on the parent element. Author Notes: #98111301 - Add a Resource criticality attribute Origin: Milton M. Anderson Status: Opened Comments: "The definition of does not contain a feature to allow the signer to declare that the resource is critical to the validity of the signature." Richard D. Brown [Page 5] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments Author Notes: I do not have all the elements for judging how relevant is this particular comment, but my first guess is that a signature applies to a particular content and semantics verification shall be left to the application layer. #98111302 - Remove dsig:eval global attribute Origin: Milton M. Anderson Status: Closed Comments: "Having the dsig:eval attribute in the element that defines the authenticated block is probably a bad idea, since different signers can use different hash algorithm." Author Notes: Others have made a similar comment, but we have reached a different conclusion: dsig:eval shall be an IDREFS instead of an IDREF. #98111303 - Add a logging attribute Origin: Milton M. Anderson Status: Closed Comments: "No ability to mark data for logging by a signing hardware is included." Author Notes: Also, very much application specific. I am not quite sure this shall be a concern for the XML DSIG Proposal. Richard D. Brown [Page 6] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #98111304 - Add a signature purpose attribute Origin: Milton M. Anderson Status: Closed Comments: "The signature doesn't have a "type of signature" element." Author Notes: This may be provided at the application level by means of a complementary attribute. #98111305 - Add a Nonce in the Manifest Origin: Milton M. Anderson Status: Closed Comments: "No nonce to be used in hashing the resource is defined." Author Notes: Milton refers to a scheme that could be used for preventing birthday-attacks against the digest algorithm. E-Check makes use of this artifice to make sure that a fraudulent signer or a Trojan Horse on the signer's computer does not have full control over the data being signed by the signing device. If the attacker were able to find two messages M1 and M2 such that H(M1) = H(M2), it could send M1 to the device and then substitute M2 later. The hardware log will record that M1 has been signed and not M2. This problem may be addressed in the hardware log by itself. The device may sign H(M1), pick a nonce at random, and log the nonce value along with H(nonce||M1) for example. Richard D. Brown [Page 7] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #98112501 - Leverage DCD and other specifications Origin: Hiroshi Maruyama Status: Opened Comments: "For data types, I think we could refer to other activities such as DCD." Author Notes: Agreed as long as these specifications are adopted in time. Notice that DCD provides mostly for basic data types. This will not resolve the problem for the constructed data types such as IssuerAndSerialNumber, Package, etc... #98121501 - IssuerAndSerialNumber is too restrictive Origin: Richard D. Brown Status: Opened Comments: "Identifying a certificate by means of the constructed data types IssuerAndSerialNumber might be too restrictive. It is not obvious that this construct is sufficient for certificates other than X509v3. The specification shall adopt syntax a bit more opened. For example, a certificate might be uniquely identified by means of a Identifier element, whose syntax depends upon the type of the certificate." Author Notes: Richard D. Brown [Page 8] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #98122601 - Allow multiple Resource in Manifest Origin: Don Eastlake Status: Adopted (990404) Comments: "I believe that multiple occurrences of Resource should be permitted in the Manifest" Author Notes: The Manifest now requires a Resources element. #98122602 - Add a base locator for HREFs Origin: Don Eastlake - IOTP WG Status: Opened Comments: "Some of the IOTP concerns about many huge locator HREFs could be satisfied if a "base" attribute were permitted at the Resources level or, even more general, a Base element, which effected all following resource." Author Notes: #98122603 - Rename the attribute dsig:eval Origin: Don Eastlake Status: Opened Comments: "I do not like the choice of "eval" even if it is arbitrary. It makes me think of Lisp or the like. I would expect it to evaluate arithmetic expressions or the like. I think the previous "hash" was better and perhaps "dsig:digest" would be best..." Author Notes: Richard D. Brown [Page 9] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #98122604 - Default encoding attribute to base64 Origin: Don Eastlake Status: Opened Comments: "What's about defaulting to base64 instead of none for the encoding." Author Notes: #99010201 - Add a ID attribute to Algorithm Origin: Mark Linehan Status: Superceded (98091001) Comments: "I suggest adding an "id" attribute to the Algorithm element, and adding an algref attribute to any element that contains an Algorithm. Purpose is to avoid repeating the same Algorithm text in many places." Author Notes: One approach to address #98091001 #99010202 - Provide a default digest algorithm Origin: Mark Linehan Status: Closed Comments: "I suggest that it would be helpful to have a way to declare a default or standard digest algorithm. Reason: in most cases, the same algorithm will be used throughout a document." Author Notes: Adequate optimization should enable use of shared definitions. In such circumstances, the overhead on a Resource element will be limited to an IDREF. At first, removing all algorithm references from the Resource element does not seem a good idea Richard D. Brown [Page 10] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #99010203 - Add a type to RecipientInfo and OriginatorInfo Origin: Mark Linehan Status: Closed Comments: "I suggest that OriginatorInfo and RecipientInfo have a "type" attribute for the same reason as the Attribute element: to identify the format of the ANY content." Author Notes: RecipientInfo and OriginatorInfo are expected to be a collection of "attributes". Therefore, it does not make sense to define a "type" attribute for these elements. #99020301 - Adopt URL instead of URI Origin: Joseph Reagle Status: Opened Comments: "What's about adopting URLs instead of URNs. This will prevent registration requirements. At the least, the specification should allow URIs." Author Notes: #99021201 - Allow multiple signatures on a Manifest Origin: IOTP WG Status: Opened Comments: "Ability to have multiple signatures on a single Manifest and ability to adhere a recipient to a Signature." Richard D. Brown [Page 11] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments To address these concerns, IOTP DTD proposes the following construct: ... ... ... ... ... aBcdsejhtksagnbf== ehlekjrekkjrk== Richard D. Brown [Page 12] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments ... ... Author Notes: Assuming that the benefit expected from this construct is to prevent replication of a large Manifest in multiple Signature elements, I would remind that this specification allows for shared Resources element I can see at least three potential drawbacks with this construct: - Privacy: A signature value cannot be verified unless all the RecipientInfo elements are preserved into the Manifest. In some circumstances, it may not be desirable to disclose the identity of the other recipients. Notice however that this construct does not preclude the creation of independent signature elements. - Complexity: This construct is obviously more complicated than the one currently proposed. Dual forward references are not always easy to handle. - Inconsistency: Applying multiple signatures to a single document usually implies that the application has adopted some secret-key authentication scheme. In such circumstances, the originator may be known by the recipients under different names or accounts. But, this construct does not allow replication of the OriginatorInfo element (per recipient basis), which is supposed to carry such pieces of information. #99021202 - Enable shared digest algorithm definitions Origin: IOTP WG Status: Superceded by 98091002 Comments: "Ability to share digest algorithms for signatures, digest, and canonicalization" Richard D. Brown [Page 13] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments To address this concern, the IOTP DTD proposes to insert a collection of algorithm definitions into the signature Manifest and to use a linking mechanism for binding Resource definitions and signature algorithms to these shared definitions. Author Notes: Potential solution to optimizing the syntax. However, I would suggest replacing the collection of Algorithm elements by a DigestAlgorithms element. Also, I would limit this functionality to the Digest elements. #99031601 - Remove criticality attribute on Attribute Origin: Dave Solo, Eric Riscola Status: Opened Comments: ... IETF Meeting - following a presentation of criticality flag... Dave: "it's a bad idea: experience in CMS was to remove it" Eric: "I reinforce Dave: this bogs down every new attribute with a debate over 'criticality' ... PKIX and S/MIME show signs of precisely this kind of bloat." Author Notes: Tend to agree that criticality shall be a matter of the relying party and, therefore, a criticality attribute provided by the signer is not necessary in the syntax. Richard D. Brown [Page 14] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #99040101 - Remove Attributes element Origin: Yoshiaki Kawatsura Status: Closed Comments: "I do not understand why the Attributes element is needed." Author Notes: Collection elements such Attributes, Certificates, and Signatures has been proposed to facilitate DOM manipulation. For example, one may call some trust verification engine by passing the Certificates sub-tree. This construct enables containment of similar and related elements. #99040102 - Allow attributes on Resource Origin: Richard D. Brown Status: Opened Comments: "It seems that allowing per Resource attributes may have interesting applications. For example, a rating standard could define a rating:Public attribute that could be associated directly with the Resource element. In such circumstances, a rating standard could almost suffice with the current DTD definitions." Author Notes: #99040103 - Add an CanonicalizerAlgorithm element Origin: Richard D. Brown Status: Opened Comments: "All signature schemes require canonicalization and digest of the Manifest. Thence, all the signature algorithms require at least a digest-algorithm parameter and this has lead to some inconsistencies such as requiring a digest algorithm for rsa encryption or two hash functions for HMAC. Richard D. Brown [Page 15] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments It may be preferable to add a CanonicalAlgorithm element in the signature Manifest. This element will identify the digest/canonical algorithm to be used for computation of the fingerprint of the Signature Manifest." Author Notes: #99040104 - Allow attributes on Package Origin: Richard D. Brown Status: Opened Comments: "Similarly to adding attributes to the Resource element. For example, such added functionality could be used for attaching an origin attribute to a package. This may be used for binding indirectly a detached-signature with an internal Package element." Author Notes: #99040105 - Change Attributes contents to ANY Origin: Richard D. Brown Status: Opened Comments: "Currently, the Attributes element consists of a collection of Attribute elements, which specify a type and contain an inner value element Richard D. Brown [Page 16] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments An alternative a bit more opened would consist of defining Attributes as an element of ANY contents and use constructed attribute element." ... Author Notes: One could argue that origin, digest, and the forth are also attributes of the resource and, therefore, could be sealed in the Attributes element. In fact, we could remove the Attributes element and define Resource as an element of ANY contents. But, if we were to do so, it would be impossible to enforce the presence of mandatory attribute elements such as resource locator and digest by means of the DTD. If this suggestion were to be adopted, we may consider converting the ContentInfo element into a standard attribute. #99040106 - Change ContentInfo contents to PCDATA Origin: Richard D. Brown Status: Opened Comments: "The specification proposes a ContentInfo element with a type and subtype attribute. The type attribute is defined as an URN. Unfortunately, URN specification does not allow the character "/" in the NSS. Thence, it is not possible to map directly existing MIME types into an URN without adopting adequate NSS encoding. For example, "application/msword" shall be encoded into something like "urn:MIME:application%2fmsword." Richard D. Brown [Page 17] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments An alternative could be to define the ContentInfo element as follows: application/msword OrderDescription Author Notes: #99040701 - Allow Resource by value in Manifest Origin: John Boyer, Richard D. Brown Status: Opened Comments: "It may be worth considering the possibility to define a Resource either by means of a locator and a digest or by value." We may consider the following definition: Author Notes: Adopting this approach will disallow collapsing the Locator element into the Resource element. If the value is provided it does not make a lot of sense to specify a resource location. But, Xlink specification seems to require the href attribute (not clear in the specification). Richard D. Brown [Page 18] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #99040801 - Add a Certificate Appendix to specification Origin: Richard D. Brown Status: Opened Comments: "It may be worth considering adding a certificate appendix that documents specifics for the different certificate types or certificate locators. As a matter of fact, a LDAP URL might be used but it is not sufficient for locating a particular certificate" Author Notes: #99040802 - Add a Security Appendix to specification Origin: Richard D. Brown Status: Opened Comments: "It may be worth considering adding a security appendix such as the one mandated by IETF." Author Notes: #99040803 - Add a Compliance Appendix to specification Origin: Richard D. Brown Status: Opened Comments: "It may be worth considering adding an appendix that defines compliance requirements." Author Notes: Richard D. Brown [Page 19] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments #99040804 - Segregate basic data types Origin: Richard D. Brown Status: Opened Comments: "It may be worth considering segregation of the data types that do not directly relate to XML-DSIG. For example, elements such as Integer, Float, and value might be replaced by making use of some DCD attribute, and others such as IssuerAndSerialNumber or Package might be temporarily moved into some Data DTD. These element definitions will be later superceded by definitions adopted by specialized DTDs. Author Notes: #99061601 - Replace dsig:eval by a PI Origin: Richard D. Brown Status: Opened Comments: As mentioned earlier by Milton M. Anderson (98111302), having the dsig:eval attribute directly in the element being authenticated may be unpractical if different signers were to use different hash algorithms. A different approach consists of the definition of a Processing Instruction that specifies the algorithm to be used. This processing instruction could be inserted just before the element to be hashed and is not part of the hash value. Change in the value of the processing instruction does not invalidate previous signatures. Moreover, because the digest algorithm definitions are replicated into the Manifest, an attacker cannot attack the authentication scheme by tampering with the processing instruction. Document> Richard D. Brown [Page 20] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments ... Author Notes: #99061602 - Adopt RDF Data Model Origin: XMLDISG'99 Participants Status: Opened Comments: "XML-Signature should use the RDF data model but need not use the RDF serialization syntax. " In other words, the XML Signature syntax should consist of a static representation of a RDF schema. In the short term this static representation will translate into a DTD that will be replaced by the actual RDF schema as RDF awareness will develop in the Industry. Author Notes: #99061603 - Add a index per Category Origin: Don Eastlake Status: Opened Comments: "Categorize the comments and suggestions and attach an Index per category." Author Notes: Richard D. Brown [Page 21] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments 2. Index per Reference Number #98072901 - Syntax too verbose #98091001 - Enable shared algorithm definitions #98091002 - Promote compactness over reusability #98111301 - Add a Resource criticality attribute #98111302 - Remove dsig:eval global attribute #98111303 - Add a logging attribute #98111304 - Add a signature purpose attribute #98111305 - Add a Nonce in the Manifest #98112501 - Leverage DCD and other specifications #98121501 - IssuerAndSerialNumber is too restrictive #98122601 - Allow multiple Resource in Manifest #98122602 - Add a base locator for HREFs #98122603 - Rename the attribute dsig:eval #98122604 - Default encoding attribute to base64 #99010201 - Add a ID attribute to Algorithm #99010202 - Provide a default digest algorithm #99010203 - Add a type to RecipientInfo and OriginatorInfo #99020301 - Adopt URL instead of URI #99021201 - Allow multiple signatures on a Manifest #99021202 - Enable shared digest algorithm definitions #99031601 - Remove criticality attribute on Attribute #99040101 - Remove Attributes element #99040102 - Allow attributes on Resource #99040103 - Add an CanonicalizerAlgorithm element #99040104 - Allow attributes on Package #99040105 - Change Attributes contents to ANY #99040106 - Change ContentInfo contents to PCDATA #99040701 - Allow Resource by value in Manifest #99040801 - Add a Certificate Appendix to specification #99040802 - Add a Security Appendix to specification #99040803 - Add a Compliance Appendix to specification #99040804 - Segregate basic data types #99061601 - Replace dsig:eval by a PI #99061602 - Adopt RDF Data Model Richard D. Brown [Page 22] INTERNET-DRAFT July 1998 Digital Signatures for XML - Comments 3. Index per Status Opened #98091001 - Enable shared algorithm definitions #98091002 - Promote compactness over reusability #98111301 - Add a Resource criticality attribute #98112501 - Leverage DCD and other specifications #98121501 - IssuerAndSerialNumber is too restrictive #98122602 - Add a base locator for HREFs #98122603 - Rename the attribute dsig:eval #98122604 - Default encoding attribute to base64 #99020301 - Adopt URL instead of URI #99021201 - Allow multiple signatures on a Manifest #99031601 - Remove criticality attribute on Attribute #99040102 - Allow attributes on Resource #99040103 - Add an CanonicalizerAlgorithm element #99040104 - Allow attributes on Package #99040105 - Change Attributes contents to ANY #99040106 - Change ContentInfo contents to PCDATA #99040701 - Allow Resource by value in Manifest #99040801 - Add a Certificate Appendix to specification #99040802 - Add a Security Appendix to specification #99040803 - Add a Compliance Appendix to specification #99040804 - Segregate basic data types #99061601 - Replace dsig:eval by a PI #99061602 - Adopt RDF Data Model #99061603 - Add a index per Category Closed #98111302 - Remove dsig:eval global attribute #98111303 - Add a logging attribute #98111304 - Add a signature purpose attribute #98111305 - Add a Nonce in the Manifest #99010202 - Provide a default digest algorithm #99010203 - Add a type to RecipientInfo and OriginatorInfo #99040101 - Remove Attributes element Superceded #98072901 - Syntax too verbose #99010201 - Add a ID attribute to Algorithm #99021202 - Enable shared digest algorithm definitions Adopted #98122601 - Allow multiple Resource in Manifest File Name: draft-ietf-xmldsig-signature-comments-00.txt Expires: December 1999 Richard D. Brown [Page 23]