RE: C14N Argument

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