Dr S N Henson wrote: > I'd be reluctant to have multiple APIs handling each case. What we could > have is flags or profiles saying what a certain kind of database should > support.
OpenSSL currently has separate APIs, as opposed to flags or profiles, for handling EVP_PKEYs, X509s and X509_CRLs because they are fundamentally different types supporting fundamentally different operations. The stores they reside in will mirror this disparity: a key store's (e.g. a smart card's or cryptographic hardware's) very raison d'être is to keep its keys hidden, a PKI repository's (e.g. a directory server's or RDBMS's) is to make its certificates and CRLs known. I'm not saying we *could not* consolidate both of these feature sets into a single API -- I've stumbled upon private keys in public directories more than once. I'm merely trying to point out that it might not necessarily be the optimal approach. > There are unfortunately some problems with PKCS#11. Its tantalisingly > close to whats needed but falls down in some areas. Cryptoki isn't necessarily the ideal key store implementation, especially with regards to integration with OpenSSL. As we don't seem to agree on the details of the requirements, however, I think the shortcomings you are referring to might well be what it is not doing by design: publishing and looking up certificates and CRLs, building validation paths... It is constrained by design to not provide these services. Cryptoki might not have been the best example anyway. As we're talking OpenSSL here, we should probably be disussing the Engine API instead. > Indeed it wouldn't, but full lookup need not be a complex task. The way > I'm considering this would be a layered structure which could allow some > things like smart cards to have a KISS approach. I'm not exactly sure how a layered structure would be different from having separate APIs. Maybe this is just a case of using different terminology for the same things? Please feel free to elaborate. I'm much more comfortable discussing class and interface design. :-/ Surely, if we factor out the actual "dumb" storage/retreival bits of the key store/repository implementation into its own API (layer?) we'd arrive at something a smart card would be able to understand as well as an embedded DB, a directory server or an RDBMS. KISS is indeed a noble goal, and an important part of it is the striving towards interface minimalism, consistency and independency IMHO. Best regards, //oscar ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
