- From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
- Date: Tue, 21 Aug 2001 18:32:24 +0200
- To: w3c-ietf-xmldsig@w3.org
- Cc: Joseph Reagle <reagle@w3.org>
Hi all, playing around with my implementation, I found a little problem with some combinations of <ds:Transform>s: Let's assume that - we want to verify a document which contains multiple, enveloped signatures - none of these ds:Signatures contains an Id attribute - verification of an enveloped signature means reading in an XML instance and looking for ds:Signature elements. - deciding which ds:Signature is to be verified. - (step 5) give this ds:Signature to the implementation and say: "Verify please!" - the implementation takes the document (if URI="" was signed) and applies the given ds:Transform operations on the input To implement the here() function or an enveloped-signature, the implementation must be given the node where the XPath string is stored. If the first Transform is c14n, our pointer from step5 is smashed because the DOM was transformed to byte[]s. So to make the xpath here() func or the enveloped-signature transform, I must create a new transform context - but hey, what of all these Signatures was _my_ Signature?. If I have multiple signatures in my document, how can I find the correct signature if I don't use Id attributes? The only solution I see is to "tag" the ds:Signature or ds:Transform in question prior to c14n with a random attribute which cannot occur in the original and to wipe away this attribute after selecting the correct ds:Signature and prior to next Transforms. Yes, I know that a sequence like <Transforms> <Transform Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' /> <Transform Algorithm='http://www.w3.org/2000/09/xmldsig#enveloped-signature' /> <Transform Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' /> </Transforms> does not make _much_ sense, but nevertheless, it's a valid ds:Transforms. Do the other implementors have this problem, too? Christian PS: To give a more extensive example, let's tate this one (two enveloped signatures without Id's. These signatures don't make sense because they don't use the correct transforms to exclude the right thing, but processing itself is not possible from my view) : <Document> <data>blah</data> <Signature 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=""> <Transforms> <Transform Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' /> <Transform Algorithm='http://www.w3.org/2000/09/xmldsig#enveloped-signature' /> <Transform Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> </Signature> <Signature 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=""> <Transforms> <Transform Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' /> <Transform Algorithm='http://www.w3.org/2000/09/xmldsig#enveloped-signature' /> <Transform Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> </Signature> </Document>
Received on Tuesday, 21 August 2001 12:30:51 UTC