- From: Joseph Reagle <reagle@w3.org>
- Date: Fri, 19 Apr 2002 18:12:19 -0400
- To: Misha.Wolf@reuters.com, duerst@w3.org, Philippe Le Hegaret <plh@w3.org>
- Cc: w3c-i18n-wg@w3.org, w3c-ietf-xmldsig@w3.org, xml-dist-app@w3.org
On Friday 19 April 2002 15:07, Misha.Wolf@reuters.com wrote: > Martin: Ask for a health warning re problem with Exclusive > Canonicalization, where xml:lang and perhaps namespaces get > ignored when signing a payload. Thank you for raising this issue. It gives me an opportunity to be clear about our present state on this issue. Martin and I did talk about this issue a few months ago when he was in Boston. Also, Philippe raised this question with respect to xml:base when we were entering CR. However, I don't recall any specific action or text resulting from that conversation with Martin beyond what the present text states (see below). However, I do remember the salient point of conversation. Take the following example of a soap envelope contain an svg element and signature over it: <env:Envelope xml:lang="english" xml:space="preserve" xmlns:env="...soap..."/> <env:Header>...</env:Header> <env:body> <svg>...<svg> <Signature> </env:body> </env:Envelope> Do namespace nodes and xml:* attributes pose the same sort of problems? For namespace nodes, they are nuisance and a problem. Under c14n the env: declarations aren't even needed (nuisance) in the svg element, yet they are there and contaminate the SVG such that if it is signed in context and then removed from the SOAP header and the signature is recalculated (and canonicalized outside of the envelope) it won't be able to validate. exc-c14n removes this problem. For the xml:{lang, space, and base} one can argue that they are less of a nuisance, but still pose a problem. While the env: namspace nodes in the canonical form of the svg are completely un-needed, one can argue that the SVG element should be also be considered to be in English and have important white space. Or that a relative URI in the SVG is dependent on the xml:base in the soap Envelope. However, if an application removes the SVG and acts on it as such, it wouldn't be useful anyway. (I don't know if or how SOAP defines the detachment of a payload for processing...?) Regardless, I'd expect that if the detachable SVG is to be useful when detached, it will already have its own xml:* attributes. And if it does, the canonical form in or out of the soap envelope will be the same. It's definitely a tricky issue and we explicitly solicited feedback on these points in our CR [1], but haven't had any push-back, so I hope folks are largely satisfied and the text is clear [2]. [1] http://www.w3.org/TR/2002/CR-xml-exc-c14n-20020212 Specific areas where we would appreciate further implementation experience are: 1. Speed of canonicalziation relative to Canonical XML; it should be no slower, is it faster? 2. Use in application contexts. Does the specified behaviour meet application requirements for flexibly canonicalizing document subsets if they are moved out of their context? For example, does your application scenario lead to any difficulties in which a subset (e.g., payload) require the use of an ancestor base that is not easily remedied by including xml:base in the apex of the subset? [2] http://www.w3.org/Signature/Drafts/xml-exc-c14n#sec-Limitations 1.3 Limitations Exclusive XML Canonicalization has the limitations of Canonical XML [XML-C14N] plus two additional limitations as follows: 1. The XML being canonicalized may depend on the effect of xml namespace attributes, such as xml:lang, xml:space, and xml:base appearing in ancestor nodes. To avoid problems due to the non-importation of such attributes into an enveloped document subset, either they must be explicitly given in the apex nodes of the XML document subset being canonicalized or they must always be declared with an equivalent value in every context in which the XML document subset will be interpreted. 2. Applications that use the XML being canonicalized may depend on the effect of XML namespace declarations where the namespace prefix being bound is not visibly utilized. An example would be an attribute whose value is an XPath expression and whose evaluation therefore depends upon namespace prefixes referenced in the expression. Or, an attribute value might be considered a QName [XML-Schema] by some applications, but it is only a string-value to XPath: <number xsi:type="xsd:decimal">10.09</number>. To avoid problems with such namespace declarations, + the XML must be modified so that use of the namespace prefix involved is visible or + the namespace declarations must appear and be bound to the same values in every context in which the XML will be interpreted or + the prefixes for such namespaces must appear in the InclusiveNamespaces PrefixList. http://www.w3.org/Signature/Drafts/xml-exc-c14n#sec-Considerations 5. Security Considerations This specification is used to serialize an XPath nodeset under certain assumptions given in [XML-C14N] and this specification. For example, implementations of [XML-C14N] do not render a document XML declaration; when implementations of this specification serialize a subset they do not render ancestor attributes from the "xml:" namespace (e.g., xml:lang, xml:space, and xml:base). Nor do implementations of this specification consider the appearence of a namespace prefix within an attribute value to be visibly utilized. While we feel such choices are consistent with other XML specifications and satisfy our application requirements it is important that an XML application carefully construct its transforms such that the result is meaningful and unambigous in its application context. The Limitations of this specification, the Resolutions of [XML-C14N], and the Security Considerations of [XML-DSig] should be carefully attended to. 5.1 "Esoteric" Nodesets Consider an application that might use this specification or [XML-C14N] to serialize a single attribute node. Neither specification will automatically emit a namespace declaration for that single attribute node. Consequently, a "carefully constructed" transform should create a nodeset containing the attribute and the relevant namespace declaration for serialization. We provide this example to caution that as one moves beyond well-formed [XML] and then well-balanced XML [XML-Fragment], it becomes increasingly difficult to create a result that "is meaningful and unambiguous in its application context."
Received on Friday, 19 April 2002 18:12:27 UTC