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]

Reply via email to