RE: Poll on Exclusive Canonicalization

Don,

[I wrote...]
> >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.

[Don wrote...] 
> The IETF status of this standard is Proposed which says (RFC 2026):
>[RFC 2026 verbiage snipped]

Will all due respect, Don, the passages from RFC 2026 that you have
quoted are unresponsive (and, frankly, irrelevant) to my point.  What I
said was that, speaking as the owner of an implementation of the
standard, I would not be able to ship a new version that includes a new
mandatory-to-implement canonicalization algorithm for 12-18 months.
(For reasons I cite below, I believe that were the WG to choose Option 2
it would have to make the new canonicalization algorithms MUSTs --
mandatory-to-implement.)  I work on development tools, so a 12-18 month
delay means that the *developers* I support cannot write code that
depends on these new mandatory-to-implement algorithms for 12-18 months.
That's a big negative in my book.  Now, I don't expect anyone outside my
company to care about when I can or cannot ship some piece of code, but
such a delay is reason enough alone for me to vote against going with
Option 2.
 
> 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.

True, if it's just a SHOULD then I'm still compliant, but anything other
than a MUST doesn't make sense.  You have argued that there is a
significant flaw in XMLDSIG as specified in RFC 3075, a flaw so serious
that the standard cannot progress further without the flaw being fixed.
If this flaw is so serious that it's a showstopper for XMLDSIG and will
halt the standards process, then that flaw has to be fixed in all
conforming implementations of the standard.  That means the new
canonicalization algorithm must be a MUST.

Think of it this way: you've said that XMLDSIG is not suitable as-is for
use in a protocol, that C14N as specified is incompatible with common
protocol use.  If that's true then how does adopting Option 2 as a
SHOULD or a MAY solve anything?  Protocol designers *still* wouldn't be
able to depend on the Exclusive Canonicalization algorithms because they
would not be mandatory-to-implement, so they would still have to profile
XMLDSIG and explicitly specify the canonicalization algorithms to use in
their protocols.  Option 2 without a MUST doesn't facilitate
interoperable protocols, and facilitating interoperable protocols is the
only reason we're considering Option 2 at this point.
 
> >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.

I'm not convinced it's generally broken for protocol use; it all depends
on the message flow, the design of the messages and how you take
messages apart & reassemble them mid-stream.  SOAP happens to be
exceptionally permissive (in conjunction with XML's scoping rules) in
what it lets intermediate processing nodes do to a message, which for
C14N purposes is a bad thing.

As I point out below, I believe that going with Option 2-MUST will
require recycling at Proposed Standard, thus resetting the six-month
clock and leading to a 6-12 month delay.
 
> >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.

This paragraph is so broken I don't know where to begin:

1) I never "characteriz[ed]...almost all of the protocol uses of XMLDSIG
as some insignificant particular application environment"; please don't
put words in my mouth.  XMLDSIG is a message format specification, not a
protocol specification.  While we expect to build protocols on top of
XMLDSIG, *the general case* that we deal with day in and day out in
XMLDSIG consists of signed message formats.  I stand by my statement
that lack of an Exclusive Canonicalization algorithm has not hampered
interoperability of signed message exchanges.

2) I disagree with your characterization of the intent of
canonicalization algorithm extensibility in the standard.  The WG
specified one mandatory-to-implement canonicalization algorithm to
guarantee that two conformant implementations could interop with each
other.  There is nothing in the standard that says or implies that
alternate canonicalization algorithms should only be used to "do unusual
things".  To the best of my knowledge the WG has never made any
statements or expressed any opinions along these lines.  In fact, until
MinimalCanonicalization was removed we explicitly suggested in the spec
that common cases might work better (e.g. be more performant) using
alternative canonicalization algorithms.

3) Finally, with respect to your comment to the effect that "the few
simple test cases that have been run...[are not] 'the general case'",
you can't have it both ways.  Either the tests that we have run are
sufficient to demonstrate successful interoperability among multiple
implementations or they aren't.  If the test cases do not adequately
capture "the general case" of the Proposed Standard, then they are
insufficient to be used to certify progress to Draft Standard.  

On April 27, 2001, the IETF Secretary announced Last Call for moving
XMLDSIG to Draft Standard [1].  You filed an interoperability report [2]
as part of the WG's request to move from Proposed to Draft, certifying
that at least two independent, interoperable implementations existed for
each feature in the standard.  Your report was based on results reported
by each implementation owner running each of the "simple test cases".
Either the "simple test cases" are sufficient to prove the
interoperability of XMLDSIG or they aren't.  Which is it?
  
> >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".

I disagree.  We are talking about adding a new, mandatory-to-implement
canonicalization algorithm.  At a minimum, that means:
(a) revising RFC 3076 (which is where the new algorithm should be
defined), 
(b) modifying RFC 3075 to specify a new mandatory-to-implement
canonicalization algorithm,
(c) getting two independent, interoperable implementations that can be
used to test the new canonicalization algorithm with each and every
other feature in XMLDSIG,
(d) doing the additional interop testing. (Because you're adding a new
canonicalization algorithm, that doubles the testing state space.  If
you want both with- and without-comments, that triples the test
matrix.),
(e) and filing a new interop report with the IESG
Don't you think the IESG would view a change this fundamental to core
XMLDSIG processing as at least a "significant revision" requiring
recycling at Proposed (RFC 2026, Section 6.2)?

And, of course, to top it all off, at the end of all of this additional
process we might *still* not have a good enough solution to the problem
you're trying to solve, as John Boyer has recently pointed out.
 
In closing, note that I'm not saying we shouldn't try to fix the problem
you've identified, but I strongly disagree with your proposed approach.
The WG should finish XMLDSIG 1.0 and then move on to additional
canonicalization algorithms and whatever else is needed to support
XML-based protocols in a more friendly fashion.

					--bal

[1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0089.htm
l
[2] http://www.ietf.org/IESG/Implementations/xmldsig-Implementation

Received on Tuesday, 19 June 2001 03:06:47 UTC