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

Enveloped-signature games with pre-c14n

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>
Message-id: <1986332195.998418744@pinkpanther>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC