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

Re: C14N Argument

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Wed, 25 Jul 2001 23:47:47 -0400
Message-Id: <200107260347.XAA0000050793@torque.pothole.com>
To: "Dournaee, Blake" <bdournaee@rsasecurity.com>
cc: "'John Boyer'" <JBoyer@PureEdge.com>, "Joseph M. Reagle Jr." <reagle@w3.org>, w3c-ietf-xmldsig@w3.org
Hi,

I think your argument works only for the default Canonical XML that
strips comments. If you want to retain comments or to use Exclusive
XML Canonicalization, or use some other canonicalization/serialization
some place where you are going from a node set to an octet stream then
you need to specify it explicitly.

Donald

From:  "Dournaee, Blake" <bdournaee@rsasecurity.com>
Message-ID:  <E7B6CB80230AD31185AD0008C7EBC4D2DAEFCC@exrsa01.rsa.com>
To:  "'John Boyer'" <JBoyer@PureEdge.com>,
            "Joseph M. Reagle Jr."
    	 <reagle@w3.org>
Cc:  w3c-ietf-xmldsig@w3.org
Date:  Wed, 25 Jul 2001 17:17:01 -0700

>John,
> 
>I belive your example is redundant. If we decode something that is expected
>to be XML and we process it as XML the first thing we would do would be to
>convert it into a node-set. From here, no matter what we did to it, it would
>be canonicalized as part of the node-set to binary conversion. Any additonal
>canonicalization is redundant - this is the nature of my argument.
> 
>For example
> 
>Base64 Blob -> Base64 Decode -> octets-to-node-set -> XSLT/XPath/etc ->
>node-set to octets -> hash function.
> 
>In my version above, canonicalization happens *once*.
> 
>Here is your version
> 
>Bas64 Blob -> Base64 Decode -> octets-to-node-set -> C14N -> XSLT/XPath/etc
>-> node-set to octets -> hash function.
> 
>In this version, canonicalization happens twice. Once explicitly, and once
>implicitly when the node-set gets transformed into octets. This is redundant
>canonicalization because shouldn't the XSLT and XPath transformations behave
>the same over canonicalized or non-canonicalized XML?
> 
>Further, you said: "Note that C14N is not run again at the end of the
>transform pipeline if the output is already an octet stream, see Section
>4.3.3.5:"
> 
>This is correct, I agree with you. I think you are implying that I would
>need canonicalization if I had a node-set previously that was converted into
>an octet stream and then digested. 
> 
>But, my argument still holds because canonicalization would be used to
>convert the node-set to an octet stream anyhow, so it shouldn't ever be used
>explicitly.
> 
>The only possibility that I can see is if a node-set should be canonicalized
>*before* it is used in an XPath or XSLT transform. Is this the case? If so,
>it will beat my argument and provide a reason for canonicalizing twice.
> 
>Kind Regards,
> 
>Blake Dournaee
>Toolkit Applications Engineer
>RSA Security
> 
>"The only thing I know is that I know nothing" - Socrates
> 
> 
>
>-----Original Message-----
>From: John Boyer [mailto:JBoyer@PureEdge.com]
>Sent: Wednesday, July 25, 2001 4:17 PM
>To: Dournaee, Blake; Joseph M. Reagle Jr.
>Cc: w3c-ietf-xmldsig@w3.org
>Subject: RE: C14N Argument
>
>
>
>Hi Blake, 
>
>Base-64 decode something that is expected to be a chunk of XML. 
>C14N 
>XSLT 
>
>Also, I don't understand how it would slow anything down.  I find it cleaner
>that it is possible to express the implicit behaviors.  But, expressing that
>a step should perform C14N versus implicitly performing a C14N still results
>in a C14N, so there is no real cost saving derived from leaving out the
>declaration of the C14N transform.  Note that C14N is not run again at the
>end of the transform pipeline if the output is already an octet stream, see
>Section 4.3.3.5:
>
>"If the result of the URI dereference and application of Transforms is an
>XPath node-set (or sufficiently functional replacement implemented by the
>application) then it must be converted as described in the Reference
>Processing Model (section  4.3.3.2). If the result of URI dereference and
>application of Transforms is an octet stream, then no conversion occurs..."
>
>Cheers, 
>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>  <
>http://www.pureedge.com/ <http://www.pureedge.com/> >     
>        
>
>
>-----Original Message----- 
>From: Dournaee, Blake [ mailto:bdournaee@rsasecurity.com
><mailto:bdournaee@rsasecurity.com> ] 
>Sent: Wednesday, July 25, 2001 3:49 PM 
>To: John Boyer; Joseph M. Reagle Jr. 
>Cc: w3c-ietf-xmldsig@w3.org 
>Subject: RE: C14N Argument 
>
>
>John, 
>
>Can you think of a possible example? I'm not even sure where this would fit 
>in at this point. 
>
>Canonicalization is a very expensive operation for XML Signatures, and if it
>
>is left as an acceptable transform without much further explanation I am 
>guessing that it will be used unnecessarily, further slowing down practical 
>implementations. 
>
>Blake Dournaee 
>Toolkit Applications Engineer 
>RSA Security 
>  
>"The only thing I know is that I know nothing" - Socrates 
>  
>  
>
>
>-----Original Message----- 
>From: John Boyer [ mailto:JBoyer@PureEdge.com <mailto:JBoyer@PureEdge.com> ]
>
>Sent: Wednesday, July 25, 2001 3:07 PM 
>To: Dournaee, Blake; Joseph M. Reagle Jr. 
>Cc: w3c-ietf-xmldsig@w3.org 
>Subject: RE: C14N Argument 
>
>
>
>
>Hi Blake, 
>
>It could be useful, now or in the future, to put another transform after 
>c14n. 
>
>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>  <
>http://www.pureedge.com/ <http://www.pureedge.com/> >     
>        
>
>
>-----Original Message----- 
>From: Dournaee, Blake [ mailto:bdournaee@rsasecurity.com
><mailto:bdournaee@rsasecurity.com> ] 
>Sent: Wednesday, July 25, 2001 1:47 PM 
>To: 'Joseph M. Reagle Jr.' 
>Cc: 'w3c-ietf-xmldsig@w3.org' 
>Subject: C14N Argument 
>
>
>Hello All, 
>
>There is something that I have been pondering about XML Signatures. 
>Specifically, the current Candidate Rec allows for the use of Canonical 
>XML 
>as a transform in the "transformation pipeline" above and beyond the use 
>of 
>C14N to convert any node-set to octets. 
>
>Consider this Argument: 
>
>1. If a Reference is to be processed as "XML" (node-set), it will be 
>canonicalized implicitly when the node-set is converted to octets at the 
>end 
>of the transformation pipeline. 
>
>2. If a Reference is to be processed as octets, canonicalization is 
>meaningless, since we don't know what the file format is anyhow 
>
>3. C14N, when used as a part of the transformation pipeline is 
>redundant. 
>
>Is there some exception to my argument here? What is missing? 
>
>Kind Regards, 
>
>
>Blake Dournaee 
>Toolkit Applications Engineer 
>RSA Security 
>  
>"The only thing I know is that I know nothing" - Socrates 
Received on Wednesday, 25 July 2001 23:49:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC