W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Widget Signature Issue and Proposed Resolution

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Wed, 31 Mar 2010 09:07:57 -0400
Cc: public-webapps WG <public-webapps@w3.org>, Thomas Roessler <tlr@w3.org>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>
Message-Id: <4566A7E5-7701-4229-B540-69A9123D2941@nokia.com>
To: Hirsch Frederick (Nokia-CIC/Boston) <Frederick.Hirsch@nokia.com>
Based on some feedback I have a revision to the Normative change (same  
intent)  and also a clarification that might be helpful:

(A) Revised Proposal

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  [1]:

(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 any 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.

Sectjon 7.2, add

Every ds:Reference to 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 and the ds:Reference to config.xml will each require a  
ds:Transform element to specify canonicalization method.

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. The validator SHOULD also be able to process XML content with  
a ds:Reference  that does not include a ds:Transform by using the  
default Canonical XML 1.0 canonicalization method.

(2) Non-normative change:

1.4 Example, (formatting appropriately and renumbering lines)

Change <Reference URI="config.xml">

to

<Reference URI="config.xml">
<Transforms>  <Transform Algorithm="http://www.w3.org/2006/12/xml- 
c14n11"/></Transforms>

Change <Reference URI="#prop">

to

<Reference URI="#prop">
<Transforms>  <Transform Algorithm="http://www.w3.org/2006/12/xml- 
c14n11"/></Transforms>

----------

(B) Clarificationn

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 XML referenced using a   
ds:Reference,  for example both the ds:Object element and the  
config.xml in the Widget Signature case.

In each 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 all 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


regards, Frederick

Frederick Hirsch
Nokia



On Mar 29, 2010, at 4:16 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

> ISSUE:  Widget Signature : Not specifying Canonicalization algorithm
> explicitly
>
> Detail: The current Widget Signature specification does not allow the
> use of XML Signature Transforms, however the only means to explicitly
> specify the Canonicalization method to use  to use a transform (in
> XML  Signature 1.1 and earlier). Using the default may be
> problematical if  organizations are not able to confirm the default in
> use, or because a  different algorithm is required (for example with
> an Id on ds:Object   Canonical XML 1.1 should be used, but the default
> is Canonical XML  1.0)
>
> PROPOSAL:
>
> 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  [1]:
>
> (1) Normative change:
>
> Section 7.1 Common Constraints for Signature Generation and Validation
>
> Change 3c from "The ds:Reference MUST NOT have any ds:Transform
> elements." to
>
> "The ds:Reference MUST NOT have any ds:Transform elements other than
> a  single Transform to specify the canonicalization method. A
> ds:Transform element specifying Canonicalization method  MUST be
> present when the ds:Reference is known to reference XML content.
> Canonical XML 1.1 MUST be specified as the Canonicalization
> Algorithm. For example, a ds:Transform specifying the canonicalization
> method is needed for the config.xml reference as well as the Object
> reference.
>
> (2) Non-normative change:
>
> 1.4 Example
>
> Add
>
> <Transforms>  <Transform Algorithm="http://www.w3.org/2006/12/xml-
> c14n11"/></Transforms>
> as the first child element of the following Reference elements in the
> example 1.4 (formatting appropriately and renumbering lines):
> <Reference URI="config.xml">
> <Reference URI="#prop">
> ----------
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
> [1] http://www.w3.org/TR/widgets-digsig/
Received on Wednesday, 31 March 2010 13:08:29 GMT

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