Re: Fwd: Moving exc-c14n forward: your response is needed!

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