- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 22 Apr 2002 13:38:05 -0700
- To: "Martin Duerst" <duerst@w3.org>, <reagle@w3.org>, <Misha.Wolf@reuters.com>, "Philippe Le Hegaret" <plh@w3.org>
- Cc: <w3c-i18n-wg@w3.org>, <w3c-ietf-xmldsig@w3.org>, <xml-dist-app@w3.org>
> ... the question is whether > xml:base="" means 'the current document is the base' or it means > 'don't change the base you have', or it is undefined. xml:base="" means don't change the base you have. An empty string is treated as any other relative URI. > -----Original Message----- > From: Martin Duerst [mailto:duerst@w3.org] > Sent: Sunday, April 21, 2002 5:30 PM > To: reagle@w3.org; Misha.Wolf@reuters.com; Philippe Le Hegaret; Jonathan > Marsh > Cc: w3c-i18n-wg@w3.org; w3c-ietf-xmldsig@w3.org; xml-dist-app@w3.org > Subject: Re: Fwd: Moving exc-c14n forward: your response is needed! > > Hello Joseph, > > Many thanks for your excellent summary. Just a few comments below: > > [Jonathan, there is some question about XML Base where maybe you > can help.] > > At 18:12 02/04/19 -0400, Joseph Reagle wrote: > >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" > > Should be xml:lang="en", just for the record. > > > > 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, > > Yes, there is only one of each, and they don't have prefixes hidden > in attributes and text content. > > > >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 > > Or some other language. > > >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. > > There is one specific problem with xml:lang, which is the following: > > If the SVG document to be included has no language information, it > is impossible to note that in the top SVG element or just outside. > We had some preliminary discussion on how to fix this problem; the > proposal that has received most support in the I18N WG/IG is to use > xml:lang="". > > In some specific cases, there is a similar problem with namespaces. > For xml:space, there should not be any such problem, because there > is a default, which can be made explicit. For xml:base, I don't know > if there is such a problem or not. I.e. the question is whether > xml:base="" means 'the current document is the base' or it means > 'don't change the base you have', or it is undefined. > > > >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. > > I think this covers my action from the I18N WG minutes: > > Martin: Ask for a health warning re problem with Exclusive > Canonicalization, where xml:lang and perhaps namespaces get ignored when > signing a payload. > > If somebody disagrees, please tell me. > > > > 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] > > I don't think you should cite XML-Schema, but XML-Namespaces > (http://www.w3.org/TR/REC-xml-names/#NT-QName). In the example > below, XML-Schema is only one example of an application using > QNames, nothing special. But with the reference above, it can > easily be read differently. > > > >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 > > I'm not very happy here; this can be read as "it's okay to remove > xml:lang". I think the explanation that XML-C14N and exclusive > canonicalization provide two extremes, and the application > designer has to chose the right mix, would be better. > > > > 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." > > > Regards, Martin.
Received on Monday, 22 April 2002 16:38:30 UTC