- From: Dournaee, Blake <bdournaee@rsasecurity.com>
- Date: Wed, 16 May 2001 12:26:09 -0700
- 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 UTC