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

RE: importing terminology in "XML-Signature Requirements"

From: Richard D. Brown <rdbrown@Globeset.com>
Date: Wed, 21 Jul 1999 18:43:18 -0500
To: "'Dan Connolly'" <connolly@w3.org>, "'Joseph M. Reagle Jr.'" <reagle@w3.org>
Cc: "'IETF/W3C XML-DSig WG'" <w3c-ietf-xmldsig@w3.org>
Message-ID: <009b01bed3d2$cfdb6f10$0bc0010a@artemis.globeset.com>
>
> Huh? A digital signature applies to exactly one sequence of bytes,
> no? That's a pretty basic premise of the technology, no?
>
> Yes, you can have a Web resource that is "the current edition
> of the USA Today" but there's no one digital signature that
> works for such a resource over time. A particular digital signature
> applies to the content of that resource as of this morning,
> or as of yesterday morning, but not both.
>
> While there are some URIs that refer to exactly one sequence
> of bytes (all cid: URIs, and some ftp: and http: URIs,
> like RFCs and W3C tech reports) in the general case, a URI refers to
> an object whose state varies over time, and might have different
> representations at any given time.

The point is that one could make a distinction between the raw contents of a
resource and its semantics or what it means. Consider RDF for example. There
exist three levels of simplification that could be applied to a series of
assertions without changing their semantics. The assertions remain the same
before and after simplification, but the raw contents of the document has
changed.

The current specification provides for the declaration in the signature
element of a canonicalizer algorithm, which is used to apply a
transformation on the raw contents before computation of the signature
value. It is certainly expected that the transformation does not alter the
meaning of the document, but this assessment is left to the application that
specifies and makes use of the canonicalizer. There is already some work in
progress at W3C to specify the canonical representation of an XML document
and I suspect that, sometimes, there will be another one for RDF (though
encoded in XML, additional semantical equivalences can be identified).

On the other hand you are correct that a particular signature applies to the
content of a resource in a given state. If the content is expected to vary
overtime, then the signature is not systematically verifiable from its
origin. But it is not the object of the current specification to ensure that
the content of the resource will remain constant over time. This is a matter
that should be addressed by every application (making use of XMLDSIG or not)
and is usually addressed by caching locally a copy of the resource in a
given state. If you want to prove over time an assertion made by somebody
else, you better keep a copy of that assertion on your own. :-)

> Why don't you want to be able to sign documents that don't have
> addresses? i.e. a document on stdin, or the following document:
>
> 	<doc>Four score and seven years ago today</doc>

Refer to my previous email.

>
> I thought you did want to sign such content, hence
> "portions of protocol messages" in the Introduction.

Correct. But this usually consists of a series of elements, which are
attached to the document (protocol message) along with the signature
element. Therefore, the elements are addressable from the signature element
by means of a fragment identifier.

>
> Another example of content that doesn't have an address:
> the current contents of http://www.w3.org/. In a month
> from now, the content of http://www.w3.org/ will (most likely)
> change, and there isn't any URI that refers to the content
> as of today (hm... actually, there is, but it's in our
> internal CVS web space that we don't make generally available).

I suspect that you will not sign the content of the site as a whole (i.e. by
concatenating all the resources together) but rather a site-content
'manifest'. In other words, you will create a new document that refers to
every resource in the site and specify their respective hash. As long as the
manifest exists, the signature is verifiable, though the actual resources
might change.

But, the real question is "what was the actual statement that you made in
signing the manifest". Might be something like 'I, Don Conolly, attest that
the content of W3C web site in date of July 21st, 1999 consists of the
following resources, whose content is verifiable by means of the attached
digest." The point is that you sign for a particular purpose, and this
purpose will determine your choice between embedded and detached signature,
will define 'caching/archiving' requirements...

>
> But in general, yes: a web resource that tells you what time it
> is in Geneva is different from the string "4pm".
>

In this case you should not authenticate directly the resource, but your
assertion that the resource could be trusted to obtain the time in Geneva.
In other words, you create a document/element that explicits your assertion
and refers to the trusted resource, and then you sign your assertion - not
the trusted resource. Although, this might be pretty much useless if you do
not disclose in your assertion how one could authenticate that trusted
resource or its alleged response.

Richard D. Brown
Received on Wednesday, 21 July 1999 19:43:41 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT