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

Re: Canonicalization of <SignedInfo> for Reference Validation

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Sat, 07 Jul 2001 12:51:36 -0400
Message-Id: <200107071651.MAA0000014515@torque.pothole.com>
To: "Dournaee, Blake" <bdournaee@rsasecurity.com>
cc: w3c-ietf-xmldsig@w3.org

What do you mean "does Base64 encoding go without saying"?  If you
want to use a base64 ENcode in the Transform pipeline, why?

Donald

From:  "Dournaee, Blake" <bdournaee@rsasecurity.com>
Message-ID:  <E7B6CB80230AD31185AD0008C7EBC4D2DAEF01@exrsa01.rsa.com>
To:  "'Joseph M. Reagle Jr.'" <reagle@w3.org>
Cc:  w3c-ietf-xmldsig@w3.org
Date:  Fri, 6 Jul 2001 19:24:24 -0700 

>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 Saturday, 7 July 2001 12:52:47 UTC

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