List of comments on “XML Signature Syntax and Processing Version 1.1” (dated 3 March 2011)

There are 3 comments (sorted by their types, and the section they are about).

general comment comments

Comment LC-2503: Commenter: Marcos Caceres <marcosscaceres@gmail.com> (archived message); Context: 4.5.4 The X509Data Element Identifier Type="http://www.w3....; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
On Mon, Jun 20, 2011 at 3:21 PM, Cantor, Scott E. <cantor.2@osu.edu> wrote:
> On 6/20/11 8:37 AM, "Marcos Caceres" <marcosscaceres@gmail.com> wrote:
>>Is there some means to explicitly indicate the order in which
>>certificates in an xml dig sig file should be processed? The problem
>>is that if you screw up the certificate order in the xml file, the
>>validator (e.g,. xmlsec) does not know which cert is the end-entity.
>
> BP is EE first, the rest after (and technically the order of the rest
> isn't supposed to matter).

Can I get an assurance from the XML Sec working group that a
non-normative note will be added to the XML Dig Sig specification wrt
to this best practice? Please consider this comment implementer
feedback on the CR.; Related issues: (space separated ids); WG Notes: minutes - http://lists.w3.org/Archives/Public/public-xmlsec/2011Jun/att-0058/minutes-2011-06-28.html#item09 wg email response - http://lists.w3.org/Archives/Public/public-xmlsec/2011Jun/0059.html; Resolution: No explanation should be added to XML Signature 1.1 on X.509 certificate usage as this is out of scope, but possibly add information on this topic to XML Signature Best Practices document, http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100831/; (Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2504: Commenter: Marcos Caceres <marcosscaceres@gmail.com> (archived message); Context: in (Introduction and References); Status:
assigned to Frederick Hirsch; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Add link and informative reference to XML SIgnature Best Practices document to XML Signature 1.1 introduction.; Related issues: (space separated ids); WG Notes:; Resolution: Editors draft has been updated with text in introduction and reference. http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0003.html Text added to editors draft: "The Working Group encourages implementers and developers to read XML Signature Best Practices [XMLDSIG-BESTPRACTICES]. It contains a number of best practices related to the use of XML Signature, including implementation considerations and practical ways of improving security." http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html#sec-Introduction; (Please make sure the resolution is adapted for public consumption)

Comment LC-2502: Commenter: Sean Mullan <sean.mullan@oracle.com> (archived message); Context: 4.5 The KeyInfo Element KeyInfo is an optional element that...; Status:
assigned to Frederick Hirsch; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Section 4.5, paragraph 2:

"If KeyInfo is omitted, the recipient is expected to be able to identify the key
based on application context. Multiple declarations within KeyInfo refer to the
same key. While applications may define and use any mechanism they choose
through inclusion of elements from a different namespace, compliant versions
must implement KeyValue (section 4.5.2 The KeyValue Element) and should
implement RetrievalMethod (section 4.5.3 The RetrievalMethod Element)."

These requirements seem like they should be revisited, especially since a later
section says to avoid RetrievalMethod because of potential security concerns
(see Note in section 4.5.10). Also, does this imply that all KeyValues must be
supported? I would think it should only be supported if there is a required
signature algorithm for the corresponding key type. Had there ever been any
discussion about updating the list of required KeyInfo types?

Thanks,
Sean; Related issues: (space separated ids); WG Notes: Discussion: http://lists.w3.org/Archives/Public/public-xmlsec/2011Jun/0064.html; Resolution: 1. Added text to 1st paragraph on KeyInfo section to state the following: [[ Details of the structure and usage of element children of KeyInfo other than simple types described in this specification are out of scope. For example, the definition of PKI certificate contents, certificate ordering, certificate revocation and CRL management are out of scope. ]] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html#sec-KeyInfo Added this text to both XML Signature 1.1 and XML Signature 2.0 2. Added the following note to the section on RetrievalMethod in 1.1 before the schema definition (4.5.3): [[ Note: The KeyInfoReference element is preferred over use of RetrievalMethod as it avoids use of Transform child elements that introduce security risk and implementation challenges ]] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html#sec-RetrievalMethod This and the earlier change to make KeyInfoReference a SHOULD instead of RetrievalMethod (made to both 1.1 and 2.0) should complete the changes to address LC-2506 [[ While applications may define and use any mechanism they choose through inclusion of elements from a different namespace, compliant versions must implement KeyValue (section 4.5.2 The KeyValue Element) and should implement KeyInfoReference (section 4.5.10 The KeyInfoReference Element). KeyInfoReference is preferred over use of RetrievalMethod as it avoids use of Transform child elements that introduce security risk and implementation challenges. Support for other children of KeyInfo is optional. ]] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html#sec-KeyInfo; (Please make sure the resolution is adapted for public consumption)

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:45:12 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org