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

[Richard Levitte]

In message <1479833048.2376.21.camel at HansenPartnership.com> on Tue, 22 Nov 2016 08:44:08 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Tue, 2016-11-22 at 16:28 +0000, David Woodhouse wrote:
James.Bottomley> > On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
James.Bottomley> > > 
James.Bottomley> > > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything
James.Bottomley> > > else is
James.Bottomley> > > dwmw2> redundant anyway.
James.Bottomley> > > 
James.Bottomley> > > Oh!  Ok, that makes things much simpler (at least in a way)
James.Bottomley> > 
James.Bottomley> > Kind of. But then again, there's an argument that it was none of your
James.Bottomley> > business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to
James.Bottomley> > the
James.Bottomley> > TPM engine and after that you really don't care about what's in it.
James.Bottomley> > 
James.Bottomley> > Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
James.Bottomley> > files (no ASN.1 at all). For some reason it didn't use the TssBlob
James.Bottomley> > object type, although perhaps it should.
James.Bottomley> > 
James.Bottomley> > When I started looking at it, I used the -----BEGIN TSS KEY BLOB-----
James.Bottomley> > for an OCTET STRING containing *just* that the code had previously
James.Bottomley> > been
James.Bottomley> > writing into its binary files.
James.Bottomley> > 
James.Bottomley> > If I'd been aware of the TssBlob definition at that time, I suppose I
James.Bottomley> > would have used it instead of just the OCTET STRING. But I didn't.
James.Bottomley> > 
James.Bottomley> > If we write an I-D covering the TPM keys, perhaps the PEM contents
James.Bottomley> > should be permitted to be *either* a raw OCTET STRING with the key
James.Bottomley> > blob, OR a TssBlob object. Or maybe we should add a
James.Bottomley> > ----BEGIN TSS BLOB----- (without 'KEY' in it) instead?
James.Bottomley> 
James.Bottomley> Before we rathole on this: if we use the current code to just hand off
James.Bottomley> to the engine, openssl never needs to know the format of the key files
James.Bottomley> or even what they mean.  If we hard code recognising TPM keys into
James.Bottomley> openssl, we are going to have to agree (and stick to) a key format. 
James.Bottomley>  This is one of the decisions that needs making to transform the RFC
James.Bottomley> into a real patch.
James.Bottomley> 
James.Bottomley> I will note that gnutls does hard code recognising TPM keys so there's
James.Bottomley> precedent for doing it that way.  However, I have a marginal preference
James.Bottomley> for letting the loaded engines do it because that's the way that gives
James.Bottomley> most flexibility with regard to new engines as they come along.  This
James.Bottomley> problem isn't theoretical: TPM 2.0 keys are very different from TPM 1.2
James.Bottomley> ones, so they'll likely have a new engine to handle them and a new file
James.Bottomley> format.

Actually, I agree with this, and that goes along with how our PEM
routines work (specifically, PEM_X509_INFO_read_bio()), it just
treats the data as an octet string and hands it down to a d2i routine
of choice, with a pointer to where to place the result.

It's not very hard to imagine adding the possibility for external
handlers for specific PEM content types, which could be handed an
octet string and a pointer to a X509_INFO (which is the structure used
to collect the data in), or something like that (I can also imagine
having one separate handler for each type of data that can be
returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
and so on and so forth).  That would make it possible for an engine to
declare its own handler during the binding call, along with all other
information it feeds back to libcrypto.

Cheers,
Richard

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