Richard Levitte - VMS Whacker wrote: > > From: Bear Giles <[EMAIL PROTECTED]> > > bear> Of course, this opens the whole can-o-worms of "what constitutes > bear> a duplicate cert?" Is it an exact match, or matching I+SN, or > bear> some other criteria? > > Depending on who you listen to, one could say it's the subject, others > will say it's issuer+serial. It all depends on if you want to keep > the history of a specific subject or not. This is of course taken > from a X.500 directory perspective (where things were intended to be > stored by subject, I believe (I'm sure Oscar will correct me if I'm > wrong :-))).
Consider me baited. :-) Two certificates sharing the same issuer||serial indeed pose a problem, and would need some additional form of dis-ambiguation without messing things -- revocation very notably -- up royally. Regarding certificates with identical subject names as duplicates wouldn't necessarily be a Good Thing though, for a couple of reasons: *) An entity can have different certificates with different purposes asserted: keyCertSign, cRLSign, keyEncipherment, digitalSignatures etc. *) An entity can receive certificates from any number of issuers. *) OTOH, I can't remember whether certificates are necessarily expected to be removed as soon as they are revoked, or only when they expire or even then. And what's to stop an entity from requesting an additional certificate even if they already posess a perfectly valid one. *) During CA certificate-rollover there might need to be at least as four separate certificates active for a given CA at once: self-signed about to expire, self-signed new one, self-issued old issues new and self-issued new issues old. Certificates were indeed intended to be stored by subject. After all, their raison d'être was to cryptographically authenticate said subjects to the Directory. The certificates stored in your subject entry would be those used to verify your authentication attempts. Without the Directory, or even a directory-like structure it's certainly tempting to defer to distinguished names as being little more than anachronisms. Maybe one could go so far as to wonder at the reasoning behind selecting X.509 Certificates for use as authentication mechanisms outside the realm of X.500, where the entities they are able to identify simply do not exist. I know Peter Gutman has outlined a means of using an RDBMS as a certificate store (1) and I think it ought to prove valuable insight into the types of keys that might be required/convenient. 1: http://www.cryptoengines.com/~peter/09a_cert_store.pdf //oscar ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
