Re: Problem with canonical form?

There are an infinite number of ways in which signed material can
include external references, from URIs to arbitrary pieces of source
or binary code to instructions to a human being to look something up
to who knows what.  And any standard for signatures never really has
any idea how the stuff being signed is to be
treated/interpreted/executed with the exception of some of the
material in the signature construct itself.  The semantics are all at
the application level and the application must calll signature
primatives to construct the signature in such a way that everything
the particular application needs secured is secured.

If some piece of XML is signed, how can the signature library know
whether namespace URIs, or any other kind of extrnal reference in it,
are to be used as is or perhaps only de-referenced after some some
mapping or XSLT is done on it, assuming the signature library can even
recognize the external references?  And even if it could get past all
those problems, how will it know whether the right thing is to secure
the reference or the data referred to?  If, say, the signed object is
a recommendation of some service, then it is just the URI to the
service, and maybe another key that that service uses to sign its
results, that the recommender wants to sign, not some snap shot of
some particular service results.

Fortunately, I think the vast majority of XML signatures will be for
protocol message use where most or all of these questions get decided
as the protocol is designed.  For the perhaps one in a thousand XML
signatures that are on ad hoc generally interpreted documents, which
seem to be all that you are considering, you really can't say much
more than that you need to sign everything you want to secure.
XMLDSIG has ample facilities for signing external DTDs, schemas, style
sheets, etc., if appropriate.


From:  Al Gilman <>
Message-Id:  <>
Date:  Fri, 05 Jan 2001 23:05:53 -0500
In-Reply-To:  <>
References:  <>

>At 12:20 PM 2001-01-06 +0900, Martin J. Duerst wrote:
>>[Cross-posting to 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.
>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.
>>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 <>,
>>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 Saturday, 6 January 2001 02:58:36 UTC