Re: Problem with canonical form?

----- Original Message -----
From: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>

> 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.

Except that this is simply not true. Working from the understanding that one
of the primary targets for this is digital agreement to contracts. Current
laws have set forth what can and cannot be listed in a contract. Stating
things like "I agree with what Donald Eastlake says in every page of his
personal journal" is not a supportable statement, and would be thrown out of
court if it was used as evidence (iff there is the presence of a reasonable
judge). This, simply because the journal is a continuously evolving document
of which my knowledge may or may not be complete (side note: I don't even
know if Donald Eastlake has a journal let alone the contents). Other
documents can be acceptably included, "as pertaining to the california penal
code #113" is acceptable because it is a non-evolving document. The problem
lies in that these documents have physical presence so their state of
evolution can be determined. From this reference to physical volumes are not
a concern, likewise reference to "For details see (our other rules and
regulations)" we need not concern ourselves with. However there is also the
issue of due diligence on the part of the signer, in this case that means
that the signer needs to reference those documents him/herself. This is a
special subcase where that document could be evolved without notice. Since
the supplied namespace URI is of particular concern, along with the any
other external formatting information if conceptually a part of the XML
document it must be signed when the XML is signed.

> 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.

The semantics of the attack though are at the human level, the human that
instead of holding true to the commitment the customer intended makes use of
the dirty little secret of the system to completely change the meaning after
the fact, the application would not know the difference, the application
probably won't even exist when the crime takes place.

>
> 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?

We only need to concern ourselves with direct, obvious inclusions. Indirect
inclusions, and subtleties we don't need to handle, because they are already
well defined. Finding a way to reference a particular (potentially
transient) namespace remains a viable option.

> 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?

I only see one option, include it. If there is anything involved in the
signature which is insecure, the signature is insecure

> 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.

However that would be of the indirect reference form. I agree with you that
this may be an issue, however current (assuming US) signature laws have very
strict requirements about outside documents, the issue is not dealing with
outside documents, but with dealing with inside documents, controlled as
outside documents.

>
> 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.

I tend to agree with you that the majority of signatures will be transient
contracts, or assertion statements. However with the presence of a (US)
national digital signature law, I'm already dealing with the demands of many
customers who want to use XML signatures for electronic commerce, so I
believe it will also become the rule rather than the exception. Besides do
you really think we'd have the strength of economy we have now if 1 out of
every 1000 transactions had to go to court to be revolved? The stock market
alone would grind our judicial system to a complete standstill. Justifying
creating that state of affairs, by "it's not that bad" is, in my personal
opinion, a questionable path to take. I think we need to include some form
of absolute identification of the namespaces, and anything else included,
things referenced can be left as references.
                    Joe

Received on Monday, 8 January 2001 15:23:10 UTC