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 Sunday, 21 April 2002 20:50:10 UTC