Re: signature portability / C14N / inherited namespaces

At 11:45 5/18/2001 +0100, merlin wrote:
>While it may be true that many apps will not need to move signatures
>from context to context, many may (unwittingly) do so. For example,
>when transporting signed documents over SOAP to remote Web services.

This is definitely an important application scenario.

>I'd also like to establish whether the latter is even possible.

Do you mean via specs, or in your implementation? (Or do you mean your 
implementation doesn't distinguish between the two examples you give and you 
are wondering if others' don't/do?) Regardless, if we expect this to 
interoperate, I think we have to specify the behavior one way or the other 
-- and John seems to be advocating that the desired behavior results from 
the present processing?

>Because if it is not, then the editors' note should recommend that
>signatures _must_ be computed in their final context.

I presume this would be part of the processing in section 3.2.2?
http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-CoreValidation
3.2.2 Signature Validation
1. Obtain the keying information from KeyInfo or from an external source.
2. Obtain the canonical form of the SignatureMethod using the 
CanonicalizationMethod and use the result (and previously obtained KeyInfo) 
to validate the SignatureValue over the SignedInfo element.

<!-- here's some warning text -->
/+Note, if the Signature is not the root element of the document, ancestor 
namespace context, which may change if the Signature is intended to be 
portable (e.g., transported in an XML message), may affect the canonicalized 
form of the SignedInfo and consequently its signature validity. +/

<!-- something more? -->
/+Signatures that are intended to be portable portable signatures 
must/?/should:
1. be processed in their final context. (What exactly is the final context, 
is this equivalent to the document subset with Signature at it's root?)
2. the Signature should be generated in a particular portable form. (Rob's 
solution wasn't general? -- and using the same prefix is rather 
constraining/hackish?)
+/


__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 18 May 2001 13:57:32 UTC