W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

RE: Signed in parts. Re: XML-Signatures Requirements Last Call

From: Phillip M Hallam-Baker <pbaker@verisign.com>
Date: Thu, 9 Sep 1999 14:08:27 -0400
To: "Tim Berners-Lee" <timbl@w3.org>, <chairs@w3.org>, "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, <w3c-xml-plenary@w3.org>, "Donald E. Eastlake 3rd" <dee3@us.ibm.com>, "Jon Bosak" <Jon.Bosak@eng.sun.com>
Message-ID: <001a01befaee$50e99b80$6e07a8c0@pbaker-pc.verisign.com>

	I think this is an important issue but rather than invalidating
the requirement I believe it strengthens it.

	For example consider E-Gorilla.com an e-tailer of stuffy gorillas
custom made to the customers requirements. Customers recieve confirmation
of their order via an XML email, part of which is the standard 'wellcome
customer' spiel and another part of which is an invoice.

	What is the desirable scope for the signature on the invoce?

* It is quite likely the receipt is to be stripped out and sent to
	another application which does not understand the 'wellcome
	customer' spiel. This is likely to take place at both the
	merchant and the customer sites.

* Further the wellcome customer spiel may well incorporate text items
	suplied by the customer (such as the chosen name).

	So now consider the case that a malicious customer notices
that the name chosen is returned in the invoice and chooses a name
which includes a tag which in turn causes an override of the 
invoice, which in turn causes the merchant's equipment to decide that
payment is not required.

	I believe that in this case the safest approach is to severely
restrict the scope of the signature. The essential principle to apply
is that the scope of the signature should exactly match the scope
of the message to be exported to another application.

	I agree that this leaves a problem with the semantics of 
compound documents, but transclusion is always problemeatic trust 
wise - as experience with the <IMG> tag has proven. 

	In general an application should only rely upon data that
is sufficiently authenticated.


> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Tim Berners-Lee
> Sent: Wednesday, September 08, 1999 3:59 PM
> To: chairs@w3.org; Joseph M. Reagle Jr.
> Cc: IETF/W3C XML-DSig WG; w3c-xml-plenary@w3.org; Donald E. Eastlake
> 3rd; Jon Bosak
> Subject: Signed in parts. Re: XML-Signatures Requirements Last Call
> -----Original Message-----
> From: Joseph M. Reagle Jr. <reagle@w3.org>
> Date: Friday, August 20, 1999 4:35 PM
> Subject: XML-Signatures Requirements Last Call
> >http://www.w3.org/TR/xmldsig-requirements
> I am concerned (now after much thought) about the impact of
> the requirement 3.1.3
> "XML-signatures must be able to apply to a part or totality of a XML
> document [Charter, Brown]"
> I was a great advocate of that, but since I have been studying the
> relationship between
> a document and its semantics.
>  My concern is that the semantics of any XML element
> is totally dependent upon its enclosing context.  Think of a 
> document as an
> expression.
> What does signing part of a document mean?  If it means signing a virtual
> document
> formed by stripping out (in a well defined way) everything which is not
> signed, then
> I understand it.  I think that definition can work but must be explicit.
> If it means taking responsibility for certain parts only in 
> context, then I
> don't.
> The outer surrounding context can invalidate, negate, or transform the
> meaning of the
> child elements in any way.
> Maybe this has been addressed, in which case I apologize for 
> bringing it up
> again.
> Tim Berners-Lee
> xml-plenary group
> PS:  For example, in my investigations into extending RDF to logic, in
> http://www.w3.org/DesignIssues/Toolbox
> defines an "RDF-transparent" property of an XML element which 
> allows RDF to
> be taken out of context
> but cannot be assumed.
Received on Thursday, 9 September 1999 14:08:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:56 UTC