RE: Problem with canonical form?

I don't think that a viable goal in a working group is to prevent people
from shooting themselves in the foot.

The spec says very clearly that you can trust only what is signed. If there
is a reference to another object the application must work out the degree to
which the referenced object is trustworthy.


There are two types of reference in XML

1) Semantics attached to the Signifier
	In this case the URI reference alone specifies the semantics. It is
not necessary to derefference the URI to understand the semantics. An
example of this type is a URN that specifies an ISBN or a bar code. It is
not necessary to get the can of beans to know that a can of beans is being
referred to (a prize for the first person to work out how to sign a can of
beans using RSA).

2) Semantics attached to the Signified
	In this case the reference itself is simply a method of obtaining a
piece of data. For example the target of an <IMG> tag.

In case (2) it is clearly desirable to authenticate the referenced data. In
case (1) the referenced data is not the issue and may not even be a digital
document.


The purpose of the Canonical XML document is not to describe what is known
in the formal methods literature as a canonical form, it does not guarantee
that all documents with the same semantics have the same syntactic
representation.

What Canonical XML actually does is to define a unique encoding of a typical
XML parse tree. This allows an XML Signature implementation to act on the
parsed representation rather than the actual encoding. But there are many
semantically equivalent parse trees that have different encodings. An
implementation could for example automatically unify all the namespace
prefixes since an application does not care whether it is s0:Signature or
xyz83759:Signature.


Canonicalization is not intended to provide additional security. It is
simply a protection against certain syntax transformations which may occur
during message processing.

Using XML Signature is not a substitute for a comprehensive security
evaluation of a protocol. The security implications of every transformation
have to be considered. If the signed object is f(x) the f(x) is what is
trustworthy. Applications have no business trusting x and a security aware
program design would ensure that the program modules requiring security
sensitive processing would ONLY see f(x) and be entirely unable to access x.

	Phill



> -----Original Message-----
> From: Joseph Ashwood [mailto:jashwood@arcot.com]
> Sent: Friday, January 05, 2001 5:39 PM
> To: w3c-ietf-xmldsig@w3.org
> Subject: Problem with canonical form?
> 
> 
> I've found a security risk in canonical XML that I believe needs to be
> covered. Simply stated through example (with probably large 
> portions of xml
> left out):
> 
> ...
> <... namespace declaration...>
> <agreement>I agree to pay the amount(s) shown in the 
> namespace</agreement>
> ...
> 
> once signed, can be later altered simply by changing the namespace
> declaration from reading "Purchase Barbie for 19.95" to 
> "Purchase Ferrari
> for 150,000". The effect being that instead of getting a 
> charge of 19.95 on
> the credit card, the charge becomes 150,000. We have seen 
> these security
> risks become reality with servers being continually hacked 
> all across the
> internet. I can think of no immediate solution outside of 
> embedding the
> namespace file in the canonical XML. I don't think this 
> problem will go
> away, it will just get worse.
>                             Joe
>

Received on Monday, 8 January 2001 13:35:48 UTC