RE: C14N Argument

John,

Thanks for your detailed explanation. The reason why I am concerned about
where C14N is/should be used is because it will be important for developers
to know when they must use canonicalization and when they can omit it.
Canonicalization is one of the most time-consuming operations in most Java
implementations of XML Signatures, and developers are going to want to omit
C14N when it is redundant. Stating very clearly where C14N is required and
where it is redundant will be helpful and will clear up confusion regarding
the issue. If it is easy for developers to misunderstand canonicalization
and use it in a redundant manner, the practical performance of XML signing
will be slow. 

Perhaps we should add some guidelines that state more clearly when
canonicalization *would be* redundant? A few sentences (something along the
lines of what John said) would be helpful.

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: Thursday, July 26, 2001 10:00 AM
To: Dournaee, Blake; Joseph M. Reagle Jr.
Cc: w3c-ietf-xmldsig@w3.org
Subject: RE: C14N Argument




Hi Blake,

I had to be brief yesterday and yet still ran out of time.  Fortunately,
Donald and Merlin nailed much of the essential points I had wanted to
say about the issue.  

1) We used to have minimal c14n, but that got thrown out.  However, we
still have two c14n variations, one with and the other without comments,
and we have another 'exclusive' c14n on the way to deal with unwanted
inheritance of namespace.  Each c14n algorithm appears as a different
Algorithm attribute to a Transform.  It seems prudent to include
comment-less c14n in the list of recognized algorithm identifiers.

2) Anytime the output of a transform is an octet stream that is XML, it
may be necessary to c14n the result before subsequent processing.  The
example I gave is not redundant because the results of an XSLT (or even
an XPath) can change between a document and the c14n of a document
(admittedly many of the reasons for this that come to my mind quickly
are also things that should perhaps not be done, but we have little
control over that).  However, I think the archives are littered with
concern from many of us regarding the output of XSLT.

Indeed, so great is the concern that in Section 6.6.5, "we further
RECOMMEND inserting a transform after the XSLT transform to canonicalize
the output".  Naturally, many will want to express the regular
comment-less version in addition to the other kinds of c14n.

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 
 

-----Original Message-----
From: Dournaee, Blake [mailto:bdournaee@rsasecurity.com]
Sent: Wednesday, July 25, 2001 5:17 PM
To: John Boyer; Joseph M. Reagle Jr.
Cc: w3c-ietf-xmldsig@w3.org
Subject: 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/>     
        


-----Original Message----- 
From: Dournaee, Blake [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] 
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/>     
        


-----Original Message----- 
From: Dournaee, Blake [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 Thursday, 26 July 2001 13:16:03 UTC