W3C home > Mailing lists > Public > public-xmlsec@w3.org > November 2010

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

From: Pratik Datta <pratik.datta@oracle.com>
Date: Tue, 30 Nov 2010 11:23:13 -0800 (PST)
Message-ID: <aac2be53-d6ab-49a0-8946-b29a32886f56@default>
To: sampo@zxidp.org, Frederick.Hirsch@nokia.com
Cc: Frederick.Hirsch@nokia.com, public-xmlsec@w3.org
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. 

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, 30 November 2010 19:24:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 30 November 2010 19:24:12 GMT