RE: Canonicalization of <SignedInfo> for Reference Validation

Joesph,

Thank you very much for this information.

As an aside, there is one other thing that puzzled me regarding XML dsig. In
one of the examples that you used below, you mentioned Base64 as an encoding
transform. This sort of encoding transform would have a great deal of
utility in producing enveloping signatures over binary data, yet XML Dsig
doesn't explicitly mention Base64 as an encoding transform (see
http://www.w3.org/2000/09/xmldsig#base64). The specifics for how decoding
are to be handled are laid out, and Base64 is pervasive in other parts of
the recommendation (for encoding key values, for example), but I can't see
where Base64 is specified as a viable encoding Transform. Perhaps I am
overlooking the obvious or does Base64 encoding go without saying?

Kind Regards,

Blake Dournaee
Toolkit Applications Engineer
RSA Security
 
"The only thing I know is that I know nothing" - Socrates
 
 


-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Friday, July 06, 2001 11:51 AM
To: Dournaee, Blake
Cc: 'John Boyer'; w3c-ietf-xmldsig@w3.org
Subject: RE: Canonicalization of <SignedInfo> for Reference Validation


At 23:00 7/5/2001, Dournaee, Blake wrote:
>I'm guessing that all of this was hashed out some time ago and I probably
>came a little late for this discussion. Any thoughts or pointers to
previous
>discussion on this would be most helpful.

These are good questions actually and in the past this was part of our
discussions/debate regarding the transforms [1] in 1999 and something John
called "Document Closure." From that argument I don't think we ever
extracted a ringingly crisp and clear consensus, but fortunately in the
ensuing year of work on the spec I think we've ended up with a clear
position none-the-less: "When transforms are applied the signer is not
signing the native (original) document but the resulting (transformed)
document. (See Only What is Signed is Secure (section 8.1).)"[2]

[1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0372.html
[2]
http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-Transforms

I believe originally folks had three understandings of how transforms
worked:
1. One is signing the resulting document.
2. One is signing a relationship between the source document, the
transforms, and the resulting set of possible documents -- akin to John's
document closure.
3. One is signing the original document even given arbitrary transforms.

Option 1 is supported by the spec; option 2 is a different way of thinking
of the same thing but with some inferences an application might make (at its
own peril) about the relationship between the source and original document:
if the transforms are "safe" the application *might* make some inferences
about their relationship -- but that's outside the scope of this spec and it
can be dangerous. Option 3 can be a common mistake but is wrong.

To illustrate these options via a few examples:

A. SOURCE ENCODED
<Reference URI="source.base64">...
         <Transform Algorithm="&dsig;base64">

1. One is signing the decoding of the base64 encoded source. (Correct!)
2. One is signing a class of documents that result from applying a base64
decode to the source file. (One-to-one mapping, and the result set only
includes one document and is similar to option 1).
3. One is signing the base64 document. (Wrong)


B. SOURCE ENCODED
<Reference URI="source.xml">...
         <Transform Algorithm="&dsig;base64">

1. One is signing the encoding of the xml document. (Correct!)
2. One is signing a class of documents that result from applying a base64
encode to the xml file. (One-to-one mapping, and the result set only
includes one document and is similar to option 1).
3. One is signing the source.xml . (Wrong, and dangerous because since the
application/user is obligated to see what it signs, it's seeing the base64
version. Folks make this same mistake [3] with encryption, thinking that if
one signs encrypted data, one is signing the source data and they also
confuse the issue by lumping in implicit signature semantics. The correct
response is you only are signing the plain form when you use a decryption
transform to make it the final result![4])

[3] http://lists.w3.org/Archives/Public/xml-encryption/2001Jul/0010.html
[4] http://www.w3.org/TR/xmlenc-decrypt


C. SOURCE TRANSFORMED WITH XPATH
<Reference URI="source.xml">...
            <Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
              <XPath xmlns:dsig="&dsig;">
                   -select-everything-but-user-entry-data-fields-
             </XPath>

1. One is signing the transformed xml document. (Correct! Changes to the
user entry elements that are no longer in the resulting document aren't
signed obviously.)
2. One is signing the resulting document and its relationship (via
transforms) to the source document. So, if the transforms are well
specified, standardized, and understood while the application signed (and
should "see") the resulting document, it might also continue to "see" the
original document in the context of that relationship. So for instance,
consider a multi-party work flow in which a document is canonicalized every
time some processing and signature validation occurs. However, the
processors don't want to pass on the canonical form because it is ugly for
their purposes. Since the relationship between the original document and its
resulting canonical form is well understood, they might validate the
signature over the canonical form, but continue to process the original.
They may wish to do the same thing with the form example above.
3. One is signing the source.xml . (Wrong, again.)

--
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 6 July 2001 22:21:10 UTC