Re: Widget Signature modification proposal (revised)

Hi all,

from the implementors perspective these modifications don't introduce too much trouble. But I'm a little bit concerned about the explicit ban of canonicalizations for 'external' documents like config.xml. In real life it happens very fast that an XML file is still valid but modified in some benign way. Especially when you think of the processing the widget to apply an additional signature. 

Generally I'm about astound about the abandonment of the advantages of XMLDSig and now I can much better understand the proposal to use the jar signature standard as it provides nothing less in functionality. You will have your reasons for this and I didn't follow discussion from the start. But it may be useful for readers of the spec to just briefly outline the considerations that lead to this result.  

Greetings

Andreas

----- original Nachricht --------

Betreff: Widget Signature modification proposal (revised)
Gesendet: Mi, 07. Apr 2010
Von: Frederick Hirsch<frederick.hirsch@nokia.com>

> Below is revised widget signature modification proposal that includes  
> limiting Reference canonicalization to same-document references and  
> allows for verification backward compatibility, while also retaining  
> the restriction on Transforms for non same-document references.
> 
> Thanks for the review comments.
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> - start -
> 
> (A) Revised Proposal (correction for limiting canonicalization of XML  
> to same document references and backward compatibility)
> 
> Disallow all Transforms except for a single canonicalization  
> transform  that is required for every ds:Reference that needs XML  
> content canonicalization.
> 
> Specifically, this would result in the following changes to the  
> Widget  Signature specification (editors draft ,
> http://dev.w3.org/2006/waf/widgets-digsig/ 
>   ):
> 
> (1) Normative change:
> 
> (a) Section 7.1 Common Constraints for Signature Generation and  
> Validation
> 
> Change 3c from "The ds:Reference MUST NOT have any ds:Transform  
> elements." to
> 
> A ds:Reference to same-document XML content MUST have a ds:Transform  
> element child that specifies the canonicalization method. Canonical  
> XML 1.1 MUST be specified as the Canonicalization  Algorithm for this  
> transform.  A ds:Reference that is not to same-document XML content  
> MUST NOT have any ds:Transform elements.
> 
> An implementation SHOULD be able to process a ds:Reference to same- 
> document XML content when that ds:Reference does not have   
> ds:Transform, for backward compatibility. In this case the default   
> canonicalization algorithm Canonical XML 1.0 will be used, as   
> specified in XML Signature 1.1.
> 
> Note: The relevant section in  XML Signature 1.1 is section 4.4.3.2,  
> "The Reference Processing Model". This section states "Unless the URI- 
> Reference is such a 'same-document' reference , the result of  
> dereferencing the URI-Reference MUST be an octet stream. In  
> particular, an XML document identified by URI is not parsed by the  
> signature application unless the URI is a same-document reference or  
> unless a transform that requires XML parsing is applied." In the same  
> section the specification notes, "In this specification, a 'same- 
> document' reference is defined as a URI-Reference that consists of a  
> hash sign ('#') followed by a fragment or alternatively consists of an  
> empty URI...".
> 
> Sectjon 7.2, add
> 
> Every ds:Reference to same-document XML content MUST have exactly one  
> ds:Transform element to specify the canonicalization method. Canonical  
> XML 1.1 MUST be specified as the Canonicalization  Algorithm.
> 
> Note: that this specifically means that a ds:Reference to the  
> ds:Object element will  require a ds:Transform element to specify  
> canonicalization method. A reference to config.xml will not, however,  
> since it is not a same-document reference.
> 
> Section 7.3, add after the third paragraph ("If a ds:KeyInfo element  
> is present") the following new paragraph:
> 
> When validating a Widget Signature, a validator MUST be able to  
> process a ds:Reference that has a ds:Transform specifying the  
> canonicalization method. The validator MUST be able to process a  
> ds:Reference that specifies Canonical XML 1.1 as a canonicalization  
> method. A validator SHOULD be able to process a ds:Reference to same- 
> document XML content when that ds:Reference does not have   
> ds:Transform, for backward compatibility
> 
> (2) Non-normative change:
> 
> 1.4 Example, (formatting appropriately and renumbering lines)
> 
> Change <Reference URI="#prop">
> 
> to
> 
> <Reference URI="#prop">
> <Transforms>  <Transform Algorithm="http://www.w3.org/2006/12/xml- 
> c14n11"/></Transforms>
> 
> ----------
> 
> (B) Clarification
> 
> There are two different places in XML Signature where XML  
> canonicalization applies, hence  leading to possible confusion.
> 
> First, there is the canonicalization of SignedInfo. This  is  
> determined by the CanonicalizationMethod of SignedInfo. This only  
> applies to the canonicalization of SignedInfo itself, however
> 
> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Canoni
> calizationMethod
> 
> Second,  there is the  canonicalization of same-document XML  
> referenced using a  ds:Reference,  for example the ds:Object element  
> in the Widget Signature case.
> 
> In this case the content obtained from the URI for the ds:Reference  
> requires canonicalization unless already an octet stream, so by  
> default canonicalization is used to convert the XML to an octet  
> stream. If no transform is specified, then the default 1.0  
> canonicalization algorithm is used. This has two problems - it isn't  
> obvious that canonicalization was done at all and this might become  
> an  interop problem, and Canonical XML 1.0 is used instead of 1.1  
> (that  fixes known issues with xml:id). By putting an explicit  
> Transform  within each ds:Reference element it makes this clear.
> 
> There is no mechanism in XML Signature to specify how all ds:Reference  
> elements to XML are to be canonicalized - it is specified individually  
> for each Reference, and in XML Signature 1.1 and earlier this is done  
> by specifying a transform, as noted in this example 2.1 from XML  
> Signature 1.1:
> 
> [s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
> [s06] <Transforms>
> [s07] <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
> [s08] </Transforms>
> [s09] <DigestMethod Algorithm="http://www.w3.org/2001/04/ 
> xmlenc#sha256"/>
> [s10] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue>
> [s11] </Reference>
> 
> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-o-Simp
> le
> 
> - end -
> 
> 
> 

--- original Nachricht Ende ----

Received on Wednesday, 7 April 2010 10:00:09 UTC