EVP-level load_key functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux