[openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Richard Levitte levitte at openssl.org
Tue Nov 22 12:48:59 UTC 2016


In message <1479744347.2309.21.camel at HansenPartnership.com> on Mon, 21 Nov 2016 08:05:47 -0800, James Bottomley <James.Bottomley at 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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/


More information about the openssl-dev mailing list