Re: Enveloped-signature games with pre-c14n

Hi Merlin

misunderstanding: I only have on single document with multiple enveloped signatures. The problem is that after the first Transform c14n returns an octet stream as input for the second transform. This second transform, which is a enveloped-signature has to parse the octet stream and construct a document. But now the problem occurs _which_ XPath text in which Transform in which Signature is the correct context for enveloped-signature....

I don't take to enveloped-signature Trasform to apply it to a second document. The "second" org.w3c.dom.Document object is created after reparsing the canonicalized "first" document... That's exactly my problem: I want to find the XPath Elements Text node in the "second" Document to filter the second document.

Christian


--On Dienstag, 21. August 2001 18:03 +0100 merlin <merlin@baltimore.ie> wrote:

> 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.
>
>> 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
>






Mit freundlichen Grüßen,

Christian Geuer-Pollmann


--------------------------------------------------------------------------
Institute for Data Communications Systems             University of Siegen
Hoelderlinstrasse 3                 D-57068 Siegen                 Germany

mail:  mailto:geuer-pollmann@nue.et-inf.uni-siegen.de
web:  <http://www.nue.et-inf.uni-siegen.de/~geuer-pollmann/>

Received on Tuesday, 21 August 2001 13:16:28 UTC