RE: XML and canonicalization

We have been over this many times.

The ability to reconstruct signatures after a document has been parsed and
regenerated was a dreadfull idea for ASN.1 leading to the mistake of DER.
But for DER, ASN.1 would probably have never gained the reputation it has.

This canonicalization algorithm you keep touting is exactly the type of
baroque SGML boondogle that made invention of XML necessary in the first
place.


The chances of the canonicalization algorithm being generally implemented 
well enough to be relied upon and actually used for the purpose of parsing
datastructures into databases and reconstructing them are zero. People had
difficulty with PKCS#12 which is many orders of magnitude simpler. The fact
that there is an argument going on on this list as to what the c14n form
would be is a case in point.


The processing overhead required to reassemble the attributes in order is
significant, particularly when the object in question is a complex data 
structure generated from an XML schema, possibly incorporating several Mb
of internal attributes.

Systems are already being built based on the PKCS#7 detached signature
format. If you insist on re-opening this issue yet again those systems
will cease to be prototypes and be embedded production systems by the
time the specification is complete.

Needless to say the chances of someone taking a working production system
and then introducing an unnecessary transformation to sort all the XML
attributes into alphabetical order before verifying a signature is small.


If you really MUST support the functionality proposed, canonicalization 
(which has a well defined meaning in computer science) is NOT the way
to achieve it.

Instead of canonicalization, specify a syntax constraint. This might 
state for example that the signed octets presented were presented with
null space eliminated, tags fully epanded and attributes sorted into
alphabetical order.

The only functional difference between this approach and the one you 
propose is that the signature on the syntax constrained text would fail
if it were to be passed through this 'noisy channel' that you keep
claiming exists (although I have never known a noisy channel 
gratuitously re-order bytes).

On the processing side such a syntax constraint would require minimal
code, a few lines to check that each attribute was presented in order,
no unexpected whitespace appearing etc.


A syntax constraint is acceptable, a c14n requirement is not.


If we continue to keep re-opening this issue I don't think consensus 
will be reached. Worse still, I predict that as with ASN.1 in PKIX 
there will be a steady stream of attempts to re-open the syntax issue
and 'simplify', generally leading to entirely different syntaxes.


		Phill

Received on Monday, 25 October 1999 11:13:49 UTC