> 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. In cases like this I don't think it's acceptable for the backend to depend on the good behavior of the application. There are many cases where you can use a trusting backend and keep all of the key logic in the application. But I don't think you can safely assume that the backend will always accept everything thrown its way. > In such a case > things like duplicate issuer and serial numbers may occur and should be > protected against (at whatever level). I'm beginning to think that the plug-ins will just need to document such things and let the user decide. Even if this is a legitimate concern for an "address book" type application, many sites will only be concerned with their own certs and can guarantee the necessary uniqueness. > 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. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
