[openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[James Bottomley]

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-bounces at openssl.org on behalf of 
> James.Bottomley at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161130/4b722030/attachment-0001.bin>