Re: Enveloped Signature Transform


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:


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


>> <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
>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
>But it really exists an XPath for this problem??
>Mauro Arcolini,

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.

Received on Thursday, 7 February 2002 14:47:53 UTC