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

[James Bottomley]

On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote:
> 
> James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
> december 2016 07:36:26 CET)
> > On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
> > > 
> > > James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
> > > december 2016 00:42:09 CET)
[...]
> > > > On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
> > > > > 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.

Actually, I missed this initially.  This is definitely not a
requirement: engines that wish to parse PEM keys may do so, but an
engine that doesn't simply doesn't implement the callback.  Only
engines that are loaded from the configuration file actually get asked
if they understand the key, and then only if they supply the callback,
so this is a decision on which engines to is made by the admin or
packager (and the engine builder, who decides whether to implement or
not).

> > > 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.
> > 
> > That's this new pull request:
> > 
> > https://github.com/openssl/openssl/pull/2011/files
> 
> Yes. 
> 
> > Just so I understand you, you mean register a store handler from 
> > the engine for the TPM BLOB PEM files so that a reference to the 
> > file via the store can use the PEM file as an EVP_PKEY?
> 
> Essentially, yes. 
> 
> > That will work, I'm just not clear from the current pull request 
> > how the store would be integrated with the existing PEM file
> > handler
> > ...
> > Will every application have to be modified to use the new store, or
> > will you hook it like I did for the engine keys?
> 
> Generally speaking, I was thinking that applications would move to
> use the STORE API. 
> 
> > The think I'm looking for is to have a TPM PEM key file just work 
> > in place of a standard RSA private key file.
> 
> I get your point. That could be med as a call after the 
> PEM_bytes_read_bio call. At that point, the necessary data for an 
> internal store loading are available. It's still a hack, but if you 
> must... 

If I summarise the arguments about self identifying files from the v1
thread:

   1. We agreed that usability is greatly enhanced if openssl simply loads
      a key when presented with the file/uri etc. without the user having
      to specify what the format of a key is
   2. For PEM files, we believe this is easy because the guards uniquely
      identify the file format, so whatever key the application needs, we
      can verify is contained in the thing presented
   3. THere was more debate on the files that aren't fully self
      describing, like DER.  The argument was that the DER structure is
      usually unique enough, so we could do this, but there were
      reservations.
   4. I thought there was agreement that we could move forwards with the
      PEM bit because it was uncontroversial

The current PEM key loading code is already hooked for PKCS8, to make
the above a reality, we should hook it for pkcs12 as well.  Once you
have the store code, I believe it should be hooked for this as well. 
 In this scenario, I don't quite see why it's not a hack to hook for
pkcs8 (and presumably 12) but it is a hack to hook for engines and
store.

If we agree on DER, the ideal world becomes all apps simply use
OPENSSL_load_privkey() and no-one needs to worry about format for key
loading because any reasonable format just works.

James