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
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
