Richard Levitte - VMS Whacker wrote: > > From: Dr S N Henson <[EMAIL PROTECTED]> > > stephen.henson> My point was that in some applications certificates > stephen.henson> may be added from an untrusted source. An example > stephen.henson> would be an S/MIME application which adds certificates > stephen.henson> for later use from S/MIME messages. It may add > stephen.henson> certificates even though it doesn't trust the issuer > stephen.henson> so that a user might trust a certificate by out of > stephen.henson> band means. This is the kind of thing that Netscape > stephen.henson> messenger and other S/MIME clients can do. In such a > stephen.henson> case things like duplicate issuer and serial numbers > stephen.henson> may occur and should be protected against (at whatever > stephen.henson> level). > > I'm not sure in what case (modulo idioty like more than 1 issuer using > the same Snake Oil certificate as CA certificate) there would be > duplication. I can imagine that one might get the same certificate > from several source, but I'm pretty sure it could be resolved but > applying a little bit of automagic intelligence and tossing all > duplicates except for the copy that has the highest trust attached to > it. >
It depends on the situation. As long as the database doesn't go ape and does something sensible if it sees duplicate issuer and serial numbers then thats OK. > Trust, BTW, could rather easily be handled by attaching internal > attributes to certificates with extra information. Those attributes > are not part of the certificate itself, of course. Was that > approximately the way you saw this being done as well? > That's how its already done when I needed to add trust and various non certificate fields (such as an alias) to the PEM format. There are various functions (with TRUST in their names) that can dump additional auxiliary information about a certificate. This is encoded by dumping the extra info in a small structure after the certificate encoding (which is untouched). The extra stuff is stored in the X509 structure and is largely invisible except when the TRUST functions are used. However that's just a convenient encoding for some OpenSSL cases. As long as the database handles the request and returns all the relevant information in the X509 (or whatever) structure (including any trust settings) how it stores the details doesn't matter. > In any case, I find this discussion a bit moot, since different > application might search for anything. Netscape Navigator, as far as > I have understood, has the email addresses as index key for S/MIME > certificates. I would rather see that applications can request > indexes on a rather flexible set of basic types, and request searches > according to basically whatever. The keys used could be attached to > each certificates as another of those internal attributes I mentioned > above (and each certificate could have more than one key attached to > it). If actual indexes are really built would be up to the plugin. > Then, having indexes based on the hash of the full certificate > wouldn't be something we'd have to decide, would it? > > Does that sound like a feasible thought? > IMHO what to index should be the job of the database implementation and the API shouldn't care. In some cases such as smart cards where maybe one or two certificates are involved an in memory list using a linear search is perfectly OK. I think even the Netscape database stuff does a linear search in some circumstances. Though for many cases it has several indices. How I'd initially invisaged the "multi attribute" search is that the database implementation would look through the requested attributes and decide which (if any) to do a lookup on and retrieve all the matches. Then it could use a general compare to prune the result to return the exact match. That makes a linear search on (say) a STACK_OF(X509) trivial. I'd say that an in memory database (indexed or otherwise) should be the only real candidate for inclusing in the OpenSSL core code. On the grounds that *something* has to handle the equivalent of the current X509_LOOKUP (file + directory) mess and that's pretty much guaranteed to work on all platforms. 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]
