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

XML Signatures and binary files

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



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>

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>



// Enveloped:

<foo>

...

  	<Signature> ... </Signature>

</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>



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
Received on Wednesday, 16 May 2001 15:26:29 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:13 GMT