> 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.
I was thinking a bit more broadly. As someone currently thinking more like
a DBA, I'm learning toward the issuer||serial since it looks like the best
candidate for the key in 3NF. ("All fields depend on the key, the whole
key, and nothing but the key. So help me Coad.") The subject is out since
you can have identical subjects from different issuers, while the whole-cert
hash strikes me as an artificial contrivance without the meaningful
dependency you expect of a key.
But I also understand that from a X.509 perspective it's the subject
that counts. Or subject||issuer.
And from a pragmatic perspective, whole-cert hashes make a lot of sense.
>From a DBA perspective, it's annoying (but not scary) to add additional
constraints. The big fear is wrongly excluding valid data by using an
overly restrictive primary key... closely followed by fears about bogus
data when an overly permissive key is used.
> 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.
Then perhaps the problem can be reduced to this:
in order to avoid operational problems (e.g., with revocation),
either (issuer,serial) can be treated as a unique identifier,
or (issuer,serial,X) will be sufficient to uniquely identify each
cert.
The question is "what is X"?
> Regarding certificates with identical subject names as duplicates
> wouldn't necessarily be a Good Thing though, for a couple of reasons:
>
> *) 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.
Worse, it's easy to imagine a system where some uses will properly
verify a cert, but "less critical" ones will just check the local cache.
(Or the CRL information is unavailable, etc.) It's easy to imagine a
situation where a cert is stored, then determined to be revoked, removed,
then received again and stored again,....
It's much better to keep an explicit status flag in the database.
If a cert is revoked, the store may refuse to delete it until after
it's expired to avoid such accidental reinsertion. Obviously some
stores can't do this (smart cards, in particular, have limited storage),
but it may be a recommended practice.
> Certificates were indeed intended to be stored by subject.
Certificates were intended to be stored in LDAP (X.500), not RDBMS or
Berkeley database files, and LDAP supports query-by-example.
> 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.
It gets even more complex once you realize that many LDAP servers can
use RDBMS systems as their backend, with all that implies.
> 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
It's odd to see his design - my jsp stuff does the same thing, but I
let the postgresql extension and some 'rules' pull out the fields used
for searching instead of application code... precisely because I don't
trust application code.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
