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
participants (3)
-
cme＠cybercash.com -
Derek Atkins -
Perry E. Metzger