# Re: URC usage scenarios

Daniel W. Connolly (connolly@hal.com)
Wed, 28 Sep 1994 18:10:01 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: uri-request@mocha.bunyip.com: "Re: URC usage scenarios"
- Previous message: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"
- In reply to: Ronald E. Daniel: "Re: URC usage scenarios"
- Next in thread: rdaniel@acl.lanl.gov: "Re: URC usage scenarios"
- Reply: rdaniel@acl.lanl.gov: "Re: URC usage scenarios"

    Message-Id: <9409282310.AA04630@ulua.hal.com>

    To: uri@bunyip.com

    Subject: Re: URC usage scenarios

    In-Reply-To: Your message of "Wed, 28 Sep 1994 11:23:21 MDT."

                 <199409281723.LAA29414@idaknow.acl.lanl.gov>

    Date: Wed, 28 Sep 1994 18:10:01 -0500

    From: "Daniel W. Connolly" <connolly@hal.com>

In message <199409281723.LAA29414@idaknow.acl.lanl.gov>, "Ronald E. Daniel" wri
tes:
>Hi Dan,
>
>> >Ensuring the veracity of the resource
>...
>1) User has a URN. Part of the URN is the publisher ID.
...
>All of this is predicted on the assumption that there exists a secure,
>ubiquitous public key infrastructure. There are several efforts going on
>in this area, so that in a few years such an infrastucture is likely to
>exist.

OK. So we agree. I think this brings out a new requirement:

From a URN, we must be able to determine the name
of a principal in an authentication framework.

>Now, lets go through your example of JoeBob's voting record.
...
>
>3) The user sends the URN to the URC service which returns a URC
> like:
> URC.0 {
> URN: IANA:senate.gov:voting_records/1994/joebob
> Location {
> URL: http://www.senate.gov/voting_records/1994/joebob.txt
> Signature.RSA: sdlkfjopivoverdfdhefhwofhwpofhwpfhwefh
> }
> Signature.RSA: jfwe423njcvdihw4nsdciouh24njwdouiekjlfd98u023rj
> }
>4) The browser has been configured for parinoia, so it attempts to
> validate everything. First, it takes the signature of the URC as
> a whole (the one starting with jfwe), grabs the public key of the
> publisher (IANA:senate.gov) and attempts to validate the URC.

It's still not clear to me: what do the signatures certify?
The "jfwe..." signature can't certify the whole URC: you'd have
to (1) write down the URC, (2) compute the MD5 checksum, and (3)
encrypt it with the secret key, and (4) stick the signature back
in the URC. Step 4 would invalidate the signature.

And what does the "sdlk" signature certify? I suggest that
it should certify:

"P says B represents N from t0 to t1"
where P is the certifying principal,
B is the body of data (actually its MD5 digest)
(t0, t1) is the lifetime of the certificate.

Before you sign something, you have to write it down as a very precise
sequence of bytes so that the verifier can take that sequence of bytes
and compute its MD5 checksum.

So the syntax of these URC's must be decided before folks can start
signing them.

I'd rather not have folks sign URCs. They'll change too much, I
think. I'd rather have them certify that the data itself is an
accurate representation of the named resource. The URC service looks
to me like a replication service: a service that maps a single name to
one or more locations.

Hmm... on the other hand, if a URC contains an abstract, you might
want to be sure the abstract is authentic.

>This is similar in some respects to the CommerceNet SHTTP example
>you used- <A href="xxx" DN="JoeBob">, except that the DN (Distinguished
>Name) comes from the publisher field of the URN.

Yes... very much. For my purposes, a URN is just like a URL, except
that it includes the DN (distinguished name, or principal) info.

>
>> Anyway... I propose that URCs be able to contain a set of
>> certificates of the form:
>
>Yes, but that is not all they should be able to contain. I favor
>a Signature element that is specialized to say what signature scheme
>is being used. MD-5, DSS, gnu-cksum, whatever. The contents of that
>field will be scheme-specific. If you are using RSA signatures
>(MD-5 encrypted with private key) the the Signature field will need
>to look much like your proposal.

Hmmm... an RSA signature is fundamentally different from MD5, DSS, and
gnu-cksum, in that it includes a secret. From a given piece of data,
anybody can compute an MD5, DSS or gnu-cksum. Only the holder of the
private key can compute the RSA signature.

MD5, DSS, and gnu-cksum are suitable for verifying that the data was
not garbled, but they don't tell you anything about the origin of the
data.

> However, I think that is too detailed
>for the scenarios document.

IMHO, nothing is too detailed for the scenarios document. The more
concrete you make it, the more clear things become, and the more
issues you flesh out. The whole point of the scenarios document is to
walk through the process step by step and examine the interactions and
make sure all the right info gets to all the right places.

Dan

- Next message: uri-request@mocha.bunyip.com: "Re: URC usage scenarios"
- Previous message: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"
- In reply to: Ronald E. Daniel: "Re: URC usage scenarios"
- Next in thread: rdaniel@acl.lanl.gov: "Re: URC usage scenarios"
- Reply: rdaniel@acl.lanl.gov: "Re: URC usage scenarios"