Re: Problem with canonical form?

----- Original Message -----
From: "Joseph M. Reagle Jr." <reagle@w3.org>

> I'm actually not sure I understand your example without the portions of
XML,
> but it sounds like an issue discussed before. The following text was
agreed
> to in the specification to address it:


The issue I'm discussing has nothing to do with XSLT (or any other
transform), it's instead an issue with documents that are used for the
interpretation, specifically documents that are internal to the meaning of
the document, but external to the signature. I think the alternative example
given was far better, and much more likely. A seller maintains 2 namespace
documents, housed at the same URI, and the decision to show one or the other
is based on criteria outside of the document itself (e.g. whether or not the
request comes from the courts). The two documents are identical except that
every occurance of Lira (sp?) is replaced by US Dollar, the result is that
the customer sees a slightly lower than it should be price identified as
Lira (say 80% of what the price should be), when billed the billing occurs
in US Dollars, but the number remains the same (in court the seller presents
the US Dollar namespace document), the result is that the customer is billed
~2000 times what should have been billed
(http://finance.yahoo.com/m5?a=1&s=USD&t=ITL). Admittedly this conversion
should never occur, the signed document should express the amount in the
local currency, but foreign currency sales are not going away any time soon.
This is a path a less than ethical person could take to achieve court
ordered fraud debt collection.


>
> As Phill points out, Canonical XML provides a serialization of a XML node
> set, that's it. If you have concerns about other references, that is an
> application issue as Donald points out. (Consider a weird screw case where
> some applications might *wish* to make a statement about a URI with
dynamic
> content.)

That's an entirely different case than what is being discussed, making a
statement about a URI makes statements about an external document, this is a
discussion of internal documents that are, because of an omission in the
spec, external to the signature.

> Otherwise, if you want these things to be signed, then sign them
> in the Signature or package them together in some such archive.

This is a fraud waiting to happen, that is my issue, plain and simple. If
the rest of the spec made this fraud difficult to pull off, the benefits
extremely low, or easy to detect, I would have no issue. However the rest of
the document does not inhibit the commission of this fraud, does not limit
the magnitude of the benefits, and makes detection more difficult because
people are less likely to examine documents once signed. There are documents
that are implicitly signed, but which have no inclusion in the signature,
this is a classic mistake, this is the same type of mistake that made the
original PKCS 1 insecure the main difference is that it is far easier to
perform the switch in our format.
                            Joe

Received on Monday, 8 January 2001 18:09:12 UTC