[openssl-dev] [RFC v2 2/2] pem: load engine keys

Roumen Petrov openssl at roumenpetrov.info
Sun Dec 11 15:59:07 UTC 2016


HI Richard,

Richard Levitte wrote:
> In message<58472E4F.3010204 at roumenpetrov.info>  on Tue, 06 Dec 2016 23:31:59 +0200, Roumen Petrov<openssl at roumenpetrov.info>  said:
>
> openssl> Hi Richard,
> openssl>
> [SNIP]
> openssl> > Check.  My STORE branch is made to support that.
> openssl> One URI could represent more then one item.
> openssl> STORE_INFO_types is enumerate but URI could be associated to custom
> openssl> data (handle) and this data could be used to get other data(handles).
> openssl>
> openssl> See capi engine CAPI_KEY *capi_find_key(CAPI_CTX * ctx, const char
> openssl> *id)
> [SNIP]
> openssl> Is above case PKEY is loaded only if CERT is located(found).
>
> I'm trying to understand but am failing.  Looking at your example,
> it's quite clear that what you want to retrieve is a key, even though
> you have to go through the corresponding certificate to get to it.
After first review of API delared in openssl/store.h I misunderstand 
goal of load method.

I think that code of capi engine could be considered as sample what is 
need for an loadable module (engine) to use "OpenSSL Store API". I post 
above code just to get idea where currently is used an "external store api".
Just imagine how existing capi code could be changed to use store-API 
and to implement loader(scheme?).

I'm asking as currently there is no interface (API) that could associate 
key (private) and X.509 certificate. Currently engines implement custom 
command as work-around. For instance LOAD_CERT_CTRL (pkcs11 and e_nss) 
and LOAD_CERT_EVP(e_nss).

This one of areas where applications could benefit from "Store API".

I post a sniped from CAPI code because it is part of OpenSSL, but king 
of "external store api" is used by other engines.


> However,*nothing*  stops anyone from making a loader for the "capi"
> scheme (if there is such a thing) that has a load method that will
> return the certificate (STORE_INFO_CERT) on the first call and the
> associated key (STORE_INFO_PKEY) on the second for the same URI.  It's
> all about caching information, and there is a context variable (type
> STORE_LOADER_CTX, which is just a template type for loader defined
> 'struct store_loader_ctx_st') to be used exactly for that kind of
> purpose.

I guess that "load" method is supposed to return all data at once.

Actually it is an iterator!

Please update comments before method and if possible to change name of 
method.


> [SNIP]
> In your example above, I fail to see where the custom data would be
> needed...  And frankly, STORE is first of all meant to handle types
> that can be used with the rest of OpenSSL.  That being said, adding a
> "whatever" STORE_INFO type isn't very hard either.  I'm just not
> terribly convinced yet, but let's keep talking, I'll probably
> understand sooner or later what you're actually after.
I also fail to see why a store scheme has to return "custom data". Note 
that thread start from request for load TPM keys and some one mention 
that TMP key has custom data.


In addition to load of key from file there is one another interfaces 
where could be used store api - see RT4681.
The goal is expired from fact that X.509 load method is hidden in 
OpenSSL 1.1.
I guess that "by dir" and "by file" could be updated to use store api. 
Also applications has to able to register that a "store scheme" could by 
used by X.509 lookups.


> Cheers,
> Richard ( oh, and if example code is needed, I can provide )

+4 for OpenSSL store api ;)

Regards,
Roumen



More information about the openssl-dev mailing list