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

[Richard Levitte]

In message <584d77cb.7090...@roumenpetrov.info> on Sun, 11 Dec 2016 17:59:07 
+0200, Roumen Petrov  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 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 

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

[Richard Levitte]

Roumen Petrov  skrev: (11 december 2016 17:31:10 CET)
>Hi Richard,
>
>Richard Levitte wrote:
>> In message<20161206.223057.237264374331072901.levi...@openssl.org> 
>on Tue, 06 Dec 2016 22:30:57 +0100 (CET), Richard
>Levitte  said:
>>
>> levitte> [SNIP]
>>
>> The easiest was actually to rewrite PEM_read_bio_PrivateKey()
>> entirely, so it solely uses the internal store_file functions I've
>> provided.
>> I wonder what kind of impact this would have on the community at
>> large.
>
>PEM_read_bio_PrivateKey use custom password callback . You propose
>"Store-API" with UI_METHOD  as password callback.
>Rewrite of pem_read... method obsoletes pem_password_cb.
>
>What about to ensure a transition period?
>For instance in openssl 1.1 to provide new functions based on UI_METHOD
>and to mark existing as deprecated.
>
>
>One remark for store load function api - in most cases (load from file)
>it is password callback but is other cases it could be PIN or something
>different.
>Please use more generic description.
>For instance engine callback is defined in generic way -  ui_method and
>its callback_data.

Earlier, I mentioned an experimental branch, 
https://github.com/levitte/openssl/tree/tpm_engine-support?files=1

If you have a look, you'll find an added UI utility function to wrap a pem 
password callback in a UI_METHOD. 

>
> 
>
>> Cheers,
>> Richard
>
>Regards,
>Roumen

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Roumen Petrov]

Hi Richard,

Richard Levitte wrote:

In message<20161206.223057.237264374331072901.levi...@openssl.org>  on Tue, 06 Dec 
2016 22:30:57 +0100 (CET), Richard Levitte  said:

levitte> [SNIP]

The easiest was actually to rewrite PEM_read_bio_PrivateKey()
entirely, so it solely uses the internal store_file functions I've
provided.
I wonder what kind of impact this would have on the community at
large.


PEM_read_bio_PrivateKey use custom password callback . You propose "Store-API" 
with UI_METHOD  as password callback.
Rewrite of pem_read... method obsoletes pem_password_cb.

What about to ensure a transition period?
For instance in openssl 1.1 to provide new functions based on UI_METHOD and to 
mark existing as deprecated.


One remark for store load function api - in most cases (load from file) it is 
password callback but is other cases it could be PIN or something different.
Please use more generic description.
For instance engine callback is defined in generic way -  ui_method and its 
callback_data.




Cheers,
Richard


Regards,
Roumen
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Roumen Petrov]

HI Richard,

Richard Levitte wrote:

In message<58472e4f.3010...@roumenpetrov.info>  on Tue, 06 Dec 2016 23:31:59 +0200, 
Roumen Petrov  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

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev