[openssl-users] EVP-level load_key functions

[Jakob Bohm]

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