[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bootstrap of key-centric binding of person to key
>Subject: Re: CRLs versus short Validity periods
At 12:42 3/1/96, Frank O'Dwyer wrote:
>I think we basically agree here?
Yes, I think we agree. There are applications/CAs for which CRLs are the
clear performance winner. There are others for which short-lived certs are
the clear winner.
>I could imagine a lot of apps
>being compiled -DNO_CRLS.
yes -- if the application had no place to hold a persistent CRL. E.g., an
applet might be forced into the short-validity cert model.
>I agree (if I've understood), and I really like the key-centric nature
>of what you have proposed.
Thanks.
>However I'm a little confused about how
>you bootstrap into this key-centric scheme, since most applications will start
>out with some kind of identifier in hand, not a key. Applications are
>right now doing application things, after all, not key things, and users
>don't type keys.
Of course they don't. However, my first example of a key thing is an
application thing: signed e-mail and USENET News. When I encounter a
signed message from someone I've never met, I can check the signature to
see if the message has been altered since leaving the author, but I don't
know the author so it makes no sense to check the key itself. The first
time I see a message from this person, I'll probably have to fetch the
naked key from some DB just to check the sig.
In this case, my knowledge about the person is being created from zero,
using the content of the message. My impression of the person [I'm looking
for the right noun here: knowledge?, reputation?, trust?, ...] flows from
the message body into the key -- charging the key with impression
[knowledge, reputation, trust] the way one charges a battery. After enough
messages, that key is now charged and can lend impression [knowledge,
reputation, trust] to other messages signed with it. That is, all the key
does is link together messages from the same source and let those messages
influence the way I interpret other messages from the same source.
There is no difference between that process and what happens in real life,
when you first meet someone and carry that first conversation through to an
acquaintanceship.
>Suppose, for example,
>all my application has is its own key pair and out of the blue is given
>something's IP address. It wants to connect to some resource that
>'really is' at that IP address (leave ports out of it for the moment), for
>some value of 'really is' (this might only work for local IP addresses).
If someone is giving me an IP address to which I'm supposed to connect
securely, that message itself needs to be signed [to prevent substitution
of the IP address] and could just as easily have the public key of the
service at that IP address in the same message. If you're talking about
some existing application which just sends you an IP address, then it's
already not secure [for lack of the signature]. If all you get is an IP
address, unsigned, but you trust it then the app will have to be changed to
accept the key of the service.
>How does my app get to the key or keys that it needs for this? That is
>really a basic PKI question--how do you map something or other (usually
>some text string?) to a key, securely?
You need to learn about the thing to do from something else -- so that
something else sends you the key along with other information [like URL or
IP address].
The real issue is how keys get injected into the system in the first place.
For USENET News or e-mail, the method is clear [as outlined above]. For
things in which authority is being granted, then the source of that
authority generates a certificate granting the authority. For large
publicly visible entities [IBM, the US Post Office, MasterCard, ...] it is
adequate to publish a key's secure hash in a variety of media [TV,
newspapers, magazines, ...] along with the URL for the key itself. If
someone spoofs this in national media, the real company will hear about it
and start police action. If you look at all the entities which are
broadcasting their home page URLs now, I'd imagine some fraction of them
giving key hashes at the same time. [A few years ago, I never would have
believed the number of URLs. After all, they're geeky.]
>In your model, I assume that my app pulls out its own key (or one of the
>keys it's been physically configured with), and searches the net (how?)
>for attributes bound to it (signed by it).
For many things, the app wanting to exercise some granted authority
supplies the cert [on demand, or all the time] with the request. I
envision each cert having a pointer [URL? UR*?] to the Issuer's key and
certs, not just to the Subject's key.
>I assume that certain special
>types of attributes would allow the search to recurse using attributes
>signed by other keys (i.e. usual certificate chaining). Other attributes
>might perhaps require the search to come up 3 or 4 'lesser' keys vouching
>for some information (cf. PGP's 'marginal' signatures).
I'm a PGP user but I don't find much value in PGP key signing. The meaning
hasn't been established firmly enough. In general, I assume a traditional
cert chain validation.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091 Tel: (703) 620-4200 |
+--------------------------------------------------------------------------+
Follow-Ups: