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

[James Bottomley]

On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote:
> In message <1480697558.2410.33.camel at HansenPartnership.com> on Fri,
> 02 Dec 2016 08:52:38 -0800, James Bottomley <
> James.Bottomley at HansenPartnership.com> said:
> 
> James.Bottomley> On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte
> wrote:
> James.Bottomley> > 
> James.Bottomley> > James Bottomley <
> James.Bottomley at HansenPartnership.com> skrev: (1
> James.Bottomley> > december 2016 07:36:26 CET)
> James.Bottomley> > > On Thu, 2016-12-01 at 01:38 +0100, Richard
> Levitte wrote:
> James.Bottomley> > > > 
> James.Bottomley> > > > James Bottomley <
> James.Bottomley at HansenPartnership.com> skrev: (1
> James.Bottomley> > > > december 2016 00:42:09 CET)
> James.Bottomley> [...]
> James.Bottomley> > > > > On Thu, 2016-12-01 at 00:22 +0100, Richard
> Levitte wrote:
> James.Bottomley> > > > > > Generally speaking, I am unsure about your
> solution. It seems
> James.Bottomley> > > > > > like hack to fit a specific case where
> something more general
> James.Bottomley> > > > > > could be of greater service to others as
> well.
> James.Bottomley> > > > > 
> James.Bottomley> > > > > Well, the more adaptable patch set was the
> previous one that 
> James.Bottomley> > > > > overloaded the meaning of key_id.  This one
> has a specific bio 
> James.Bottomley> > > > > mechanism for loading PEM files, so it only
> really works for 
> James.Bottomley> > > > > engines that have PEM representable unloaded
> keys (which, to be
> James.Bottomley> > > > > fair, is almost all of them, since even the
> USB crypto keys 
> James.Bottomley> > > > > have a wrapped format).
> James.Bottomley> > > > > 
> James.Bottomley> > > > > I've tried to make it as generic as
> possible, but I am 
> James.Bottomley> > > > > conditioned to think to my use case: TPM
> keys.  If you give an 
> James.Bottomley> > > > > example of another use case, it will help me
> see where it 
> James.Bottomley> > > > > should be more generic.
> James.Bottomley> > > > 
> James.Bottomley> > > > Among other things, I'd rather not encourage
> an API that 
> James.Bottomley> > > > inherently makes the engine<->libcrypto tie
> even tighter. Also, 
> James.Bottomley> > > > it puts a requirement on the engine to parse
> PEM, which is
> James.Bottomley> > > > unnecessary.
> James.Bottomley> 
> James.Bottomley> Actually, I missed this initially.  This is
> definitely not a
> James.Bottomley> requirement: engines that wish to parse PEM keys may
> do so, but an
> James.Bottomley> engine that doesn't simply doesn't implement the
> callback.  Only
> James.Bottomley> engines that are loaded from the configuration file
> actually get asked
> James.Bottomley> if they understand the key, and then only if they
> supply the callback,
> James.Bottomley> so this is a decision on which engines to is made by
> the admin or
> James.Bottomley> packager (and the engine builder, who decides
> whether to implement or
> James.Bottomley> not).
> 
> When I made that argument, I hadn't thought and felt things through
> entirely.  Truth be told, I'm feeling very uneasy handing over the
> reading and parsing of the PEM file to an engine.  However, handing
> over the decoded data and leaving it to the engine to do something
> sensible with it, no issues at all.

OK, can I pick on this a bit (I'll look at the store stuff later and
reply after I've played with it)?  What is it that you imagine handing
to the engine?  Some type of buffer that contains the full PEM
representation?

The reason I chose a BIO is that it's the basic abstract data handler
for openssl. I can hand a buffer to the engine, sure, but I'd need to
transform it to a BIO again (because it would need PEM parsing and all
the PEM parsers speak BIOs), so it feels suboptimal.

James