RE: Poll on Exclusive Canonicalization

I agree here with Brian. We MUST NOT specify any more mandatory to implement
features at this point.

Everybody working on Signing SOAP/XML Protocol messages is aware of the
problem at this stage.

I am wondering if an alternative solution might be possible as a stopgap.
How about a parameter on the C14N declaration that lists the necessary
namespace information? How about specifying the namespaces as signing
attributes? etc. etc.

There is more than one way to boil an ocean.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Brian LaMacchia [mailto:bal@microsoft.com]
> Sent: Tuesday, June 19, 2001 2:45 AM
> To: Donald E. Eastlake 3rd
> Cc: IETF/W3C XML-DSig WG
> Subject: 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/2001AprJu
n/0089.htm
l
[2] http://www.ietf.org/IESG/Implementations/xmldsig-Implementation