- From: <Frederick.Hirsch@nokia.com>
- Date: Mon, 15 Aug 2011 18:25:08 +0000
- To: <Frederick.Hirsch@nokia.com>
- CC: <public-xmlsec@w3.org>
I agree with the changes. regards, Frederick Frederick Hirsch Nokia On Aug 15, 2011, at 2:18 PM, ext frederick.hirsch@nokia.com wrote: > > 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:26:13 UTC