[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]