W3C home > Mailing lists > Public > public-xmlsec@w3.org > August 2011

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

From: <Frederick.Hirsch@nokia.com>
Date: Mon, 15 Aug 2011 18:25:08 +0000
To: <Frederick.Hirsch@nokia.com>
CC: <public-xmlsec@w3.org>
Message-ID: <4540B065-33A2-4206-ABA8-1E55240F8A24@nokia.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:16 UTC