W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: Exclusive Canonicalization: A trivial problem

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Thu, 21 Jun 2001 00:10:26 -0400
Message-Id: <200106210410.AAA0000068231@torque.pothole.com>
To: "John Boyer" <JBoyer@PureEdge.com>
cc: <w3c-ietf-xmldsig@w3.org>
Hi John,

From:  "John Boyer" <JBoyer@PureEdge.com>
Date:  Wed, 20 Jun 2001 11:42:38 -0700
Message-ID:  <7874BFCCD289A645B5CE3935769F0B521962B3@tigger.PureEdge.com>
To:  "Phil Griffin" <phil.griffin@asn-1.com>,
            "Phillip Hallam-Baker" <pbaker@verisign.com>
Cc:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            <w3c-ietf-xmldsig@w3.org>

>As you may have guessed from my prior email "RE: Poll on Exclusive
>Canonicalization", there remains a simple design tweak to XMLDSig that
>A) would not hold up anything pertaining to status of the XML DSig spec,
>B) should be trivial to implement and test for interoperability, and C)
>solves more problems than just the namespace issue.
>
>I mention this technique in part to help everyone understand that the
>current conflict is not arising from a shortcoming in C14N but rather in
>XML DSig's application of C14N and/or the application of XML DSig in a
>particular scenario (signing SOAP messages).  

Well, C14N does what it was designed to do well but it defaults
towards including the context.  That's great when it is what you want.
But for cases where you want to exclude the context, it does not
default the way you would want.  It is true that you can overcome this
with sufficient application of the power of XPath.

>Consider the following sentence from the C14N Spec "Since XML
>canonicalization converts an XPath node-set into a canonical form, the
>first parameter MUST either be an XPath node-set or ..."
>
>Suppose we add an XPath element to the Signature element as a sibling of
>SignedInfo.  The XPath would say how to filter the SignedInfo.  The
>processing model would then say:
>
>1) Form a node-set consisting of the entire subtree rooted at
>SignedInfo, including namespace and attribute nodes.
>
>2) Apply the XPath expression.

There are advantages to this.  It is certainly very general and
powerful.  However, I also see disadvantages.

- It requires XPath implementation at both generation and verification.

- In general, it requires good XPath expression checking at the
verification end to determine if it is (1) safe and (2) secure, to
apply the provided XPath expression as part of canonicalization.

- It is my impression that, if the applicationis using an XPath data
model, the XPath expression you apply will need to contain the list of
needed namespace declarations and xml namespace attributes to retain
at the top level. That means this XPath expression will need to be
dynamially created. (Alternatively, all XMLDSIG applications could be
required to read the document containing the Signature into a
non-XPath data structure which retained original namespace delaration
position.)

On the other hand an exclusive c14n, while it might not cover every
case, would cover many, would not require XPath imlementation, would
be safe, would be secure if used as directed, and not require dynamic
modification for those cases where namespace prefix use is visible.

>3) Add the subtree rooted by the XPath element in Signature, including
>attributes and namespaces.

I don't think this works, if the application uses the XPath data
model, because this subtree will have been already been invaded by
ancestor namespace declaration.  And there are security problems with
having it filter itself. Alternativley, all XMLDSIG applciations could
be required to

>4) Send resultant node-set to C14N.
>
>5) Sign result.
>
>End of story.  Full stop to conflict.  Thanks for coming out.
>
>John Boyer
>Senior Product Architect, Software Development
>Internet Commerce System (ICS) Team
>PureEdge Solutions Inc. 
>Trusted Digital Relationships
>v: 250-708-8047  f: 250-708-8010
>1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>  	

Thanks,
Donald
Received on Thursday, 21 June 2001 00:11:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC