[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Proposed text on C14N
> 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
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]