- 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