> > Issuer and subject number should also be unique, and it's a common > > search pattern. I don't think anyone searches on the hash of the > > entire certificate. > > It should be unique but it might not be, either by accident or malicious > intent.
This indirectly raises a question we've been skirting: is this a dumb store that accepts anything passed to it, or is it an intelligent store that attempts to enforce some minimal level of internal consistency? Flipping the question around, I think there's no doubt that it would be desirable to allow plug-ins to implement various levels of checking, both during the initial insertion of a record and during subsequent internal consistency checks. An application may use a simple store, while a CA cert repository may use a very strict one. But this begs the question of what's the minimum standard expected of all stores? Should they ever be accomodating of malicious intent? > There are a couple of cases that use the hash of the whole certificate. > The OCSP v2 draft for example. I'm not arguing that the database shouldn't support searches on this hash, just that it may not be the best primary key. I would expect there are more requests for cert chains (which are extremely efficient with issuer-and-serial-number indexing) than full-cert hash values. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
