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

[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
essentially uses a URI and tries to fetch certs, keys, crls, ... from
it)

Please have a look.

Cheers,
Richard

In message <20161121135052.18280523.78584.102...@ll.mit.edu> on Mon, 21 Nov 
2016 13:50:43 +, "Blumenthal, Uri - 0553 - MITLL"  said:

uri> 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 :).
uri> 
uri> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE 
network.
uri>   Original Message  
uri> From: David Woodhouse
uri> Sent: Monday, November 21, 2016 08:43
uri> To: Richard Levitte; openssl-dev@openssl.org
uri> Reply To: openssl-dev@openssl.org
uri> Cc: James Bottomley
uri> Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM 
based RSA keys in openssl
uri> 
uri> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
uri> > 
uri> > Many years ago, I was thinking of something along the same lines, but
uri> > with a .pem file that would just have a few headers, holding the name
uri> > of the intended engine and the key identity, something like this:
uri> > 
uri> >     -BEGIN PRIVATE KEY-
uri> >     X-key-id: flarflarflar
uri> >     X-key-engine: foo
uri> >     -END PRIVATE KEY-
uri> > 
uri> > The intent was that the PEM code would be massaged to recognise these
uri> > headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
uri> > with those data and that would be it.
uri> > 
uri> > James, did I catch your intention about right?  I think that's
uri> > essentially what e_tpm.c does for loading keys, right?
uri> ‎
uri> Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
uri> added that a few years back (it used to just dump the binary blob
uri> instead). Both the TPM ENGINE and GnuTLS will load those files, as
uri> noted at http://www.infradead.org/openconnect/tpm.html
uri> 
uri> The problem is that applications have to jump through special hoops to
uri> recognise the files and invoke the engine (and there's a special API in
uri> GnuTLS too). It would be good if the appropriate engine could be
uri> invoked *automatically*, so the crypto library just does the right
uri> thing without all the applications even having to *know* about it.
uri> (Just like GnuTLS will automatically Just Work in many situations when
uri> presented with a PKCS#11 URI instead a filename, as OpenSSL also
uri> should, but doesn't yet.)
uri> 
uri> However, the contents of the PEM file should *not* be OpenSSL-specific
uri> and have engine names; I objected to James's original incarnation of
uri> this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
uri> and had the "tpm" engine automatically loaded on demand. It needs to be
uri> something generic. Which means engines need to indicate *which* PEM
uri> headers they can grok. And maybe the solution to this will tie in with
uri> the general fixes we need for "normal" key files, so that applications
uri> can Just Work with all of those too (qv¹).
uri> 
uri> Once the dust settles on TPMv2.0 we should probably put together an I-D 
uri> for the TPM-wrapped blob PEM files. And I should definitely add
uri> something about them to ¹.
uri> 
uri> -- 
uri> dwmw2
uri> 
uri> ¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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 PRIVATE KEY-
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?

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 http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
and had the "tpm" engine automatically loaded on demand. It needs to be
 something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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  
From: David Woodhouse
Sent: Monday, November 21, 2016 08:43
To: Richard Levitte; openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Cc: James Bottomley
Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM 
based RSA keys in openssl

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 PRIVATE KEY-
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?
‎
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 http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
and had the "tpm" engine automatically loaded on demand. It needs to be
something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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 http://www.infradead.org/openconnect/tpm.html
> The problem is that applications have to jump through special hoops
> to
> recognise the files and invoke the engine (and there's a special API
> in
> GnuTLS too). It would be good if the appropriate engine could be
> invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations
> when
> presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)

Note that for TPM wrapped keys, there was no new API introduced for
gnutls. The intention is to access such keys using a special URI [0].
However, since tpm2.0 is a completely different beast, I no longer
believe on direct TPM support, without a PKCS#11 wrapper.

[0]. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

regards,
Nikos

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

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

[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 engine and the key identity, something
> > like this:
> > 
> > -BEGIN PRIVATE KEY-
> > X-key-id: flarflarflar
> > X-key-engine: foo
> > -END PRIVATE KEY-
> > 
> > The intent was that the PEM code would be massaged to recognise 
> > these headers and would then use ENGINE_by_id() /
> > ENGINE_load_private_key() with those data and that would be it.
> > 
> > James, did I catch your intention about right?  I think that's
> > essentially what e_tpm.c does for loading keys, right?

Yes, that's right.  When any SSL program sees a TPM wrapped key, it
should just do the right thing if it has the engine capability without
needing the user to add any options to the command line.

> 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 http://www.infradead.org/openconnect/tpm.html
> 
> The problem is that applications have to jump through special hoops 
> to recognise the files and invoke the engine (and there's a special 
> API in GnuTLS too). It would be good if the appropriate engine could 
> be invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations 
> when presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)
> 
> However, the contents of the PEM file should *not* be OpenSSL
> -specific and have engine names; I objected to James's original 
> incarnation of this, which had something like
>  -BEGIN tpm ENGINE PRIVATE KEY-
> and had the "tpm" engine automatically loaded on demand. It needs to 
> be  something generic. Which means engines need to indicate *which* 
> PEM headers they can grok. And maybe the solution to this will tie in
> with the general fixes we need for "normal" key files, so that
> applications can Just Work with all of those too (qv¹).

Right, I forgot to add in the blurb that I'm looking for a mechanism
that all SSL implementations could follow, so it can't be tied to
anything specific in openSSL (like the engine name).  I modelled it on
gnutls because that has the same "just works(tm)" characteristic that I
was looking for.

> Once the dust settles on TPMv2.0 we should probably put together an I
> -D for the TPM-wrapped blob PEM files. And I should definitely add
> something about them to ¹.

Once we agree, I'll be happy to write up something.  We can use the pem
header concept to extend this format if it becomes necessary.

James


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev