Bear Giles wrote: > > > 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. > > I think that would be a serious mistake. I'm specifically thinking > of something like the CA cert repository/JSP code in my postgresql > library - it's designed to be the store that's published to the world > as THE official repository for a CA. If it gets bad data stuffed into > it, the security of an entire organization can be quickly compromised. >
What would you classify as "bad data" in this case? Actually I didn't word that comment too well. The database shouldn't accept everything thrown at it by any means. The API will to some extent restrict "everything" in that the data passed has to be in valid structure. What I meant to say was that some checks are easier to perform outside the plugin and may be application specific. For example a duplicate issuer an serial number in S/MIME may be the result of a broken certificate sent in a signed message or malicious intent and it should be possible to resolve this. A duplicate I+SN in a CA application is likely to be much more serious and may be a result of a fatal error in the serial number allocation. > > > I'd say that the actual plugin API should not concern itself with such > > details. > > I agree, but that doesn't mean there's no connection between the > two. > > As a specific example, I think it's now clear that any key returned > from a 'findByX' command must be considered opaque. Some backends may > use hash-of-certificate, others hash-of-issuer-and-serial-number. > This in turn restricts the type of caching that the application itself > can do. Is there some specific reason why the API should return a "key" at all and not just the certificate (or whatever) it corresponds to? 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]
