Re: Poll on Exclusive Canonicalization

Hi Brian,

Continuing as an advocate of the proposal...

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 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.)
>
>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.

The IETF status of this standard is Proposed which says (RFC 2026):

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

Presumably one of the reasons for the mandatory six month wait between
Proposed and Draft levels of IETF standards is to find problems like
this which may not be immediately apparent. The same RFC says of Draft
standards:

   A Draft Standard is normally considered to be a final specification,
   and changes are likely to be made only to solve specific problems
   encountered.  In most circumstances, it is reasonable for vendors to
   deploy implementations of Draft Standards into a disruption sensitive
   environment.

In any case, if Option 2 is adopted with RECOMMENDED and the proposal
tweaked to be consistent therewith, you would still be conformant to
the standard.

>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.

I don't think something along the lines of the proposed change will
delay widespread adoption. Certainly I think it will delay it less
than XMLDSIG being generally broken for protocol use and requiring
special profiling and patching to get each protocol use to work.

>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.

I disagree completely with your characterization of the few simple
test cases that have been run as being "the general case" and your
characterization of almost all of the protocol uses of XMLDSIG as some
insignificant particular application environment. The ability to
specify alternate canonicalization algorithms is indeed there to allow
people to do unusual things. It was never intended that a special
custom canonicalization algorithm would have to be crafted for each
protocol use of XMLDSIG.

>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.

As far as I can tell, we are talking, at worst, about resetting the
last call clock, a matter of a few weeks, not "resetting the standard
clock".

>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 agree with your statement above. I don't think it has much bearing
on the desireability of fixing XMLDSIG to work in the protocol
environment without special profiling except in truly unusual cases.
SOAP is really a simple instance and it is ominous that, with the
current specification, the problem becomes immediately apparent there.

>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.

There is no proposal for significant delay. If everyone working on
uses of XMLDSIG in the protocol space is having namespace propagation
problems, including you guys, we should fix it.

>					--bal

Donald

Received on Monday, 18 June 2001 15:50:44 UTC