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

Additional editorial updates to address LC-2506

From: <Frederick.Hirsch@nokia.com>
Date: Mon, 8 Aug 2011 18:52:20 +0000
To: <public-xmlsec@w3.org>
CC: <Frederick.Hirsch@nokia.com>
Message-ID: <54E5479F-D754-4225-82E3-B8C0532D3171@nokia.com>
I have completed additional editorial updates to complete addressing issue LC-2506 [1].

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.
]]

I 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
]]

No change was needed for 2.0 as it already has similar text, and also disallows Transform child within RetrievalMethod (though I'm not sure why RetrievalMethod isn't disallowed in non-compatibility mode)

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

Please review and note any concern on the list.

regards, Frederick

Frederick Hirsch
Nokia


[1] LC-2506, http://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmldsig-core2-20110421/2506?cid=2506

proposal:

Begin forwarded message:

> From: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>>
> Date: July 1, 2011 10:28:08 AM EDT
> To: ext Sean Mullan <sean.mullan@oracle.com<mailto:sean.mullan@oracle.com>>, XMLSec WG <public-xmlsec@w3.org<mailto:public-xmlsec@w3.org>>
> Cc: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com<mailto: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
>>
>

regards, Frederick

Frederick Hirsch
Nokia
Received on Monday, 8 August 2011 18:52:52 UTC

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