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

[Richard Levitte]

In message <584D77CB.7090307 at roumenpetrov.info> on Sun, 11 Dec 2016 17:59:07 +0200, Roumen Petrov <openssl at roumenpetrov.info> said:

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

Actually, it did change at one point.  Oh, and just so we're all on
the same page, I started over a few weeks ago, when Rich Salz
expressed some concerns with the previous "grab everything" load
call.  The active branch is "store2", available as this pull request:

https://github.com/openssl/openssl/pull/2011

(I can't remember if I said that already)

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

I don't know CAPI at all, really, so whatever scheme is used will
depend on what CAPI provides.  From a quick read of the docs, it looks
like simple files, and it's possible that a few extra file handlers
(which are another set of dynamically definable functions within the
STORE 'file' scheme) will suffice.

openssl> I'm asking as currently there is no interface (API) that could
openssl> associate key (private) and X.509 certificate. Currently engines
openssl> implement custom command as work-around. For instance LOAD_CERT_CTRL
openssl> (pkcs11 and e_nss) and LOAD_CERT_EVP(e_nss).
openssl> 
openssl> This one of areas where applications could benefit from "Store API".

That's exactly the sort of thing I'm aiming for :-)

openssl> I post a sniped from CAPI code because it is part of OpenSSL, but king
openssl> of "external store api" is used by other engines.
openssl> 
openssl> 
openssl> > However,*nothing*  stops anyone from making a loader for the "capi"
openssl> > scheme (if there is such a thing) that has a load method that will
openssl> > return the certificate (STORE_INFO_CERT) on the first call and the
openssl> > associated key (STORE_INFO_PKEY) on the second for the same URI.  It's
openssl> > all about caching information, and there is a context variable (type
openssl> > STORE_LOADER_CTX, which is just a template type for loader defined
openssl> > 'struct store_loader_ctx_st') to be used exactly for that kind of
openssl> > purpose.
openssl> 
openssl> I guess that "load" method is supposed to return all data at once.
openssl> 
openssl> Actually it is an iterator!

Yes.  That was a change that happened a few weeks ago

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

I don't know how up to date you are.  This is the current comment for
STORE_load() in store.h:

    /*
     * Read one data item (a key, a cert, a CRL) that is supported by the STORE
     * functionality, given a context.
     * Returns a STORE_INFO pointer, from which OpenSSL typed data can be extracted
     * with STORE_INFO_get0_PKEY(), STORE_INFO_get0_CERT(), ...
     * NULL is returned on error, which may include that the data found at the URI
     * can't be figured out for certain or is ambiguous.
     */
    STORE_INFO *STORE_load(STORE_CTX *ctx);

If STORE_load() is a bad name, what would you suggest that makes it
better?

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

Well, as far as I understand, the "custom data" is extra data
associated with a key that's used for key access, not free floating
individual data that needs to be returned.  I think that's different.

openssl> I guess that "by dir" and "by file" could be updated to use store
openssl> api. Also applications has to able to register that a "store scheme"
openssl> could by used by X.509 lookups.

Yes, I expect that to happen.  It will not necessarely be part of my
store branch, but I expect things to happen organically after it's
been approved (which I certainly hope it will).

openssl> > Cheers,
openssl> > Richard ( oh, and if example code is needed, I can provide )
openssl> 
openssl> +4 for OpenSSL store api ;)

:-)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/