Re: XML Signature 1.1 KeyInfo requirements

On 7/1/11 10:28 AM, Frederick.Hirsch@nokia.com wrote:
> 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. ]]

Looks fine. I initially was wondering what "MUST implement KeyValue" really
means. But then I noticed that this sentence in section 4.5.2 is pretty clear
about what that means:

"Structured formats for defining DSA (required), RSA (required) and ECDSA
(required) public keys are defined in section 6.4 Signature Algorithms."

--Sean

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

Received on Friday, 1 July 2011 17:05:13 UTC