OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] Proposed text on C14N


At 05:52 PM 8/28/2003, Rich Salz wrote:
> 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>

Why is that wrong. What does "proper signing" mean?

If
<i:innermost ID="foo">foo</i:innermost>
is signed, then we can verify that the holder of the key saw that element. What the application does with that information is up to the application. The application might not care about the tag, but only about the text("foo"). If the application cares about the tag, then the original message should have contained

      <i:innermost xmlns:i="foo.com" ID="foo">foo</i:innermost>

and that should have been signed.

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]