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
> 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
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.
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev