Bear Giles wrote: > > > > 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? >
To avoid duplication of code I'd say such concerns should be addressed either at the application level or on top of whatever OpenSSL plugin API is adopted. My point was that in some applications certificates may be added from an untrusted source. An example would be an S/MIME application which adds certificates for later use from S/MIME messages. It may add certificates even though it doesn't trust the issuer so that a user might trust a certificate by out of band means. This is the kind of thing that Netscape messenger and other S/MIME clients can do. In such a case things like duplicate issuer and serial numbers may occur and should be protected against (at whatever level). > > 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. I'd say that the actual plugin API should not concern itself with such details. It should just send a request to the plugin requesting all the objects (certificates, CRLs, private keys etc) that match certain criteria and it would be up to the plugin itself to decide the most efficient way to satisfy the request. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
