[openssl-users] EVP-level load_key functions

[Jakob Bohm]

On 07/08/2015 01:06, Dr. Stephen Henson wrote:
> On Thu, Aug 06, 2015, Reinier Torenbeek wrote:
>
>> I am interested in leveraging the following three functions:
>>
>> ENGINE_load_private_key()
>> ENGINE_load_public_key()
>> ENGINE_load_certificate()
>>
>> Unfortunately, the latter is missing. This was mentioned in a recent
>> thread on this list as well (see
>> http://www.mail-archive.com/openssl-users@openssl.org/msg77566.html). Is
>> it planned for any future release?
>>
> At some point yes but it's quite complex decided what the parameters should
> be: e.g. to lookup certificates matching one or more criteria.
>
>
>> The former two functions are present though and I was looking for their
>> EVP-level counterparts to access them in the proper way. Apparently,
>> those do not exist either. Previously, I was under the impression that
>> the EVP API exposes all engine-implemented functions. Are these
>> EVP_load_xxx functions missing from EVP because they are "todo in a
>> future release" or are they omitted by design?
>>
> The ENGINE_load*key functions rerturn an EVP_PKEY structure which can be
> used by EVP directly.
>
> There are other functions which can load an EVP_PKEY structure too like the
> PEM and PKCS12 functions.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150807/ed8455e8/attachment-0001.html>