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