Re: Poll on Exclusive Canonicalization

Hi,

Apologies for being post-deadline.

I have qualms about pushing XMLDSIG out the door without protocol support
(exclusive c14n) because this will have a major impact on many dependent
standard efforts, and they may wind up with various uncomfortable
workarounds.

I also have significant qualms about delaying XMLDSIG because this will
have a major impact on many dependent standard efforts.

Iff we can define, implement and interop an exclusive c14n that addresses
basic protocol needs (noninheritance of namespaces and xml:* attributes)
to the satisfaction of, for example, XKMS over SOAP, and this will not
significantly delay the standards processes, then I would vote for 2.

If there will be any significant process delays then I would vote for 1.

I do not claim a sufficient understanding of the relevant processes
to know whether a significant delay would occur. For reference, an
offhand implementation of an exclusive C14N took all of 15 minutes,
so I am not particularly concerned about implementation delays.

And, as a sidenote, I dislike the URIs &c14n;, &c14n;#WithComments,
&c14n;#XXX, &c14n;#XXX-WithComments. IMO, it is a nasty misuse of
the URI. I would advocate exclusivity being specified by including an
Exclusive (or whatever) child element which can contain any desired
parameters.

Merlin

r/reagle@w3.org/2001.06.14/16:27:05
>
>Members of the WG (and particularly implementors represented in the interop 
>matrix), it's important that we know which direction you would like us to 
>take. So please respond, on the list, to the following poll by end of Monday 
>June 18th.
>
>With respect to the issue of excluding ancestor context from the canonical 
>form of a signature[1], the WG should pursue option:
>
>1. Specify the exclusive canonicalization as part of the non-normative (nor 
>required to implement) dsig-more specification [2].
>2.Specify the exclusive canonicalization as part of the normative 
>xmldsig-core  as proposed in [3] (but with the URIs of [4]) as [REQUIRED, 
>RECOMMENDED, OPTIONAL]. (This option requires interoperable implementation 
>of this feature before xmldsig advances.)
>
>Donald & Joseph
>
>[1] 
>http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-NamespaceCon
>text
>[2] http://www.w3.org/2001/04/xmldsig-more
>[3] 
>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/att-0293/01-si
>gport.html
>[4] http://www.w3.org/2000/09/xmldsig#excC14N
>      http://www.w3.org/2000/09/xmldsig#excC14N-WithComments
>
>--
>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
>

Received on Wednesday, 20 June 2001 13:19:27 UTC