Re: A brief comparison of email encryption protocols

At 12:01 2/29/96, Laurence Lundblade wrote:

>
>Isn't using a hash as the identifier replicating the key distribution
>problem that PGP has or are you including some other data that can be used
>to look up the cert?  I think a problem occurs when you have 20 billion of
>these certs (two for every person in the year 2010 or such).  A simple hash
>into a table isn't going to cut it because you a single database (with
>replication?) isn't going to be possible.  Some hierarchical lookup like
>DNS is going to be needed. The look ups are needed to check for revocation.

Our current straw-man http://www.clark.net/pub/cme/html/cert.html
uses the following to identify a key within a certificate:

KEY_ID ::=  <hash of public key>
           [<nickname chosen by the owner>]
           [<URL of the full key>]

It is assumed that the key is in a cache at the verifier.  The verifier can
add it to his cache by having it sent to him directly, by fetching it
via the URL (if present), or through some other means.

One of my co-workers [Donald Eastlake] is proposing distribution of keys
via the DNS and that sounds fine, too.

We weren't tying the distribution problem to the certificate problem.
They really are separate.



Revocation is a separate problem.  My personal preference [quite seriously]
is not to allow for revocation -- rather to issue certificates with a
validity only long enough to get the job done but not so long that you'd
be seriously damaged by having an invalid cert honored.  There's no way to
get 100%, immediate validation [by non-existence on a revocation list].
For more words on this subject, see cert.html.

If one really needs CRL checking, I'd recommend including a URL for the
Issuer's own revocation list as a field in the cert.

 - 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                                 |
+--------------------------------------------------------------------------+

Carl Ellison writes:
> We weren't tying the distribution problem to the certificate problem.
> They really are separate.

I'm not entirely sure.

I think it would be valuable if signature formats specified not only
an arbitrary key-id but a DNSable string or URL to retrieve the
certificate responsible for the signature. One of the things we've
learned from PGP is the difficulty of dealing with random numbers as
key ids. In this, I'm not sure we shouldn't be including better lookup
mechanisms. This is not to say that meaning should be assigned to a
lookup string beyond its saying where to find the key.

Perry

> I think it would be valuable if signature formats specified not only
> an arbitrary key-id but a DNSable string or URL to retrieve the
> certificate responsible for the signature. One of the things we've
> learned from PGP is the difficulty of dealing with random numbers as
> key ids. In this, I'm not sure we shouldn't be including better lookup
> mechanisms. This is not to say that meaning should be assigned to a
> lookup string beyond its saying where to find the key.

This is something that I've spoken to Phil about at length, and I've
been trying to devise solutions.  The problem is how to offset the
"hint" and the size of the signature.  You want the signature to
contain some informatin that hints at the location of the key.  On the
other hand, you dont want to bloat the signature in doing this.

So, there needs to be a compromise, some shorthand method to describe
the hint.  One solution is to provide a "keyserver" type and then some
string that says which "keyserver" to use.  For example, if there is a
DNS-style keyserver deplyed, I could put '1,"mit.edu"' in all my
signatures, if we assume that '1' is the DNS-style keyserver code.

I'm sure there are other possible solutions as well, and any real
suggestions are welcome.

-derek