signature portability / C14N / inherited namespaces

Hi,

I've been running into some issues with XMLDSIG (specifically, portability
of signatures) which make it difficult to use in a few situations.

XPath states that an element's namespace axis includes all non-overridden
namespace declarations from all ancestors. C14N then states that we
must write these out during canonicalization, whether or not they are
used. This means, as we know, that signatures cannot be successfully
moved into documents which have other namespaces in force.

I have an application that generates signed contracts:

<Contract xmlns="&foo;">
  ...
  <Signature xmlns="&dsig;">
    ...
  </Signature>
</Contract>

I then ship the contract off for remote processing:

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  ...
  <SOAP-ENV:Body>
    <Contract>
      ...
    </Contract>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The contract signature is now invalid.

The signer has no knowledge of the enveloping that will be used during
transport, if any, so it can't generate a signature that will be valid
in this context.

According to XPath and (I think) the XML info set, when the recipient
reads in this SOAP document, every element will receive a namespace axis
consisting of all inherited namespace attributes.

So, my fundamental question is: Is it sufficient for me to de-parent the
Contract in DOM for it to lose these inherited namespaces? In practice,
it is (using one particular parser). It is not clear to me whether this
is strictly correct according to all the relevant specs.

Even if it is sufficient for me to do this, is it acceptable that the XML
document on the wire isn't signatorially valid, and that the recipient
must know where to deparent the document for things to become valid?

I think that this might be worth a paragraph in the spec because I believe
it will be a common problem as XMLDSIG becomes more widely adopted.

Merlin


-----------------------------------------------------------------------------
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 Wednesday, 16 May 2001 08:56:56 UTC