I don't know, I have not studied that part of OpenSSL closely enough to decide. I was mostly trying to come up with a reasonable counterargument to "designing a comprehensive certificate and key loading engine API is too hard to bother" reasoning. On 09/08/2015 20:56, Reinier Torenbeek wrote: > Hello Jakob, > > Looking at crypt/store/store.h, do you agree that a store > implementation is the place where the functionality that you describe > below belongs? > > Thanks, > Reinier > > > On 8/6/15 8:44 PM, Jakob Bohm wrote: >> I think what one wants as a first approximation is >> functions that can enumerate and load keys and >> certificates from "engine storage", such as smart >> cards (most engines would obviously load only >> "proxy structures/handles" when asked to load a >> private key). >> >> E.g. >> >> PSOME_PRIVKEY_TYPE EVP_EnumPrivKeys(T hEngine, ofs_t i); >> >> PSOME_PUBKEY_TYPE EVP_EnumPubKeys(T hEngine, ofs_t i); >> >> PSOME_CERT_TYPE EVP_EnumCerts(T hEngine, ofs_t i); >> >> Each will return either: >> >> The item at index i in engine storage >> >> NULL for no such item at index i >> >> (void*)(size_t)(1) for "i past last currently >> valid index for such items" >> >> Engines would have some leeway if they will return >> NULL or 1 for some values slightly past last index, >> and if there will be any relationships between indexes >> for different types. >> >> A second order approximation would be functions >> that can look for matching triplets: >> Given a public key, private key or certificate, >> load a matching item of one of the other 2 kinds, >> if present in storage, or return a "not found" >> error (of cause the cases of private key or cert >> to public key mapping are already trivial without >> calling the engine, the remaining 4 cases are the >> interesting ones, some engines can do them >> efficiently others would fall back to generic EVP >> layer loops over the first order enumeration >> functions and a generic EVP layer public key >> compare). Note, I can imagine engines that can >> quickly go between private keys and certs, but not >> from public key to either, so all 4 cases need to >> be exposed to the engine level, even if (PrivToCert >> and CertToPriv methods have defaults that call >> PubToCert and PubToPriv). >> >> With these two simpler approximations, application >> code should be able to do most of the needed real >> world jobs, such as figuring out which useful >> certificates with matching private keys are present >> on an inserted smart card or key fob. >> >> A third item that might be wanted for some engines >> (such as the generic "engine" that can look in >> /etc/ssl/certs) would be a search for certs by exact >> subject distinguished name match, with the >> possibility of returning more than one result (think >> different serials/keyids). >> >> Arbitrary criteria searching would typically end up >> as a loop over enumeration functions anyway. >> >> Searching for chain building purposes can be built >> on top of all this without bloating the EVP and engine >> interfaces with all that code. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
