Bear Giles wrote: > And from a pragmatic perspective, whole-cert hashes make a lot of sense.
NB: I've only ever messed about with relational databases for a brief spell a few years back, so please excuse my struggling with the terminology. As primary keys go, I'm certain that whole-cert hashes would come in quite handy. They're trivial to compute, and for all practical intents and purposes guaranteed to be unique. As for lookups, I don't know in how many cases, apart from OCSPv2 apparently, a lookup on whole-cert-hash would actually be called for. You would definitely need to be able to do lookups by subject name though, in order to support path construction, and for convienence presumably on subject name||keyId as well. I guess these could then be used in supporting tables in order to look up foreign keys leading into the 'master table'. > 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"? The issuer's key identifier? Authority key identifiers are MUSTs in both certificates and CRLs in accordance with the PKIX profile. I would be much more comfortable with treating issuer||serial duplicates as error conditions though. People should be much more careful with their trust management, and not just invite any old cert the browser brought home with it to stay. For building a CRL, an issuer needs to be able to retreive a list of all revoked certificates (serial numbers, revocation date, reasons etc.) given its name, or optionally its name||keyId if it partitions CRLs that way. There's bound to be loads and loads more use cases in there that need to be taken into account. > 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,.... I checked in X.509, and neither revocation nor expiry are necessarily grounds for removal from the Directory, as there might well be a need to verify old signatures etc. > 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. I think this is very much up to the individual implementation. If you are working in a banking application you might conceivably be required by law to keep every issued certificate and CRL available for 10-20 years in order to be able to go back and prove/disprove the validity of old transactions. And yes, while they're quite handy for protecting and storing an end-entity's keys and certificates, a smart card certainly wouldn't be the ideal candidate for a PKI repository. I definitely think an RDBMS would be the way to go. Best regards, //oscar ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
