In message <584d77cb.7090...@roumenpetrov.info> on Sun, 11 Dec 2016 17:59:07 +0200, Roumen Petrov <open...@roumenpetrov.info> said:
openssl> HI Richard, openssl> openssl> Richard Levitte wrote: openssl> > In message<58472e4f.3010...@roumenpetrov.info> on Tue, 06 Dec 2016 openssl> > 23:31:59 +0200, Roumen Petrov<open...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
