W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

RE: Poll on Exclusive Canonicalization

From: Brian LaMacchia <bal@microsoft.com>
Date: Mon, 18 Jun 2001 10:30:31 -0700
Message-ID: <BCDB2C3F59F5744EBE37C715D66E779CEAB717@red-msg-04.redmond.corp.microsoft.com>
To: "Joseph M. Reagle Jr." <reagle@w3.org>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Cc: "Donald Eastlake" <dee3@torque.pothole.com>, <lde008@dma.isg.mot.com>
>With respect to the issue of excluding ancestor context from the
>form of a signature[1], the WG should pursue option:
>1. Specify the exclusive canonicalization as part of the non-normative
>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
>RECOMMENDED, OPTIONAL]. (This option requires interoperable
>of this feature before xmldsig advances.)

I vote for Option 1 for the following reasons:

1) First, the purely pragmatic reason: I have an implementation that is
compliant with the current spec that will be shipping in multiple
products over the next several months, and we are beyond the point where
I can add any new features to that implementation.  If the WG goes with
Option 2 it will be at least 12-18 months before I can ship an update to
our software and field an Option 2-compliant implementation.

2) Related to (1), I fear that a major change in the spec like going
with Option 2 will seriously delay widespread adoption of XMLDSIG.  If
adoption of this standard is delayed by even 6-12 months then that's
going to have a cascade effect on everything that depends on it.

3) We have already demonstrated interoperability among multiple
implementations with the current spec.  Lack of the additional
canonicalization algorithm has not hindered interoperability *in the
general case*.  Yes, there are particular application environments where
the default canonicalization algorithm isn't necessarily what you want,
but that's why we allow individual implementations to specify alternate
canonicalization algorithms.

4) I see no reason why, upon completion of the standardization process
for XMLDSIG 1.0, this WG cannot immediately turn around and specify a
1.1 version with additional mandatory-to-implement algorithms.  This
would seem to me to be much more reasonable than to reset the standard
clock on XMLDSIG 1.0.

5) Similarly, there's no reason why a signature standard for a
particular application (e.g. SOAP) cannont profile XMLDSIG and specify
their own canonicalization algorithm or the substitution of another
canonicalization algorithm for C14N.  This happens all the time (S/MIME
did it with CMS and PKIX, for example).  It would certainly be
reasonable for a particular application-specific profile to say, "For
our signatures, you have to use Exclusive Canonicalization." 

I completely understand why folks want a specification for Exclusive
Canonicalization that is widely supported and deployed.  We have run
into problems ourselves related to namespace propagation.  However, the
fact that such problems exist in some appliation contexts is no reason
to significantly delay a foundational standard for all contexts.

Received on Monday, 18 June 2001 14:07:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC