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. Most likely (and hopefully) the latter keys will be handled over PKCS#11 rather than directly. regards, Nikos -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
