Message-Id: <9409272349.AA04391@ulua.hal.com>
To: uri@bunyip.com
Subject: Re: URC usage scenarios
In-Reply-To: Your message of "Mon, 26 Sep 1994 11:38:35 MDT."
<199409261738.LAA24891@idaknow.acl.lanl.gov>
Date: Tue, 27 Sep 1994 18:49:58 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <199409261738.LAA24891@idaknow.acl.lanl.gov>, "Ronald E. Daniel" wri
tes:
>
>Here is my first cut at a document detailing a fair number of scenarios of
>how the URC service might be used. Your feedback is sought.
Excellet work...
>Ensuring the veracity of the resource
>++++++++++++++++++++++++++++++++++++++
>
> o The user starts to retrieve a resource according to the first
> scenario.
>
> o As the browser is going through its list of Locations, it notes if
> the current location has signature information. The rest of this
> scenario assumes that we successfully retrieve a resource which
> has signature info.
>
> o When the browser retrieves the resource, it displays it to the
> user.
>
> o In the background, the browser verifies the signature on the
> information.
I'd like to get more clarity on this step: what exactly is it that
you're verifying? You can check the integrity of the retrieved
resource with respect to the URC, but that doesn't make any connection
to the URN that the user started with. So we've got a break in the
secure communication link between the URN and the referent data.
This brings up my first issue: authenticity begins with URNs, not
URCs. The object of the game, if you ask me, is reliable links,
where reliability varies from application to application.
For example, suppose I'm reading campaign info on JoeBob, and it
contains a link to his voting record. As a reader, I'm interested in
the integrity of the link between this campaing info (which I obtained
through a secure and/or trusted source) and the referent data, the
voting record.
If the link info in the campaign info -- the URN -- doesn't contain
authenication info, then when I go to the URC service and get locations
for the data, who says the URC server is not a rogue? What party signs
the URC's? What is the sentiment expressed in the certificate?
In this case, I have a document which contains a link that expresses:
"If you resolve URN xxx, you'll get JoeBob's voting record."
I obtained the document from JoeBob through secure means. For example,
it was signed with JoeBob's public key. I can conclude:
"JoeBob says that if you resolve the resource corresponding to
the URN xxx, you'll get JoeBob's voting record."
If I can find a URC _signed by JoeBob_ that says
"If you find some data with MD5 checksum yyy, then
you've retrieved URN xxx."
then if I resolve any of the URLs in that URC, and the data ddd has
checksum yyy, then I can conclude:
"Joebob says ddd is his voting record."
So far so good. But what if BillyRae, JoeBob's opponent, wants to
make a link to JoeBob's voting record in his speech?
I might find BillyRae's speech, which contains a link which expresses:
"To find JoeBob's voting record, resolve the URN xxx."
If the speech is signed by BillyRae, I can conclude that
"BillyRae says the resource corresponding to URN xxx is
JoeBob's voting record."
Then I have to find a URC signed by BillyRay. So to make a link to
JoeBob's speech, BillyRae must be able to add signatures to the URCs
in the URC service. This shouldn't be necessary. We should be able
to chain inferences in the authentication logic.
The link should have authentication info inside it. For example, if a
link could identify some principal in an authentication framework,
then the link in BillyRae's speech could express:
(1) "If JoeBob says you have successfully retrieved a resource
corresponding to the name xxx, then it's JoeBob's voting record."
(for example, <A href="xxx" DN="JoeBob">, as in CommerceNet's SHTTP
secure HTTP extensions.)
Then, as a user, I can take xxx to the URC service and get the
aforementioned URC signed by JoeBob which states
(2) "If you find some data with MD5 checksum yyy, then
you've retrieved URN xxx."
>From the fact that I believe (1) (because it was signed by BillyRae,
but independent of whether it was signed by JoeBob) and the fact
that (2) is signed by JoeBob, I can conclude
"Data with MD5 checksum yyy is JoeBob's voting record."
And I can use this to check the data that I get by resolving any of
the URLs in a URC.
Bleh... I can't seem to bake this down to a cogent explanation.
Anyway... I propose that URCs be able to contain a set of
certificates of the form:
((P, N, F, c, t0, t1), S)
where P is a principal,
S is the result of encrypting the MD5sum
of some string representation of (P, N, F, c, t0, t1)
with P's secret key, and (P, N, F, c, t0, t1) represents
"P certifies that during the interval from t0 to t1,
the data with a checksum of c (as defined by F)
represents the resource named N."
Note that there may be several such certificates:
* a principal may certify that postscript file
and a TeX file both represent some resource.
* a principal may certify that different data sets
represent the resource at different times (e.g. a weather map)
* different principals may certify the same resource
* a principal may certify a resource with different
checksum functions: MD5, gnu checksum, etc.
Dan