[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Proposed text on C14N
r/rsalz@datapower.com/2003.08.28/20:52:23
>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 (hope I) did not say that exclusive is *weaker*, I (hope I)
said that inclusive is *safer*. That is to say, it is easy
to make subtle mistakes with exclusive c14n; not so with
inclusive. Inclusive is, on the other hand, more sensitive to
context changes. However, such changes will only ever result
in a good signature failing to validate. Exclusive has the much
more dangerous ability to successfully validate bad signatures;
e.g., if I sign "I owe you 1000 oz:Dollars" but do not include
the prefix oz on the inclusive namespace prefix list, you can
then change the binding of xmlns:oz to http://www.treas.gov/,
hand this off to a bank and the signature will validate.
>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.
I disagree with your characterization of this as an example
of what exc-c14n is designed for. Exc-c14n is for securing
items and *then* placing them into new XML documents. We
are placing items into XML documents and *then* securing,
for which inclusive is safer, in that it does not need the
close coupling of application to security module.
Judicious avoidance of QNames is not sufficient, and not
possible. We make extensive use of QNames in the WSSE spec,
and namespace prefixes may also be used by text content, such
as the XPath and XPath 2.0 transforms. We cannot reasonably
ask all users of WSSE to avoid this; it is standard (and good)
XML practice.
Finally, exc-c14n is not immune to the namespace inheritance
problem. Consider signing this with exc-c14n, including the
foo prefix in the unsuppressed namespace prefix list.
<Body>
<ToBeSigned wsu:Id="tbs">
<Data xmlns:foo="urn:foo" Something="foo:Bar />
</ToBeSigned>
</Body>
If an intermediary introduces the use of this namespace
prefix in an ancestor, then the signature will break because
xmlns:foo will be canonicalized with the ToBeSigned element
instead of the Data element.
Security-aware intermediaries MUST be aware of the dangers
of introducing new ancestor context into signed documents and
MUST consequently avoid this practice. This can be easily
effected by simply restricting any changes they make to SOAP
headers directed at them.
Merlin
-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorised use, disclosure, copying or alteration of this message is
strictly forbidden. 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.
This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]