W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Widget Signature modification proposal (revised)

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 6 Apr 2010 22:02:18 -0400
Message-Id: <9A9DE7E7-918C-4A09-A9B6-0213560D428A@nokia.com>
To: public-webapps WG <public-webapps@w3.org>
Cc: 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-CanonicalizationMethod

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

- end -
Received on Wednesday, 7 April 2010 02:29:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT