Re: Problem with canonical form?

At 12:20 PM 2001-01-06 +0900, Martin J. Duerst wrote:
>[Cross-posting to xml-uri@w3.org. Sorry if this topic has
>already been hashed throgh there.]

No, it hasn't been hashed to a conclusion.  And I think it is separable. 
_Grace a Dieu_.

>
>I agree. Namespaces are also not intended to contain actual data
>such as payment information, and it's not ever agreed that the
>namespace URI should point to an actual document, nor how the
>document looks like, or that there would be only a single one.
>
>So proposing to always include a namespace document when signing
>is currently a non-starter.
>
>But there are cases where it's not too difficult to imagine
>that the namespace influences the meaning of the document.
>Imagine that a DTD contains the following:
>
><!ELEMENT payment-amount #PCDATA> -- amount in Italian Lire --
>
>and is changed to
>
><!ELEMENT payment-amount #PCDATA> -- amount in British Pounds --
>
>So the question is how to make sure that a namespace cannot
>easily be changed in such ways. This provides interesting
>challenges in lots of ways, and some input into the namespace
>and uri debate. It would definitely increase the stability
>of the transaction against attacks if the DTD that contained
>the above fragment could be singed.
>

AG::

There is a generic problem of signing anything which has a dependency on an
include-by-reference other document.  That is the case above.  We need to
separate this from the disputes about namespaces.

The trick is to use a trustworthy form of reference, for which a vanilla
URI-reference is in general not sufficient.  [There may be URNs for which the
semantics of the scheme make the reference trustworthy.]  However, a practice
involving chained signatures (the dependent document includes among its
[signed] data a counter-sign [checksum] for the depended-on document) is not
hard to construct.  This belongs in the DSIG group, not XML-URI, I believe. 
DSIG may wish to define a pattern of practice for such chained signatures that
will allow dependent documents to be signed without materially degrading their
trustworthiness as record instruments.

There may well be names also drawn from the depended-on document, but
dependencies on anything in another document would constitute a semantic
extension of the base of existing consensus namespaces interpretation and is a
TBD hot spot as the archive of this list will show.  The signature stuff
can be
healthy without getting tangled in this eelgrass.

$.02

Al

>Regards,   Martin.
>
>
>At 01/01/05 18:25 -0500, Rich Salz wrote:
>>No, I think this is another example that points out that the signature often
>>must cover more than just the XML, but rather the stylesheets, etc., that
>>are related to it.  I believe the XMLDSIG spec discusses this sufficiently.
>>         /r$
>
>
>
>The original posting, from Joseph Ashwood <jashwood@arcot.com>,
>for completeness:
>
> >>>>
>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 Friday, 5 January 2001 23:01:01 UTC