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

2016-11-21 Thread Richard Levitte
I'm leaning in that direction as well. Speaking of URIs, you might be interested in some work I did last week, which would do good to get a bit of external scrutiny. https://github.com/openssl/openssl/pull/1961 (for URI decoding) https://github.com/openssl/openssl/pull/1962 (a STORE module that

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

2016-11-21 Thread David Woodhouse
On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote: > > Many years ago, I was thinking of something along the same lines, but > with a .pem file that would just have a few headers, holding the name > of the intended engine and the key identity, something like this: > >     -BEGIN

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

2016-11-21 Thread Blumenthal, Uri - 0553 - MITLL
Frankly, I think this approach of specially-encoded PEM or DER files telling the app what key to ask from the engine is madness, compared to the straightforward URI approach (no pun intended :). Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message  

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

2016-11-21 Thread Nikos Mavrogiannopoulos
On Mon, 2016-11-21 at 13:42 +, David Woodhouse wrote: > Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I > added that a few years back (it used to just dump the binary blob > instead). Both the TPM ENGINE and GnuTLS will load those files, as > noted at

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

2016-11-21 Thread James Bottomley
On Mon, 2016-11-21 at 13:42 +, David Woodhouse wrote: > On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote: > > > > Many years ago, I was thinking of something along the same lines, > > but with a .pem file that would just have a few headers, holding > > the name of the intended