Re: ISSUE-183: Constraining 2.0 c14n algorithm

(1) Currently XML Signature 2.0 says in section 6.5 ( http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-c14nAlg )

"2.0 mode signatures, must use the 2.0 mode Canonicalization algorithms. They are described in section 2.0 Mode Canonicalization Algorithms"

I like your suggestion of future-proofing, so how about changing this sentence to read:

"All 2.0 mode signatures MUST use  Canonicalization algorithms designated as compatible with 2.0 mode.  Section 6.8 ( "2.0 Mode" Canonicalization Algorithms) lists such compatible algorithms as of publication.

(2) In addition, proposed change to 3.1.3, Signature Generation ( http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-SignatureGeneration ):

Change step 2 

"Canonicalize and then calculate the SignatureValue over SignedInfo based on algorithms specified in SignedInfo.

by adding

"Canonicalization in this step MUST use a canonicalization algorithm designated as compatible with 2.0 mode for signatures created in 2.0 mode. This 2.0 mode canonicalization algorithm SHOULD be the same as used for Reference canonicalization."

regards, Frederick

Frederick Hirsch
Nokia



On Jul 27, 2010, at 12:00 PM, ext Scott Cantor wrote:

> So, the question is whether 2.0 mode signatures (in either Reference,
> SignedInfo, or both) should lock down c14n to just the newly defined method,
> or leave it open.
> 
> Currently we say nothing about SignedInfo, but Pratik indicated that sec 6.5
> of the draft locks down Reference c14n to require the c14n 2.0 algorithm
> only.
> 
> My proposal is that we do not restrict this in either Reference or
> SignedInfo, but leave it open, subject to the constraint that for Reference
> c14n, only algorithms defined for use with XML Signature 2.0 will work.
> That's simply a consequence of the input interface (the list of subtrees
> plus exclusions, etc.)
> 
> My reason for this is future-proofing, basically. Of course, c14n 2.0 would
> be the only MTI algorithm.
> 
> As an alternative, if we leave the language as is, and require c14n 2.0 for
> References, I believe we should make sure that the same is true for
> SignedInfo. There's no use case for having a different rule there.
> 
> -- Scott
> 
> 
>

Received on Monday, 2 August 2010 14:48:36 UTC