James Bottomley <james.bottom...@hansenpartnership.com> skrev: (1 december 2016 
00:42:09 CET)
>On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
>> This patch doesn't fit the rest... 
>
>I'm not quite sure I follow why.

It casts bp to const char *. That was for your earlier implementation, wasn't 
it? It doesn't fit the latest incarnation of your API. 

>> Generally speaking, I am unsure about your solution. It seems like
>> hack to fit a specific case where something more general could be of
>> greater service to others as well. 
>
>Well, the more adaptable patch set was the previous one that overloaded
>the meaning of key_id.  This one has a specific bio mechanism for
>loading PEM files, so it only really works for engines that have PEM
>representable unloaded keys (which, to be fair, is almost all of them,
>since even the USB crypto keys have a wrapped format).
>
>I've tried to make it as generic as possible, but I am conditioned to
>think to my use case: TPM keys.  If you give an example of another use
>case, it will help me see where it should be more generic.

Among other things, I'd rather not encourage an API that inherently makes the 
engine<->libcrypto tie even tighter. Also, it puts a requirement on the engine 
to parse PEM, which is unnecessary. 

Also, we already have thoughts on loading keys by uri references, and there may 
be new ideas and formats coming in the future. All this is tied together and 
solving it one small hack at a time is sub-optimal in the long run. 

I'll repeat myself again, please have a look at the STORE stuff I'm working on. 
TPM files could very well serve as a first use case. 

>James
>
>
>> Cheers 
>> Richard 
>> 
>> On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley <
>> james.bottom...@hansenpartnership.com> wrote:
>> > Before trying to process the PEM file, hand it to each of the
>> > loaded
>> > engines to see if they recognise the PEM guards.  This uses the new
>> > bio based load key callback, so the engine must be loaded and
>> > implement this callback to be considered.
>> > 
>> > Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com>
>> > ---
>> > crypto/pem/pem_pkey.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> > 
>> > diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
>> > index 04d6319..e3737f0 100644
>> > --- a/crypto/pem/pem_pkey.c
>> > +++ b/crypto/pem/pem_pkey.c
>> > @@ -85,6 +85,10 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp,
>> > EVP_PKEY
>> > **x, pem_password_cb *cb,
>> >     int slen;
>> >     EVP_PKEY *ret = NULL;
>> > 
>> > +    /* first check to see if an engine can load the PEM */
>> > +    if (ENGINE_find_engine_load_key(NULL, &ret, (const char *)bp,
>> > cb,
>> > u) == 1)
>> > +        return ret;
>> > +
>> > if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY, bp,
>> > cb,
>> > u))
>> >         return NULL;
>> >     p = data;
>> 
>> -- 
>> levi...@openssl.org 

-- 
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

Reply via email to