On Wed, 2016-11-30 at 21:41 +0000, Blumenthal, Uri - 0553 - MITLL
>     >> So why is it better to say “…engine –key
> /some/weird/path/weird
>     >> -file.pem” than “…engine –key pkcs11:id=02” (or such)?
>     >
>     > There appears to be some confusion here.  pkcs11 is a
> representation
>     > for defined tokens. 
> Well, I did not mean *specifically* pkcs11 – just as an example of
> something that currently works.
>     > However, for TPM, there's also file representation
>     > of an unloaded key (it has to be parented or "wrapped" to one
> of the
>     > loaded storage keys, usually the SRK). 
> So this PEM wrapping is needed just to load keys into TPM? How do you
> refer to those keys when they are already loaded?

The keys are TPM volatile, so they're effectively unloaded as soon as
you close the TPM connection.  The engine code to use them is here


the TPM connection is from engine init to engine finish and once the
key is loaded, it stays in the TPM until engine finish.  create_tpm_key
is what takes a standard RSA key and wraps it to the SRK as a volatile
key for the TPM.

>     > 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. 

I like it because it's easier than trying to set up and use TPM token,
which seems to be very hard without admin privileges (the PEM file
approach can be used by any user of the system provided the SRK has a
well known authority).


Attachment: smime.p7s
Description: S/MIME cryptographic signature

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to