In message <1479744347.2309.21.ca...@hansenpartnership.com> on Mon, 21 Nov 2016 08:05:47 -0800, James Bottomley <james.bottom...@hansenpartnership.com> said:
James.Bottomley> On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote: James.Bottomley> > On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote: James.Bottomley> > > James.Bottomley> > > Many years ago, I was thinking of something along the same lines, James.Bottomley> > > but with a .pem file that would just have a few headers, holding James.Bottomley> > > the name of the intended engine and the key identity, something James.Bottomley> > > like this: James.Bottomley> > > James.Bottomley> > > -----BEGIN PRIVATE KEY----- James.Bottomley> > > X-key-id: flarflarflar James.Bottomley> > > X-key-engine: foo James.Bottomley> > > -----END PRIVATE KEY----- James.Bottomley> > > James.Bottomley> > > The intent was that the PEM code would be massaged to recognise James.Bottomley> > > these headers and would then use ENGINE_by_id() / James.Bottomley> > > ENGINE_load_private_key() with those data and that would be it. James.Bottomley> > > James.Bottomley> > > James, did I catch your intention about right? I think that's James.Bottomley> > > essentially what e_tpm.c does for loading keys, right? James.Bottomley> James.Bottomley> Yes, that's right. When any SSL program sees a TPM wrapped key, it James.Bottomley> should just do the right thing if it has the engine capability without James.Bottomley> needing the user to add any options to the command line. Mm... I'm not sure I agree with the method, passing a BIO for the key_id. I would much rather have seen a patch where OpenSSL's PEM module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing it somehow (since key_id is expected to be be NUL terminated) and pass that to the engine. James.Bottomley> > Once the dust settles on TPMv2.0 we should probably put together an I James.Bottomley> > -D for the TPM-wrapped blob PEM files. And I should definitely add James.Bottomley> > something about them to ยน. James.Bottomley> James.Bottomley> Once we agree, I'll be happy to write up something. We can use the pem James.Bottomley> header concept to extend this format if it becomes necessary. My vote goes to a URI based spec rather than bastardising PEM files. I understand this kinda throws years of developmemt out the window, but there you have it. -- 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
