RE: Comments on last call draft (BRAVO Kent!!!)

>I think Kent is arguing that from an implementor's point
>of view, requiring minimal canonicalization is a real pain
>not because minimal canonicalization is hard to implement,
>...

The issue is not whether one scheme or the other is hard to
implement but that the placement of the signature checking
module needs to be different for the two schemes.

If one places the signature checker after having reduced the
text to an XML parse tree then one can only support fully
c14n messages. That is undesirable from a security point of 
view since c14n is a substantially more complex transformation
than cryptography people are generally happy with. Without a
comprehensive formal analysis of the potential substitution
attacks it would take a very long time to gain confidence in
the spec.


It is however quite possible to resolve the conflicting 
constraints, it is difficult to explain how to do this in 
ASCII however.


Briefly, one needs to code the XML parser with separate FSR
and parse tree building modules (a good idea in any case).
The initial FSR module needs to have a switch to divert code
through a hash algorithm when required. The switch needs to be
activated by the signature verifier at the appropriate point.

It is quite easy to write an integrated parsing / signature
verification module in C on this structure without the use of 
any global variables. XML was designed to be very easy to 
write parse tools for.


Alternatively if one is perfoming DOM style all in one go 
parsing then one can reasonably expect to have the entire
input text available when performing the parse, supporting
verification is then a simple matter of making an index of the
position of the current lexeme within the input text avaliable
to the parser.


	Phill