From: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>
Date: Wed, 28 Sep 1994 11:23:21 -0600
Message-Id: <199409281723.LAA29414@idaknow.acl.lanl.gov>
To: connolly@hal.com
Subject: Re: URC usage scenarios
Hi Dan,
> >Ensuring the veracity of the resource
...
>
> 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.
OK, here is my picture of what I think might happen.
1) User has a URN. Part of the URN is the publisher ID.
2) User's browser starts to resolve the URN - it is sent to the URC
service.
3) URC service returns a URC to the browser that contains info on
the location(s) of the resource and digital signature info that
can be used to verify the resource pulled from that location. This
validation ensures that the user gets the resource that the URC is
describing. These signatures will be signed with the private key of
the publisher.
4) The URC info itself has signature info. It is signed with the private
key of the publisher. This ensures that the URC info is what the
publisher intends it to be. This is the point of the 3'rd scenario,
"Ensuring the veracity of the URC".
5) How do we get the public key of the publisher so that we can validate
the signature of the URC? From the publisher portion of the URN.
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.
Now, lets go through your example of JoeBob's voting record.
1) User is browsing JoeBob's campaign literature, published by
IANA:JoeBob.tx.gop.org. We know that this is JoeBob's literature
and not some hoax because we have taken the signature from the
URC, decrypted it with the public key of IANA:tx.gop.org, and
compared to the MD-5 hash of the thing we are reading.
2) User comes across a link to JoeBob's voting record. Lets assume
the URN is <URN:IANA:senate.gov:voting_records/1994/joebob>.
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.
5) In order to speed things up, the browser operates on the assumption
that the URC info is good. It starts a retrieval and display of the
resource from the URL.
6) Using the public key of IANA:senate.gov, it attempts to validate the
signature of the location.
7) If either validation fails, the browser alerts the reader.
OK, now we have JoeBob's opponent BillyRae citing JoeBob's record in
the transcript of a speech. That speech is published as
<URN:IANA:tx.demo.org:campaign_1994/speeches/BillyRae/bs_23>.
If we attempt to resolve that URN we find a URC of the form:
URC.0 {
URN: IANA:tx.demo.org:campaign_1994/speeches/BillyRae/bs_23
Location {
URL: http://www.tx.demo.org/speeches_94/BillyRae/bs_23.html
Signauture.RSA: kjeoihjwe[ifhqij34ifhdghjfqoifgjhwfghr
}
Signature.RSA: okjdfoirkjdfouierkjlfd90io32kjef9043kjlfd
}
This speech also contains a reference to JoeBob's voting record, from
the same place as JoeBob uses - the US Senate's server. The record
is protected by the Senate's key. BillyRae's speech will contain
text of the form:
... And my opponent's
<A HREF="URN:IANA:senate.gov:voting_records/1994/joebob">
miserable voting record
</A> ...
That text is protected by the signature of the location, which is encrypted
by the publisher's (IANA:tx.demo.org) private key. The locations
signature is protected by the signature on the URC, also encrypted with
the private key of the Democratic party of Texas. Secure retrieval of
public keys is not the job of the URC service.
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.
> 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. However, I think that is too detailed
for the scenarios document.
Thanks for the feedback, please let me know if you still have
questions on this or other parts of the URC scenarios.
Ron