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

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. 

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 Friday, 19 November 2010 20:49:25 UTC