In message <1481042048.4406.14.ca...@hansenpartnership.com> on Tue, 06 Dec 2016
08:34:08 -0800, James Bottomley <james.bottom...@hansenpartnership.com> said:
James.Bottomley> On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1480697558.2410.33.ca...@hansenpartnership.com>
on Fri,
James.Bottomley> > 02 Dec 2016 08:52:38 -0800, James Bottomley <
James.Bottomley> > james.bottom...@hansenpartnership.com> said:
James.Bottomley> >
James.Bottomley> > When I made that argument, I hadn't thought and felt things
through
James.Bottomley> > entirely. Truth be told, I'm feeling very uneasy handing
over the
James.Bottomley> > reading and parsing of the PEM file to an engine. However,
handing
James.Bottomley> > over the decoded data and leaving it to the engine to do
something
James.Bottomley> > sensible with it, no issues at all.
James.Bottomley>
James.Bottomley> OK, can I pick on this a bit (I'll look at the store stuff
later and
James.Bottomley> reply after I've played with it)? What is it that you imagine
handing
James.Bottomley> to the engine? Some type of buffer that contains the full PEM
James.Bottomley> representation?
In my STORE branch, you will find this in include/openssl/store_file.h:
/*
* The try_decode function is called to check if the blob of data can
* be used by this handler, and if it can, decodes it into a supported
* OpenSSL and returns a STORE_INFO with the recorded data.
* Input:
* pem_name: If this blob comes from a PEM file, this holds
* the PEM name. If it comes from another type of
* file, this is NULL.
* blob: The blob of data to match with what this handler
* can use.
* len: The length of the blob.
* handler_ctx: For a handler marked repeatable, this pointer can
* be used to create a context for the handler. IT IS
* THE HANDLER'S RESPONSIBILITY TO CREATE AND DESTROY
* THIS CONTEXT APPROPRIATELY, i.e. create on first call
* and destroy when about to return NULL.
* password_ui: Application UI method for getting a password.
* password_ui_data:
* Application data to be passed to password_ui when
* it's called.
* Output:
* a STORE_INFO
*/
typedef STORE_INFO *(*STORE_FILE_try_decode_fn)(const char *pem_name,
const unsigned char *blob,
size_t len,
void **handler_ctx,
const UI_METHOD
*password_ui,
void *password_ui_data);
This is the central function that tries to see if it can decode
whatever's thrown at it. As you can see, it gets handed the PEM name
if it's called as part of a PEM read. The |blob| is the decoded *and
decrypted* data.
James.Bottomley> The reason I chose a BIO is that it's the basic abstract data
handler
James.Bottomley> for openssl. I can hand a buffer to the engine, sure, but I'd
need to
James.Bottomley> transform it to a BIO again (because it would need PEM parsing
and all
James.Bottomley> the PEM parsers speak BIOs), so it feels suboptimal.
With a try_decode function, I really do not see why there's a need to
deal with the BIO...
--
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
