RE: XML Signatures and binary files

Hello everyone,

Another thing just occurred to me, and perhaps this comment comes from my
ignorance on the totality of the XML signature spec, but it
looks like the Base64 transform is only defined as a decoding transform. It
seems to me that it would make a natural candidate for an *encoding*
transform. Currently, to sign an arbitrary binary file as part of an
enveloping signature, the binary file must be base-64 encoded and then set
as a Reference. It would seem natural that one would want to sign binary
files and include them in an enveloping signature without 'pre-encoding' the
files.

Is there a good reason (or an obvious one that I am overlooking) for not
having base-64 encoding as a viable encoding transform?

Kind Regards,

Blake Dournaee


-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
Sent: Thursday, May 17, 2001 5:34 AM
To: Dournaee, Blake
Cc: w3c-ietf-xmldsig@w3.org
Subject: Re: XML Signatures and binary files 



From:  "Dournaee, Blake" <bdournaee@rsasecurity.com>
Message-ID:  <E7B6CB80230AD31185AD0008C7EBC4D2DAEC94@exrsa01.rsa.com>
To:  w3c-ietf-xmldsig@w3.org
Date:  Wed, 16 May 2001 12:26:09 -0700

>Hello All,
>
>I began thinking about the various ways one might sign an arbitrary binary
>file via an XML signature and came up with the following possibilities. I
>wanted to run these scenarios by all of you to make sure I am understanding
>things correctly. 
>
>Please feel free to be overly critical if I state something that is not
>entirely correct (flame suit is on!) :)
>
>For all the following cases, I am assuming that I have a file in a binary
>format that is not in a text-represent able format. Let me call this file
>"B"
>
>Solution #1: Create a detached signature. Represent "B" in terms of some
URI
>and create a reference for this URI and then
>add this reference to the <SignedInfo> element.
>
>Follow up question/comment: No transforms should be *required* to make this
>happen. We might apply an application specific
>transform such as a compression scheme, but this is likely to be of little
>use since most binary formats have a high degree
>of redundancy. Furthermore, we shouldn't require any canonicalization here
>since the reference is not XML data.

What technique you use depends on you situation. Your Soluition #1 is
fine.  If the data over which the signature is computed and that over
which it verified are identical, then transforms serve no purpose.
This is true whether the data is truly a "binary" format or not.  Even
if the data is "XML", if you can be sure this external file doesn't
change and is not being processed as XML, then you can treat it as
binary.

>Solution #2: Create an enveloping or enveloped signature. Represent "B" in
>terms of some URI. Before we sign, our binary
>reference must be transformed into well-formed XML. Two transforms can be
>applied to make this happen. First we can
>Base-64 encode the binary data using the Base-64 transform. At this point,
>we have valid ASCII data, we could apply some other
>sort of user-defined transform that would "XMLify" the ASCII data by
putting
>a root element and a closing tag. Ex:
>
><foo>
>
>MIID1DCCArwCAQAwDQYJKoZIhvcNAQEEBQAwga8xCzAJBgNVBAYTAlVTMRMwEQYD
>VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTYW4gTWF0ZW8xKzApBgNVBAoTIkJp
>ZyBCbGFrZSdzIEF1dGhlbnRpY2F0aW9uIFNlcnZpY2UxFDASBgNVBAsTC0VuZ2lu
>
></foo>

I don't off hand see why you need the surrounding element, since you
can just stick it in an Object.

>After these transforms have completed the resulting reference is XML and
the
>final signature should look like one of these two possibilities:
>
>// Enveloping
>
><Signature>
>
>	<foo> ...</foo>
>
></Signature>

Above should use Object and so does not need "foo", I think.

>// Enveloped:
>
><foo>
>
>...
>
>  	<Signature> ... </Signature>
>
></foo>

Obviously, in this case you do need foo...

>Solution #3: Use the <Object> element
>
>
>	I am a bit unclear on how this would work. If we assume that a URI
>points directly to a binary file and we add a bas64 transform to the file
>would
>the resulting signature look like this?
>
><Signature>
>
>...
>
>	<SignedInfo>
>	...
>		<Reference URI="#arbitraryBase64EncodedData"
>Type="http://www.w3.org/2000/09/xmldsig#Object">
>			<DigestMethod
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>    
>	
><DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>   
>		</Reference>    
>	
>	</SignedInfo>   
>
>	<Object Id="arbitraryBase64EncodedData" MimeType="text/base64">
>	
>	
>MIID1DCCArwCAQAwDQYJKoZIhvcNAQEEBQAwga8xCzAJBgNVBAYTAlVTMRMwEQYD
>	
>VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTYW4gTWF0ZW8xKzApBgNVBAoTIkJp
>	
>ZyBCbGFrZSdzIEF1dGhlbnRpY2F0aW9uIFNlcnZpY2UxFDASBgNVBAsTC0VuZ2lu
>	
>	</Object>
>
>...
>
></Signature>

Close, but I would think it would be more like

<Object Id="arbitraryBase64EncodedData"
	Encoding="http://www.w3.org/2000/09/xmldsig#base64"
	MimeType="application/octet-stream">

>Is this correct? I would assume that we could only include an arbitrary
>binary blob in an Object element if it was Base64 encoded, so this would
>have to be
>a transform applied to the data somehow. What about the "encoding"
attribute
>in the <Object> element. How does this come into play?
>
>I think the correct approach is something like Solution #3, but I am
>unclear. Is Solution #2 a viable approach? Are there problems with it?
>
>Kind Regards,
>
>Blake Dournaee

Donald

Received on Thursday, 17 May 2001 14:29:53 UTC