Re: Problem with canonical form?

At 15:08 1/8/2001 -0800, Joseph Ashwood wrote:
>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

Hi Joe, I agree that Martin's scenario is a compelling one.

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

Your proposal was that somehow the Canonical form include the "meaning" of 
its namespace. One approach would be to include the DTD(internal 
subset)/schema(no idea...)? This still wouldn't completely solve the problem 
as Martin's example had because the meaning of the element was derived from 
a DTD comment, which is not 'normative' and is indicative that meaning may 
or may not be associated with a namespace, and some of that meaning is based 
on computer understandable structures (DTD/schema), the natural language 
tokens appearing in them, comments, natural language specifications 
associated with them, and shared history and context of that namespace. (For 
instance, in this scenario I'd expect courts to look at the receipts of 
previous exchanges, and then ask why did one party's understanding change 
for this particular transaction.)

Regardless, your proposal has not been a requirement/proposal of Canonical 
XML, issues of "context affecting the meaning" have long been recognized and 
are simply addressed by including a Signature//Reference to those other 
contextual documents where possible. Concerns that this leaves room for 
signature users to create and rely upon ambiguous signatures has not been 
sufficient to deter the WG from relying upon the present approach -- though 
it has led to more text/warnings about this issue:
>"The XML Signature is a method of associating a key with referenced data 
>(octets); it does not normatively specify how keys are associated with 
>persons or institutions, nor the meaning of the data being referenced and 
>signed."
>[1] http://www.w3.org/Signature/20000228-last-call-issues.html (Davis issue)


So I think there are three courses open to you on this issue:
1. A substantive proposal with significant agreement from the WG to change 
the specifications. (This doesn't seem likely given the list response.)
2. A proposal to change the text of the specification to more strongly 
identify/warn about this issue. I propose a new sentence at the end of 8.1.1:
>Also, users concerned with the integrity of the element type definitions 
>associated with the XML instance being signed may wish to sign those 
>definitions as well (i.e,. the schema, DTD, or natural language description 
>associated with that namespace/identifier).
3. A noted opposition in the specifications' issues document.


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 9 January 2001 13:33:05 UTC