Re: importing terminology in "XML-Signature Requirements"

"Joseph M. Reagle Jr." wrote:
> 
> [Resulting version from all comments and editing should be available by
> Wednesday.]
> 
> At 04:17 PM 7/13/99 -0500, Dan Connolly wrote:
> > http://www.w3.org/TR/1999/xmldsig-requirements-990623.html
[...]
>  >but I don't think that identity is an essential property
>  >of a thing that you want to sign. The essential property
>  >of a thing that you want to digitally sign is that it's
>  >(expressible as) a sequence of bytes.
> 
> Hrmm... We want to sign digital content, certainly. But sometimes in the
> signature one has an abstraction on the digital content that provides a
> model of what that digital content is. In some ways, you are signing that
> abstraction as well.

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.

> Consequently, the syntax of the identifier in some way
> provides the context/abstraction of what one means by resource... Another
> way of looking at it is that we are merely signing bytes, and a (URI |
> locator) is a way of invoking a chunk of bytes to be passed to the signature
> application, but this way of thinking of it kills the data semantics...

I don't see any other way of looking at it, and I don't
understand "kills the data semantics..."

>  >So I'd suggest replacing that "signatures on Web resources"
>  >with "signatures on digital content." So:
> 
> This is certainly true. You can sign anything you can perform the
> cryptographic operation on. Is there a class of digital content that we
> don't wish to sign? No. Is there a class of digital object that we can't
> sign? Yes, that which is not addressable.

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>

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

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

For W3C tech reports, we explicitly assign an address for
"the content as published on YYYY-MM-DD" and another address
for "the current contents as of the latest (public) revision".
But it's hardly the case that every time-chaning resource has
explictly assigned addresses that refer to each of its versions.

> Consequently, we could define Web
> resource as any digital content that can be addressed and specified within a
> signature manifest. The syntax of that address is presently defined by the
> XLink locator.

As I say above, I don't think that's what you want/mean.


>  >      ... signatures on digital content: content of Web resources,
> 
> Is the content of a Web resource different than the Web resource?

In some particular cases, no: http://www.ietf.org/rfc/rfc0822.txt
refers to a resource which is precisely one sequence of bytes.

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

... which just goes to show that "the content of a Web resource"
is a definite description error, like saying "the arm of the man."
Which arm?

[that's all for this message... perhaps more in other messages.]


-- 
Dan Connolly, W3C
http://www.w3.org/People/Connolly/

Received on Wednesday, 21 July 1999 11:47:41 UTC