Re: XML Signature 2.0 LC comment - proposed changes ( LC-2506)

 Dear <Frederick.Hirsch@nokia.com>,

The XML Security Working Group has reviewed the comments you sent [1] on
the Last Call Working Draft [2] of the XML Signature Syntax and Processing
Version 2.0 published on 21 Apr 2011. Thank you for having taken the time
to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-xmlsec@w3.org if you agree with it or not before 22 August 2011. In
case of disagreement, you are requested to provide a specific solution for
or a path to a consensus with the Working Group. If such a consensus cannot
be achieved, you will be given the opportunity to raise a formal objection
which will then be reviewed by the Director during the transition of this
document to the next stage in the W3C Recommendation Track.

Thanks,

For the XML Security Working Group,
Thomas Roessler
W3C Staff Contact

 1. http://www.w3.org/mid/27A10702-97EE-478C-87AB-7560EC3159D9@nokia.com
 2. http://www.w3.org/TR/2011/WD-xmldsig-core2-20110421/


=====

Your comment on 7. The KeyInfo Element KeyInfo is an optional element
that...:
> 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
> >> 
> >


Working Group Resolution (LC-2506):
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.



----

Received on Monday, 15 August 2011 18:18:43 UTC