There are 4 comments (sorted by their types, and the section they are about).
substantive comments
Comment LC-2487
Commenter: <Frederick.Hirsch@nokia.com> (archived message ) Context: 2. Signature Overview and Examples This section is non-norm...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Pratik Datta
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :There is an error in the XML Signature 2.0 examples, the dsig2:Selection attribute which specifies the type is named "type" and it should be named "Algorithm" according to the schema ( see http://www.w3.org/TR/2011/WD-xmldsig-core2-20110421/#sec-Selection )
Proposal, change "type='" to "Algorithm=" in the following.
(a) In 2.1, http://www.w3.org/TR/2011/WD-xmldsig-core2-20110421/#sec-o-Simple-2.0
[s07a] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" xmlns:dsig2="http://www.w3.org/2010/xmldsig2#"
URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126">
(b) In 2.2, http://www.w3.org/TR/2011/WD-xmldsig-core2-20110421/#sec-DetailedIdExample-2.0
[ i23 ] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" URI="#MsgBody" />
(c) and in 2.3, http://www.w3.org/TR/2011/WD-xmldsig-core2-20110421/#sec-DetailedXPathExample-2.0
[ p24 ] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" URI="">
regards, Frederick
Frederick Hirsch
Nokia
xs:element name="Selection" type="dsig2:SelectionType"/>
<xs:complexType name="dsig2:SelectionType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="URI" type="xs:anyURI" use="required"/>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
Related issues: (space separated ids)
WG Notes:
Resolution: Fixed, http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0013.html
(Please make sure the resolution is adapted for public consumption)
Comment LC-2506
Commenter: <Frederick.Hirsch@nokia.com> (archived message ) Context: 7. The KeyInfo Element KeyInfo is an optional element that...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :I suggest we make the corresponding changes to XML Signature 2.0 as noted in the proposal below and submit this as a Last Call Comment for XML Signature 2.0
For 2.0 (1) would apply to Section 7. The KeyInfo Element, (2) would apply to Section 7.3 The RetrievalMethod Element, and (3) would apply to Section 7. The KeyInfo Element, all as proposed.
regards, Frederick
Frederick Hirsch
Nokia
Begin forwarded message:
> From: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
> Date: July 1, 2011 10:28:08 AM EDT
> To: ext Sean Mullan <sean.mullan@oracle.com>, XMLSec WG <public-xmlsec@w3.org>
> Cc: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
> Subject: Re: XML Signature 1.1 KeyInfo requirements
>
> I have entered this into tracker as a comment, LC-2502 (even though the document is in CR)
>
> http://www.w3.org/2006/02/lc-comments-tracker/42458/CR-xmldsig-core1-20110303/2502
>
> Looking at this and Scott's mail, I propose the following changes to section 4.5 of XML Signature 1.1 [1]. Do we agree that these are the changes we want?
>
> (1) Change last sentence in section 4.5 paragraph 2 and add sentences, to read
>
> [[
> 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). The 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.
> ]]
>
> This changes the SHOULD from RetrievalMethod to KeyInfoReferenceElement and makes explicit that support for KeyInfo children is optional.
>
> (2) Add at end of section 4.5.3 "The RetrievalMethod Element" the following note:
>
> [[
> 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.
> ]]
>
> (3) add sentence to end of 1st paragraph of section 4.5 "The KeyInfo Element"
>
> [[
> Details of mechanisms used with element children of KeyInfo are out of scope for this specification, e.g. PKI certificate contents or ordering, CRL management and so on.
> ]]
>
>
> If we change the normative language this document would need to go back to Last Call for a short review of the noted changes, but this should not be a schedule issue at this time, given that the ECC PAG continues. I would recommend we try to resolve this on the list and complete another Last Call if needed before August.
>
> Please indicate agreement or suggested changes to the proposal on the list.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> [1] http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/#sec-KeyInfohttp://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/#sec-KeyInfo
>
> On Jun 29, 2011, at 3:24 PM, ext Sean Mullan wrote:
>
>> 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:
Resolution: The changes proposed have been made to XML Signature 2.0, but we changed 2.0 to allow RetrievalMethod Transform child (for consistency) and thus made note consistent with 1.1.
(Please make sure the resolution is adapted for public consumption)
editorial comments
Comment LC-2507
Commenter: <Frederick.Hirsch@nokia.com> (archived message ) Context: in (Introduction, references)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Frederick Hirsch
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :I propose the following changes to XML Signature 1.1 and XML Signature 2.0 to reference XML Signature Best Practices:
(1) Add new paragraph at end of Section 1, Introduction , as follows:
A number of good practices related to the use of XML Signature, including practical implementation considerations and practices for improving security are documented in the XML Signature Best Practices document which should be considered by implementers of this specification [XMLDSIG-BESTPRACTICES].
(2) Add informative reference to A.2 Informative references, as follows:
[XMLDSIG-BESTPRACTICES]
Pratik Datta; Frederick Hirsch. XML Signature Best Practices. 31 August 2010. W3C Working Draft. (Work in progress.) URL:http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100831/
regards, Frederick
Frederick Hirsch
Nokia
Related issues: (space separated ids)
WG Notes:
Resolution: Paragraph added to introduction to refer to Best Practices, including reference. Updated to use language proposed by Marcos - "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." (Please make sure the resolution is adapted for public consumption)
Add a comment .