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

Tue Dec 6 14:12:26 UTC 2016

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.

James.Bottomley> If I summarise the arguments about self identifying files from the v1
James.Bottomley> thread:
James.Bottomley> 
James.Bottomley>    1. We agreed that usability is greatly enhanced if openssl simply loads
James.Bottomley>       a key when presented with the file/uri etc. without the user having
James.Bottomley>       to specify what the format of a key is

Check.  My STORE branch is made to support that.

James.Bottomley>    2. For PEM files, we believe this is easy because the guards uniquely
James.Bottomley>       identify the file format, so whatever key the application needs, we
James.Bottomley>       can verify is contained in the thing presented

Check.

James.Bottomley>    3. THere was more debate on the files that aren't fully self
James.Bottomley>       describing, like DER.  The argument was that the DER structure is
James.Bottomley>       usually unique enough, so we could do this, but there were
James.Bottomley>       reservations.

Yup...  The current TSS KEY BLOB is among those reservations ;-)

James.Bottomley>    4. I thought there was agreement that we could move forwards with the
James.Bottomley>       PEM bit because it was uncontroversial

We're not quite on the same page regarding the exact implementation.
However, I think I have a solution...

James.Bottomley> The current PEM key loading code is already hooked for PKCS8, to make
James.Bottomley> the above a reality, we should hook it for pkcs12 as well.  Once you
James.Bottomley> have the store code, I believe it should be hooked for this as well. 
James.Bottomley>  In this scenario, I don't quite see why it's not a hack to hook for
James.Bottomley> pkcs8 (and presumably 12) but it is a hack to hook for engines and
James.Bottomley> store.
James.Bottomley> 
James.Bottomley> If we agree on DER, the ideal world becomes all apps simply use
James.Bottomley> OPENSSL_load_privkey() and no-one needs to worry about format for key
James.Bottomley> loading because any reasonable format just works.

I toyed around with the idea that I already mentioned, that instead of
passing the BIO and have the engine read it at its leasure, there
would be a STORE call after the PEM_bytes_read_bio() call in
PEM_read_bio_PrivateKey(), where the decoded data would be passed in
the STORE call.  The result is a branch of mine that I haven't made
into a PR, built in top of my STORE branch:

https://github.com/levitte/openssl/tree/tpm_engine-support

Please have a look, and especially at these changes:

https://github.com/levitte/openssl/commit/ae9f05a9d8d60e2c05d8f3b442161e648d1a0738

I think they should fit your bill fairly well, all that's needed is
that you add a store file handler to e_tpm.c (I did toy around with
that as well, but it's too dependent on pre 1.1.0 OpenSSL, I didn't
want to spend more time clearing that up).  I have an untested patch
that I can send you if you want.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/