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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
