Re: Objection to dead list and Fwd: EXC-XML-C14N ambiguity in processing InclusiveNamespaces PrefixList with undefined prefix

<Frederick.Hirsch@nokia.com> said:

> Sampo, 

> 

> The WG also considered your concerns and agreed [1] to add the following errata for  "Exclusive XML Canonicalization Version 1.0" [2] to the "Errata of the Exclusive Canonicalization Version 1.0 Specification" [3]:

> 

> [[

> 

> E08 2010-11-30 (Clarification)

> 

> In section 3. Specification of Exclusive XML Canonicalization, rule 2 needs to be read to require ignoring prefixes that are never encountered during the processing of the node set, rather than treating them as errors or attempting to output them in some way. It should read:

> 

> 	The Exclusive XML Canonicalization method may receive an additional, possibly null, parameter InclusiveNamespaces PrefixList containing a list of namespace prefixes and/or a token indicating the presence of the default namespace. All namespace nodes whose prefixes appear on this list are handled as provided in Canonical XML [XML-C14N]. If prefixes appear on this list but are not encountered in the course of processing the node set, they are ignored.

> 

> ]]

> 

> This should address your concern. Please indicate if you agree by 3 January 2011. If we don't hear from you by then we shall assume your agreement.

> 



This indeed addresses my concern (clarity, even if not the solution I proposed).



Thanks

--Sampo



> Thanks!

> 

> regards, Frederick

> 

> Frederick Hirsch, Nokia

> Chair XML Security WG

> 

> [1] http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/att-0043/minutes-2010-12-07.html#item10

> 

> [2] http://www.w3.org/TR/xml-exc-c14n/

> 

> [3] http://www.w3.org/2002/07/xml-exc-c14n-errata

> 

> For tracker, this should complete ACTION-731

> 

> On Dec 5, 2010, at 2:04 PM, ext sampo@zxidp.org wrote:

> 

> > Pratik Datta <pratik.datta@oracle.com> said:

> >> Sampo,

> >> 

> >> There are some interop examples that may clarify this

> >> See http://www.w3.org/Signature/2002/02/01-exc-c14n-interop.html

> >> Open up the Y4 test vector.

> >> 

> >> The Y4 test vector does not illustrate the exact issue that you are mentioning, but it general it shows that missing / undefined prefixes are perfectly fine. 

> >> 

> > 

> > Thanks. This helps.

> > 

> > Was it somehow findable from the spec web page? An open spec should publicize such

> > test vectors if they are required for correct understanding of the spec.

> > 

> > Cheers,

> > --Sampo

> > 

> >> Pratik

> >> -----Original Message-----

> >> From: sampo@zxidp.org [mailto:sampo@zxidp.org] 

> >> Sent: Thursday, November 25, 2010 11:09 AM

> >> To: Frederick.Hirsch@nokia.com

> >> Cc: sampo@zxidp.org; Frederick.Hirsch@nokia.com; public-xmlsec@w3.org

> >> Subject: Re: Objection to dead list and Fwd: EXC-XML-C14N ambiguity in processing InclusiveNamespaces PrefixList with undefined prefix

> >> 

> >> <Frederick.Hirsch@nokia.com> said:

> >> 

> >>> Sampo

> >> 

> >>> 

> >> 

> >>> The XML Security WG considered the concern you noted regarding Exclusive Canonicalization at our last teleconference on 16 November 2010 [1]  and decided that no change is needed. 

> >> 

> >>> 

> >> 

> >>> The rationale is that if an unknown prefix were to be provided in the prefix list it would have no impact as it would not have any match during the algorithm processing, and thus could safely be ignored.

> >> 

> >>> Thus there is no need for special language to handle this case. 

> >> 

> >> 

> >> 

> >> Refusal to clarify this in any way, essentially communicates that you are not concerned

> >> 

> >> by the interoperability difficulties that the hard to understand specification creates.

> >> 

> >> A spec that requires insider knowledge to interpret correctly is not an open specification

> >> 

> >> because someone who is not in the select group of insiders can not create an interoperable

> >> 

> >> implementation. Good to know the stance of the WG.

> >> 

> >> 

> >> 

> >> Is the decision in minutes? Are they publicly accessible? Could the minutes be linked from

> >> 

> >> the errata page?

> >> 

> >> 

> >> 

> >> --Sampo

> >> 

> >> 

> >> 

> >>> Regarding the mailing list, we are investigating whether it can have its traffic forwarded to our currently active mailing list ( which is on the cc list of this email).

> >> 

> >>> 

> >> 

> >>> regards, Frederick

> >> 

> >>> 

> >> 

> >>> Frederick Hirsch, Nokia

> >> 

> >>> Chair XML Security WG

> >> 

> >>> 

> >> 

> >>> [1] http://lists.w3.org/Archives/Public/public-xmlsec/2010Nov/att-0020/minutes-2010-11-16.html#item12

> >> 

> >>> 

> >> 

> >>> For tracker, this should close ACTION-731

> >> 

> >>> 

> >> 

> >>> 

> >> 

> >>> On Nov 13, 2010, at 2:36 PM, ext sampo@zxidp.org wrote:

> >> 

> >>> 

> >> 

> >>>> This mail is to forward a mail submitted to w3c-ietf-xmldsig@w3.org (as directed on

> >> 

> >>>> 

> >> 

> >>>> page http://www.w3.org/2002/07/xml-exc-c14n-errata)

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2010OctDec/0000.html

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> I have learned from a friendly source that the said mailing list is "dead".

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> I find it quite disturbing that specifications and errata mention as the official reporting

> >> 

> >>>> 

> >> 

> >>>> mechanism a mailing list that is "dead" or not monitored by any human. You can hardly

> >> 

> >>>> 

> >> 

> >>>> claim a transparent and open standards process if such dead mailing lists exist so that

> >> 

> >>>> 

> >> 

> >>>> all comments go to /dev/null. Is the intent not to receive any comments?

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> I reproduce here the original mail:

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> The specification [XML-EXC-C14N] does not state how a namespace prefix, not

> >> 

> >>>> 

> >> 

> >>>> defined earlier in the document, should be processed. Section 3, bullet 2

> >> 

> >>>> 

> >> 

> >>>> does not help much as it seems to assume input where the prefixes are

> >> 

> >>>> 

> >> 

> >>>> always well defined. Similarily section 3.1 bullet 3.2.1 seems to assume

> >> 

> >>>> 

> >> 

> >>>> that all prefixes in the PrefixList are well defined.

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> My interpretation is that the undefined prefixes are errors that should

> >> 

> >>>> 

> >> 

> >>>> cause digital signature to be rejected. However I have been challenged

> >> 

> >>>> 

> >> 

> >>>> by some vendors on the market, claiming that their signatures with

> >> 

> >>>> 

> >> 

> >>>> undefined prefixes in InclusiveNamespaces PrefixList are indeed valid

> >> 

> >>>> 

> >> 

> >>>> as the specification does not expressly forbid such undefined

> >> 

> >>>> 

> >> 

> >>>> prefixes.

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> I think the specifications should be more clear on this issue. I would

> >> 

> >>>> 

> >> 

> >>>> hope for errata to be released to clarify this.

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> [XML-EXC-C14N] John Boyer, Donald E. Eastlake 3rd, Joseph Reagle: "Exclusive

> >> 

> >>>> 

> >> 

> >>>> XML Canonicalization Version 1.0", W3C Recommendation 18 July 2002,

> >> 

> >>>> 

> >> 

> >>>> http://www.w3.org/TR/xml-exc-c14n/

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> --Sampo

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>>> 

> >> 

> >>> 

> >> 

> >>> 

> >> 

> >> 

> 

>

Received on Tuesday, 14 December 2010 01:45:14 UTC