On Wed, 2016-11-30 at 21:18 +0000, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" < > openssl-dev-boun...@openssl.org on behalf of > james.bottom...@hansenpartnership.com> wrote: > > > One of the principle problems of using TPM based keys is that > there's > > no easy way of integrating them with standard file based keys. > > Why should token- and/or TPM-based keys be integrated with file-based > keys? OpenSSL and its engines need/should accept URI pointing at the > keys. Pointing them at files containing some proprietary reference to > keys that are kept in hardware does not seem to make sense. > > 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. 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). There is no URI reference (other than a file one) because any key so described may exist only in the file and don't have to be part of the tpm token infrastructure. To make use of it, the engine first has to load the key into the TPM. It's actually a simpler way of handling keys than loading them into the TPM pkcs11 token infrastructure and naming them by slot and key 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). James
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev