Chapter 6 XML Proxy Signature Scheme
6.4 XML Proxy Signature Packaging
6.4.3 Detached Signature
The signature is over content and out of the tag <Signature>. The target is figured out via a URI. The signature is certainly "detached" from the content as it signed. This definition typically applies to separate data objects, but it also includes the instance where the signature block and data object reside within the same XML document but are sibling elements.
This is the model for detached signature as below:
<!-- Detached Signature -->
<Signature>
…
</Signature>
The content is excluded from the proxy signature but maybe exists somewhere. The problem we suffered at first is how to deal with the redundant parameters. The reference points to the destination for signing and it is impossible changing its original content. Maybe adding them into context if the target is text, document or some sort related to readable file.
There is no doubt that can not insert them if the target is a type of image or binary file. It should be have more complicate means than the others. But now, let’s see the example as below:
<Signature Id="BusinessTrip" xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="http://www.jimmyscott.com/CrucialMessage.tif">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>1PxHHtXLpomODMb2wQe/+4IAt58=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>E7RGu2x4q2c/2J ... kevAjEEwH40=</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P> AP1/U4EddR…6AR7ECL </P>
<Q> AJdgUI8VIwvMspK5gqLrhAvwWBz1</Q>
<G> APfhoIXWmz3ey7yrXDa…HtVJWQBTDv+z0kq </G>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
The original signed object, we know, is used by URI to point out somewhere likes enveloping signature but the content is not existed in local files. There must be have a modified manner and the simplest way is to transfer original binary content by Base64 encoding algorithm. Once the content is converted to printable character, the format will be transformed to the style of enveloping signature. Those of three parameters, thus, can be put together with the content. The example is like as below:
<SignedInfo>
<Reference>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>OLaPA/jptmnzqePsSAiqPhFXQBg=</DigestValue>
</Reference>
</SignedInfo>
<Object>
<GP>
AKCJs8YBU6mZoW9QkevAjEEwH43xACe7eF+Tvj7EWdJDGTqGyhDiyoPx/vyekj 0CIJe690R+CUu5o6uoJbq1YtSqQAWKcf4Oqzs3IrtD3RQ2UwtqabDhwOWHbx8O0 wWQY53+T/YBkHgf7ek1ys4qVYak7nZTZmR0M0xQrc3cWcJH
</GP>
<RA>
Lz5gJLvNbAIBMG9t6mrLGOeTQPQclqGbbUHslLZnFeGvygvqHw96cGTSUtFgJ0Y KYOWWyR/tlXlIQjn5YjsWcOL1/CmMUt6Ca2w7siBKJWHGDVcBRRJ9ZElxz1Yo wknHI5noo5szb4qdC4uE6jQA9ZoUvQEytrlss90F1J3rexc=
</RA>
<EP>
PtkhMHMhA0WPrReQx0oFfzvRhV0=
</EP>
<CrucialPicture Id="ImportantPicture" MimeType="image/gif"
Encoding="http://www.w3.org/2000/09/xmldsig#base64">
aWcgQmxha2UncyBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlMRQwEgYDVQQLEw tFbmdpbmVlcmluZzEWMBQGA1UEAxMNQmlnIEJhZCBCbGFrZTEcMBoGCSqG SIb3DQEJARYNYmJiQGJiYmFzLmNvbTAeFw0wMDA2MjAyMTEzMzVaFw0xMT A2MDMyMTEzMzVaMH4xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lL VN0YXRlMQ8wDQYDVQQKEwZTZXJ2ZXIxFDASBgNVBAsTC1NlcnZlciBDZX J0MRMwEQYDVQQDEwpTZXJ2ZXJDZXJ0MR4wHAYJKoZIhvcNAQkBFg9zZXJ 2ZXJAY2VydC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMg7Y 9ZByAKLTf4eOaNo8i5Ttge+fT1ipOpMB7kNip+qZR2XeaJCiS7VMetA5ysX7deDU
YYkpefxJmhbL2hO+hXj72JCY0LGJEKK4eIf8LTR99LIrctz </CrucialPicture>
</Object>
In this case, it will not be a detached signature model but enveloping one whatever it is reasonable and works. We, however, discard this method to establish the proxy signature because of incorrect structure. All about this, there would have another way to fit with our request.
We should not, on the other hand, add parameters any more to follow the compatibility we emphasized in advance but parameters block can be regard as an independent document.
Thus, the XML standard announces that the tag <Manifest> could pack multiple objects, so that both of two can be signed at the same time.
<Signature Id="DetachedSignature">
<SignedInfo>
<Reference URI="#TripSig" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>545x3rVEyOWvKfMup9NbeTujUk=</DigestValue>
</Reference>
</SignedInfo>
<Object>
<Manifest Id="TripSig">
<Reference Type="http://www.w3.org/TR/2000/09/xmlsig#Object"
URI=”#TripParameter”>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>3K2DgPfmmrm632wx547nDOU60v8=</DigestValue>
</Reference>
<Reference URI="http://www.jimmyscott.com/announce.png">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>ALIOvKHxUqjCynnxeBibMJ1Yh5E=</DigestValue>
</Reference>
</Manifest>
<TripParameter>
<GP>
AKCJs8YBU6mZoW9QkevAjEEwH43xACe7eF+Tvj7EWdJDGTqGyhDiyoPx/v yekj0CIJe690R+CUu5o6uoJbq1YtSqQAWKcf4Oqzs3IrtD3RQ2UwtqabDhwOW Hbx8O0wWQY53+T/YBkHgf7ek1ys4qVYak7nZTZmR0M0xQrc3cWcJH </GP>
<RA>
Lz5gJLvNbAIBMG9t6mrLGOeTQPQclqGbbUHslLZnFeGvygvqHw96cGTSUtF gJ0YKYOWWyR/tlXlIQjn5YjsWcOL1/CmMUt6Ca2w7siBKJWHGDVcBRRJ9 ZElxz1YowknHI5noo5szb4qdC4uE6jQA9ZoUvQEytrlss90F1J3rexc=
</RA>
<EP>
PtkhMHMhA0WPrReQx0oFfzvRhV0=
</EP>
</TripParameter>
</Object>
...
</Signature>
The above example has two parts in <Mainfest> block, first one is stored the parameters section named <TripParameter> locally and another is pointed by URI out there. The signature has a final digest value for the <Manifest> to prevent someone from falsification.
Thinking more about the parameters section surrounded by the tag <TripParameter>, it looks like using the way of enveloping signature as arranging the original content. We can make it more similar with the detached signature, getting rid of the parameters section and stored to an individual file. Taking the first <Reference> block and figured out by URI same with the second one. Supposed the parameters file is located on the following address:
“http://www.jimmyscott.com/proxysigner/thirdqrtsig.xml”, the <Reference> block should be written as below:
<Reference URI=” http://www.jimmyscott.com/proxysigner/thirdqrtsig.xml”>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>3K2DgPfmmrm632wx547nDOU60v8=</DigestValue>
</Reference>
After introducing how to create the detached proxy signature, let’s think about what type of data format suitable for it. There are, as matter of fact, all can be applied to the detached proxy signature. It merely uses the URI but exclude the original content to specify where it is, so that all we do is to get apart the content from the <Signature> block and put into the file anywhere that everybody can read it. But one stuff we concerned is more appropriate than other two data format and that is the binary data. It can be adopted by the detached manner, and the content transferred by Base64 encoding for applying enveloped or enveloping proxy
signature will make the XML file too large to read conveniently for human beings. That’s why we take the detached proxy signature to be the best way if processing the binary content.
Beyond these three types of proxy signature format, we summarized all characteristics discussed previously at the next section.