On Thu, 2016-12-01 at 12:49 +0100, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote: > > > > > The point here is that because there's a pem file > > > representation of the > > > > key, it can be used anywhere a PEM file can be *without* > > > having > > > to tell > > > > openssl what the engine is (the PEM guards being unique to > > > the > > > key > > > > type). > > > > > > Well, I think I can see your point (except for the above > > > question), but frankly I don’t like this approach very much. > > > > It's already a mechanism used by gnutls to load TPM keys, so it > > makes sense from a compatibility point of view that it should just > > work for openssl as well. It doesn't preclude using a pkcs11 token > > approach as well, it's just a different mechanism for handling > > keys. > > Note that gnutls' mechanism relies on the "tpmkey:" URLs to load > them, rather than loading via any other PEM mechanism. The URL > approach has the advantage that it provides a uniformity in handling > similar to PKCS#11 URLs (and it wouldn't matter whether these keys > are in file, in the TPM itself or in some other OS storage area - you > specify them all the same). > > However, neither of URLs or file loading would survive the TPM 2.0 > thing.
Actually, I believe it will. The main difference is that TPM2 has multiple SRKs so you need to know which one, plus TSS2 will be different from TSS1 so they can't be handled by the same engine: so the format will have a new guard (TSS2 KEY BLOB probably) and the multiple root can be coped with by specifying the root as a PEM parameter). Incidentally, a similar problem does exist in TPM1: although everything chains up to a single SRK, you can have multiple sub SRK storage keys to which the keys are wrapped. Right at the moment, the current openssl_tpm_engine doesn't contemplate this possibility, but I'm thinking of extending it to do so, because it's useful when doing TPM tenancy (cloud container use case). > Most likely (and hopefully) the latter keys will be handled over > PKCS#11 rather than directly. I have reservations about scaling pkcs11 into a multi-tenant environment, but I agree, in principle it is possible. I'm looking at trying to do it better for TPM now (well, it's the next thing to get to on my list). James -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
