RE: [wss] Proposed text on C14N

[Rich Salz <rsalz@datapower.com>]

> but why should
> we require canonicalization that adds any xmlns attributes to the XML being
> signed?

Suppose you have this document, where (via out of band or DTD) we know that
ID is an ID attribute:
    <outer xmlns:i="urn:foo.com">
        <a:inner xmlns:a="urn:a">
            <i:innermost ID="foo">foo</i:innermost>
        </a:innert>
    </outer>

XML DSIG lets you sign
        <dsig:Reference uri="foo">...
In order to perperly sign the innermost element, you *have* to import
the xmlns:i attribute from the outer element.  XML C14N was developed
to let you sign a subset of a document; without it, the following
would verify against the original signature, and that's clearly wrong:
    <outer xmlns:i="urn:foo.com">
        <a:inner xmlns:a="urn:a" xmlns:i="urn:i">
            <i:innermost ID="foo">foo</i:innermost>
        </a:innert>
    </outer>

Contrary to what someone else posted (name escapes me), I strongly believe
that exc-c14n is *not* weaker htan xml-c14n.  It *can* be more inconvenient,
and can require close integration with the application, if the XML being
treated uses QNAMES as attribute values or element context.

I believe we should recommend EXC-C14N.  It's designed to handle the
case of xml being wrapped, which is what we're talking about here -- XML
document being put inside a SOAP message, and being secured.  Its problems
can be avoided by judicious avoidance of QNAMES as data; that is generally
something the application can address.  If we expect most SOAP and WS-Security
libraries to be generic toolkits, as opposed to custom applications written
by application developers, then we cannot expect them to have such fine-grain
control over the namespace declarations used by the SOAP framework, and
therefore XML-c14n will not be viable.

>In your last paragraph you raise an interesting point - is it unique to
>SOAP signing?

No.  There are a whole passle of issues involved in embedding XML in
XML (such as character encoding, DTD's [conveniently disallowed by
SOAP], conflicting ID/IDREF attributes), but that is really an XML
problem; SOAP can address it by using attachments, where the SOAP
body is a referrent, as imposed to inline.

        /r$
--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html