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

[James Bottomley]

On Tue, 2016-11-22 at 16:28 +0000, David Woodhouse wrote:
> On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
> > 
> > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything
> > else is
> > dwmw2> redundant anyway.
> > 
> > Oh!  Ok, that makes things much simpler (at least in a way)
> 
> Kind of. But then again, there's an argument that it was none of your
> business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to
> the
> TPM engine and after that you really don't care about what's in it.
> 
> Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
> files (no ASN.1 at all). For some reason it didn't use the TssBlob
> object type, although perhaps it should.
> 
> When I started looking at it, I used the -----BEGIN TSS KEY BLOB-----
> for an OCTET STRING containing *just* that the code had previously
> been
> writing into its binary files.
> 
> If I'd been aware of the TssBlob definition at that time, I suppose I
> would have used it instead of just the OCTET STRING. But I didn't.
> 
> If we write an I-D covering the TPM keys, perhaps the PEM contents
> should be permitted to be *either* a raw OCTET STRING with the key
> blob, OR a TssBlob object. Or maybe we should add a
> ----BEGIN TSS BLOB----- (without 'KEY' in it) instead?

Before we rathole on this: if we use the current code to just hand off
to the engine, openssl never needs to know the format of the key files
or even what they mean.  If we hard code recognising TPM keys into
openssl, we are going to have to agree (and stick to) a key format. 
 This is one of the decisions that needs making to transform the RFC
into a real patch.

I will note that gnutls does hard code recognising TPM keys so there's
precedent for doing it that way.  However, I have a marginal preference
for letting the loaded engines do it because that's the way that gives
most flexibility with regard to new engines as they come along.  This
problem isn't theoretical: TPM 2.0 keys are very different from TPM 1.2
ones, so they'll likely have a new engine to handle them and a new file
format.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/a3a3955d/attachment.bin>