W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

Re: Enveloped Signature Transform

From: merlin <merlin@baltimore.ie>
Date: Thu, 07 Feb 2002 19:47:47 +0000
To: "Mauro Arcolini" <arcolini@sec.di.unipi.it>
Cc: w3c-ietf-xmldsig@w3.org
Message-Id: <20020207194747.7F76243BEA@yog-sothoth.ie.baltimore.com>

Mauro,

The XPath filter "not (ancestor-or-self::ds:Signature)" will
remove _all_ signatures from the document, so signatures can
be added at will without breaking validity.

An alternative filter could be constructed using:

here()/ancestor::ds:Signature[1]/following-sibling::ds:Signature

This would be slow, and would simply remove Signatures added
_following_ this signature. This would constrain the placement
of signatures, but might be more interesting.

Alternatively, with the enveloped signature transform, new
signatures could be added as ds:Object elements within the
first signature itself without XPath and without breaking
validity.

Merlin

r/arcolini@sec.di.unipi.it/2002.02.07/11:48:36
>
>Example:
>> <test:a ...>
>>   ...
>>   <ds:Signature ... >...</ds:Signature> <!-- first signature refers to
>> test:a -->    <ds:Signature ... >...</ds:Signature> <!-- second signature
>> refers also to test:a -->  </test:a>
>>
>> Both of these signatures contain enveloped transform and refer to the
>> same "test:a" element.  According to the specification the first
>> signature should sign the second one and the second one should sign the
>> first.  The same problem arise during verification phase. Is there any
>> reccomendation for this case?
>
>>>When you add sig1 to the document, you sign the document (which does
>>>include sig1 and the data) and exclude sig1. Then you add sig2 which signs
>>>the document (data + sig1 + sig2) and then exclude sig2;
>
>>>Verification of sig2 will work ok, but verification of sig1 fails: You
>>>verify the document (data + sig1 + sig2) and exclude sig1. So you verify
>>>(data + sig2) which was not signed (only data was signed).
>
>>>Solution: Use an XPath which omits all Signature, not only the current one.
>The XPath is only for the first ds:Signature??. If yes, there are no problem
>for verification
>of the first ds:Signature, after adding other ds:Signature, but for the second
>ds:Signature?
>The second ds:Signature signs also the first, but after adding other ds:
>Signature, the verification fails
>Solution: For each ds:Signature use an XPath omits all ds:Signature added
>after.
>But it really exists an XPath for this problem??
>Mauro Arcolini,
>GapXse


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

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 Thursday, 7 February 2002 14:47:53 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:14 GMT