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

Re: Enveloped-signature games with pre-c14n

From: merlin <merlin@baltimore.ie>
Date: Tue, 21 Aug 2001 18:03:19 +0100
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: w3c-ietf-xmldsig@w3.org, Joseph Reagle <reagle@w3.org>
Message-Id: <20010821170320.0B69B43D34@yog-sothoth.ie.baltimore.com>

Hi Christian,

The meaning is clearly defined in the spec; here() is *an error*
if applied to a different document.

Were this not the case, the here() function is defined to return
a node set containing the parent element of the node(s) containing
the XPath expression. This node set would simply not intersect with
the result of c14n and then parsing.

But, per spec, it's an error.

Merlin

r/geuer-pollmann@nue.et-inf.uni-siegen.de/2001.08.21/18:32:24
>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>
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com
Received on Tuesday, 21 August 2001 13:04:14 UTC

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