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

[David Woodhouse]

On Mon, 2016-11-21 at 13:50 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> Frankly, I think this approach of specially-encoded PEM or DER files
> telling the app what key to ask from the engine is madness, compared
> to the straightforward URI approach (no pun intended :).

Right. There are two separate things that the TPM can do for keys.

There is storage in the TPM itself, and you can reference a key therein
by its UUID. In Nikos's draft, and in GnuTLS, you end up with something
like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user

To use a PEM file for that does seem like madness; I agree.

However, Nikos's draft also supports a URI of the form:
 tpmkey:file=/foo/bar/key.pem

This, I do not like. It runs entirely contrary to my assertion in
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that
applications should Just Bloody Work with whatever file they're handed,
without needing to be *told* what the file contains.

Besides, it requires files in the form described by the Portable Data
section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
(which is mostly redundant as in this case we're always talking about
key blobs), the blob length (which is entirely redundant) and then the
actual blob as an OCTET STRING. I don't know of any tool which actually
creates such files.

The -----BEGIN TSS KEY BLOB----- PEM files which are created and used
by both GnuTLS and OpenSSL TPM engine contain *just* the OCTET STRING
containing the blob itself.

I assert that if the application is given such a PEM blob (by filename,
or just text embedded in a configuration file, or whatever), then it
MUST NOT require any further information about the contents of that
blob, except perhaps a password.

I have updated my draft with a section about TPM keys:
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4

We should probably consolidate Nikos's now-expired draft with a
documentation of the -----BEGIN TSS KEY BLOB----- PEM format, as well
as bringing it up to date with the v2.0 specifications as appropriate.

I'd *like* to think that we can punt it to PKCS#11 at least for TPM2,
but I'm not sure. PKCS#11 doesn't make it easy to deal with the fact
that there can be multiple PINs for the various keys in the chain, and
doesn't easily cope with the fact that the key material might not be
stored in the TPM and accessible by reference; it actually has to be
*loaded*. I do not want to inflict another horror like nss-pem on the
world... :)

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