<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/08/2015 01:06, Dr. Stephen Henson
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_20150806230618_GA26266_openssl_org"
cite="mid:20150806230618.GA26266@openssl.org" type="cite">
<pre wrap="">On Thu, Aug 06, 2015, Reinier Torenbeek wrote:
</pre>
<blockquote class=" cite" id="Cite_4344001" type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/openssl-users@openssl.org/msg77566.html">http://www.mail-archive.com/openssl-users@openssl.org/msg77566.html</a>). Is
it planned for any future release?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote class=" cite" id="Cite_2038707" type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<tt>I think what one wants as a first approximation is <br>
functions that can enumerate and load keys and <br>
certificates from "engine storage", such as smart <br>
cards (most engines would obviously load only <br>
"proxy structures/handles" when asked to load a <br>
private key).<br>
<br>
E.g. <br>
<br>
PSOME_PRIVKEY_TYPE EVP_EnumPrivKeys(T hEngine, ofs_t i);<br>
<br>
PSOME_PUBKEY_TYPE EVP_EnumPubKeys(</tt><tt><tt>T hEngine, </tt>ofs_t
i);<br>
<br>
PSOME_CERT_TYPE EVP_EnumCerts(</tt><tt><tt>T hEngine, </tt>ofs_t
i);<br>
<br>
Each will return either:<br>
<br>
The item at index i in engine storage<br>
<br>
NULL for no such item at index i<br>
<br>
(void*)(size_t)(1) for "i past last currently <br>
valid index for such items"<br>
<br>
Engines would have some leeway if they will return <br>
NULL or 1 for some values slightly past last index, <br>
and if there will be any relationships between indexes <br>
for different types.<br>
<br>
A second order approximation would be functions <br>
that can look for matching triplets: <br>
Given a public key, private key or certificate, <br>
load a matching item of one of the other 2 kinds, <br>
if present in storage, or return a "not found" <br>
error (of cause the cases of private key or cert <br>
to public key mapping are already trivial without <br>
calling the engine, the remaining 4 cases are the <br>
interesting ones, some engines can do them <br>
efficiently others would fall back to generic EVP <br>
layer loops over the first order enumeration <br>
functions and a generic EVP layer public key <br>
compare). Note, I can imagine engines that can <br>
quickly go between private keys and certs, but not <br>
from public key to either, so all 4 cases need to <br>
be exposed to the engine level, even if (PrivToCert <br>
and CertToPriv methods have defaults that call <br>
PubToCert and PubToPriv).<br>
<br>
With these two simpler approximations, application <br>
code should be able to do most of the needed real <br>
world jobs, such as figuring out which useful <br>
certificates with matching private keys are present <br>
on an inserted smart card or key fob.<br>
</tt><br>
<tt>A third item that might be wanted for some engines <br>
(such </tt><tt></tt><tt>as the generic "engine" that can look in <br>
/etc/ssl/certs) would be </tt><tt>a search for certs by exact <br>
subject distinguished name match, </tt><tt>with the <br>
possibility of returning more than one result (think <br>
different serials/keyids).<br>
</tt><tt></tt><br>
<tt>Arbitrary criteria searching would typically end up <br>
as a loop over enumeration functions anyway.<br>
<br>
Searching for chain building purposes can be built <br>
on top of all this without bloating the EVP and engine <br>
interfaces with all that code.<br>
<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
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 </pre>
</body>
</html>