From levitte at openssl.org  Thu Dec  1 00:38:34 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 01 Dec 2016 01:38:34 +0100
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480549329.2372.97.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <CE0347A6-8757-412C-ADAB-C849AF18C3C4@openssl.org>
 <1480549329.2372.97.camel@HansenPartnership.com>
Message-ID: <1936CAA0-4B78-4C39-BB70-0BD078BD4FD9@openssl.org>



James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1 december 2016 00:42:09 CET)
>On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
>> This patch doesn't fit the rest... 
>
>I'm not quite sure I follow why.

It casts bp to const char *. That was for your earlier implementation, wasn't it? It doesn't fit the latest incarnation of your API. 

>> Generally speaking, I am unsure about your solution. It seems like
>> hack to fit a specific case where something more general could be of
>> greater service to others as well. 
>
>Well, the more adaptable patch set was the previous one that overloaded
>the meaning of key_id.  This one has a specific bio mechanism for
>loading PEM files, so it only really works for engines that have PEM
>representable unloaded keys (which, to be fair, is almost all of them,
>since even the USB crypto keys have a wrapped format).
>
>I've tried to make it as generic as possible, but I am conditioned to
>think to my use case: TPM keys.  If you give an example of another use
>case, it will help me see where it should be more generic.

Among other things, I'd rather not encourage an API that inherently makes the engine<->libcrypto tie even tighter. Also, it puts a requirement on the engine to parse PEM, which is unnecessary. 

Also, we already have thoughts on loading keys by uri references, and there may be new ideas and formats coming in the future. All this is tied together and solving it one small hack at a time is sub-optimal in the long run. 

I'll repeat myself again, please have a look at the STORE stuff I'm working on. TPM files could very well serve as a first use case. 

>James
>
>
>> Cheers 
>> Richard 
>> 
>> On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley <
>> James.Bottomley at HansenPartnership.com> wrote:
>> > Before trying to process the PEM file, hand it to each of the
>> > loaded
>> > engines to see if they recognise the PEM guards.  This uses the new
>> > bio based load key callback, so the engine must be loaded and
>> > implement this callback to be considered.
>> > 
>> > Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
>> > ---
>> > crypto/pem/pem_pkey.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> > 
>> > diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
>> > index 04d6319..e3737f0 100644
>> > --- a/crypto/pem/pem_pkey.c
>> > +++ b/crypto/pem/pem_pkey.c
>> > @@ -85,6 +85,10 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp,
>> > EVP_PKEY
>> > **x, pem_password_cb *cb,
>> >     int slen;
>> >     EVP_PKEY *ret = NULL;
>> > 
>> > +    /* first check to see if an engine can load the PEM */
>> > +    if (ENGINE_find_engine_load_key(NULL, &ret, (const char *)bp,
>> > cb,
>> > u) == 1)
>> > +        return ret;
>> > +
>> > if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY, bp,
>> > cb,
>> > u))
>> >         return NULL;
>> >     p = data;
>> 
>> -- 
>> levitte at openssl.org 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From James.Bottomley at HansenPartnership.com  Thu Dec  1 06:36:26 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 22:36:26 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1936CAA0-4B78-4C39-BB70-0BD078BD4FD9@openssl.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <CE0347A6-8757-412C-ADAB-C849AF18C3C4@openssl.org>
 <1480549329.2372.97.camel@HansenPartnership.com>
 <1936CAA0-4B78-4C39-BB70-0BD078BD4FD9@openssl.org>
Message-ID: <1480574186.2372.114.camel@HansenPartnership.com>

On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
> 
> James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
> december 2016 00:42:09 CET)
> > On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
> > > This patch doesn't fit the rest... 
> > 
> > I'm not quite sure I follow why.
> 
> It casts bp to const char *. That was for your earlier
> implementation, wasn't it? It doesn't fit the latest incarnation of
> your API. 

Good catch: a leftover I missed the warning for in the spray of other
compile information.  Apparently the debug-linux-x86_64 target doesn't
have a -Werror ... I've added it so I should pick a problem like this
up easily.

> > > Generally speaking, I am unsure about your solution. It seems 
> > > like hack to fit a specific case where something more general 
> > > could be of greater service to others as well.
> > 
> > Well, the more adaptable patch set was the previous one that 
> > overloaded the meaning of key_id.  This one has a specific bio 
> > mechanism for loading PEM files, so it only really works for 
> > engines that have PEM representable unloaded keys (which, to be 
> > fair, is almost all of them, since even the USB crypto keys have a
> > wrapped format).
> > 
> > I've tried to make it as generic as possible, but I am conditioned 
> > to think to my use case: TPM keys.  If you give an example of 
> > another use case, it will help me see where it should be more
> > generic.
> 
> Among other things, I'd rather not encourage an API that inherently
> makes the engine<->libcrypto tie even tighter. Also, it puts a
> requirement on the engine to parse PEM, which is unnecessary. 
> 
> Also, we already have thoughts on loading keys by uri references, and
> there may be new ideas and formats coming in the future. All this is
> tied together and solving it one small hack at a time is sub-optimal
> in the long run. 
> 
> I'll repeat myself again, please have a look at the STORE stuff I'm
> working on. TPM files could very well serve as a first use case. 

That's this new pull request:

https://github.com/openssl/openssl/pull/2011/files

?

Just so I understand you, you mean register a store handler from the
engine for the TPM BLOB PEM files so that a reference to the file via
the store can use the PEM file as an EVP_PKEY?

That will work, I'm just not clear from the current pull request how
the store would be integrated with the existing PEM file handler ...
Will every application have to be modified to use the new store, or
will you hook it like I did for the engine keys?

The think I'm looking for is to have a TPM PEM key file just work in
place of a standard RSA private key file.

James


> > James
> > 
> > 
> > > Cheers 
> > > Richard 
> > > 
> > > On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley <
> > > James.Bottomley at HansenPartnership.com> wrote:
> > > > Before trying to process the PEM file, hand it to each of the
> > > > loaded
> > > > engines to see if they recognise the PEM guards.  This uses the
> > > > new
> > > > bio based load key callback, so the engine must be loaded and
> > > > implement this callback to be considered.
> > > > 
> > > > Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
> > > > ---
> > > > crypto/pem/pem_pkey.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
> > > > index 04d6319..e3737f0 100644
> > > > --- a/crypto/pem/pem_pkey.c
> > > > +++ b/crypto/pem/pem_pkey.c
> > > > @@ -85,6 +85,10 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp,
> > > > EVP_PKEY
> > > > **x, pem_password_cb *cb,
> > > >     int slen;
> > > >     EVP_PKEY *ret = NULL;
> > > > 
> > > > +    /* first check to see if an engine can load the PEM */
> > > > +    if (ENGINE_find_engine_load_key(NULL, &ret, (const char
> > > > *)bp,
> > > > cb,
> > > > u) == 1)
> > > > +        return ret;
> > > > +
> > > > if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY,
> > > > bp,
> > > > cb,
> > > > u))
> > > >         return NULL;
> > > >     p = data;
> > > 
> > > -- 
> > > levitte at openssl.org 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.


From levitte at openssl.org  Thu Dec  1 08:30:32 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 01 Dec 2016 09:30:32 +0100
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480574186.2372.114.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <CE0347A6-8757-412C-ADAB-C849AF18C3C4@openssl.org>
 <1480549329.2372.97.camel@HansenPartnership.com>
 <1936CAA0-4B78-4C39-BB70-0BD078BD4FD9@openssl.org>
 <1480574186.2372.114.camel@HansenPartnership.com>
Message-ID: <C8433B5B-9E18-42B1-875D-4BB780DF804D@openssl.org>



James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1 december 2016 07:36:26 CET)
>On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
>> 
>> James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
>> december 2016 00:42:09 CET)
>> > On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
>> > > This patch doesn't fit the rest... 
>> > 
>> > I'm not quite sure I follow why.
>> 
>> It casts bp to const char *. That was for your earlier
>> implementation, wasn't it? It doesn't fit the latest incarnation of
>> your API. 
>
>Good catch: a leftover I missed the warning for in the spray of other
>compile information.  Apparently the debug-linux-x86_64 target doesn't
>have a -Werror ... I've added it so I should pick a problem like this
>up easily.

The debug config targets create binaries that can easily be run through a debugger, nothing more. What you're looking for is the configuration option --strict-warnings. 

>> > > Generally speaking, I am unsure about your solution. It seems 
>> > > like hack to fit a specific case where something more general 
>> > > could be of greater service to others as well.
>> > 
>> > Well, the more adaptable patch set was the previous one that 
>> > overloaded the meaning of key_id.  This one has a specific bio 
>> > mechanism for loading PEM files, so it only really works for 
>> > engines that have PEM representable unloaded keys (which, to be 
>> > fair, is almost all of them, since even the USB crypto keys have a
>> > wrapped format).
>> > 
>> > I've tried to make it as generic as possible, but I am conditioned 
>> > to think to my use case: TPM keys.  If you give an example of 
>> > another use case, it will help me see where it should be more
>> > generic.
>> 
>> Among other things, I'd rather not encourage an API that inherently
>> makes the engine<->libcrypto tie even tighter. Also, it puts a
>> requirement on the engine to parse PEM, which is unnecessary. 
>> 
>> Also, we already have thoughts on loading keys by uri references, and
>> there may be new ideas and formats coming in the future. All this is
>> tied together and solving it one small hack at a time is sub-optimal
>> in the long run. 
>> 
>> I'll repeat myself again, please have a look at the STORE stuff I'm
>> working on. TPM files could very well serve as a first use case. 
>
>That's this new pull request:
>
>https://github.com/openssl/openssl/pull/2011/files

Yes. 

>Just so I understand you, you mean register a store handler from the
>engine for the TPM BLOB PEM files so that a reference to the file via
>the store can use the PEM file as an EVP_PKEY?

Essentially, yes. 

>That will work, I'm just not clear from the current pull request how
>the store would be integrated with the existing PEM file handler ...
>Will every application have to be modified to use the new store, or
>will you hook it like I did for the engine keys?

Generally speaking, I was thinking that applications would move to use the STORE API. 

>The think I'm looking for is to have a TPM PEM key file just work in
>place of a standard RSA private key file.

I get your point. That could be med as a call after the PEM_bytes_read_bio call. At that point, the necessary data for an internal store loading are available. It's still a hack, but if you must... 

>
>James
>
>
>> > James
>> > 
>> > 
>> > > Cheers 
>> > > Richard 
>> > > 
>> > > On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley <
>> > > James.Bottomley at HansenPartnership.com> wrote:
>> > > > Before trying to process the PEM file, hand it to each of the
>> > > > loaded
>> > > > engines to see if they recognise the PEM guards.  This uses the
>> > > > new
>> > > > bio based load key callback, so the engine must be loaded and
>> > > > implement this callback to be considered.
>> > > > 
>> > > > Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
>> > > > ---
>> > > > crypto/pem/pem_pkey.c | 4 ++++
>> > > > 1 file changed, 4 insertions(+)
>> > > > 
>> > > > diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
>> > > > index 04d6319..e3737f0 100644
>> > > > --- a/crypto/pem/pem_pkey.c
>> > > > +++ b/crypto/pem/pem_pkey.c
>> > > > @@ -85,6 +85,10 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp,
>> > > > EVP_PKEY
>> > > > **x, pem_password_cb *cb,
>> > > >     int slen;
>> > > >     EVP_PKEY *ret = NULL;
>> > > > 
>> > > > +    /* first check to see if an engine can load the PEM */
>> > > > +    if (ENGINE_find_engine_load_key(NULL, &ret, (const char
>> > > > *)bp,
>> > > > cb,
>> > > > u) == 1)
>> > > > +        return ret;
>> > > > +
>> > > > if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY,
>> > > > bp,
>> > > > cb,
>> > > > u))
>> > > >         return NULL;
>> > > >     p = data;
>> > > 
>> > > -- 
>> > > levitte at openssl.org 
>> 
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From nmav at redhat.com  Thu Dec  1 11:49:16 2016
From: nmav at redhat.com (Nikos Mavrogiannopoulos)
Date: Thu, 01 Dec 2016 12:49:16 +0100
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1480543183.2372.91.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>
 <1480541604.2372.74.camel@HansenPartnership.com>
 <91441F38-5D25-47BE-B6C4-567B1C83BC14@ll.mit.edu>
 <1480543183.2372.91.camel@HansenPartnership.com>
Message-ID: <1480592956.2396.8.camel@redhat.com>

On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote:

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

Note that gnutls' mechanism relies on the "tpmkey:" URLs to load them,
rather than loading via any other PEM mechanism. The URL approach has
the advantage that it provides a uniformity in handling similar to
PKCS#11 URLs (and it wouldn't matter whether these keys are in file, in
the TPM itself or in some other OS storage area - you specify them all
the same).

However, neither of URLs or file loading would survive the TPM 2.0
thing. Most likely (and hopefully) the latter keys will be handled over
PKCS#11 rather than directly.

regards,
Nikos


From levitte at openssl.org  Fri Dec  2 13:04:11 2016
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 02 Dec 2016 14:04:11 +0100 (CET)
Subject: [openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless handling
 of TPM based RSA keys in openssl)
In-Reply-To: <1479823032.8937.37.camel@infradead.org>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
Message-ID: <20161202.140411.100930035020452052.levitte@openssl.org>

In message <1479823032.8937.37.camel at infradead.org> on Tue, 22 Nov 2016 13:57:12 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Just let me shamelessly mention my STORE effort again ;-)
dwmw2> > Among others, it does attempt to solve that very problem (in the
dwmw2> > 'file' scheme handler).
dwmw2> 
dwmw2> Neat. Note that I have a ready-made test suite for you in OpenConnect:
dwmw2> http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
dwmw2> 
dwmw2> For every one of the key files therein, does your current
dwmw2> implementation work? :)

It does now for everything but PKCS#12 files.  Those are trickier, and
I'm working on it.

Speaking of...  do you mind if I pilfer from that Makefile.am for our
tests?

dwmw2> (Yeah, I need to sort out the tpm emulator in the test environment,
dwmw2> then add some -----BEGIN TSS KEY BLOB----- files too :)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From James.Bottomley at HansenPartnership.com  Fri Dec  2 16:03:19 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Fri, 02 Dec 2016 08:03:19 -0800
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1480592956.2396.8.camel@redhat.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>
 <1480541604.2372.74.camel@HansenPartnership.com>
 <91441F38-5D25-47BE-B6C4-567B1C83BC14@ll.mit.edu>
 <1480543183.2372.91.camel@HansenPartnership.com>
 <1480592956.2396.8.camel@redhat.com>
Message-ID: <1480694599.2410.12.camel@HansenPartnership.com>

On Thu, 2016-12-01 at 12:49 +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote:
> 
> > >     > 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. 
> 
> Note that gnutls' mechanism relies on the "tpmkey:" URLs to load 
> them, rather than loading via any other PEM mechanism. The URL 
> approach has the advantage that it provides a uniformity in handling 
> similar to PKCS#11 URLs (and it wouldn't matter whether these keys 
> are in file, in the TPM itself or in some other OS storage area - you 
> specify them all the same).
> 
> However, neither of URLs or file loading would survive the TPM 2.0
> thing.

Actually, I believe it will.  The main difference is that TPM2 has
multiple SRKs so you need to know which one, plus TSS2 will be
different from TSS1 so they can't be handled by the same engine: so the
format will have a new guard (TSS2 KEY BLOB probably) and the multiple
root can be coped with by specifying the root as a PEM parameter).

Incidentally, a similar problem does exist in TPM1: although everything
chains up to a single SRK, you can have multiple sub SRK storage keys
to which the keys are wrapped.  Right at the moment, the current
openssl_tpm_engine doesn't contemplate this possibility, but I'm
thinking of extending it to do so, because it's useful when doing TPM
tenancy (cloud container use case).

>  Most likely (and hopefully) the latter keys will be handled over
> PKCS#11 rather than directly.

I have reservations about scaling pkcs11 into a multi-tenant
environment, but I agree, in principle it is possible.  I'm looking at
trying to do it better for TPM now (well, it's the next thing to get to
on my list).

James



From James.Bottomley at HansenPartnership.com  Fri Dec  2 16:52:38 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Fri, 02 Dec 2016 08:52:38 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <C8433B5B-9E18-42B1-875D-4BB780DF804D@openssl.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <CE0347A6-8757-412C-ADAB-C849AF18C3C4@openssl.org>
 <1480549329.2372.97.camel@HansenPartnership.com>
 <1936CAA0-4B78-4C39-BB70-0BD078BD4FD9@openssl.org>
 <1480574186.2372.114.camel@HansenPartnership.com>
 <C8433B5B-9E18-42B1-875D-4BB780DF804D@openssl.org>
Message-ID: <1480697558.2410.33.camel@HansenPartnership.com>

On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote:
> 
> James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
> december 2016 07:36:26 CET)
> > On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
> > > 
> > > James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
> > > december 2016 00:42:09 CET)
[...]
> > > > On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
> > > > > Generally speaking, I am unsure about your solution. It seems
> > > > > like hack to fit a specific case where something more general
> > > > > could be of greater service to others as well.
> > > > 
> > > > Well, the more adaptable patch set was the previous one that 
> > > > overloaded the meaning of key_id.  This one has a specific bio 
> > > > mechanism for loading PEM files, so it only really works for 
> > > > engines that have PEM representable unloaded keys (which, to be
> > > > fair, is almost all of them, since even the USB crypto keys 
> > > > have a wrapped format).
> > > > 
> > > > I've tried to make it as generic as possible, but I am 
> > > > conditioned to think to my use case: TPM keys.  If you give an 
> > > > example of another use case, it will help me see where it 
> > > > should be more generic.
> > > 
> > > Among other things, I'd rather not encourage an API that 
> > > inherently makes the engine<->libcrypto tie even tighter. Also, 
> > > it puts a requirement on the engine to parse PEM, which is
> > > unnecessary.

Actually, I missed this initially.  This is definitely not a
requirement: engines that wish to parse PEM keys may do so, but an
engine that doesn't simply doesn't implement the callback.  Only
engines that are loaded from the configuration file actually get asked
if they understand the key, and then only if they supply the callback,
so this is a decision on which engines to is made by the admin or
packager (and the engine builder, who decides whether to implement or
not).

> > > Also, we already have thoughts on loading keys by uri references,
> > > and there may be new ideas and formats coming in the future. All
> > > this is tied together and solving it one small hack at a time is
> > > sub-optimal in the long run.
> > > 
> > > I'll repeat myself again, please have a look at the STORE stuff 
> > > I'm working on. TPM files could very well serve as a first use
> > > case.
> > 
> > That's this new pull request:
> > 
> > https://github.com/openssl/openssl/pull/2011/files
> 
> Yes. 
> 
> > Just so I understand you, you mean register a store handler from 
> > the engine for the TPM BLOB PEM files so that a reference to the 
> > file via the store can use the PEM file as an EVP_PKEY?
> 
> Essentially, yes. 
> 
> > That will work, I'm just not clear from the current pull request 
> > how the store would be integrated with the existing PEM file
> > handler
> > ...
> > Will every application have to be modified to use the new store, or
> > will you hook it like I did for the engine keys?
> 
> Generally speaking, I was thinking that applications would move to
> use the STORE API. 
> 
> > The think I'm looking for is to have a TPM PEM key file just work 
> > in place of a standard RSA private key file.
> 
> I get your point. That could be med as a call after the 
> PEM_bytes_read_bio call. At that point, the necessary data for an 
> internal store loading are available. It's still a hack, but if you 
> must... 

If I summarise the arguments about self identifying files from the v1
thread:

   1. We agreed that usability is greatly enhanced if openssl simply loads
      a key when presented with the file/uri etc. without the user having
      to specify what the format of a key is
   2. For PEM files, we believe this is easy because the guards uniquely
      identify the file format, so whatever key the application needs, we
      can verify is contained in the thing presented
   3. THere was more debate on the files that aren't fully self
      describing, like DER. ?The argument was that the DER structure is
      usually unique enough, so we could do this, but there were
      reservations.
   4. I thought there was agreement that we could move forwards with the
      PEM bit because it was uncontroversial

The current PEM key loading code is already hooked for PKCS8, to make
the above a reality, we should hook it for pkcs12 as well.  Once you
have the store code, I believe it should be hooked for this as well. 
 In this scenario, I don't quite see why it's not a hack to hook for
pkcs8 (and presumably 12) but it is a hack to hook for engines and
store.

If we agree on DER, the ideal world becomes all apps simply use
OPENSSL_load_privkey() and no-one needs to worry about format for key
loading because any reasonable format just works.

James


From dwmw2 at infradead.org  Sat Dec  3 00:32:11 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 03 Dec 2016 00:32:11 +0000
Subject: [openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless
 handling of TPM based RSA keys in openssl)
In-Reply-To: <20161202.140411.100930035020452052.levitte@openssl.org>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
 <20161202.140411.100930035020452052.levitte@openssl.org>
Message-ID: <1480725131.3829.3.camel@infradead.org>

On Fri, 2016-12-02 at 14:04 +0100, Richard Levitte wrote:
> It does now for everything but PKCS#12 files.? Those are trickier, and
> I'm working on it.

Nice.

> Speaking of...? do you mind if I pilfer from that Makefile.am for our
> tests?

Not at all; please do. You're welcome to use anything in the test suite
under the OpenSSL licence. With the caveat/exception that bits of it
came from Nikos ? but that was mostly the ocserv test harness which
isn't the bit you want.

I really will augment it with password/charset torture testing one of
these days...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161203/186d4db5/attachment.bin>

From dwmw2 at infradead.org  Mon Dec  5 23:09:21 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Dec 2016 23:09:21 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1480694599.2410.12.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>
 <1480541604.2372.74.camel@HansenPartnership.com>
 <91441F38-5D25-47BE-B6C4-567B1C83BC14@ll.mit.edu>
 <1480543183.2372.91.camel@HansenPartnership.com>
 <1480592956.2396.8.camel@redhat.com>
 <1480694599.2410.12.camel@HansenPartnership.com>
Message-ID: <1480979361.81411.6.camel@infradead.org>

On Fri, 2016-12-02 at 08:03 -0800, James Bottomley wrote:
> > ? Most likely (and hopefully) the latter keys will be handled over
> > PKCS#11 rather than directly.
> 
> I have reservations about scaling pkcs11 into a multi-tenant
> environment, but I agree, in principle it is possible.? I'm looking at
> trying to do it better for TPM now (well, it's the next thing to get to
> on my list).

There are two problems with PKCS#11 and TPM.

Firstly, PKCS#11 only supports one PIN per PKCS#11 provider. If each
key can have its *own* PIN, that doesn't work so well. You can play
deprecated tricks and have a separate slot for each key, but that
quickly gets horrid, and more so when you consider the second
problem...

Secondly, wrapped keys don't actually exist in the TPM so there's no
'URI' that you can refer to them by; they are ephemeral. The encrypted
key is actually *in* the PEM file, and gets loaded into the TPM for it
to decrypt and use.

So to cope with this through PKCS#11 you'd need some kind of nasty hack
where it loads the PEM file and a new token magically "hotplugs" into
existence. We already have something that's *almost* this horrid, with
the nss-pem abomination that NSS uses to load PEM files; you call the
C_CreateObject() method using an object 'label' which is actually a
file name.... it's vile, and it's not really a model we want to follow.

I think we really do need native support for loading these PEM files,
and not to attempt to make it work through PKCS#11.

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

From joel.winarske at gmail.com  Tue Dec  6 03:22:31 2016
From: joel.winarske at gmail.com (Joel Winarske)
Date: Mon, 5 Dec 2016 19:22:31 -0800
Subject: [openssl-dev] Building 1.1.0c for WIN32
Message-ID: <CABKMkP+Q-bQfANdgAYfifvhj5nyX50CVZ5K71QB_BG+aW+kzyQ@mail.gmail.com>

Hi folks,

I'm having trouble building 1.1.0c for WIN32.  Perl ends up in a hard
loop.  I see same symtom building 1.0.2j, but different error.  Any
suggestions to get past this?


perl Configure VC-WIN32 no-asm
--prefix=OpenSSL_1_1_0c-install-msvc1900-32-Release
nmake


2>   cl  /I "." /I "crypto/include" /I "include" -DOPENSSL_USE_APPLINK
-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE
-DOPENSSL_PIC
"-DENGINESDIR=\"C:/Users/joel/Documents/GitHub/xeno_build/OpenSSL_1_1_0c-install-msvc1900-32-Release/lib/engines-1_1\""
"-DOPENSSLDIR=\"C:\\Program Files (x86)\\Common Files\\SSL\"" -W3 -wd4090
-Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN
-D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 /Zi /Fdossl_static
-c /Focrypto/dllmain.obj "crypto/dllmain.c"
2>  dllmain.c
2>   "perl" "util/mkdef.pl" "crypto" 32 > libcrypto-1_1.def
2>  File include/openssl/ssl.h: cannot parse: ()
2>  #INFO::;
2>  File include/openssl/ssl.h: cannot parse: ()
2>
2>
2>  enum;
2>  File include/openssl/tls1.h: cannot parse: ()
2>
2>  #INFO::;
2>  File include/openssl/tls1.h: cannot parse: ()
2>
2>  #INFO::;
2>  File include/openssl/tls1.h: cannot parse:
SSL_CTX_ctrl(ssl,SSL_CTRL_GET_TLSEXT_STATUS_REQ_CB_ARG,0, ()arg
2>  #INFO::;


Thanks!
Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161205/7aa1c668/attachment.html>

From levitte at openssl.org  Tue Dec  6 14:12:26 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 06 Dec 2016 15:12:26 +0100 (CET)
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480697558.2410.33.camel@HansenPartnership.com>
References: <1480574186.2372.114.camel@HansenPartnership.com>
 <C8433B5B-9E18-42B1-875D-4BB780DF804D@openssl.org>
 <1480697558.2410.33.camel@HansenPartnership.com>
Message-ID: <20161206.151226.2129387863349296405.levitte@openssl.org>

In message <1480697558.2410.33.camel at HansenPartnership.com> on Fri, 02 Dec 2016 08:52:38 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote:
James.Bottomley> > 
James.Bottomley> > James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
James.Bottomley> > december 2016 07:36:26 CET)
James.Bottomley> > > On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
James.Bottomley> > > > 
James.Bottomley> > > > James Bottomley <James.Bottomley at HansenPartnership.com> skrev: (1
James.Bottomley> > > > december 2016 00:42:09 CET)
James.Bottomley> [...]
James.Bottomley> > > > > On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
James.Bottomley> > > > > > Generally speaking, I am unsure about your solution. It seems
James.Bottomley> > > > > > like hack to fit a specific case where something more general
James.Bottomley> > > > > > could be of greater service to others as well.
James.Bottomley> > > > > 
James.Bottomley> > > > > Well, the more adaptable patch set was the previous one that 
James.Bottomley> > > > > overloaded the meaning of key_id.  This one has a specific bio 
James.Bottomley> > > > > mechanism for loading PEM files, so it only really works for 
James.Bottomley> > > > > engines that have PEM representable unloaded keys (which, to be
James.Bottomley> > > > > fair, is almost all of them, since even the USB crypto keys 
James.Bottomley> > > > > have a wrapped format).
James.Bottomley> > > > > 
James.Bottomley> > > > > I've tried to make it as generic as possible, but I am 
James.Bottomley> > > > > conditioned to think to my use case: TPM keys.  If you give an 
James.Bottomley> > > > > example of another use case, it will help me see where it 
James.Bottomley> > > > > should be more generic.
James.Bottomley> > > > 
James.Bottomley> > > > Among other things, I'd rather not encourage an API that 
James.Bottomley> > > > inherently makes the engine<->libcrypto tie even tighter. Also, 
James.Bottomley> > > > it puts a requirement on the engine to parse PEM, which is
James.Bottomley> > > > unnecessary.
James.Bottomley> 
James.Bottomley> Actually, I missed this initially.  This is definitely not a
James.Bottomley> requirement: engines that wish to parse PEM keys may do so, but an
James.Bottomley> engine that doesn't simply doesn't implement the callback.  Only
James.Bottomley> engines that are loaded from the configuration file actually get asked
James.Bottomley> if they understand the key, and then only if they supply the callback,
James.Bottomley> so this is a decision on which engines to is made by the admin or
James.Bottomley> packager (and the engine builder, who decides whether to implement or
James.Bottomley> not).

When I made that argument, I hadn't thought and felt things through
entirely.  Truth be told, I'm feeling very uneasy handing over the
reading and parsing of the PEM file to an engine.  However, handing
over the decoded data and leaving it to the engine to do something
sensible with it, no issues at all.

James.Bottomley> If I summarise the arguments about self identifying files from the v1
James.Bottomley> thread:
James.Bottomley> 
James.Bottomley>    1. We agreed that usability is greatly enhanced if openssl simply loads
James.Bottomley>       a key when presented with the file/uri etc. without the user having
James.Bottomley>       to specify what the format of a key is

Check.  My STORE branch is made to support that.

James.Bottomley>    2. For PEM files, we believe this is easy because the guards uniquely
James.Bottomley>       identify the file format, so whatever key the application needs, we
James.Bottomley>       can verify is contained in the thing presented

Check.

James.Bottomley>    3. THere was more debate on the files that aren't fully self
James.Bottomley>       describing, like DER. ?The argument was that the DER structure is
James.Bottomley>       usually unique enough, so we could do this, but there were
James.Bottomley>       reservations.

Yup...  The current TSS KEY BLOB is among those reservations ;-)

James.Bottomley>    4. I thought there was agreement that we could move forwards with the
James.Bottomley>       PEM bit because it was uncontroversial

We're not quite on the same page regarding the exact implementation.
However, I think I have a solution...

James.Bottomley> The current PEM key loading code is already hooked for PKCS8, to make
James.Bottomley> the above a reality, we should hook it for pkcs12 as well.  Once you
James.Bottomley> have the store code, I believe it should be hooked for this as well. 
James.Bottomley>  In this scenario, I don't quite see why it's not a hack to hook for
James.Bottomley> pkcs8 (and presumably 12) but it is a hack to hook for engines and
James.Bottomley> store.
James.Bottomley> 
James.Bottomley> If we agree on DER, the ideal world becomes all apps simply use
James.Bottomley> OPENSSL_load_privkey() and no-one needs to worry about format for key
James.Bottomley> loading because any reasonable format just works.

I toyed around with the idea that I already mentioned, that instead of
passing the BIO and have the engine read it at its leasure, there
would be a STORE call after the PEM_bytes_read_bio() call in
PEM_read_bio_PrivateKey(), where the decoded data would be passed in
the STORE call.  The result is a branch of mine that I haven't made
into a PR, built in top of my STORE branch:

https://github.com/levitte/openssl/tree/tpm_engine-support

Please have a look, and especially at these changes:

https://github.com/levitte/openssl/commit/ae9f05a9d8d60e2c05d8f3b442161e648d1a0738

I think they should fit your bill fairly well, all that's needed is
that you add a store file handler to e_tpm.c (I did toy around with
that as well, but it's too dependent on pre 1.1.0 OpenSSL, I didn't
want to spend more time clearing that up).  I have an untested patch
that I can send you if you want.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From James.Bottomley at HansenPartnership.com  Tue Dec  6 16:34:08 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Tue, 06 Dec 2016 08:34:08 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161206.151226.2129387863349296405.levitte@openssl.org>
References: <1480574186.2372.114.camel@HansenPartnership.com>
 <C8433B5B-9E18-42B1-875D-4BB780DF804D@openssl.org>
 <1480697558.2410.33.camel@HansenPartnership.com>
 <20161206.151226.2129387863349296405.levitte@openssl.org>
Message-ID: <1481042048.4406.14.camel@HansenPartnership.com>

On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote:
> In message <1480697558.2410.33.camel at HansenPartnership.com> on Fri,
> 02 Dec 2016 08:52:38 -0800, James Bottomley <
> James.Bottomley at HansenPartnership.com> said:
> 
> James.Bottomley> On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte
> wrote:
> James.Bottomley> > 
> James.Bottomley> > James Bottomley <
> James.Bottomley at HansenPartnership.com> skrev: (1
> James.Bottomley> > december 2016 07:36:26 CET)
> James.Bottomley> > > On Thu, 2016-12-01 at 01:38 +0100, Richard
> Levitte wrote:
> James.Bottomley> > > > 
> James.Bottomley> > > > James Bottomley <
> James.Bottomley at HansenPartnership.com> skrev: (1
> James.Bottomley> > > > december 2016 00:42:09 CET)
> James.Bottomley> [...]
> James.Bottomley> > > > > On Thu, 2016-12-01 at 00:22 +0100, Richard
> Levitte wrote:
> James.Bottomley> > > > > > Generally speaking, I am unsure about your
> solution. It seems
> James.Bottomley> > > > > > like hack to fit a specific case where
> something more general
> James.Bottomley> > > > > > could be of greater service to others as
> well.
> James.Bottomley> > > > > 
> James.Bottomley> > > > > Well, the more adaptable patch set was the
> previous one that 
> James.Bottomley> > > > > overloaded the meaning of key_id.  This one
> has a specific bio 
> James.Bottomley> > > > > mechanism for loading PEM files, so it only
> really works for 
> James.Bottomley> > > > > engines that have PEM representable unloaded
> keys (which, to be
> James.Bottomley> > > > > fair, is almost all of them, since even the
> USB crypto keys 
> James.Bottomley> > > > > have a wrapped format).
> James.Bottomley> > > > > 
> James.Bottomley> > > > > I've tried to make it as generic as
> possible, but I am 
> James.Bottomley> > > > > conditioned to think to my use case: TPM
> keys.  If you give an 
> James.Bottomley> > > > > example of another use case, it will help me
> see where it 
> James.Bottomley> > > > > should be more generic.
> James.Bottomley> > > > 
> James.Bottomley> > > > Among other things, I'd rather not encourage
> an API that 
> James.Bottomley> > > > inherently makes the engine<->libcrypto tie
> even tighter. Also, 
> James.Bottomley> > > > it puts a requirement on the engine to parse
> PEM, which is
> James.Bottomley> > > > unnecessary.
> James.Bottomley> 
> James.Bottomley> Actually, I missed this initially.  This is
> definitely not a
> James.Bottomley> requirement: engines that wish to parse PEM keys may
> do so, but an
> James.Bottomley> engine that doesn't simply doesn't implement the
> callback.  Only
> James.Bottomley> engines that are loaded from the configuration file
> actually get asked
> James.Bottomley> if they understand the key, and then only if they
> supply the callback,
> James.Bottomley> so this is a decision on which engines to is made by
> the admin or
> James.Bottomley> packager (and the engine builder, who decides
> whether to implement or
> James.Bottomley> not).
> 
> When I made that argument, I hadn't thought and felt things through
> entirely.  Truth be told, I'm feeling very uneasy handing over the
> reading and parsing of the PEM file to an engine.  However, handing
> over the decoded data and leaving it to the engine to do something
> sensible with it, no issues at all.

OK, can I pick on this a bit (I'll look at the store stuff later and
reply after I've played with it)?  What is it that you imagine handing
to the engine?  Some type of buffer that contains the full PEM
representation?

The reason I chose a BIO is that it's the basic abstract data handler
for openssl. I can hand a buffer to the engine, sure, but I'd need to
transform it to a BIO again (because it would need PEM parsing and all
the PEM parsers speak BIOs), so it feels suboptimal.

James



From bkaduk at akamai.com  Tue Dec  6 16:38:07 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 6 Dec 2016 10:38:07 -0600
Subject: [openssl-dev] Building 1.1.0c for WIN32
In-Reply-To: <CABKMkP+Q-bQfANdgAYfifvhj5nyX50CVZ5K71QB_BG+aW+kzyQ@mail.gmail.com>
References: <CABKMkP+Q-bQfANdgAYfifvhj5nyX50CVZ5K71QB_BG+aW+kzyQ@mail.gmail.com>
Message-ID: <03b4a019-bf35-2568-494e-f27f4f3c06a1@akamai.com>

On 12/05/2016 09:22 PM, Joel Winarske wrote:
> Hi folks,
>
> I'm having trouble building 1.1.0c for WIN32.  Perl ends up in a hard
> loop.  I see same symtom building 1.0.2j, but different error.  Any
> suggestions to get past this?
>

What version of perl?

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161206/96635ad0/attachment.html>

From levitte at openssl.org  Tue Dec  6 16:47:51 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 06 Dec 2016 17:47:51 +0100 (CET)
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1481042048.4406.14.camel@HansenPartnership.com>
References: <1480697558.2410.33.camel@HansenPartnership.com>
 <20161206.151226.2129387863349296405.levitte@openssl.org>
 <1481042048.4406.14.camel@HansenPartnership.com>
Message-ID: <20161206.174751.699271166087003593.levitte@openssl.org>

In message <1481042048.4406.14.camel at HansenPartnership.com> on Tue, 06 Dec 2016 08:34:08 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1480697558.2410.33.camel at HansenPartnership.com> on Fri,
James.Bottomley> > 02 Dec 2016 08:52:38 -0800, James Bottomley <
James.Bottomley> > James.Bottomley at HansenPartnership.com> said:
James.Bottomley> > 
James.Bottomley> > When I made that argument, I hadn't thought and felt things through
James.Bottomley> > entirely.  Truth be told, I'm feeling very uneasy handing over the
James.Bottomley> > reading and parsing of the PEM file to an engine.  However, handing
James.Bottomley> > over the decoded data and leaving it to the engine to do something
James.Bottomley> > sensible with it, no issues at all.
James.Bottomley> 
James.Bottomley> OK, can I pick on this a bit (I'll look at the store stuff later and
James.Bottomley> reply after I've played with it)?  What is it that you imagine handing
James.Bottomley> to the engine?  Some type of buffer that contains the full PEM
James.Bottomley> representation?

In my STORE branch, you will find this in include/openssl/store_file.h:

    /*
     * The try_decode function is called to check if the blob of data can
     * be used by this handler, and if it can, decodes it into a supported
     * OpenSSL and returns a STORE_INFO with the recorded data.
     * Input:
     *    pem_name:     If this blob comes from a PEM file, this holds
     *                  the PEM name.  If it comes from another type of
     *                  file, this is NULL.
     *    blob:         The blob of data to match with what this handler
     *                  can use.
     *    len:          The length of the blob.
     *    handler_ctx:  For a handler marked repeatable, this pointer can
     *                  be used to create a context for the handler.  IT IS
     *                  THE HANDLER'S RESPONSIBILITY TO CREATE AND DESTROY
     *                  THIS CONTEXT APPROPRIATELY, i.e. create on first call
     *                  and destroy when about to return NULL.
     *    password_ui:  Application UI method for getting a password.
     *    password_ui_data:
     *                  Application data to be passed to password_ui when
     *                  it's called.
     * Output:
     *    a STORE_INFO
     */
    typedef STORE_INFO *(*STORE_FILE_try_decode_fn)(const char *pem_name,
                                                    const unsigned char *blob,
                                                    size_t len,
                                                    void **handler_ctx,
                                                    const UI_METHOD *password_ui,
                                                    void *password_ui_data);

This is the central function that tries to see if it can decode
whatever's thrown at it.  As you can see, it gets handed the PEM name
if it's called as part of a PEM read.  The |blob| is the decoded *and
decrypted* data.

James.Bottomley> The reason I chose a BIO is that it's the basic abstract data handler
James.Bottomley> for openssl. I can hand a buffer to the engine, sure, but I'd need to
James.Bottomley> transform it to a BIO again (because it would need PEM parsing and all
James.Bottomley> the PEM parsers speak BIOs), so it feels suboptimal.

With a try_decode function, I really do not see why there's a need to
deal with the BIO...

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From James.Bottomley at HansenPartnership.com  Tue Dec  6 17:01:12 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Tue, 06 Dec 2016 09:01:12 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161206.174751.699271166087003593.levitte@openssl.org>
References: <1480697558.2410.33.camel@HansenPartnership.com>
 <20161206.151226.2129387863349296405.levitte@openssl.org>
 <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
Message-ID: <1481043672.4406.22.camel@HansenPartnership.com>

On Tue, 2016-12-06 at 17:47 +0100, Richard Levitte wrote:
> In message <1481042048.4406.14.camel at HansenPartnership.com> on Tue,
> 06 Dec 2016 08:34:08 -0800, James Bottomley <
> James.Bottomley at HansenPartnership.com> said:
> 
> James.Bottomley> On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte
> wrote:
> James.Bottomley> > In message <
> 1480697558.2410.33.camel at HansenPartnership.com> on Fri,
> James.Bottomley> > 02 Dec 2016 08:52:38 -0800, James Bottomley <
> James.Bottomley> > James.Bottomley at HansenPartnership.com> said:
> James.Bottomley> > 
> James.Bottomley> > When I made that argument, I hadn't thought and
> felt things through
> James.Bottomley> > entirely.  Truth be told, I'm feeling very uneasy
> handing over the
> James.Bottomley> > reading and parsing of the PEM file to an engine. 
> However, handing
> James.Bottomley> > over the decoded data and leaving it to the engine
> to do something
> James.Bottomley> > sensible with it, no issues at all.
> James.Bottomley> 
> James.Bottomley> OK, can I pick on this a bit (I'll look at the store
> stuff later and
> James.Bottomley> reply after I've played with it)?  What is it that
> you imagine handing
> James.Bottomley> to the engine?  Some type of buffer that contains
> the full PEM
> James.Bottomley> representation?
> 
> In my STORE branch, you will find this in
> include/openssl/store_file.h:
> 
>     /*
>      * The try_decode function is called to check if the blob of data
> can
>      * be used by this handler, and if it can, decodes it into a
> supported
>      * OpenSSL and returns a STORE_INFO with the recorded data.
>      * Input:
>      *    pem_name:     If this blob comes from a PEM file, this
> holds
>      *                  the PEM name.  If it comes from another type
> of
>      *                  file, this is NULL.
>      *    blob:         The blob of data to match with what this
> handler
>      *                  can use.
>      *    len:          The length of the blob.
>      *    handler_ctx:  For a handler marked repeatable, this pointer
> can
>      *                  be used to create a context for the handler. 
> IT IS
>      *                  THE HANDLER'S RESPONSIBILITY TO CREATE AND
> DESTROY
>      *                  THIS CONTEXT APPROPRIATELY, i.e. create on
> first call
>      *                  and destroy when about to return NULL.
>      *    password_ui:  Application UI method for getting a password.
>      *    password_ui_data:
>      *                  Application data to be passed to password_ui
> when
>      *                  it's called.
>      * Output:
>      *    a STORE_INFO
>      */
>     typedef STORE_INFO *(*STORE_FILE_try_decode_fn)(const char
> *pem_name,
>                                                     const unsigned
> char *blob,
>                                                     size_t len,
>                                                     void
> **handler_ctx,
>                                                     const UI_METHOD
> *password_ui,
>                                                     void
> *password_ui_data);
> 
> This is the central function that tries to see if it can decode
> whatever's thrown at it.  As you can see, it gets handed the PEM name
> if it's called as part of a PEM read.  The |blob| is the decoded *and
> decrypted* data.
> 
> James.Bottomley> The reason I chose a BIO is that it's the basic
> abstract data handler
> James.Bottomley> for openssl. I can hand a buffer to the engine,
> sure, but I'd need to
> James.Bottomley> transform it to a BIO again (because it would need
> PEM parsing and all
> James.Bottomley> the PEM parsers speak BIOs), so it feels suboptimal.
> 
> With a try_decode function, I really do not see why there's a need to
> deal with the BIO...

OK, I get what you want.  There are two problems with this.  The first
is easy: I'm eventually going to need the BIO header as well because
TPM2 keys are going to need to describe external things that aren't in
the key representation (and even TPM1 keys might need to say who their
parent key is).  However, this is fixable by simply expanding your
prototype above to have const char *pem_name and const char *pem_header
... is that OK?

The next problem is that this is slightly harder simply to insert into
the PEM code.  The BIO parsing is done in PEM_bytes_read_bio() not
 PEM_read_bio_PrivateKey().  The easy way to cope with this would be to
move PEM parsing into the ENGINE_find_engine_load_key() function and
then hand the name, header, blob to the engine.  The disadvantage of
this is that we'll end up pulling the PEM apart twice: once in
ENGINE_find_engine_load_key() and then again in PEM_bytes_read_bio(). 
 Is this OK?  If it is I can code up a v3.  If not, I can think about
how we might integrate this into PEM_bytes_read_bio().

James




From joel.winarske at gmail.com  Tue Dec  6 18:08:12 2016
From: joel.winarske at gmail.com (Joel Winarske)
Date: Tue, 6 Dec 2016 10:08:12 -0800
Subject: [openssl-dev] Building 1.1.0c for WIN32
In-Reply-To: <03b4a019-bf35-2568-494e-f27f4f3c06a1@akamai.com>
References: <CABKMkP+Q-bQfANdgAYfifvhj5nyX50CVZ5K71QB_BG+aW+kzyQ@mail.gmail.com>
 <03b4a019-bf35-2568-494e-f27f4f3c06a1@akamai.com>
Message-ID: <CABKMkPJD_auSxw=Y9n=EWhG2+F5tmUg_ymSF7VQzvxxW+=Pa=g@mail.gmail.com>

ActiveState Perl64: "This is perl 5, version 24, subversion 0 (v5.24.0)
built for MSWin32-x64-multi-thread"

I sorted it out.  The key is to build from either
"VS2015 x86 Native Tools Command Prompt" || "VS2015 x64 Native Tools
Command Prompt"

It doesn't like being built from:
"MSBuild Command Prompt for VS2015"


Cheers,
Joel

On Tue, Dec 6, 2016 at 8:38 AM, Benjamin Kaduk <bkaduk at akamai.com> wrote:

> On 12/05/2016 09:22 PM, Joel Winarske wrote:
>
> Hi folks,
>
> I'm having trouble building 1.1.0c for WIN32.  Perl ends up in a hard
> loop.  I see same symtom building 1.0.2j, but different error.  Any
> suggestions to get past this?
>
>
> What version of perl?
>
> -Ben
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161206/bb4df9c2/attachment.html>

From bkaduk at akamai.com  Tue Dec  6 18:15:13 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 6 Dec 2016 12:15:13 -0600
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1481043672.4406.22.camel@HansenPartnership.com>
References: <1480697558.2410.33.camel@HansenPartnership.com>
 <20161206.151226.2129387863349296405.levitte@openssl.org>
 <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
Message-ID: <2d714708-c020-0b13-2641-bdbeefa699dc@akamai.com>

On 12/06/2016 11:01 AM, James Bottomley wrote:
> The next problem is that this is slightly harder simply to insert into
> the PEM code.  The BIO parsing is done in PEM_bytes_read_bio() not
>  PEM_read_bio_PrivateKey().  The easy way to cope with this would be to
> move PEM parsing into the ENGINE_find_engine_load_key() function and
> then hand the name, header, blob to the engine.  The disadvantage of
> this is that we'll end up pulling the PEM apart twice: once in
> ENGINE_find_engine_load_key() and then again in PEM_bytes_read_bio(). 
>  Is this OK?  If it is I can code up a v3.  If not, I can think about
> how we might integrate this into PEM_bytes_read_bio().

FWIW, you may find the refactored version at
https://github.com/openssl/openssl/pull/1700 easier to reason about.  I
expect to have some time to update the pull request this week.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161206/658fcc22/attachment.html>

From levitte at openssl.org  Tue Dec  6 21:30:57 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 06 Dec 2016 22:30:57 +0100 (CET)
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1481043672.4406.22.camel@HansenPartnership.com>
References: <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
Message-ID: <20161206.223057.237264374331072901.levitte@openssl.org>

In message <1481043672.4406.22.camel at HansenPartnership.com> on Tue, 06 Dec 2016 09:01:12 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Tue, 2016-12-06 at 17:47 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1481042048.4406.14.camel at HansenPartnership.com> on Tue,
James.Bottomley> > 06 Dec 2016 08:34:08 -0800, James Bottomley <
James.Bottomley> > James.Bottomley at HansenPartnership.com> said:
James.Bottomley> > 
James.Bottomley> > James.Bottomley> On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte
James.Bottomley> > wrote:
James.Bottomley> > James.Bottomley> > In message <
James.Bottomley> > 1480697558.2410.33.camel at HansenPartnership.com> on Fri,
James.Bottomley> > James.Bottomley> > 02 Dec 2016 08:52:38 -0800, James Bottomley <
James.Bottomley> > James.Bottomley> > James.Bottomley at HansenPartnership.com> said:
James.Bottomley> > James.Bottomley> > 
James.Bottomley> > James.Bottomley> > When I made that argument, I hadn't thought and
James.Bottomley> > felt things through
James.Bottomley> > James.Bottomley> > entirely.  Truth be told, I'm feeling very uneasy
James.Bottomley> > handing over the
James.Bottomley> > James.Bottomley> > reading and parsing of the PEM file to an engine. 
James.Bottomley> > However, handing
James.Bottomley> > James.Bottomley> > over the decoded data and leaving it to the engine
James.Bottomley> > to do something
James.Bottomley> > James.Bottomley> > sensible with it, no issues at all.
James.Bottomley> > James.Bottomley> 
James.Bottomley> > James.Bottomley> OK, can I pick on this a bit (I'll look at the store
James.Bottomley> > stuff later and
James.Bottomley> > James.Bottomley> reply after I've played with it)?  What is it that
James.Bottomley> > you imagine handing
James.Bottomley> > James.Bottomley> to the engine?  Some type of buffer that contains
James.Bottomley> > the full PEM
James.Bottomley> > James.Bottomley> representation?
James.Bottomley> > 
James.Bottomley> > In my STORE branch, you will find this in
James.Bottomley> > include/openssl/store_file.h:
James.Bottomley> > 
James.Bottomley> >     /*
James.Bottomley> >      * The try_decode function is called to check if the blob of data
James.Bottomley> > can
James.Bottomley> >      * be used by this handler, and if it can, decodes it into a
James.Bottomley> > supported
James.Bottomley> >      * OpenSSL and returns a STORE_INFO with the recorded data.
James.Bottomley> >      * Input:
James.Bottomley> >      *    pem_name:     If this blob comes from a PEM file, this
James.Bottomley> > holds
James.Bottomley> >      *                  the PEM name.  If it comes from another type
James.Bottomley> > of
James.Bottomley> >      *                  file, this is NULL.
James.Bottomley> >      *    blob:         The blob of data to match with what this
James.Bottomley> > handler
James.Bottomley> >      *                  can use.
James.Bottomley> >      *    len:          The length of the blob.
James.Bottomley> >      *    handler_ctx:  For a handler marked repeatable, this pointer
James.Bottomley> > can
James.Bottomley> >      *                  be used to create a context for the handler. 
James.Bottomley> > IT IS
James.Bottomley> >      *                  THE HANDLER'S RESPONSIBILITY TO CREATE AND
James.Bottomley> > DESTROY
James.Bottomley> >      *                  THIS CONTEXT APPROPRIATELY, i.e. create on
James.Bottomley> > first call
James.Bottomley> >      *                  and destroy when about to return NULL.
James.Bottomley> >      *    password_ui:  Application UI method for getting a password.
James.Bottomley> >      *    password_ui_data:
James.Bottomley> >      *                  Application data to be passed to password_ui
James.Bottomley> > when
James.Bottomley> >      *                  it's called.
James.Bottomley> >      * Output:
James.Bottomley> >      *    a STORE_INFO
James.Bottomley> >      */
James.Bottomley> >     typedef STORE_INFO *(*STORE_FILE_try_decode_fn)(const char
James.Bottomley> > *pem_name,
James.Bottomley> >                                                     const unsigned
James.Bottomley> > char *blob,
James.Bottomley> >                                                     size_t len,
James.Bottomley> >                                                     void
James.Bottomley> > **handler_ctx,
James.Bottomley> >                                                     const UI_METHOD
James.Bottomley> > *password_ui,
James.Bottomley> >                                                     void
James.Bottomley> > *password_ui_data);
James.Bottomley> > 
James.Bottomley> > This is the central function that tries to see if it can decode
James.Bottomley> > whatever's thrown at it.  As you can see, it gets handed the PEM name
James.Bottomley> > if it's called as part of a PEM read.  The |blob| is the decoded *and
James.Bottomley> > decrypted* data.
James.Bottomley> > 
James.Bottomley> > James.Bottomley> The reason I chose a BIO is that it's the basic
James.Bottomley> > abstract data handler
James.Bottomley> > James.Bottomley> for openssl. I can hand a buffer to the engine,
James.Bottomley> > sure, but I'd need to
James.Bottomley> > James.Bottomley> transform it to a BIO again (because it would need
James.Bottomley> > PEM parsing and all
James.Bottomley> > James.Bottomley> the PEM parsers speak BIOs), so it feels suboptimal.
James.Bottomley> > 
James.Bottomley> > With a try_decode function, I really do not see why there's a need to
James.Bottomley> > deal with the BIO...
James.Bottomley> 
James.Bottomley> OK, I get what you want.  There are two problems with this.  The first
James.Bottomley> is easy: I'm eventually going to need the BIO header as well because
James.Bottomley> TPM2 keys are going to need to describe external things that aren't in
James.Bottomley> the key representation (and even TPM1 keys might need to say who their
James.Bottomley> parent key is).  However, this is fixable by simply expanding your
James.Bottomley> prototype above to have const char *pem_name and const char *pem_header
James.Bottomley> ... is that OK?
James.Bottomley> 
James.Bottomley> The next problem is that this is slightly harder simply to insert into
James.Bottomley> the PEM code.  The BIO parsing is done in PEM_bytes_read_bio() not
James.Bottomley>  PEM_read_bio_PrivateKey().  The easy way to cope with this would be to
James.Bottomley> move PEM parsing into the ENGINE_find_engine_load_key() function and
James.Bottomley> then hand the name, header, blob to the engine.  The disadvantage of
James.Bottomley> this is that we'll end up pulling the PEM apart twice: once in
James.Bottomley> ENGINE_find_engine_load_key() and then again in PEM_bytes_read_bio(). 
James.Bottomley>  Is this OK?  If it is I can code up a v3.  If not, I can think about
James.Bottomley> how we might integrate this into PEM_bytes_read_bio().

Oh....

I think I aired some thoughts on using PEM headers a very long while
ago, but that never came into fruition, among others because I ended
up doubting that it would be the best way in the long run.

These days, the use of PEM headers is considered old and kinda sorta
deprecated, even though OpenSSL still produces encrypted private key
PEM files that uses headers for the encryption metadata.  It seems
that PKCS#8 is prefered "out there".

So I have to wonder, is PEM really the right way to go for this?
Would it be just as possible to wrap a TSS key with a PKCS#8
container, and use the associated attributes for the external data?
Just a thought, though...  I can't do more than throw around ideas,
considering how little I know about TPM.

That being said, it should certainly be easy enough to change the
appropriate places to make sure headers are available as well, and I
have zero issues adding a header parameter to the try_decode
prototype and associated functions.

One thing I didn't think of earlier is that PEM_bytes_read_bio()
checks the pem name against a known set, *or* in the private key case,
that the pem name ends with " PRIVATE KEY" (which "TSS KEY BLOB" does
not), so some kind of refactoring is needed to accomodate the
store_file_load() call either way.
(quite frankly, I'm slowly realising that the STORE_FILE_HANDLER code
can replace quite a lot of the discovery code in the PEM module, so
refactoring could be in order either way)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl at roumenpetrov.info  Tue Dec  6 21:31:59 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Tue, 06 Dec 2016 23:31:59 +0200
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161206.151226.2129387863349296405.levitte@openssl.org>
References: <1480574186.2372.114.camel@HansenPartnership.com>
 <C8433B5B-9E18-42B1-875D-4BB780DF804D@openssl.org>
 <1480697558.2410.33.camel@HansenPartnership.com>
 <20161206.151226.2129387863349296405.levitte@openssl.org>
Message-ID: <58472E4F.3010204@roumenpetrov.info>

Hi Richard,

Richard Levitte wrote:
> [SNIP]
> James.Bottomley>    1. We agreed that usability is greatly enhanced if openssl simply loads
> James.Bottomley>       a key when presented with the file/uri etc. without the user having
> James.Bottomley>       to specify what the format of a key is
>
> Check.  My STORE branch is made to support that.
One URI could represent more then one item.
STORE_INFO_types is enumerate but URI could be associated to custom data 
(handle) and this data could be used to get other data(handles).

See capi engine CAPI_KEY *capi_find_key(CAPI_CTX * ctx, const char *id)
..
         hstore = capi_open_store(ctx, NULL);
         if (!hstore)
             return NULL;
         cert = capi_find_cert(ctx, id, hstore);
         if (cert) {
             key = capi_get_cert_key(ctx, cert);
             CertFreeCertificateContext(cert);
         }
         CertCloseStore(hstore, 0);
..
Is above case PKEY is loaded only if CERT is located(found).

I guess that STORE_INFO_types could be bit-mask and to support 
application specific data in addition.


[SNIP]
Roumen

From levitte at openssl.org  Tue Dec  6 22:26:05 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 06 Dec 2016 23:26:05 +0100 (CET)
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <58472E4F.3010204@roumenpetrov.info>
References: <1480697558.2410.33.camel@HansenPartnership.com>
 <20161206.151226.2129387863349296405.levitte@openssl.org>
 <58472E4F.3010204@roumenpetrov.info>
Message-ID: <20161206.232605.962139841138881.levitte@openssl.org>

In message <58472E4F.3010204 at roumenpetrov.info> on Tue, 06 Dec 2016 23:31:59 +0200, Roumen Petrov <openssl at roumenpetrov.info> said:

openssl> Hi Richard,
openssl> 
openssl> Richard Levitte wrote:
openssl> > [SNIP]
openssl> > James.Bottomley> 1. We agreed that usability is greatly enhanced if
openssl> > openssl simply loads
openssl> > James.Bottomley> a key when presented with the file/uri etc. without
openssl> > the user having
openssl> > James.Bottomley>       to specify what the format of a key is
openssl> >
openssl> > Check.  My STORE branch is made to support that.
openssl> One URI could represent more then one item.
openssl> STORE_INFO_types is enumerate but URI could be associated to custom
openssl> data (handle) and this data could be used to get other data(handles).
openssl> 
openssl> See capi engine CAPI_KEY *capi_find_key(CAPI_CTX * ctx, const char
openssl> *id)
openssl> ..
openssl>         hstore = capi_open_store(ctx, NULL);
openssl>         if (!hstore)
openssl>             return NULL;
openssl>         cert = capi_find_cert(ctx, id, hstore);
openssl>         if (cert) {
openssl>             key = capi_get_cert_key(ctx, cert);
openssl>             CertFreeCertificateContext(cert);
openssl>         }
openssl>         CertCloseStore(hstore, 0);
openssl> ..
openssl> Is above case PKEY is loaded only if CERT is located(found).

I'm trying to understand but am failing.  Looking at your example,
it's quite clear that what you want to retrieve is a key, even though
you have to go through the corresponding certificate to get to it.

However, *nothing* stops anyone from making a loader for the "capi"
scheme (if there is such a thing) that has a load method that will
return the certificate (STORE_INFO_CERT) on the first call and the
associated key (STORE_INFO_PKEY) on the second for the same URI.  It's
all about caching information, and there is a context variable (type
STORE_LOADER_CTX, which is just a template type for loader defined
'struct store_loader_ctx_st') to be used exactly for that kind of
purpose.

In your example above, I fail to see where the custom data would be
needed...  And frankly, STORE is first of all meant to handle types
that can be used with the rest of OpenSSL.  That being said, adding a
"whatever" STORE_INFO type isn't very hard either.  I'm just not
terribly convinced yet, but let's keep talking, I'll probably
understand sooner or later what you're actually after.

Cheers,
Richard ( oh, and if example code is needed, I can provide )

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Wed Dec  7 04:42:32 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 07 Dec 2016 05:42:32 +0100 (CET)
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161206.223057.237264374331072901.levitte@openssl.org>
References: <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
Message-ID: <20161207.054232.1199336940059763361.levitte@openssl.org>

In message <20161206.223057.237264374331072901.levitte at openssl.org> on Tue, 06 Dec 2016 22:30:57 +0100 (CET), Richard Levitte <levitte at openssl.org> said:

levitte> That being said, it should certainly be easy enough to change the
levitte> appropriate places to make sure headers are available as well, and I
levitte> have zero issues adding a header parameter to the try_decode
levitte> prototype and associated functions.

Done.

levitte> One thing I didn't think of earlier is that PEM_bytes_read_bio()
levitte> checks the pem name against a known set, *or* in the private key case,
levitte> that the pem name ends with " PRIVATE KEY" (which "TSS KEY BLOB" does
levitte> not), so some kind of refactoring is needed to accomodate the
levitte> store_file_load() call either way.
levitte> (quite frankly, I'm slowly realising that the STORE_FILE_HANDLER code
levitte> can replace quite a lot of the discovery code in the PEM module, so
levitte> refactoring could be in order either way)

The easiest was actually to rewrite PEM_read_bio_PrivateKey()
entirely, so it solely uses the internal store_file functions I've
provided.
I wonder what kind of impact this would have on the community at
large.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From bkaduk at akamai.com  Wed Dec  7 16:53:14 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 7 Dec 2016 10:53:14 -0600
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161207.054232.1199336940059763361.levitte@openssl.org>
References: <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
 <20161207.054232.1199336940059763361.levitte@openssl.org>
Message-ID: <b2315b39-1d6e-8ed5-d126-dee55331919e@akamai.com>

On 12/06/2016 10:42 PM, Richard Levitte wrote:
> The easiest was actually to rewrite PEM_read_bio_PrivateKey()
> entirely, so it solely uses the internal store_file functions I've
> provided.
> I wonder what kind of impact this would have on the community at
> large.
>

If you do that, please ensure that secure memory is used for the
temporary buffers involved in reading private key material (assuming
that some form of https://github.com/openssl/openssl/pull/1700 gets merged).

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161207/5a123a2c/attachment.html>

From dwmw2 at infradead.org  Thu Dec  8 23:44:41 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Dec 2016 23:44:41 +0000
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161206.223057.237264374331072901.levitte@openssl.org>
References: <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
Message-ID: <1481240681.98151.8.camel@infradead.org>

On Tue, 2016-12-06 at 22:30 +0100, Richard Levitte wrote:
> Oh....
> 
> I think I aired some thoughts on using PEM headers a very long while
> ago, but that never came into fruition, among others because I ended
> up doubting that it would be the best way in the long run.
> 
> These days, the use of PEM headers is considered old and kinda sorta
> deprecated, even though OpenSSL still produces encrypted private key
> PEM files that uses headers for the encryption metadata.? It seems
> that PKCS#8 is prefered "out there".
> 
> So I have to wonder, is PEM really the right way to go for this?
> Would it be just as possible to wrap a TSS key with a PKCS#8
> container, and use the associated attributes for the external data?
> Just a thought, though...? I can't do more than throw around ideas,
> considering how little I know about TPM.

I would definitely suggest that we *don't* want to do it with PEM
headers. Just put the additional information into the binary ASN.1
structure.

The 2.0 version of the TssBlob (from ?3.23 of the 1.2 spec) should
hopefully contain all the auxiliary information we need, without having
to stick it in PEM headers.

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

From James.Bottomley at HansenPartnership.com  Thu Dec  8 23:56:41 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 08 Dec 2016 15:56:41 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1481240681.98151.8.camel@infradead.org>
References: <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
 <1481240681.98151.8.camel@infradead.org>
Message-ID: <1481241401.2361.38.camel@HansenPartnership.com>

On Thu, 2016-12-08 at 23:44 +0000, David Woodhouse wrote:
> On Tue, 2016-12-06 at 22:30 +0100, Richard Levitte wrote:
> > Oh....
> > 
> > I think I aired some thoughts on using PEM headers a very long
> > while
> > ago, but that never came into fruition, among others because I
> > ended
> > up doubting that it would be the best way in the long run.
> > 
> > These days, the use of PEM headers is considered old and kinda
> > sorta
> > deprecated, even though OpenSSL still produces encrypted private
> > key
> > PEM files that uses headers for the encryption metadata.  It seems
> > that PKCS#8 is prefered "out there".
> > 
> > So I have to wonder, is PEM really the right way to go for this?
> > Would it be just as possible to wrap a TSS key with a PKCS#8
> > container, and use the associated attributes for the external data?
> > Just a thought, though...  I can't do more than throw around ideas,
> > considering how little I know about TPM.
> 
> I would definitely suggest that we *don't* want to do it with PEM
> headers. Just put the additional information into the binary ASN.1
> structure.

Which evil is lesser?  If we put it in ASN.1 we'll be defining our own
instead of using the TSS defined one.  If we use headers, we can put
the extra data in them and use the TSS defined ASN.1 for the key blob.

> The 2.0 version of the TssBlob (from ?3.23 of the 1.2 spec) should
> hopefully contain all the auxiliary information we need, without 
> having to stick it in PEM headers.

Which of the many specs is this?

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/20161208/0ada35c8/attachment-0001.bin>

From James.Bottomley at HansenPartnership.com  Fri Dec  9 00:22:40 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 08 Dec 2016 16:22:40 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1481241401.2361.38.camel@HansenPartnership.com>
References: <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
 <1481240681.98151.8.camel@infradead.org>
 <1481241401.2361.38.camel@HansenPartnership.com>
Message-ID: <1481242960.2361.49.camel@HansenPartnership.com>

On Thu, 2016-12-08 at 15:56 -0800, James Bottomley wrote:
> On Thu, 2016-12-08 at 23:44 +0000, David Woodhouse wrote:
> > On Tue, 2016-12-06 at 22:30 +0100, Richard Levitte wrote:
> > > Oh....
> > > 
> > > I think I aired some thoughts on using PEM headers a very long
> > > while
> > > ago, but that never came into fruition, among others because I
> > > ended
> > > up doubting that it would be the best way in the long run.
> > > 
> > > These days, the use of PEM headers is considered old and kinda
> > > sorta
> > > deprecated, even though OpenSSL still produces encrypted private
> > > key
> > > PEM files that uses headers for the encryption metadata.  It
> > > seems
> > > that PKCS#8 is prefered "out there".
> > > 
> > > So I have to wonder, is PEM really the right way to go for this?
> > > Would it be just as possible to wrap a TSS key with a PKCS#8
> > > container, and use the associated attributes for the external
> > > data?
> > > Just a thought, though...  I can't do more than throw around
> > > ideas,
> > > considering how little I know about TPM.
> > 
> > I would definitely suggest that we *don't* want to do it with PEM
> > headers. Just put the additional information into the binary ASN.1
> > structure.
> 
> Which evil is lesser?  If we put it in ASN.1 we'll be defining our
> own
> instead of using the TSS defined one.  If we use headers, we can put
> the extra data in them and use the TSS defined ASN.1 for the key
> blob.
> 
> > The 2.0 version of the TssBlob (from ?3.23 of the 1.2 spec) should
> > hopefully contain all the auxiliary information we need, without 
> > having to stick it in PEM headers.
> 
> Which of the many specs is this?

I'm guessing you mean this:

https://www.trustedcomputinggroup.org/wp-content/uploads/TSS_Version_1.2_Level_1_FINAL.pdf

?  It still doesn't tell you who the expected parent of the key would
be, which is the problem I'm currently trying to solve.

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/20161208/a15f8b24/attachment.bin>

From dwmw2 at infradead.org  Fri Dec  9 00:25:28 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 09 Dec 2016 00:25:28 +0000
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1481242960.2361.49.camel@HansenPartnership.com>
References: <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
 <1481240681.98151.8.camel@infradead.org>
 <1481241401.2361.38.camel@HansenPartnership.com>
 <1481242960.2361.49.camel@HansenPartnership.com>
Message-ID: <1481243128.98151.10.camel@infradead.org>

On Thu, 2016-12-08 at 16:22 -0800, James Bottomley wrote:
> 
> I'm guessing you mean this:
> 
> https://www.trustedcomputinggroup.org/wp-content/uploads/TSS_Version_1.2_Level_1_FINAL.pdf
> 
> ?? It still doesn't tell you who the expected parent of the key would
> be, which is the problem I'm currently trying to solve.

Right, in S3.23 ("Portable Data") or thereabouts. And yes, it doesn't
indicate the parent key. As discussed, the TssBlob structure there is
fairly pointless which is presumably why the TPM ENGINE didn't use it,
and just dumped the actual blob (which I later put into an OCTET_STRING
 in the PEM files, IIRC).

I was hoping that the TPM 2.0 spec would fix that, maybe?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/74cf272e/attachment.bin>

From James.Bottomley at HansenPartnership.com  Fri Dec  9 00:32:01 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 08 Dec 2016 16:32:01 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1481243128.98151.10.camel@infradead.org>
References: <1481042048.4406.14.camel@HansenPartnership.com>
 <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
 <1481240681.98151.8.camel@infradead.org>
 <1481241401.2361.38.camel@HansenPartnership.com>
 <1481242960.2361.49.camel@HansenPartnership.com>
 <1481243128.98151.10.camel@infradead.org>
Message-ID: <1481243521.2361.52.camel@HansenPartnership.com>

On Fri, 2016-12-09 at 00:25 +0000, David Woodhouse wrote:
> On Thu, 2016-12-08 at 16:22 -0800, James Bottomley wrote:
> > 
> > I'm guessing you mean this:
> > 
> > https://www.trustedcomputinggroup.org/wp-content/uploads/TSS_Versio
> > n_1.2_Level_1_FINAL.pdf
> > 
> > ?  It still doesn't tell you who the expected parent of the key 
> > would be, which is the problem I'm currently trying to solve.
> 
> Right, in S3.23 ("Portable Data") or thereabouts. And yes, it doesn't
> indicate the parent key. As discussed, the TssBlob structure there is
> fairly pointless which is presumably why the TPM ENGINE didn't use 
> it, and just dumped the actual blob (which I later put into an
> OCTET_STRING  in the PEM files, IIRC).
> 
> I was hoping that the TPM 2.0 spec would fix that, maybe?

Not far enough through it yet to be definitive, but I don't think so
... there's even more parent like seeds in it.

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/20161208/a985bad5/attachment-0001.bin>

From aowtea at gmail.com  Fri Dec  9 03:25:53 2016
From: aowtea at gmail.com (Aow Tea)
Date: Fri, 9 Dec 2016 11:25:53 +0800
Subject: [openssl-dev] Does OpenSSL support the extension 'subject directory
	attributes'?
Message-ID: <CACF9PRwX9D3nm9rAhH-GXdsXS_CTKkJaN7Jav7OXvxMU9G0ncA@mail.gmail.com>

Dear everyone,
       I am using PyOpenSSL which is the thin wrapper of OpenSSL to add the
extension 'subject directory attributes' to a certificate by a Python
program. The extension names 'subjectDirAttrs' and
'subjectDirectoryAttributes' have been tried but the error occurs:
"OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'unknown
extension name'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in
extension')]".

       As PyOpenSSL is the wrapper of OpenSSL, can anyone make it clear
that whether OpenSSL supports the extension 'subject directory attributes'
and what is the proper name in programming if OpenSSL supports it?

       The other question is the error is reported as follows when I add
the extension 'certificate policies' to a certificate by PyOpenSSL.
        "OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'no
config database'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in
extension')]"
       What is the config database? Does it refer to
/usr/local/ssl/openssl.cnf?  How to use it to add the extension
'certificate policies' to a certificate by PyOpenSSL?
       Many thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/9a11e7a3/attachment.html>

From fedor at indutny.com  Fri Dec  9 19:43:01 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Fri, 9 Dec 2016 20:43:01 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
Message-ID: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>

Hello,

During development of one feature for my TLS proxy bud, I have discovered
that the cert_cb is invoked only for newly generated tickets/sessions. The
reasoning behind this is clear, but I believe that it is most likely needs
a revision. Here is my reasoning:

The major use case is choosing a certificate/private key either dynamically
(based on various parameters of SSL structure) or asynchronously (by
using SSL_ERROR_WANT_X509_LOOKUP). However when the TLS ticket is provided
by the client, it will be parsed and loaded using the ticket key from the
main context, without giving a way for application to override it for
particular servername (from SNI). Furthermore, with the TLS ticket provided
application can no longer chose to provide a different certificate in case
of expiration or revocation.

The documentation says:

"It is B<always> called even is a certificate is already set so the callback
can modify or delete the existing certificate."

Additionally, when talking about things allowed in `cert_cb`:

"An application will typically call SSL_use_certificate() and
SSL_use_PrivateKey() to set the end entity certificate and private key.
It can add intermediate and optionally the root CA certificates using
SSL_add1_chain_cert()."

It only says that it is *typically* for applications to use these functions
not limiting them to set and use different secure contextes on cert_cb.
This is in fact what I've used in bud, and what we use in node.js too.

Proposal:

Invoke cert_cb before looking up session ids and parsing tls tickets. It is
a safe change, and it should be done to match intention of this API
documented in man pages.

Please let me know if I can help or work on this.

Thank you,
Fedor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/14c33e19/attachment.html>

From openssl-users at dukhovni.org  Fri Dec  9 20:28:17 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 9 Dec 2016 20:28:17 +0000
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
Message-ID: <20161209202816.GR13486@mournblade.imrryr.org>

On Fri, Dec 09, 2016 at 08:43:01PM +0100, Fedor Indutny wrote:

> During development of one feature for my TLS proxy bud, I have discovered
> that the cert_cb is invoked only for newly generated tickets/sessions. The
> reasoning behind this is clear, but I believe that it is most likely needs
> a revision. Here is my reasoning:

The callback is *correctly* only called when choosing the server
certificate.  In *that* case, it is always called.  When sessions
are resumed, there is no certificate to present, so no callback is
made.

> Furthermore, with the TLS ticket provided
> application can no longer chose to provide a different certificate in case
> of expiration or revocation.

You can implement a ticket key callback that when appropriate, will
decline tickets under suitable conditions, in which case a full
handshake will be performed.

Custom ticket callbacks that do session ticket key rotation are a
good idea in any case, the default tickets are not rotated, which
is not apppropriate for long-running processes.

-- 
	Viktor.

From fedor at indutny.com  Fri Dec  9 20:47:19 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Fri, 9 Dec 2016 21:47:19 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <20161209202816.GR13486@mournblade.imrryr.org>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <20161209202816.GR13486@mournblade.imrryr.org>
Message-ID: <CAEv2VfKVGRanYfiAACYUjswsLRPbqCMBLZTowwPqqe4xaHdkgg@mail.gmail.com>

Hello Viktor!

Replying inline.

On Fri, Dec 9, 2016 at 9:28 PM, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Fri, Dec 09, 2016 at 08:43:01PM +0100, Fedor Indutny wrote:
>
> > During development of one feature for my TLS proxy bud, I have discovered
> > that the cert_cb is invoked only for newly generated tickets/sessions.
> The
> > reasoning behind this is clear, but I believe that it is most likely
> needs
> > a revision. Here is my reasoning:
>
> The callback is *correctly* only called when choosing the server
> certificate.  In *that* case, it is always called.  When sessions
> are resumed, there is no certificate to present, so no callback is
> made.
>


That's why I said that the intended logic is clear. However, this
implementation makes the API unusable in at least one case. Even more,
there are no alternatives to this API, meaning that there is no other way
to delay certificate/key/context selection. Clearly this is the case for
which the API was created.


>
> > Furthermore, with the TLS ticket provided
> > application can no longer chose to provide a different certificate in
> case
> > of expiration or revocation.
>
> You can implement a ticket key callback that when appropriate, will
> decline tickets under suitable conditions, in which case a full
> handshake will be performed.
>
> Custom ticket callbacks that do session ticket key rotation are a
> good idea in any case, the default tickets are not rotated, which
> is not apppropriate for long-running processes.
>
>
Ticket rotation is already possible in both bud and node.js and is
completely unrelated to this issue. Even with ticket rotation valid tickets
will cause asynchronous SNI lookups to be skipped.

Let me put this into real example. "bud" does SNI balancing and
asynchronous OCSP stapling. When there are no tickets - it will connect to
some HTTP backend to fetch certificate, key, and list of cleartext
backends. It will also asynchronously fetch OCSP response from either
remote cache or OCSP authority.

However, when valid TLS ticket is received - OpenSSL will skip the
`cert_cb` and will just do regular handshake as no `cert_cb` was set. This
breaks balancing and OCSP stapling fetching, which are major use cases for
both bud and node.js (which can do all of this too through external
modules).

Hope this clarifies things a bit,
Fedor.


> --
>         Viktor.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/44203f51/attachment.html>

From openssl-users at dukhovni.org  Fri Dec  9 22:13:34 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 9 Dec 2016 22:13:34 +0000
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfKVGRanYfiAACYUjswsLRPbqCMBLZTowwPqqe4xaHdkgg@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <20161209202816.GR13486@mournblade.imrryr.org>
 <CAEv2VfKVGRanYfiAACYUjswsLRPbqCMBLZTowwPqqe4xaHdkgg@mail.gmail.com>
Message-ID: <20161209221334.GS13486@mournblade.imrryr.org>

On Fri, Dec 09, 2016 at 09:47:19PM +0100, Fedor Indutny wrote:

> > The callback is *correctly* only called when choosing the server
> > certificate.  In *that* case, it is always called.  When sessions
> > are resumed, there is no certificate to present, so no callback is
> > made.
> 
> That's why I said that the intended logic is clear. However, this
> implementation makes the API unusable in at least one case. Even more,
> there are no alternatives to this API, meaning that there is no other way
> to delay certificate/key/context selection. Clearly this is the case for
> which the API was created.

Resumed sessions don't select any certificates, so it makes no
sense to invoke certificate selection callbacks.

> Ticket rotation is already possible in both bud and node.js and is
> completely unrelated to this issue. Even with ticket rotation valid tickets
> will cause asynchronous SNI lookups to be skipped.

If you deny the key id, then a new session will be negotiated, and
certificate selection callbacks will be invoked.

> However, when valid TLS ticket is received - OpenSSL will skip the
> `cert_cb` and will just do regular handshake as no `cert_cb` was set. This
> breaks balancing and OCSP stapling fetching, which are major use cases for
> both bud and node.js (which can do all of this too through external
> modules).

There is no OCSP with resumed sessions, no certificates are sent
by the server or checked by the client.  If you want certificates,
don't do session resumption.

OpenSSL is behaving correctly.  This is a fundamental feature of TLS.

-- 
	Viktor.

From fedor at indutny.com  Fri Dec  9 22:22:54 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Fri, 9 Dec 2016 23:22:54 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <20161209221334.GS13486@mournblade.imrryr.org>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <20161209202816.GR13486@mournblade.imrryr.org>
 <CAEv2VfKVGRanYfiAACYUjswsLRPbqCMBLZTowwPqqe4xaHdkgg@mail.gmail.com>
 <20161209221334.GS13486@mournblade.imrryr.org>
Message-ID: <CAEv2VfLH25pkgHrBU6HBvJXwy2krzrAEHj-Kn2SOjmcT2ptpMw@mail.gmail.com>

On Fri, Dec 9, 2016 at 11:13 PM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

> On Fri, Dec 09, 2016 at 09:47:19PM +0100, Fedor Indutny wrote:
>
> > > The callback is *correctly* only called when choosing the server
> > > certificate.  In *that* case, it is always called.  When sessions
> > > are resumed, there is no certificate to present, so no callback is
> > > made.
> >
> > That's why I said that the intended logic is clear. However, this
> > implementation makes the API unusable in at least one case. Even more,
> > there are no alternatives to this API, meaning that there is no other way
> > to delay certificate/key/context selection. Clearly this is the case for
> > which the API was created.
>
> Resumed sessions don't select any certificates, so it makes no
> sense to invoke certificate selection callbacks.
>

The problem with ticket keys is that they are assigned globally and there
is no way to control what's happening independently in asynchronous manner.
Thus API looks a bit odd: on one hand OpenSSL allows selecting certs
asynchronously, on other hand TLS tickets are going to be processed
synchronously anyway.


>
> > Ticket rotation is already possible in both bud and node.js and is
> > completely unrelated to this issue. Even with ticket rotation valid
> tickets
> > will cause asynchronous SNI lookups to be skipped.
>
> If you deny the key id, then a new session will be negotiated, and
> certificate selection callbacks will be invoked.
>

This means disabling TLS ticket keys for both bud and node.js . It is
possible, but will hurt performance significantly.


>
> > However, when valid TLS ticket is received - OpenSSL will skip the
> > `cert_cb` and will just do regular handshake as no `cert_cb` was set.
> This
> > breaks balancing and OCSP stapling fetching, which are major use cases
> for
> > both bud and node.js (which can do all of this too through external
> > modules).
>
> There is no OCSP with resumed sessions, no certificates are sent
> by the server or checked by the client.  If you want certificates,
> don't do session resumption.
>
> OpenSSL is behaving correctly.  This is a fundamental feature of TLS.
>

While I agree about OCSP, I don't see how this fundamental feature helps in
backend selection case. Clearly it is impossible to choose backends
dynamically with such reduced API implementation.

All in all, what I am asking for is an internal change that will still
adhere to the documentation. There is no fundamental feature of TLS that
could prohibit this.



>
> --
>         Viktor.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/69fe81a9/attachment-0001.html>

From bkaduk at akamai.com  Fri Dec  9 22:24:41 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Fri, 9 Dec 2016 16:24:41 -0600
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
Message-ID: <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>

On 12/09/2016 01:43 PM, Fedor Indutny wrote:
> Hello,
>
> During development of one feature for my TLS proxy bud, I have
> discovered that the cert_cb is invoked only for newly generated
> tickets/sessions. The reasoning behind this is clear, but I believe
> that it is most likely needs a revision. Here is my reasoning:
>
> The major use case is choosing a certificate/private key either
> dynamically (based on various parameters of SSL structure) or
> asynchronously (by using SSL_ERROR_WANT_X509_LOOKUP). However when the
> TLS ticket is provided by the client, it will be parsed and loaded
> using the ticket key from the main context, without giving a way for
> application to override it for particular servername (from SNI).
> Furthermore, with the TLS ticket provided application can no longer
> chose to provide a different certificate in case of expiration or
> revocation.
>

If you had a callback that ran before session resumption (possibly the
existing SNI callback, possibly a new callback), would that allow you to
solve your problem?  I would very much like to see such an early
callback so as to be able to do SNI processing before resumption,
possibly even before version negotiation.  (And yes, I should put my
money where my mouth is and come up with a patch.)

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/f08856db/attachment.html>

From fedor at indutny.com  Fri Dec  9 22:29:18 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Fri, 9 Dec 2016 23:29:18 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
Message-ID: <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>

Hello Benjamin,

On Fri, Dec 9, 2016 at 11:24 PM, Benjamin Kaduk <bkaduk at akamai.com> wrote:

> On 12/09/2016 01:43 PM, Fedor Indutny wrote:
>
> Hello,
>
> During development of one feature for my TLS proxy bud, I have discovered
> that the cert_cb is invoked only for newly generated tickets/sessions. The
> reasoning behind this is clear, but I believe that it is most likely needs
> a revision. Here is my reasoning:
>
> The major use case is choosing a certificate/private key either
> dynamically (based on various parameters of SSL structure) or
> asynchronously (by using SSL_ERROR_WANT_X509_LOOKUP). However when the
> TLS ticket is provided by the client, it will be parsed and loaded using
> the ticket key from the main context, without giving a way for application
> to override it for particular servername (from SNI). Furthermore, with the
> TLS ticket provided application can no longer chose to provide a different
> certificate in case of expiration or revocation.
>
>
> If you had a callback that ran before session resumption (possibly the
> existing SNI callback, possibly a new callback), would that allow you to
> solve your problem?  I would very much like to see such an early callback
> so as to be able to do SNI processing before resumption, possibly even
> before version negotiation.  (And yes, I should put my money where my mouth
> is and come up with a patch.)
>

That's exactly what I am asking for. Putting it before session resumption
will be enough for my use case, though.

Thank you,
Fedor.


>
> -Ben
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/21607645/attachment.html>

From fedor at indutny.com  Fri Dec  9 22:41:04 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Fri, 9 Dec 2016 23:41:04 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
Message-ID: <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>

Oh, just to restate it. I'm willing to submit the patch if we agree on what
exactly it should do.

On Fri, Dec 9, 2016 at 11:29 PM, Fedor Indutny <fedor at indutny.com> wrote:

> Hello Benjamin,
>
> On Fri, Dec 9, 2016 at 11:24 PM, Benjamin Kaduk <bkaduk at akamai.com> wrote:
>
>> On 12/09/2016 01:43 PM, Fedor Indutny wrote:
>>
>> Hello,
>>
>> During development of one feature for my TLS proxy bud, I have discovered
>> that the cert_cb is invoked only for newly generated tickets/sessions. The
>> reasoning behind this is clear, but I believe that it is most likely needs
>> a revision. Here is my reasoning:
>>
>> The major use case is choosing a certificate/private key either
>> dynamically (based on various parameters of SSL structure) or
>> asynchronously (by using SSL_ERROR_WANT_X509_LOOKUP). However when the
>> TLS ticket is provided by the client, it will be parsed and loaded using
>> the ticket key from the main context, without giving a way for application
>> to override it for particular servername (from SNI). Furthermore, with the
>> TLS ticket provided application can no longer chose to provide a different
>> certificate in case of expiration or revocation.
>>
>>
>> If you had a callback that ran before session resumption (possibly the
>> existing SNI callback, possibly a new callback), would that allow you to
>> solve your problem?  I would very much like to see such an early callback
>> so as to be able to do SNI processing before resumption, possibly even
>> before version negotiation.  (And yes, I should put my money where my mouth
>> is and come up with a patch.)
>>
>
> That's exactly what I am asking for. Putting it before session resumption
> will be enough for my use case, though.
>
> Thank you,
> Fedor.
>
>
>>
>> -Ben
>>
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/c3658e6a/attachment.html>

From bkaduk at akamai.com  Fri Dec  9 22:46:27 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Fri, 9 Dec 2016 16:46:27 -0600
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
Message-ID: <885b7d96-7554-d0df-a578-694d20d9ce87@akamai.com>

I was mostly under the impression that Matt Caswell was planning to add
a generic "early callback" that gets called just after extensions are
read but before they are processed, and was waiting to see what that
looked like and whether the same API could be reasonably backported to
1.1.0 (not necessarily in the upstream repo, of course).  But I also
haven't had a chance to work through the extensions processing revamp
that landed this week, yet.

Just moving the existing servername_callback earlier is rather
non-trivial, since it expects to be able to reach into the session in
various ways, and of course there's no session yet.  Some things can be
worked around, like SSL_get_servername(), but I'm not sure I can
enumerate all the things that existing servername_callbacks are supposed
to be able to do, so it's hard to be confident that I can move the
servername_callback that early without introducing regressions somewhere.

-Ben

On 12/09/2016 04:41 PM, Fedor Indutny wrote:
> Oh, just to restate it. I'm willing to submit the patch if we agree on
> what exactly it should do.
>
> On Fri, Dec 9, 2016 at 11:29 PM, Fedor Indutny <fedor at indutny.com
> <mailto:fedor at indutny.com>> wrote:
>
>     Hello Benjamin,
>
>     On Fri, Dec 9, 2016 at 11:24 PM, Benjamin Kaduk <bkaduk at akamai.com
>     <mailto:bkaduk at akamai.com>> wrote:
>
>         On 12/09/2016 01:43 PM, Fedor Indutny wrote:
>>         Hello,
>>
>>         During development of one feature for my TLS proxy bud, I
>>         have discovered that the cert_cb is invoked only for newly
>>         generated tickets/sessions. The reasoning behind this is
>>         clear, but I believe that it is most likely needs a revision.
>>         Here is my reasoning:
>>
>>         The major use case is choosing a certificate/private key
>>         either dynamically (based on various parameters of SSL
>>         structure) or asynchronously (by
>>         using SSL_ERROR_WANT_X509_LOOKUP). However when the TLS
>>         ticket is provided by the client, it will be parsed and
>>         loaded using the ticket key from the main context, without
>>         giving a way for application to override it for particular
>>         servername (from SNI). Furthermore, with the TLS ticket
>>         provided application can no longer chose to provide a
>>         different certificate in case of expiration or revocation.
>>
>
>         If you had a callback that ran before session resumption
>         (possibly the existing SNI callback, possibly a new callback),
>         would that allow you to solve your problem?  I would very much
>         like to see such an early callback so as to be able to do SNI
>         processing before resumption, possibly even before version
>         negotiation.  (And yes, I should put my money where my mouth
>         is and come up with a patch.)
>
>
>     That's exactly what I am asking for. Putting it before session
>     resumption will be enough for my use case, though.
>
>     Thank you,
>     Fedor.
>      
>
>
>         -Ben
>
>         --
>         openssl-dev mailing list
>         To unsubscribe:
>         https://mta.openssl.org/mailman/listinfo/openssl-dev
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=sbnZWkN6RGNdcWHXUctjpQ0dDo4FpOmhAvXjeqlWq5A&s=l0X6ypyf5fI7pSlZ5EV9nBMPp-xa-2XNJGj-sONAPho&e=>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161209/ac913b38/attachment-0001.html>

From rsalz at akamai.com  Sat Dec 10 01:57:48 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 10 Dec 2016 01:57:48 +0000
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
Message-ID: <af0bfabe651d48d395b9469854602694@usma1ex-dag1mb1.msg.corp.akamai.com>

What seems most sensible is to have a callback once the hello is parsed, allow the callback to change almost anything it wants.  I would be very disappointed if we did something that was too specific to some special use cases.



From rsalz at akamai.com  Sat Dec 10 02:07:08 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 10 Dec 2016 02:07:08 +0000
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
Message-ID: <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>

> Oh, just to restate it. I'm willing to submit the patch if we agree on what exactly it should do.

Might want to wait a bit.  TLS 1.3 handshakes are a bit different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161210/ec5ba4eb/attachment.html>

From fedor at indutny.com  Sat Dec 10 10:13:48 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Sat, 10 Dec 2016 11:13:48 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
 <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>

This totally makes sense. Unfortunately, adding a new API method for this
means that I'll have to re-introduce ClientHello parser in bud, and make a
wider use of it in Node.js again.

On Sat, Dec 10, 2016 at 3:07 AM, Salz, Rich <rsalz at akamai.com> wrote:

> > Oh, just to restate it. I'm willing to submit the patch if we agree on
> what exactly it should do.
>
>
>
> Might want to wait a bit.  TLS 1.3 handshakes are a bit different.
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161210/9d4d8141/attachment.html>

From fedor at indutny.com  Sat Dec 10 10:14:07 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Sat, 10 Dec 2016 11:14:07 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
 <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>
Message-ID: <CAEv2VfL1hk8YUZzFaBST9OSLKr5WEHwC_O66EsOXnOHzn5kKYA@mail.gmail.com>

Thank you for feedback, though!

On Sat, Dec 10, 2016 at 11:13 AM, Fedor Indutny <fedor at indutny.com> wrote:

> This totally makes sense. Unfortunately, adding a new API method for this
> means that I'll have to re-introduce ClientHello parser in bud, and make a
> wider use of it in Node.js again.
>
> On Sat, Dec 10, 2016 at 3:07 AM, Salz, Rich <rsalz at akamai.com> wrote:
>
>> > Oh, just to restate it. I'm willing to submit the patch if we agree on
>> what exactly it should do.
>>
>>
>>
>> Might want to wait a bit.  TLS 1.3 handshakes are a bit different.
>>
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161210/341aa550/attachment.html>

From alessandro at ghedini.me  Sat Dec 10 13:35:56 2016
From: alessandro at ghedini.me (Alessandro Ghedini)
Date: Sat, 10 Dec 2016 13:35:56 +0000
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
 <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>
Message-ID: <20161210133556.zwhwpqegiinyyhdv@pinky.local>

On Sat, Dec 10, 2016 at 11:13:48AM +0100, Fedor Indutny wrote:
> This totally makes sense. Unfortunately, adding a new API method for this
> means that I'll have to re-introduce ClientHello parser in bud, and make a
> wider use of it in Node.js again.

FWIW, BoringSSL offers an early callback that is passed a semi-parsed CH, and
an API to extract specific extensions from it (though this returns the raw
unparsed extension body). Something similar could be adopted for OpenSSL.

Whether this should be called in the CH post process phase (immediately before
cert_cb) or much earlier (like BoringSSL) is likely to affect the implementation
though (e.g. I'm not sure if the CH buffer is still available in the post
process).

Might be worth noting that BoringSSL changed the CH processing recently, by
moving the session resumption logic after cert_cb, which means cert_cb is now
called every time, but without a SSL_SESSION being available. So calling the
cert_cb unconditionally is not unheard of.

Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161210/234c4bf1/attachment.sig>

From rsalz at akamai.com  Sat Dec 10 14:16:35 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 10 Dec 2016 14:16:35 +0000
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfL1hk8YUZzFaBST9OSLKr5WEHwC_O66EsOXnOHzn5kKYA@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
 <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>
 <CAEv2VfL1hk8YUZzFaBST9OSLKr5WEHwC_O66EsOXnOHzn5kKYA@mail.gmail.com>
Message-ID: <c8b999d289d841978675d62c88b99a5a@usma1ex-dag1mb1.msg.corp.akamai.com>

> Thank you for feedback, though!

Thanks for your expertise and continued interest in pushing OpenSSL into new(er) areas!

From fedor at indutny.com  Sat Dec 10 14:16:39 2016
From: fedor at indutny.com (Fedor Indutny)
Date: Sat, 10 Dec 2016 15:16:39 +0100
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <20161210133556.zwhwpqegiinyyhdv@pinky.local>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
 <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>
 <20161210133556.zwhwpqegiinyyhdv@pinky.local>
Message-ID: <CAEv2VfKVnarc2kF0D0i0w08Wf1rnvOk9UD04z4ZF80V_imgNiQ@mail.gmail.com>

Alessandro,

Indeed I just checked BoringSSL's source and it calls cert_cb before
resuming the session. Inviting David Benjamin into this conversation.

David,

Do you have any insights or motivation to share with us? The way BoringSSL
handles session resumption + cert_cb is a correct one in my opinion, and
I'm trying to persuade everyone here in this too :)

Thank you,
Fedor.

On Sat, Dec 10, 2016 at 2:35 PM, Alessandro Ghedini <alessandro at ghedini.me>
wrote:

> On Sat, Dec 10, 2016 at 11:13:48AM +0100, Fedor Indutny wrote:
> > This totally makes sense. Unfortunately, adding a new API method for this
> > means that I'll have to re-introduce ClientHello parser in bud, and make
> a
> > wider use of it in Node.js again.
>
> FWIW, BoringSSL offers an early callback that is passed a semi-parsed CH,
> and
> an API to extract specific extensions from it (though this returns the raw
> unparsed extension body). Something similar could be adopted for OpenSSL.
>
> Whether this should be called in the CH post process phase (immediately
> before
> cert_cb) or much earlier (like BoringSSL) is likely to affect the
> implementation
> though (e.g. I'm not sure if the CH buffer is still available in the post
> process).
>
> Might be worth noting that BoringSSL changed the CH processing recently, by
> moving the session resumption logic after cert_cb, which means cert_cb is
> now
> called every time, but without a SSL_SESSION being available. So calling
> the
> cert_cb unconditionally is not unheard of.
>
> Cheers
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161210/3f72a3c6/attachment.html>

From davidben at google.com  Sat Dec 10 19:26:16 2016
From: davidben at google.com (David Benjamin)
Date: Sat, 10 Dec 2016 19:26:16 +0000
Subject: [openssl-dev] cert_cb and TLS tickets
In-Reply-To: <CAEv2VfKVnarc2kF0D0i0w08Wf1rnvOk9UD04z4ZF80V_imgNiQ@mail.gmail.com>
References: <CAEv2VfKPORTYFvygA0HZEUdtMgc6aeNNz+81mbOG0HXps5mSVw@mail.gmail.com>
 <a41f5a43-8901-b176-a0b7-fb3f01f8405e@akamai.com>
 <CAEv2VfJKsJqPMAe8T1jO7szdGOCOmPwB1OnOgjWRObLcodCZZw@mail.gmail.com>
 <CAEv2VfKjujUeTFWPQ_eKQwx0mrK4_2YqUzgDcE4gvL_KL9T7JA@mail.gmail.com>
 <c505cb4b35354b81870ea08a4a87a461@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAEv2Vf+QMjtxxg8Srtr+6y4Uzpo1QLbp_By3Fz6EZgRBQN3wtw@mail.gmail.com>
 <20161210133556.zwhwpqegiinyyhdv@pinky.local>
 <CAEv2VfKVnarc2kF0D0i0w08Wf1rnvOk9UD04z4ZF80V_imgNiQ@mail.gmail.com>
Message-ID: <CAF8qwaAdFrnZDM8DdmE_cFcTGL0+Hdbcq9Sti=+h60gJ5CtshA@mail.gmail.com>

(Resending from an address which is actually subscribed. Apologies if this
causes anyone to receive this twice.)

Here's the patch series which flipped it:
https://boringssl.googlesource.com/boringssl/+/4eb95ccfd64d46fad23f36238690594d02518467
https://boringssl.googlesource.com/boringssl/+/34202b93b6195e9c55402a6bc2653956d0cd26d8
https://boringssl.googlesource.com/boringssl/+/f01f42a2ce161657c6413ef71d7c04262c7abd56
https://boringssl.googlesource.com/boringssl/+/a933c38f1af3ad7b03974ca7d7300b9df2162117

This is mostly compatible but not completely, so OpenSSL may not be able to
do it. Actually, Fedor, you might be amused to learn Node even incompatible
with it before this change:
https://github.com/nodejs/node/pull/9347

The motivation was to flip our session resumption and cipher suite logic.
cert_cb must be called before cipher selection, and extensions must be
processed before cert_cb, hence the full reorder. (We'd already replaced
OpenSSL's callbacks with BoringSSL's "early callback" mentioned elsewhere
in the thread.) But I agree this is also a more sensible ordering.

Suppose a server which prefers GCM > CBC receives:
ClientHello{cipher_suites={GCM, CBC}, ticket=session{CBC}}

The preferred cipher suite is GCM, but OpenSSL will opt to resume the
session and end up negotiating CBC. This may happen if the client or server
changed but retained ticket continuity. (Common for servers. Or client
might persist sessions.) After those changes, BoringSSL will pick the
cipher first and only resume if the cipher matches.

The suboptimal negotiation is temporary in TLS 1.2, so it's not that
important. This assumes TLS 1.2 sessions are short-lived and TLS 1.2 ticket
renewal is rare (or at least doesn't extend lifetimes).

In TLS 1.3, we have psk_dhe_ke, renewal actually refreshes keys, resumption
is more valuable (0-RTT, while 1.2 1-RTT can be done with False Start), and
there may later be an extension to renew with fresh identity assertion. I
anticipate 1.3 resumption to be more continuous. This suboptimal
negotiation now persists. Better to pay a resumption miss once and break
the cycle.

Fortunately, the "cert_cb before ciphers" rule is only true in TLS 1.2
where cipher suites include the key type. TLS 1.3's decoupled negotiation
means OpenSSL can do reordered negotiation in 1.3 without breaking cert_cb
compatibility but keep 1.2's negotiation old-style. We did it for both
because it's easier to reason about, cleaner, and "mostly compatible".

Hope this helps,

David

On Sat, Dec 10, 2016 at 9:17 AM Fedor Indutny <fedor at indutny.com> wrote:

> Alessandro,
>
> Indeed I just checked BoringSSL's source and it calls cert_cb before
> resuming the session. Inviting David Benjamin into this conversation.
>
> David,
>
> Do you have any insights or motivation to share with us? The way BoringSSL
> handles session resumption + cert_cb is a correct one in my opinion, and
> I'm trying to persuade everyone here in this too :)
>
> Thank you,
> Fedor.
>
> On Sat, Dec 10, 2016 at 2:35 PM, Alessandro Ghedini <alessandro at ghedini.me
> > wrote:
>
> On Sat, Dec 10, 2016 at 11:13:48AM +0100, Fedor Indutny wrote:
> > This totally makes sense. Unfortunately, adding a new API method for this
> > means that I'll have to re-introduce ClientHello parser in bud, and make
> a
> > wider use of it in Node.js again.
>
> FWIW, BoringSSL offers an early callback that is passed a semi-parsed CH,
> and
> an API to extract specific extensions from it (though this returns the raw
> unparsed extension body). Something similar could be adopted for OpenSSL.
>
> Whether this should be called in the CH post process phase (immediately
> before
> cert_cb) or much earlier (like BoringSSL) is likely to affect the
> implementation
> though (e.g. I'm not sure if the CH buffer is still available in the post
> process).
>
> Might be worth noting that BoringSSL changed the CH processing recently, by
> moving the session resumption logic after cert_cb, which means cert_cb is
> now
> called every time, but without a SSL_SESSION being available. So calling
> the
> cert_cb unconditionally is not unheard of.
>
> Cheers
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161210/b5a02e96/attachment.html>

From openssl at roumenpetrov.info  Sun Dec 11 15:59:07 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sun, 11 Dec 2016 17:59:07 +0200
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161206.232605.962139841138881.levitte@openssl.org>
References: <1480697558.2410.33.camel@HansenPartnership.com>	<20161206.151226.2129387863349296405.levitte@openssl.org>	<58472E4F.3010204@roumenpetrov.info>
 <20161206.232605.962139841138881.levitte@openssl.org>
Message-ID: <584D77CB.7090307@roumenpetrov.info>

HI Richard,

Richard Levitte wrote:
> In message<58472E4F.3010204 at roumenpetrov.info>  on Tue, 06 Dec 2016 23:31:59 +0200, Roumen Petrov<openssl at roumenpetrov.info>  said:
>
> openssl> Hi Richard,
> openssl>
> [SNIP]
> openssl> > Check.  My STORE branch is made to support that.
> openssl> One URI could represent more then one item.
> openssl> STORE_INFO_types is enumerate but URI could be associated to custom
> openssl> data (handle) and this data could be used to get other data(handles).
> openssl>
> openssl> See capi engine CAPI_KEY *capi_find_key(CAPI_CTX * ctx, const char
> openssl> *id)
> [SNIP]
> openssl> Is above case PKEY is loaded only if CERT is located(found).
>
> I'm trying to understand but am failing.  Looking at your example,
> it's quite clear that what you want to retrieve is a key, even though
> you have to go through the corresponding certificate to get to it.
After first review of API delared in openssl/store.h I misunderstand 
goal of load method.

I think that code of capi engine could be considered as sample what is 
need for an loadable module (engine) to use "OpenSSL Store API". I post 
above code just to get idea where currently is used an "external store api".
Just imagine how existing capi code could be changed to use store-API 
and to implement loader(scheme?).

I'm asking as currently there is no interface (API) that could associate 
key (private) and X.509 certificate. Currently engines implement custom 
command as work-around. For instance LOAD_CERT_CTRL (pkcs11 and e_nss) 
and LOAD_CERT_EVP(e_nss).

This one of areas where applications could benefit from "Store API".

I post a sniped from CAPI code because it is part of OpenSSL, but king 
of "external store api" is used by other engines.


> However,*nothing*  stops anyone from making a loader for the "capi"
> scheme (if there is such a thing) that has a load method that will
> return the certificate (STORE_INFO_CERT) on the first call and the
> associated key (STORE_INFO_PKEY) on the second for the same URI.  It's
> all about caching information, and there is a context variable (type
> STORE_LOADER_CTX, which is just a template type for loader defined
> 'struct store_loader_ctx_st') to be used exactly for that kind of
> purpose.

I guess that "load" method is supposed to return all data at once.

Actually it is an iterator!

Please update comments before method and if possible to change name of 
method.


> [SNIP]
> In your example above, I fail to see where the custom data would be
> needed...  And frankly, STORE is first of all meant to handle types
> that can be used with the rest of OpenSSL.  That being said, adding a
> "whatever" STORE_INFO type isn't very hard either.  I'm just not
> terribly convinced yet, but let's keep talking, I'll probably
> understand sooner or later what you're actually after.
I also fail to see why a store scheme has to return "custom data". Note 
that thread start from request for load TPM keys and some one mention 
that TMP key has custom data.


In addition to load of key from file there is one another interfaces 
where could be used store api - see RT4681.
The goal is expired from fact that X.509 load method is hidden in 
OpenSSL 1.1.
I guess that "by dir" and "by file" could be updated to use store api. 
Also applications has to able to register that a "store scheme" could by 
used by X.509 lookups.


> Cheers,
> Richard ( oh, and if example code is needed, I can provide )

+4 for OpenSSL store api ;)

Regards,
Roumen


From openssl at roumenpetrov.info  Sun Dec 11 16:31:10 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sun, 11 Dec 2016 18:31:10 +0200
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <20161207.054232.1199336940059763361.levitte@openssl.org>
References: <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
 <20161207.054232.1199336940059763361.levitte@openssl.org>
Message-ID: <584D7F4E.8090801@roumenpetrov.info>

Hi Richard,

Richard Levitte wrote:
> In message<20161206.223057.237264374331072901.levitte at openssl.org>  on Tue, 06 Dec 2016 22:30:57 +0100 (CET), Richard Levitte<levitte at openssl.org>  said:
>
> levitte> [SNIP]
>
> The easiest was actually to rewrite PEM_read_bio_PrivateKey()
> entirely, so it solely uses the internal store_file functions I've
> provided.
> I wonder what kind of impact this would have on the community at
> large.

PEM_read_bio_PrivateKey use custom password callback . You propose "Store-API" with UI_METHOD  as password callback.
Rewrite of pem_read... method obsoletes pem_password_cb.

What about to ensure a transition period?
For instance in openssl 1.1 to provide new functions based on UI_METHOD and to mark existing as deprecated.


One remark for store load function api - in most cases (load from file) it is password callback but is other cases it could be PIN or something different.
Please use more generic description.
For instance engine callback is defined in generic way -  ui_method and its callback_data.

     

> Cheers,
> Richard

Regards,
Roumen

From levitte at openssl.org  Sun Dec 11 16:48:38 2016
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 11 Dec 2016 17:48:38 +0100
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <584D7F4E.8090801@roumenpetrov.info>
References: <20161206.174751.699271166087003593.levitte@openssl.org>
 <1481043672.4406.22.camel@HansenPartnership.com>
 <20161206.223057.237264374331072901.levitte@openssl.org>
 <20161207.054232.1199336940059763361.levitte@openssl.org>
 <584D7F4E.8090801@roumenpetrov.info>
Message-ID: <68BEE1E2-2B75-4498-A3C3-681A51F0E441@openssl.org>



Roumen Petrov <openssl at roumenpetrov.info> skrev: (11 december 2016 17:31:10 CET)
>Hi Richard,
>
>Richard Levitte wrote:
>> In message<20161206.223057.237264374331072901.levitte at openssl.org> 
>on Tue, 06 Dec 2016 22:30:57 +0100 (CET), Richard
>Levitte<levitte at openssl.org>  said:
>>
>> levitte> [SNIP]
>>
>> The easiest was actually to rewrite PEM_read_bio_PrivateKey()
>> entirely, so it solely uses the internal store_file functions I've
>> provided.
>> I wonder what kind of impact this would have on the community at
>> large.
>
>PEM_read_bio_PrivateKey use custom password callback . You propose
>"Store-API" with UI_METHOD  as password callback.
>Rewrite of pem_read... method obsoletes pem_password_cb.
>
>What about to ensure a transition period?
>For instance in openssl 1.1 to provide new functions based on UI_METHOD
>and to mark existing as deprecated.
>
>
>One remark for store load function api - in most cases (load from file)
>it is password callback but is other cases it could be PIN or something
>different.
>Please use more generic description.
>For instance engine callback is defined in generic way -  ui_method and
>its callback_data.

Earlier, I mentioned an experimental branch, https://github.com/levitte/openssl/tree/tpm_engine-support?files=1

If you have a look, you'll find an added UI utility function to wrap a pem password callback in a UI_METHOD. 

>
>     
>
>> Cheers,
>> Richard
>
>Regards,
>Roumen

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From levitte at openssl.org  Mon Dec 12 07:09:34 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 12 Dec 2016 08:09:34 +0100 (CET)
Subject: [openssl-dev] STORE [was:  [RFC v2 2/2] pem: load engine keys]
In-Reply-To: <584D77CB.7090307@roumenpetrov.info>
References: <58472E4F.3010204@roumenpetrov.info>
 <20161206.232605.962139841138881.levitte@openssl.org>
 <584D77CB.7090307@roumenpetrov.info>
Message-ID: <20161212.080934.499308073016130167.levitte@openssl.org>

In message <584D77CB.7090307 at roumenpetrov.info> on Sun, 11 Dec 2016 17:59:07 +0200, Roumen Petrov <openssl at roumenpetrov.info> said:

openssl> HI Richard,
openssl> 
openssl> Richard Levitte wrote:
openssl> > In message<58472E4F.3010204 at roumenpetrov.info> on Tue, 06 Dec 2016
openssl> > 23:31:59 +0200, Roumen Petrov<openssl at roumenpetrov.info> said:
openssl> >
openssl> > openssl> Hi Richard,
openssl> > openssl>
openssl> > [SNIP]
openssl> > openssl> > Check.  My STORE branch is made to support that.
openssl> > openssl> One URI could represent more then one item.
openssl> > openssl> STORE_INFO_types is enumerate but URI could be associated to
openssl> > custom
openssl> > openssl> data (handle) and this data could be used to get other
openssl> > data(handles).
openssl> > openssl>
openssl> > openssl> See capi engine CAPI_KEY *capi_find_key(CAPI_CTX * ctx, const
openssl> > char
openssl> > openssl> *id)
openssl> > [SNIP]
openssl> > openssl> Is above case PKEY is loaded only if CERT is located(found).
openssl> >
openssl> > I'm trying to understand but am failing.  Looking at your example,
openssl> > it's quite clear that what you want to retrieve is a key, even though
openssl> > you have to go through the corresponding certificate to get to it.
openssl> After first review of API delared in openssl/store.h I misunderstand
openssl> goal of load method.

Actually, it did change at one point.  Oh, and just so we're all on
the same page, I started over a few weeks ago, when Rich Salz
expressed some concerns with the previous "grab everything" load
call.  The active branch is "store2", available as this pull request:

https://github.com/openssl/openssl/pull/2011

(I can't remember if I said that already)

openssl> I think that code of capi engine could be considered as sample what is
openssl> need for an loadable module (engine) to use "OpenSSL Store API". I
openssl> post above code just to get idea where currently is used an "external
openssl> store api".
openssl> Just imagine how existing capi code could be changed to use store-API
openssl> and to implement loader(scheme?).

I don't know CAPI at all, really, so whatever scheme is used will
depend on what CAPI provides.  From a quick read of the docs, it looks
like simple files, and it's possible that a few extra file handlers
(which are another set of dynamically definable functions within the
STORE 'file' scheme) will suffice.

openssl> I'm asking as currently there is no interface (API) that could
openssl> associate key (private) and X.509 certificate. Currently engines
openssl> implement custom command as work-around. For instance LOAD_CERT_CTRL
openssl> (pkcs11 and e_nss) and LOAD_CERT_EVP(e_nss).
openssl> 
openssl> This one of areas where applications could benefit from "Store API".

That's exactly the sort of thing I'm aiming for :-)

openssl> I post a sniped from CAPI code because it is part of OpenSSL, but king
openssl> of "external store api" is used by other engines.
openssl> 
openssl> 
openssl> > However,*nothing*  stops anyone from making a loader for the "capi"
openssl> > scheme (if there is such a thing) that has a load method that will
openssl> > return the certificate (STORE_INFO_CERT) on the first call and the
openssl> > associated key (STORE_INFO_PKEY) on the second for the same URI.  It's
openssl> > all about caching information, and there is a context variable (type
openssl> > STORE_LOADER_CTX, which is just a template type for loader defined
openssl> > 'struct store_loader_ctx_st') to be used exactly for that kind of
openssl> > purpose.
openssl> 
openssl> I guess that "load" method is supposed to return all data at once.
openssl> 
openssl> Actually it is an iterator!

Yes.  That was a change that happened a few weeks ago

openssl> Please update comments before method and if possible to change name of
openssl> method.

I don't know how up to date you are.  This is the current comment for
STORE_load() in store.h:

    /*
     * Read one data item (a key, a cert, a CRL) that is supported by the STORE
     * functionality, given a context.
     * Returns a STORE_INFO pointer, from which OpenSSL typed data can be extracted
     * with STORE_INFO_get0_PKEY(), STORE_INFO_get0_CERT(), ...
     * NULL is returned on error, which may include that the data found at the URI
     * can't be figured out for certain or is ambiguous.
     */
    STORE_INFO *STORE_load(STORE_CTX *ctx);

If STORE_load() is a bad name, what would you suggest that makes it
better?

openssl> > [SNIP]
openssl> > In your example above, I fail to see where the custom data would be
openssl> > needed...  And frankly, STORE is first of all meant to handle types
openssl> > that can be used with the rest of OpenSSL.  That being said, adding a
openssl> > "whatever" STORE_INFO type isn't very hard either.  I'm just not
openssl> > terribly convinced yet, but let's keep talking, I'll probably
openssl> > understand sooner or later what you're actually after.
openssl> I also fail to see why a store scheme has to return "custom
openssl> data". Note that thread start from request for load TPM keys
openssl> and some one mention that TMP key has custom data.

Well, as far as I understand, the "custom data" is extra data
associated with a key that's used for key access, not free floating
individual data that needs to be returned.  I think that's different.

openssl> I guess that "by dir" and "by file" could be updated to use store
openssl> api. Also applications has to able to register that a "store scheme"
openssl> could by used by X.509 lookups.

Yes, I expect that to happen.  It will not necessarely be part of my
store branch, but I expect things to happen organically after it's
been approved (which I certainly hope it will).

openssl> > Cheers,
openssl> > Richard ( oh, and if example code is needed, I can provide )
openssl> 
openssl> +4 for OpenSSL store api ;)

:-)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From beldmit at gmail.com  Mon Dec 12 12:16:07 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 12 Dec 2016 15:16:07 +0300
Subject: [openssl-dev] Typo in BUF_reverse manual
Message-ID: <CADqLbzJmNOpYbgHxLwFKaH6tCtJqVe0hGdBL=fasD72k6CTuNg@mail.gmail.com>

Hello!

I found a typo in the BUF_reverse manual
(https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)

The manual says:

BUF_reverse() reverses size bytes at in into out. If out is NULL, the array
is reversed in-place.

But in fact in-place reverse is done when the in ptr is NULL.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161212/32746732/attachment.html>

From matt at openssl.org  Mon Dec 12 12:17:46 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 12 Dec 2016 12:17:46 +0000
Subject: [openssl-dev] Typo in BUF_reverse manual
In-Reply-To: <CADqLbzJmNOpYbgHxLwFKaH6tCtJqVe0hGdBL=fasD72k6CTuNg@mail.gmail.com>
References: <CADqLbzJmNOpYbgHxLwFKaH6tCtJqVe0hGdBL=fasD72k6CTuNg@mail.gmail.com>
Message-ID: <41bfe186-198b-c823-e2ce-6e4467174923@openssl.org>

Could you open that as an issue in GitHub? Or even better a PR to fix it ;-)

Thanks

Matt


On 12/12/16 12:16, Dmitry Belyavsky wrote:
> Hello!
> 
> I found a typo in the BUF_reverse manual 
> (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)
> 
> The manual says:
> 
> BUF_reverse() reverses size bytes at in into out. If out is NULL, the
> array is reversed in-place.
> 
> But in fact in-place reverse is done when the in ptr is NULL.
> 
> Thank you!
> 
> -- 
> SY, Dmitry Belyavsky
> 
> 

From beldmit at gmail.com  Mon Dec 12 12:44:31 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 12 Dec 2016 15:44:31 +0300
Subject: [openssl-dev] Typo in BUF_reverse manual
In-Reply-To: <41bfe186-198b-c823-e2ce-6e4467174923@openssl.org>
References: <CADqLbzJmNOpYbgHxLwFKaH6tCtJqVe0hGdBL=fasD72k6CTuNg@mail.gmail.com>
 <41bfe186-198b-c823-e2ce-6e4467174923@openssl.org>
Message-ID: <CADqLbzLF22PdoReSZ2qLtPPEJKDLmzto2O6Mn59tpPcff03skA@mail.gmail.com>

Hello Matt,

https://github.com/openssl/openssl/pull/2075

On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <matt at openssl.org> wrote:

> Could you open that as an issue in GitHub? Or even better a PR to fix it
> ;-)
>
> Thanks
>
> Matt
>
>
> On 12/12/16 12:16, Dmitry Belyavsky wrote:
> > Hello!
> >
> > I found a typo in the BUF_reverse manual
> > (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)
> >
> > The manual says:
> >
> > BUF_reverse() reverses size bytes at in into out. If out is NULL, the
> > array is reversed in-place.
> >
> > But in fact in-place reverse is done when the in ptr is NULL.
> >
> > Thank you!
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161212/6e00bf0f/attachment.html>

From levitte at openssl.org  Mon Dec 12 07:50:03 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 12 Dec 2016 08:50:03 +0100 (CET)
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <584D7F4E.8090801@roumenpetrov.info>
References: <20161206.223057.237264374331072901.levitte@openssl.org>
 <20161207.054232.1199336940059763361.levitte@openssl.org>
 <584D7F4E.8090801@roumenpetrov.info>
Message-ID: <20161212.085003.1679152412118071825.levitte@openssl.org>

In message <584D7F4E.8090801 at roumenpetrov.info> on Sun, 11 Dec 2016 18:31:10 +0200, Roumen Petrov <openssl at roumenpetrov.info> said:

openssl> One remark for store load function api - in most cases (load from
openssl> file) it is password callback but is other cases it could be PIN or
openssl> something different.
openssl> Please use more generic description.
openssl> For instance engine callback is defined in generic way - ui_method and
openssl> its callback_data.

I see what you mean.  Just did the improvement.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From eranm at google.com  Mon Dec 12 14:37:19 2016
From: eranm at google.com (Eran Messeri)
Date: Mon, 12 Dec 2016 14:37:19 +0000
Subject: [openssl-dev] Support for deterministic ECDSA signatures
Message-ID: <CALzYgEfk56m6_mqaz7VXrEq+6nFaJjjdNxmbB+70Sz1O0h_cPQ@mail.gmail.com>

Hi,

Would it be possible to have OpenSSL support generation of ECDSA signatures
in a deterministic manner?

This would be necessary to implement RFC6962-bis. Specifically, Section
12.4 (draft 21) requires the use of deterministic signatures (
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-21#section-12.4).

The rationale behind it is to prevent fingerprinting/tracking of TLS
clients by producing Signed Tree Heads / Signed Certificate Timestamps with
the same data but different signatures, then tracking propagation of these
SCTs / STHs via gossip protocols.

Thanks,
Eran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161212/d2bf7df1/attachment-0001.html>

From beldmit at gmail.com  Mon Dec 12 18:11:18 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 12 Dec 2016 21:11:18 +0300
Subject: [openssl-dev] Typo in BUF_reverse manual
In-Reply-To: <CADqLbzLF22PdoReSZ2qLtPPEJKDLmzto2O6Mn59tpPcff03skA@mail.gmail.com>
References: <CADqLbzJmNOpYbgHxLwFKaH6tCtJqVe0hGdBL=fasD72k6CTuNg@mail.gmail.com>
 <41bfe186-198b-c823-e2ce-6e4467174923@openssl.org>
 <CADqLbzLF22PdoReSZ2qLtPPEJKDLmzto2O6Mn59tpPcff03skA@mail.gmail.com>
Message-ID: <CADqLbzKmFBhHFLKVhHrebv0xM4ufzOxE4jBpVJwrigQbz86EbQ@mail.gmail.com>

Dear Matt,
Shouldn't the fix also be applied to 1.1.0 branch?

On Mon, Dec 12, 2016 at 3:44 PM, Dmitry Belyavsky <beldmit at gmail.com> wrote:

> Hello Matt,
>
> https://github.com/openssl/openssl/pull/2075
>
> On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <matt at openssl.org> wrote:
>
>> Could you open that as an issue in GitHub? Or even better a PR to fix it
>> ;-)
>>
>> Thanks
>>
>> Matt
>>
>>
>> On 12/12/16 12:16, Dmitry Belyavsky wrote:
>> > Hello!
>> >
>> > I found a typo in the BUF_reverse manual
>> > (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)
>> >
>> > The manual says:
>> >
>> > BUF_reverse() reverses size bytes at in into out. If out is NULL, the
>> > array is reversed in-place.
>> >
>> > But in fact in-place reverse is done when the in ptr is NULL.
>> >
>> > Thank you!
>> >
>> > --
>> > SY, Dmitry Belyavsky
>> >
>> >
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>
>
>
> --
> SY, Dmitry Belyavsky
>



-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161212/436fbdbc/attachment.html>

From npmccallum at redhat.com  Mon Dec 12 21:24:43 2016
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Mon, 12 Dec 2016 16:24:43 -0500
Subject: [openssl-dev] Constant Time Conversion of Bytes to P521 Multiplier
Message-ID: <CAOASepNzJwc-f6LmvsFkbMOPo7cbCOWNarmg6BTP4j08NtYXsw@mail.gmail.com>

I'm working on a draft[0] and an implementation[1] of a protocol using
elliptic curves. As part of this draft, we need to convert a byte
array to a multiplier. This byte array is a private long-term key.

Specifically of concern is this comment:

https://github.com/openssl/openssl/blob/master/crypto/ec/ecp_nistp521.c#L1947

In the case where the multiplier is converted from 66 random bytes to
a P-521 multiplier, it is extremely likely that the multiplier will be
greater than the order. Can we achieve constant time by calling
BN_set_flags(multiplier, BN_FLG_CONSTTIME) followed by
BN_mod(multiplier, group->order) before calling EC_POINT_mul()? If
not, is there another way to do this?

[0] - https://tools.ietf.org/html/draft-mccallum-kitten-krb-spake-preauth-00
[1] - https://github.com/greghudson/krb5/tree/spake

From matt at openssl.org  Tue Dec 13 09:11:39 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 13 Dec 2016 09:11:39 +0000
Subject: [openssl-dev] Typo in BUF_reverse manual
In-Reply-To: <CADqLbzKmFBhHFLKVhHrebv0xM4ufzOxE4jBpVJwrigQbz86EbQ@mail.gmail.com>
References: <CADqLbzJmNOpYbgHxLwFKaH6tCtJqVe0hGdBL=fasD72k6CTuNg@mail.gmail.com>
 <41bfe186-198b-c823-e2ce-6e4467174923@openssl.org>
 <CADqLbzLF22PdoReSZ2qLtPPEJKDLmzto2O6Mn59tpPcff03skA@mail.gmail.com>
 <CADqLbzKmFBhHFLKVhHrebv0xM4ufzOxE4jBpVJwrigQbz86EbQ@mail.gmail.com>
Message-ID: <82906cf5-2bd9-8bdf-71af-20cbf2ecc9e7@openssl.org>



On 12/12/16 18:11, Dmitry Belyavsky wrote:
> Dear Matt, 
> Shouldn't the fix also be applied to 1.1.0 branch?

Err, it was?

Matt

> 
> On Mon, Dec 12, 2016 at 3:44 PM, Dmitry Belyavsky <beldmit at gmail.com
> <mailto:beldmit at gmail.com>> wrote:
> 
>     Hello Matt,
> 
>     https://github.com/openssl/openssl/pull/2075
>     <https://github.com/openssl/openssl/pull/2075>
> 
>     On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <matt at openssl.org
>     <mailto:matt at openssl.org>> wrote:
> 
>         Could you open that as an issue in GitHub? Or even better a PR
>         to fix it ;-)
> 
>         Thanks
> 
>         Matt
> 
> 
>         On 12/12/16 12:16, Dmitry Belyavsky wrote:
>         > Hello!
>         >
>         > I found a typo in the BUF_reverse manual
>         >
>         (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html <https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html>)
>         >
>         > The manual says:
>         >
>         > BUF_reverse() reverses size bytes at in into out. If out is
>         NULL, the
>         > array is reversed in-place.
>         >
>         > But in fact in-place reverse is done when the in ptr is NULL.
>         >
>         > Thank you!
>         >
>         > --
>         > SY, Dmitry Belyavsky
>         >
>         >
>         --
>         openssl-dev mailing list
>         To unsubscribe:
>         https://mta.openssl.org/mailman/listinfo/openssl-dev
>         <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> 
> 
> 
> 
>     -- 
>     SY, Dmitry Belyavsky
> 
> 
> 
> 
> -- 
> SY, Dmitry Belyavsky
> 
> 

From beldmit at gmail.com  Tue Dec 13 09:25:37 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 13 Dec 2016 12:25:37 +0300
Subject: [openssl-dev] Typo in BUF_reverse manual
In-Reply-To: <82906cf5-2bd9-8bdf-71af-20cbf2ecc9e7@openssl.org>
References: <CADqLbzJmNOpYbgHxLwFKaH6tCtJqVe0hGdBL=fasD72k6CTuNg@mail.gmail.com>
 <41bfe186-198b-c823-e2ce-6e4467174923@openssl.org>
 <CADqLbzLF22PdoReSZ2qLtPPEJKDLmzto2O6Mn59tpPcff03skA@mail.gmail.com>
 <CADqLbzKmFBhHFLKVhHrebv0xM4ufzOxE4jBpVJwrigQbz86EbQ@mail.gmail.com>
 <82906cf5-2bd9-8bdf-71af-20cbf2ecc9e7@openssl.org>
Message-ID: <CADqLbzKRHvs7bTi4A4kQkSoOqtgFCugRp_X2nXWOp2Yz-iHjQw@mail.gmail.com>

Sorry, my fault :(

On Tue, Dec 13, 2016 at 12:11 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 12/12/16 18:11, Dmitry Belyavsky wrote:
> > Dear Matt,
> > Shouldn't the fix also be applied to 1.1.0 branch?
>
> Err, it was?
>
> Matt
>
> >
> > On Mon, Dec 12, 2016 at 3:44 PM, Dmitry Belyavsky <beldmit at gmail.com
> > <mailto:beldmit at gmail.com>> wrote:
> >
> >     Hello Matt,
> >
> >     https://github.com/openssl/openssl/pull/2075
> >     <https://github.com/openssl/openssl/pull/2075>
> >
> >     On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <matt at openssl.org
> >     <mailto:matt at openssl.org>> wrote:
> >
> >         Could you open that as an issue in GitHub? Or even better a PR
> >         to fix it ;-)
> >
> >         Thanks
> >
> >         Matt
> >
> >
> >         On 12/12/16 12:16, Dmitry Belyavsky wrote:
> >         > Hello!
> >         >
> >         > I found a typo in the BUF_reverse manual
> >         >
> >         (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_
> ex.html <https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html
> >)
> >         >
> >         > The manual says:
> >         >
> >         > BUF_reverse() reverses size bytes at in into out. If out is
> >         NULL, the
> >         > array is reversed in-place.
> >         >
> >         > But in fact in-place reverse is done when the in ptr is NULL.
> >         >
> >         > Thank you!
> >         >
> >         > --
> >         > SY, Dmitry Belyavsky
> >         >
> >         >
> >         --
> >         openssl-dev mailing list
> >         To unsubscribe:
> >         https://mta.openssl.org/mailman/listinfo/openssl-dev
> >         <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> >
> >
> >
> >
> >     --
> >     SY, Dmitry Belyavsky
> >
> >
> >
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161213/927538a4/attachment.html>

From steve at openssl.org  Tue Dec 13 13:09:18 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 13 Dec 2016 13:09:18 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1480519470.2372.2.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
Message-ID: <20161213130918.GA29518@openssl.org>

On Wed, Nov 30, 2016, James Bottomley 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.  This
> proposal adds a generic method for handling file based engine keys that
> can be loaded as PEM files.  Integration into the PEM loader requires a
> BIO based engine API callback which the first patch adds.  The second
> patch checks to see if the key can be loaded by any of the present
> engines.  Note that this requires that any engine which is to be used
> must be present and initialised via openssl.cnf.
> 
> I'll also post to this list the patch to openssl_tpm_engine that makes
> use if this infrastructure so the integration of the whole can be seen.
>  It should also be noted that gnutls has had this functionality since
> 2012.
> 
> The patch was done against 1.0.2h for easier testing and you can try it
> and the openssl_tpm_engine out (if you run openSUSE) here:
> 

I can see a couple of problems with this approach.

Firstly the BIO containing the private key may not be seekable: that is
BIO_reset() might not rewind it to the start. This could happen with a BIO
chain, a socket or a pipe for example. 

The second problem is that the file might contain multiple private keys so
(say) if you're reading the second private key in a file a reset will end up
taking you back to the beginning.

However the required functionality to support custom PEM key forms actually
largely already exists in OpenSSL so significant changes are not required if
we want to go down this route.

To see what I mean consider an existing format such as an RSA key which has
-----BEGIN RSA PRIVATE KEY----- at the start. When the PEM file is parsed in
PEM_read_bio_PrivateKey() it sees that the header ends in "PRIVATE KEY" and
then attempts to look up the key string: "RSA" in this case. It then
passes the decoded contents of the PEM file to the relavent algorithm ASN.1
method by looking for one that handles the appropriate string. Although all
current methods use ASN.1 for the private key data this shouldn't be necessary.

So for RSA this is rsa_ameth.c and the function is old_rsa_priv_decode. This
takes the encoded data and returns an EVP_PKEY structure containing the key.

So in theory if you wanted to handle a key of the form:

-----BEGIN TPM PRIVATE KEY-----
-----END TPM PRIVATE KEY----

you just create an almost empty ASN.1 method which handles the string "TPM"
and which only contains the PEM decoder. An ENGINE can also contain its own
custom methods so you could include an ENGINE which contains the relevant
handler. This would require no changes to OpenSSL to work.

There is however a snag. The relevant structure (EVP_PKEY_ASN1_METHOD) is
opaque and there is currently no way to set the pem decoder for a custom
string (the field is called "old_priv_decode"): only methods which are part of
OpenSSL can do that. The reason for that is that the PEM forms which contain
the key algorithm in the PEM header were considered legacy types and new methods
should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
discourage their use.

In this case the reason is different: the header doesn't contain the algorithm
type but a string which an ENGINE can handle. So it isn't a "legacy format"
but a custom one.

So if we wanted to go down this route all that is needed to get a form of this
functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Tue Dec 13 13:29:06 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 13 Dec 2016 13:29:06 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <20161213130918.GA29518@openssl.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
Message-ID: <20161213132906.GA30355@openssl.org>

On Tue, Dec 13, 2016, Dr. Stephen Henson wrote:

> 
> So if we wanted to go down this route all that is needed to get a form of this
> functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.
> 

Note however that this currently assumes the data between the PEM headers is
base64 encoded and it passes the decoded version to the relevant handler. So
if the data is of a textual form instead it cannot (currently) be handled but
that could be changed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From dwmw2 at infradead.org  Tue Dec 13 22:28:57 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 13 Dec 2016 22:28:57 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <20161213130918.GA29518@openssl.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
Message-ID: <1481668137.98151.45.camel@infradead.org>

On Tue, 2016-12-13 at 13:09 +0000, Dr. Stephen Henson wrote:
> The reason for that is that the PEM forms which contain
> the key algorithm in the PEM header were considered legacy types and new methods
> should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
> discourage their use.
> 
> In this case the reason is different: the header doesn't contain the algorithm
> type but a string which an ENGINE can handle. So it isn't a "legacy format"
> but a custom one.
> 
> So if we wanted to go down this route all that is needed to get a form of this
> functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.

I am not entirely averse to the idea of saying that TPM, at least as of
2.0, should have a wrapped-key storage format which is based in PKCS#8
rather than doing its own thing.

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

From steve at openssl.org  Tue Dec 13 23:32:47 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 13 Dec 2016 23:32:47 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1481668137.98151.45.camel@infradead.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
 <1481668137.98151.45.camel@infradead.org>
Message-ID: <20161213233247.GA7581@openssl.org>

On Tue, Dec 13, 2016, David Woodhouse wrote:

> On Tue, 2016-12-13 at 13:09 +0000, Dr. Stephen Henson wrote:
> > The reason for that is that the PEM forms which contain
> > the key algorithm in the PEM header were considered legacy types and new methods
> > should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
> > discourage their use.
> > 
> > In this case the reason is different: the header doesn't contain the algorithm
> > type but a string which an ENGINE can handle. So it isn't a "legacy format"
> > but a custom one.
> > 
> > So if we wanted to go down this route all that is needed to get a form of this
> > functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.
> 
> I am not entirely averse to the idea of saying that TPM, at least as of
> 2.0, should have a wrapped-key storage format which is based in PKCS#8
> rather than doing its own thing.
> 

If you go the PKCS#8 route then it would presumably be the unencrypted form.
One way to handle things would be to assign an OID for TPM and have an ASN.1
module unwrap the thing and return an EVP_PKEY structure.

That would work with any version of OpenSSL without modification if the ENGINE
included a TPM ASN.1 EVP_PKEY_ASN1_METHOD.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From James.Bottomley at HansenPartnership.com  Wed Dec 14 00:49:59 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Tue, 13 Dec 2016 16:49:59 -0800
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1481668137.98151.45.camel@infradead.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
 <1481668137.98151.45.camel@infradead.org>
Message-ID: <1481676599.2473.98.camel@HansenPartnership.com>

On Tue, 2016-12-13 at 22:28 +0000, David Woodhouse wrote:
> On Tue, 2016-12-13 at 13:09 +0000, Dr. Stephen Henson wrote:
> > The reason for that is that the PEM forms which contain
> > the key algorithm in the PEM header were considered legacy types 
> > and new methods should use PKCS#8 instead. So there was no way to 
> > set legacy PEM decoders to discourage their use.
> > 
> > In this case the reason is different: the header doesn't contain 
> > the algorithm type but a string which an ENGINE can handle. So it 
> > isn't a "legacy format" but a custom one.
> > 
> > So if we wanted to go down this route all that is needed to get a 
> > form of this functionality is a function to set the PEM decoder in
> > EVP_PKEY_ASN1_METHOD.
>
> I am not entirely averse to the idea of saying that TPM, at least as
> of 2.0, should have a wrapped-key storage format which is based in
> PKCS#8 rather than doing its own thing.

So the proposal is to have a TPM specific value for PrivateKeyAlgorithm
(which would have to be proposed as an OID) and use PrivateKeyInfo for
the key?  That could be made to work.

The slight fly in the ointment that's worrying me is that I need a key
format that works for pkcs#11 tokens as well.  The problem here is that
TPM keys don't have an id or a label and that's pretty much a
requirement of using a pkcs#11 token, so the pkcs#11 code has to be
able to set these attributes on the key files.  I was originally
thinking of putting them into the PEM header with a pkcs11- prefix.  I
suppose I can do the same with the attributes and some manufactured OID
prefix with the CKA_ parameters we're interested in as a suffix but
it's messy.

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/20161213/f44e35f7/attachment.bin>

From dwmw2 at infradead.org  Wed Dec 14 09:07:19 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 14 Dec 2016 09:07:19 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1481676599.2473.98.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
 <1481668137.98151.45.camel@infradead.org>
 <1481676599.2473.98.camel@HansenPartnership.com>
Message-ID: <1481706439.98151.51.camel@infradead.org>

On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote:
> 
> So the proposal is to have a TPM specific value for PrivateKeyAlgorithm
> (which would have to be proposed as an OID) and use PrivateKeyInfo for
> the key?? That could be made to work.

Right.

> The slight fly in the ointment that's worrying me is that I need a key
> format that works for pkcs#11 tokens as well.? The problem here is that
> TPM keys don't have an id or a label and that's pretty much a
> requirement of using a pkcs#11 token, so the pkcs#11 code has to be
> able to set these attributes on the key files.? I was originally
> thinking of putting them into the PEM header with a pkcs11- prefix.? I
> suppose I can do the same with the attributes and some manufactured OID
> prefix with the CKA_ parameters we're interested in as a suffix but
> it's messy.

Hm, this seems odd. If something is stored in a file then exposing it
through PKCS#11 doesn't make sense at all. Do not attempt to use
PKCS#11 for any file access.

Seriously, if you have any doubts about that at all, go read nss-pem
and ponder its operation. Then drink until you've forgotten most of it,
but remember that PKCS#11 isn't to be used for accessing stuff that you
have in a file.

PKCS#11 can sanely be used for keys which are persistently stored *in*
the TPM storage, which *do* have a UUID which can be used as CKA_ID.
(Or maybe as CKA_LABEL since CKA_ID really SHOULD be the pubkey hash,
if we can manage that).

If you're talking about a PKCS#11 token which has its *own* storage of
wrapped keys, then sure ? you can keep whatever metadata you like. But
you don't need that to be part of the PKCS#8 standard format. In fact
if you want this you're probably better off extending SoftHSM to stored
wrapped keys and use the TPM for operating them.

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

From James.Bottomley at HansenPartnership.com  Wed Dec 14 14:58:53 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 14 Dec 2016 06:58:53 -0800
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1481706439.98151.51.camel@infradead.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
 <1481668137.98151.45.camel@infradead.org>
 <1481676599.2473.98.camel@HansenPartnership.com>
 <1481706439.98151.51.camel@infradead.org>
Message-ID: <1481727533.2399.17.camel@HansenPartnership.com>

On Wed, 2016-12-14 at 09:07 +0000, David Woodhouse wrote:
> On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote:
> > 
> > So the proposal is to have a TPM specific value for 
> > PrivateKeyAlgorithm (which would have to be proposed as an OID) and 
> > use PrivateKeyInfo for the key?  That could be made to work.
> 
> Right.
> 
> > The slight fly in the ointment that's worrying me is that I need a 
> > key format that works for pkcs#11 tokens as well.  The problem here 
> > is that TPM keys don't have an id or a label and that's pretty much 
> > a requirement of using a pkcs#11 token, so the pkcs#11 code has to 
> > be able to set these attributes on the key files.  I was originally
> > thinking of putting them into the PEM header with a pkcs11- prefix.
> >   I suppose I can do the same with the attributes and some 
> > manufactured OID prefix with the CKA_ parameters we're interested 
> > in as a suffix but it's messy.
> 
> Hm, this seems odd. If something is stored in a file then exposing it
> through PKCS#11 doesn't make sense at all. Do not attempt to use
> PKCS#11 for any file access.

OK, so the horse has already left the stable on that one with TPM
enabling gnome-keyring for ssh keys because it exports *every* key over
pkcs11.  Since it does, I thought I'd play about with it a bit to see
how it would work.  The below is what I found out playing around.

> Seriously, if you have any doubts about that at all, go read nss-pem
> and ponder its operation. Then drink until you've forgotten most of 
> it, but remember that PKCS#11 isn't to be used for accessing stuff 
> that you have in a file.
> 
> PKCS#11 can sanely be used for keys which are persistently stored 
> *in* the TPM storage, which *do* have a UUID which can be used as 
> CKA_ID. (Or maybe as CKA_LABEL since CKA_ID really SHOULD be the 
> pubkey hash, if we can manage that).

So this is the actual problem: the TPM only stores private keys.  The
public key thing (can be simple, cert or something more fancy) isn't
known to it.  All pkcs11 searchers find the public key in the public
objects and then look for the private key by id and label (this is what
the standard recommends).  The problem is that the label they use isn't
going to be the UUID, so we need the private key to be labelled by what
its public counterpart expects to use the TPM for arbitrary keys, like
certificate private keys (or even gpg or ssh private keys).  The UUID
thing works for stuff that expects separate private and public key
descriptions, like gnutls and openssl, but not for anything that uses
the full pkcs11 protocol (like netscape).

The second problem is that C_FindObject expects to be able to search
all the keys.  Unfortunately, neither the TPM nor Trousers has an
enumeration protocol for TPM objects (we could hack trousers to do it,
becuase it knows every key it inserted in an internal database, but
there's no TSS API for it).  Without enumeration, searching fails.

Based on this, I think offline keys are a better format for pkcs11
because we have all the data present and can make it searchable.  ssh,
for instance, internally finds the private key using CKA_MODULUS and
CKA_PUBLIC_EXPONENT, which we can't do if the key is inside the TPM,
before exporting it by id (md5 fingerprint) and label (ssh comment).

Plus there's the unsolved resource issue, of course: we can only fit
about 10 keys in the TPM, whereas offline is infinitely expandable.

My vision of how this would work is that we probably need a database of
attributes.  For certificates it's going to look something like the
keyring gnome2 one, so there's no way to base any sophisticated pkcs11
implementation on something that doesn't have files at its core
(regardless of where the TPM key resides).  I'm agnostic over whether
we have two files (one for the private and one for the public key) or a
single one.  I'm actually starting to think that a vanilla private key
coupled with an attribute search on CKA_MODULUS,CKA_PUBLIC_EXPONENT is
the best thing to do (except it won't work with TPM loaded keys).

James


> If you're talking about a PKCS#11 token which has its *own* storage 
> of wrapped keys, then sure ? you can keep whatever metadata you like.
> But you don't need that to be part of the PKCS#8 standard format. In 
> fact if you want this you're probably better off extending SoftHSM to
> stored wrapped keys and use the TPM for operating them.

-------------- 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/20161214/e6bcc269/attachment.bin>

From dwmw2 at infradead.org  Wed Dec 14 17:05:23 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 14 Dec 2016 17:05:23 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1481727533.2399.17.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
 <1481668137.98151.45.camel@infradead.org>
 <1481676599.2473.98.camel@HansenPartnership.com>
 <1481706439.98151.51.camel@infradead.org>
 <1481727533.2399.17.camel@HansenPartnership.com>
Message-ID: <1481735123.98151.54.camel@infradead.org>

On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote:
> > Hm, this seems odd. If something is stored in a file then exposing it
> > through PKCS#11 doesn't make sense at all. Do not attempt to use
> > PKCS#11 for any file access.
> 
> OK, so the horse has already left the stable on that one with TPM
> enabling gnome-keyring for ssh keys because it exports *every* key over
> pkcs11.  Since it does, I thought I'd play about with it a bit to see
> how it would work.  The below is what I found out playing around.

I think we're talking about two different things. What I mean is that a
given application?shall never have to deal with files and PKCS#11 for a
given single object. Like the nss-pem horridness, where we create an
object whose CKA_LABEL is the filename, and we want the soft token to
go and load that file.

You seem to be talking about software-based PKCS#11 tokens which happen
to use their *own* files behind the scenes, but all the *application*
ever knows about is sane PKCS#11 operations. That is absolutely fine.
There's plenty of examples of that ? including SoftHSM, GNOME keyring,
and NSS's softokn.

And you'll note that none of those examples need extensions to the
PKCS#8 format to store arbitrary PKCS#11 attributes such as CKA_LABEL,
CKA_PRIVATE, CKA_APPLICATION or anything else. Because it's their own
database and they can do what they like; they don't have to store it in
a PKCS#8 or similar file.

The example you give with GNOME keyring doing SSH keys is a *different*
special case. There it's automatically discovering the files in a known
location (~/.ssh/id_*) and has to infer what it can from them, but
still it's only exposing them over PKCS#11 in a standard way. There's
none of the horridness for 'here, load *this* file into the token', is
there? You can do that with ssh-add perhaps, but that's mostly
orthogonal to what we're talking about here.

> So this is the actual problem: the TPM only stores private keys.  The
> public key thing (can be simple, cert or something more fancy) isn't
> known to it.  All pkcs11 searchers find the public key in the public
> objects and then look for the private key by id and label (this is what
> the standard recommends).

Which part of the standard are you referring to? It isn't really that
prescriptive about how you look things up, as far as I was aware.

>   The problem is that the label they use isn't
> going to be the UUID, so we need the private key to be labelled by what
> its public counterpart expects to use the TPM for arbitrary keys, like
> certificate private keys (or even gpg or ssh private keys).  The UUID
> thing works for stuff that expects separate private and public key
> descriptions, like gnutls and openssl, but not for anything that uses
> the full pkcs11 protocol (like netscape).

Right, you need a full software token for stuff like NSS. But didn't
you already do that in GNOME keyring? It stores the CKO_CERTIFICATE
objects just like it always did, and now it's capable of storing the
actual private key of a CKO_PRIVATE object in TSS-wrapped form, but the
other attributes are still stored in its database just as they always
were?

And we could make SofTHSM and NSS support the same things.

None of *that* needs to touch on the PKCS#8 storage format at all. That
is *only* relevant to the case where the application is given a *file*
with the private key it's supposed to use, and there is no PKCS#11 in
sight.

All of the above is for *wrapped* keys, of course. Not keys stored
persistently in the TPM.

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

From James.Bottomley at HansenPartnership.com  Wed Dec 14 23:03:23 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 14 Dec 2016 18:03:23 -0500
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1481735123.98151.54.camel@infradead.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
 <1481668137.98151.45.camel@infradead.org>
 <1481676599.2473.98.camel@HansenPartnership.com>
 <1481706439.98151.51.camel@infradead.org>
 <1481727533.2399.17.camel@HansenPartnership.com>
 <1481735123.98151.54.camel@infradead.org>
Message-ID: <1481756603.2399.33.camel@HansenPartnership.com>

On Wed, 2016-12-14 at 17:05 +0000, David Woodhouse wrote:
> On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote:
> > > Hm, this seems odd. If something is stored in a file then 
> > > exposing it through PKCS#11 doesn't make sense at all. Do not 
> > > attempt to use PKCS#11 for any file access.
> > 
> > OK, so the horse has already left the stable on that one with TPM
> > enabling gnome-keyring for ssh keys because it exports *every* key 
> > over pkcs11.  Since it does, I thought I'd play about with it a bit 
> > to see how it would work.  The below is what I found out playing
> > around.
> 
> I think we're talking about two different things. What I mean is that 
> a given application shall never have to deal with files and PKCS#11 
> for a given single object.

Sure (as in I thought that went without saying).

>  Like the nss-pem horridness, where we create an object whose
> CKA_LABEL is the filename, and we want the soft token to
> go and load that file.
> 
> You seem to be talking about software-based PKCS#11 tokens which 
> happen to use their *own* files behind the scenes, but all the 
> *application* ever knows about is sane PKCS#11 operations. That is 
> absolutely fine. There's plenty of examples of that ? including 
> SoftHSM, GNOME keyring, and NSS's softokn.

Yes ... I was mostly reacting against your statement that the keys
needed to be inside the TPM for PKCS11 use.

> And you'll note that none of those examples need extensions to the
> PKCS#8 format to store arbitrary PKCS#11 attributes such as 
> CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because 
> it's their own database and they can do what they like; they don't 
> have to store it in a PKCS#8 or similar file.

OK, so as long as you're happy with pkcs11 being used on TPM key files
which are then loaded as needed via the pkcs11 interface, I think we're
on the same page.  I'm coming to the conclusion that we need the files
in pairs and the public key can supply the attributes ... it's more or
less how gnome keyring currently does it.

> The example you give with GNOME keyring doing SSH keys is a 
> *different* special case. There it's automatically discovering the 
> files in a known location (~/.ssh/id_*) and has to infer what it can 
> from them, but still it's only exposing them over PKCS#11 in a 
> standard way. There's none of the horridness for 'here, load *this* 
> file into the token', is there? You can do that with ssh-add perhaps, 
> but that's mostly orthogonal to what we're talking about here.

OK, so a token can be writeable as well, but I expect the object to be
loaded into the token to be correctly serialised according to the
protocol and also possibly wrapped.

> > So this is the actual problem: the TPM only stores private keys. 
> >  The public key thing (can be simple, cert or something more fancy)
> > isn't known to it.  All pkcs11 searchers find the public key in the
> > public objects and then look for the private key by id and label 
> > (this is what the standard recommends).
> 
> Which part of the standard are you referring to? It isn't really that
> prescriptive about how you look things up, as far as I was aware.

Section 4.8 in the current OASIS base spec:

    The CKA_ID field is intended to distinguish among multiple keys. In
    the case of public and private keys, this field assists in handling
    multiple keys held by the same subject; the key identifier for a
    public key and its corresponding private key should be the same. The
    key identifier should also be the same as for the corresponding
    certificate, if one exists.

In practice it seems that most things use CKA_ID and CKA_LABEL if they
both exist.

> >   The problem is that the label they use isn't going to be the 
> > UUID, so we need the private key to be labelled by what its public 
> > counterpart expects to use the TPM for arbitrary keys, like
> > certificate private keys (or even gpg or ssh private keys).  The
> > UUID thing works for stuff that expects separate private and public 
> > key descriptions, like gnutls and openssl, but not for anything 
> > that uses the full pkcs11 protocol (like netscape).
> 
> Right, you need a full software token for stuff like NSS. But didn't
> you already do that in GNOME keyring? It stores the CKO_CERTIFICATE
> objects just like it always did, and now it's capable of storing the
> actual private key of a CKO_PRIVATE object in TSS-wrapped form, but 
> the other attributes are still stored in its database just as they 
> always were?

Yes, I can do it, but the TPM private keys are going to have to inherit
the certificate CKA_ID, which is usually something like the subject ...
they can't be the uuid.

> And we could make SofTHSM and NSS support the same things.
> 
> None of *that* needs to touch on the PKCS#8 storage format at all. 
> That is *only* relevant to the case where the application is given a
> *file* with the private key it's supposed to use, and there is no 
> PKCS#11 in sight.
> 
> All of the above is for *wrapped* keys, of course. Not keys stored
> persistently in the TPM.

I'm starting to think keys permanently loaded into the TPM aren't the
right way to go ... the wrapped format is secure and much more
flexible.  The only advantage a loaded key has over a wrapped one is
that you don't need the parent authority and the key authority to use
it.

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/20161214/2bd5116b/attachment-0001.bin>

From dwmw2 at infradead.org  Wed Dec 14 23:28:59 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 14 Dec 2016 23:28:59 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1481756603.2399.33.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <20161213130918.GA29518@openssl.org>
 <1481668137.98151.45.camel@infradead.org>
 <1481676599.2473.98.camel@HansenPartnership.com>
 <1481706439.98151.51.camel@infradead.org>
 <1481727533.2399.17.camel@HansenPartnership.com>
 <1481735123.98151.54.camel@infradead.org>
 <1481756603.2399.33.camel@HansenPartnership.com>
Message-ID: <1481758139.98151.60.camel@infradead.org>

On Wed, 2016-12-14 at 18:03 -0500, James Bottomley wrote:
> > I think we're talking about two different things. What I mean is that 
> > a given application shall never have to deal with files and PKCS#11 
> > for a given single object.
> 
> Sure (as in I thought that went without saying).

If only :)

> Yes ... I was mostly reacting against your statement that the keys
> needed to be inside the TPM for PKCS11 use.

Ok. I didn't (mean to) say that.

> > And you'll note that none of those examples need extensions to the
> > PKCS#8 format to store arbitrary PKCS#11 attributes such as 
> > CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because 
> > it's their own database and they can do what they like; they don't 
> > have to store it in a PKCS#8 or similar file.
> 
> OK, so as long as you're happy with pkcs11 being used on TPM key files
> which are then loaded as needed via the pkcs11 interface, I think we're
> on the same page. 

I think so, but *ick*, don't say "files".

I'm happy with PKCS#11 being used, where the PKCS#11 provider keeps its
own database (completely separate from the application, like NSS
softokn, SoftHSM, GNOME Keyring already do it).

We don't normally use the word "files" when we talk of high-level
concepts involving those three examples, even though SoftHSM actually
does use individual files for storage. So let's avoid confusion by not
talking about 'files' for the TPM one either. In this usage model, the
application never sees a file.

The application uses a PKCS#11 token. That token has its own storage
which as far as the application is concerned, is magical.


There is *another* usage model, where the application actually sees a
file akin to the existing -----BEGIN TSS KEY BLOB----- files (and for
which we ought to extend PKCS#8 to do it properly). That usage model
should also be supported.

>  I'm coming to the conclusion that we need the files
> in pairs and the public key can supply the attributes ... it's more or
> less how gnome keyring currently does it.

You want it *exactly* how GKR (or the other examples I gave) do it,
with the sole exception that RSA keys can be wrapped by the TPM
instead. I had also been talking about using Skylake's SGX software
enclaves to do a similar augmentation to software tokens.

> > The example you give with GNOME keyring doing SSH keys is a 
> > *different* special case. There it's automatically discovering the 
> > files in a known location (~/.ssh/id_*) and has to infer what it can 
> > from them, but still it's only exposing them over PKCS#11 in a 
> > standard way. There's none of the horridness for 'here, load *this* 
> > file into the token', is there? You can do that with ssh-add perhaps, 
> > but that's mostly orthogonal to what we're talking about here.
> 
> OK, so a token can be writeable as well, but I expect the object to be
> loaded into the token to be correctly serialised according to the
> protocol and also possibly wrapped.
> 
> > > So this is the actual problem: the TPM only stores private keys. 
> > >  The public key thing (can be simple, cert or something more fancy)
> > > isn't known to it.  All pkcs11 searchers find the public key in the
> > > public objects and then look for the private key by id and label 
> > > (this is what the standard recommends).
> > 
> > Which part of the standard are you referring to? It isn't really that
> > prescriptive about how you look things up, as far as I was aware.
> 
> Section 4.8 in the current OASIS base spec:
> 
>     The CKA_ID field is intended to distinguish among multiple keys. In
>     the case of public and private keys, this field assists in handling
>     multiple keys held by the same subject; the key identifier for a
>     public key and its corresponding private key should be the same. The
>     key identifier should also be the same as for the corresponding
>     certificate, if one exists.
> 
> In practice it seems that most things use CKA_ID and CKA_LABEL if they
> both exist.

OK, right. So it isn't just NSS; *most* things will automatically try
to find a private key once they've already been pointed at the cert, by
matching CKA_ID and/or CKA_LABEL. Sure, you *can* explicitly point at
separate cert and privkey, but you generally shouldn't need to.

> > All of the above is for *wrapped* keys, of course. Not keys stored
> > persistently in the TPM.
> 
> I'm starting to think keys permanently loaded into the TPM aren't the
> right way to go ... 

Right, which is why I stopped there at the observation that we weren't
talking about that :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161214/72c6c2e9/attachment.bin>

From Peter_Djalaliev at symantec.com  Sat Dec 17 01:59:00 2016
From: Peter_Djalaliev at symantec.com (Peter Djalaliev (CS))
Date: Sat, 17 Dec 2016 01:59:00 +0000
Subject: [openssl-dev] backporting CVE-2016-8610 fix to 1.0.1 branch
Message-ID: <E5635C9F-BE67-428C-A8D6-69BA3CBBEE54@symantec.com>

Hello,

Will commit

Don't allow too many consecutive warning alerts

author   Matt Caswell <matt at openssl.org>
                Wed, 21 Sep 2016 08:07:31 -0500 (14:07 +0100)
committer            Matt Caswell <matt at openssl.org>
                Wed, 21 Sep 2016 14:17:04 -0500 (20:17 +0100)
commit  af58be768ebb690f78530f796e92b8ae5c9a4401
tree        087701bd731382d1933438bcd73cb7029264e16b
parent   7dc0ad4d6dca81a003be7fa1fbd58a55f4be8646

be backported to 1.0.1? This has been assigned CVE-2016-8610. I understand that OpenSSL 1.0.1 is going EOL on Dec 31.

Thank you,
Peter Djalaliev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161217/1990bee5/attachment-0001.html>

From sgraham at topnotchtech.com  Sun Dec 18 19:20:22 2016
From: sgraham at topnotchtech.com (Sean Graham)
Date: Sun, 18 Dec 2016 14:20:22 -0500
Subject: [openssl-dev] Cross compiling openssl for an old ARM environment -
	howto?
Message-ID: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>

Hello everyone,

I'm trying to do my research, and not sure if this should go into the -dev
or -user mailing list...

I have an embedded device which runs an ARM7T armv4t 16-bit thumb platform.

I'm not finding much info other than the compile guide telling me to modify
$cflags and $ldflags.

The IDE for development is typically done in GUI mode - and I have no clue
how I could compile OpenSSL in this manner. I could try just adding all the
files in proper directory format, but I suspect that there may be problems
down the road.

I'm hopeful that I can just link in the library, it seems to have a built
in arm-elf compiler/linker and has its own internal library files as .elf

I noticed that there are linux-armv4 and linux-elf compilation targets in
./Configure, so I'm hopeful that I can go in this direction, but I'm
struggling to find documentation on how to approach it in this manner. On
windows I can build for windows, but the cygwin environment doesn't appear
to include any compile tools which support linux-armv4.

Alternately is it possible to direct-compile with an IDE? I assume it's not
just as simple as adding all the .c files in...

I'm normally a windows guy :)

Thanks in advance!

----------
Sean Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161218/31b2d14d/attachment.html>

From kgoldman at us.ibm.com  Sun Dec 18 20:28:48 2016
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Sun, 18 Dec 2016 15:28:48 -0500
Subject: [openssl-dev] Openssl 1.1 port - hash state serializing context
Message-ID: <o36rhq$vft$1@blaine.gmane.org>

I have a simulation of a hardware device that has the following 
characteristics:

- does hashing functions
- resource constrained
- multi-user

Therefore, a typical pattern is that one application starts a digest 
calculation, then the hash state must get swapped out for another user.

In 1.0, I did this by (cheating) serializing the hash state to swap out, 
than deserializing to swap back in.  This required looking inside the 
hash state structure.  I know it wasn't portable across versions, but 
the structure was pretty stable.

Is there a way to do this in 1.1?  Can one be added?


From rsalz at akamai.com  Mon Dec 19 18:22:30 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 19 Dec 2016 18:22:30 +0000
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment -	howto?
In-Reply-To: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
Message-ID: <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>


> I have an embedded device which runs an ARM7T armv4t 16-bit thumb platform.

I don't think openssl ever really ran on 16bit.

From sgraham at topnotchtech.com  Mon Dec 19 18:25:31 2016
From: sgraham at topnotchtech.com (Sean Graham)
Date: Mon, 19 Dec 2016 13:25:31 -0500
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CALsbA4=sTfq4enFnqa0GuPQH+GO=7wVEA6x4s4ZsWq5NSuohEw@mail.gmail.com>

Hi!

Thanks for the reply - I didn't think it actually made the mailing list.

The thumb platform supports all 32-bit operations and even 64-bit numbers,
so I wouldn't expect it to be a problem.

The ./Configure does explicitly talk about thumb mode compiling, so I
imagine there must be support for it.




----------
Sean Graham


On Mon, Dec 19, 2016 at 1:22 PM, Salz, Rich <rsalz at akamai.com> wrote:

>
> > I have an embedded device which runs an ARM7T armv4t 16-bit thumb
> platform.
>
> I don't think openssl ever really ran on 16bit.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161219/11ae74aa/attachment.html>

From levitte at openssl.org  Mon Dec 19 18:39:08 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Dec 2016 19:39:08 +0100 (CET)
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161219.193908.1795620118256700616.levitte@openssl.org>

In message <72e690f1b12147588b1dc3e7ee93c73e at usma1ex-dag1mb1.msg.corp.akamai.com> on Mon, 19 Dec 2016 18:22:30 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > I have an embedded device which runs an ARM7T armv4t 16-bit thumb platform.
rsalz> 
rsalz> I don't think openssl ever really ran on 16bit.

It certainly doesn't any more.  It did, though, a looooong time ago.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From sgraham at topnotchtech.com  Mon Dec 19 18:50:58 2016
From: sgraham at topnotchtech.com (Sean Graham)
Date: Mon, 19 Dec 2016 13:50:58 -0500
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <20161219.193908.1795620118256700616.levitte@openssl.org>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161219.193908.1795620118256700616.levitte@openssl.org>
Message-ID: <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>

Are we saying that it absolutely will not support ARM7 thumb mode anymore?

Wouldn't the generic C-only version (no ASM) support pretty much any
platform?


----------
Sean Graham


On Mon, Dec 19, 2016 at 1:39 PM, Richard Levitte <levitte at openssl.org>
wrote:

> In message <72e690f1b12147588b1dc3e7ee93c73e at usma1ex-dag1mb1.msg.corp.
> akamai.com> on Mon, 19 Dec 2016 18:22:30 +0000, "Salz, Rich" <
> rsalz at akamai.com> said:
>
> rsalz>
> rsalz> > I have an embedded device which runs an ARM7T armv4t 16-bit thumb
> platform.
> rsalz>
> rsalz> I don't think openssl ever really ran on 16bit.
>
> It certainly doesn't any more.  It did, though, a looooong time ago.
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161219/43bee9e8/attachment.html>

From levitte at openssl.org  Mon Dec 19 19:04:07 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Dec 2016 20:04:07 +0100 (CET)
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
References: <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161219.193908.1795620118256700616.levitte@openssl.org>
 <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
Message-ID: <20161219.200407.198105199733505763.levitte@openssl.org>

We are saying that we don't support 16-bit platforms and haven't
really done so for a long time.  The C-only version is no exception.

However, the response was that 32- and 64-bit operations and numbers
are supported on that device, so it should still be possible to play
with.

Cheers,
Richard

In message <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw at mail.gmail.com> on Mon, 19 Dec 2016 13:50:58 -0500, Sean Graham <sgraham at topnotchtech.com> said:

sgraham> Are we saying that it absolutely will not support ARM7 thumb mode
sgraham> anymore?
sgraham> 
sgraham> Wouldn't the generic C-only version (no ASM) support pretty much any
sgraham> platform?
sgraham> 
sgraham> ----------
sgraham> Sean Graham
sgraham> 
sgraham> On Mon, Dec 19, 2016 at 1:39 PM, Richard Levitte <levitte at openssl.org>
sgraham> wrote:
sgraham> 
sgraham>     In message
sgraham>     <72e690f1b12147588b1dc3e7ee93c73e at usma1ex-dag1mb1.msg.corp.akamai.com
sgraham>    > on Mon, 19 Dec 2016 18:22:30 +0000, "Salz, Rich"
sgraham>     <rsalz at akamai.com> said:
sgraham> 
sgraham>     rsalz>
sgraham>     rsalz> > I have an embedded device which runs an ARM7T armv4t
sgraham>     16-bit thumb platform.
sgraham>     rsalz>
sgraham>     rsalz> I don't think openssl ever really ran on 16bit.
sgraham> 
sgraham>     It certainly doesn't any more. It did, though, a looooong time
sgraham>     ago.
sgraham> 
sgraham>     --
sgraham>     Richard Levitte levitte at openssl.org
sgraham>     OpenSSL Project http://www.openssl.org/~levitte/
sgraham> 
sgraham> 
sgraham>     --
sgraham>     openssl-dev mailing list
sgraham>     To unsubscribe:
sgraham>     https://mta.openssl.org/mailman/listinfo/openssl-dev
sgraham> 
sgraham> 

From rsalz at akamai.com  Mon Dec 19 19:07:27 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 19 Dec 2016 19:07:27 +0000
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161219.193908.1795620118256700616.levitte@openssl.org>
 <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
Message-ID: <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>

> Are we saying that it absolutely will not support ARM7 thumb mode anymore?

Nobody is saying that.  We're saying that if the address-space is 16bit, openssl will not work.

> Wouldn't the generic C-only version (no ASM) support pretty much any platform?

Probably.



From openssl-users at dukhovni.org  Mon Dec 19 19:16:50 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 19 Dec 2016 14:16:50 -0500
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161219.193908.1795620118256700616.levitte@openssl.org>
 <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
 <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <9B7219B5-2DA4-4494-BC8F-112E2C1430C2@dukhovni.org>


> On Dec 19, 2016, at 2:07 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
>> Are we saying that it absolutely will not support ARM7 thumb mode anymore?
> 
> Nobody is saying that.  We're saying that if the address-space is 16bit, openssl will not work.
> 
>> Wouldn't the generic C-only version (no ASM) support pretty much any platform?
> 
> Probably.

For ARM platforms, especially on resource-constrainted variants, the OP is
most likelyh better of with mbedTLS:

https://tls.mbed.org/

-- 
	Viktor.


From sgraham at topnotchtech.com  Mon Dec 19 19:19:45 2016
From: sgraham at topnotchtech.com (Sean Graham)
Date: Mon, 19 Dec 2016 14:19:45 -0500
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161219.193908.1795620118256700616.levitte@openssl.org>
 <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
 <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CALsbA4m9hiZ=_sE3N8ZMBZGHxkg6jEPDzzx=9n81wLGSUYaFDQ@mail.gmail.com>

Hi Guys,

My apologies for the blunt reply -- merely trying to be clear -- and thank
you for your answers!

Would anyone happen to have any reference material that I could look at
which would help me along this line?  I apologize for the newb questions.

Specifically I already have a gcc toolchain with makefile support for this
processor and environment. Is it possible to configure to use this
toolchain in "C only" mode for initial testing?  OpenSSL's custom make
environment is a bit confusing.




----------
Sean Graham


On Mon, Dec 19, 2016 at 2:07 PM, Salz, Rich <rsalz at akamai.com> wrote:

> > Are we saying that it absolutely will not support ARM7 thumb mode
> anymore?
>
> Nobody is saying that.  We're saying that if the address-space is 16bit,
> openssl will not work.
>
> > Wouldn't the generic C-only version (no ASM) support pretty much any
> platform?
>
> Probably.
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161219/cab97e50/attachment.html>

From sgraham at topnotchtech.com  Mon Dec 19 19:25:52 2016
From: sgraham at topnotchtech.com (Sean Graham)
Date: Mon, 19 Dec 2016 14:25:52 -0500
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <9B7219B5-2DA4-4494-BC8F-112E2C1430C2@dukhovni.org>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161219.193908.1795620118256700616.levitte@openssl.org>
 <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
 <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>
 <9B7219B5-2DA4-4494-BC8F-112E2C1430C2@dukhovni.org>
Message-ID: <CALsbA4=yb+GBY92AEK16ZMjN=LS-_=w+E-sfdFjQvt3C+FbsXg@mail.gmail.com>

Viktor,

Thank you so very much for that - I will definitely look into that.


----------
Sean Graham


On Mon, Dec 19, 2016 at 2:16 PM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

>
> > On Dec 19, 2016, at 2:07 PM, Salz, Rich <rsalz at akamai.com> wrote:
> >
> >> Are we saying that it absolutely will not support ARM7 thumb mode
> anymore?
> >
> > Nobody is saying that.  We're saying that if the address-space is 16bit,
> openssl will not work.
> >
> >> Wouldn't the generic C-only version (no ASM) support pretty much any
> platform?
> >
> > Probably.
>
> For ARM platforms, especially on resource-constrainted variants, the OP is
> most likelyh better of with mbedTLS:
>
> https://tls.mbed.org/
>
> --
>         Viktor.
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161219/3ad0a52e/attachment.html>

From appro at openssl.org  Mon Dec 19 20:07:29 2016
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 19 Dec 2016 21:07:29 +0100
Subject: [openssl-dev] Cross compiling openssl for an old ARM
 environment - howto?
In-Reply-To: <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CALsbA4nxjfcWbkww_+qOW5f+6jwEaL1xzqRemhL9-uY02N64ow@mail.gmail.com>
 <72e690f1b12147588b1dc3e7ee93c73e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161219.193908.1795620118256700616.levitte@openssl.org>
 <CALsbA4=S3kHESYQ64dqb5MxGgaNJvQbyf26ky=B_3DnKX9y-kw@mail.gmail.com>
 <1cd2c180229f4ac791a9ca08adadb4fe@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <386dc4f2-a907-56fe-983c-9f43ff9eb7eb@openssl.org>

>> Are we saying that it absolutely will not support ARM7 thumb mode anymore?
> 
> Nobody is saying that.  We're saying that if the address-space is 16bit, openssl will not work.

16-bit in original request refers to instructions' size, not address
space. But it's actually a misnomer, as Thumb, or at least its ARMv7
flavour, is a *mixture* of 16- and 32-bit instructions. Again, 16- and
32-bit *sized* instructions, not address space. OpenSSL fully supports
AVMv7 Thumb, a.k.a. Thumb2, all the way down to assembly pack. If
compiler doesn't generate Thumb2 code by default, then it might be
necessary to pass additional arch-specific flag[s] as additional
argument to ./Configure. This is discussed in commentary around
linux-armv4 config-line in Configurations/10-main.cf in master/1.1.0 or
Configre in 1.0.2.

As for cross compilation, it's discussed in INSTALL, look for
--cross-compile-prefix.

Well, to be completely accurate, everything said above implies that
compiler is gcc. ARM's compiler was never tested, but nobody complained
so far...


From James.Bottomley at HansenPartnership.com  Thu Dec 22 04:55:26 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 21 Dec 2016 20:55:26 -0800
Subject: [openssl-dev] [RFC 0/1] TPM2 engine support for openssl
Message-ID: <1482382526.2350.57.camel@HansenPartnership.com>

This is a basic RFC to show that it's possible to get TPM2 to act as an
engine for openssl as well as TPM1.2.  The format follows as closely as
possible what happens in TPM1.2.  The file format is full blown ASN.1
because we have to include both a public and private key blob.  I chose
to use TSS2 KEY BLOB as the guards to distinguish it from the TPM1.2
file.

TPM2 has significant limitations over TPM1.2 in what it will sign:
basically it must recognise the signature algorithm (that's why all the
signature parsing in the rsa_priv_enc() routine).  There's also another
problem in that a primary asymmetric key of the SPS must be provisioned
every time we perform this operation (which is time consuming and
annoying).  I think we need to do something about this under Linux, but
I'll take that off the openssl list because they likely won't be
interested.

The authority handling is missing at the moment, but I'll add that
shortly.  We should probably discuss how policy based authorisation
should be handled: I think as extensions to the key ASN.1 file.

Because of the signature recognition problem, you have to test this out
with x509 certificates:

openssl genrsa 2048 > tmp.key
create_tpm2_key -w tmp.key tmp.bin
openssl req -new -engine tpm2 -key tmp.bin -keyform e > tmp.csr
openssl x509 -req -engine tpm2 -in tmp.csr -signkey tmp.bin -keyform e -out tmp.crt
openssl x509 -text -in tmp.crt
 
The last step will validate you've got a genuine x509 self signed
certificate with the key from the TPM.

This kit is constructed using the IBM TSS2:

https://sourceforge.net/projects/ibmtpm20tss/

And, at the moment, it's only been validated on a software TPM2.

James

---

James Bottomley (1):
  add TPM2 version of create_tpm2_key and libtpm2.so engine

 Makefile.am       |  12 +-
 create_tpm2_key.c | 381 ++++++++++++++++++++++++++++++++++++++++++
 e_tpm2.c          | 482 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tpm2-asn.h        |  35 ++++
 tpm2-common.c     | 172 +++++++++++++++++++
 tpm2-common.h     |  10 ++
 6 files changed, 1090 insertions(+), 2 deletions(-)
 create mode 100644 create_tpm2_key.c
 create mode 100644 e_tpm2.c
 create mode 100644 tpm2-asn.h
 create mode 100644 tpm2-common.c
 create mode 100644 tpm2-common.h

-- 
2.6.6


From James.Bottomley at HansenPartnership.com  Thu Dec 22 04:56:42 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 21 Dec 2016 20:56:42 -0800
Subject: [openssl-dev] [RFC 1/1] add TPM2 version of create_tpm2_key and
	libtpm2.so engine
In-Reply-To: <1482382526.2350.57.camel@HansenPartnership.com>
References: <1482382526.2350.57.camel@HansenPartnership.com>
Message-ID: <1482382602.2350.59.camel@HansenPartnership.com>

Proof of concept patch to wrap RSA (and eventually other) keys in TPM2
format and use them to load into a TPM2 to perform signatures.

This scheme has significant limitations over TPM1.2 in that TPM2
insists on knowing and validating the signature, so it will only sign
stuff it knows the OID to.  That's also why the signature has to be
parsed into an X509_SIG before signing.

Signed-off-by: James Bottomley <James.Bottomley at HansenPartnership.com>
---
 Makefile.am       |  12 +-
 create_tpm2_key.c | 381 ++++++++++++++++++++++++++++++++++++++++++
 e_tpm2.c          | 482 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tpm2-asn.h        |  35 ++++
 tpm2-common.c     | 172 +++++++++++++++++++
 tpm2-common.h     |  10 ++
 6 files changed, 1090 insertions(+), 2 deletions(-)
 create mode 100644 create_tpm2_key.c
 create mode 100644 e_tpm2.c
 create mode 100644 tpm2-asn.h
 create mode 100644 tpm2-common.c
 create mode 100644 tpm2-common.h

diff --git a/Makefile.am b/Makefile.am
index 4932fae..a704d8c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,12 +2,20 @@ SUBDIRS=. test
 
 EXTRA_DIST = README  openssl.cnf.sample
 
-openssl_engine_LTLIBRARIES=libtpm.la
-bin_PROGRAMS=create_tpm_key
+openssl_engine_LTLIBRARIES=libtpm.la libtpm2.la
+bin_PROGRAMS=create_tpm_key create_tpm2_key
 openssl_enginedir=@libdir@/openssl/engines
 
 libtpm_la_LIBADD=-lcrypto -lc -ltspi
 libtpm_la_SOURCES=e_tpm.c e_tpm.h e_tpm_err.c
 
+libtpm2_la_LIBADD=-lcrypto -lc -ltss
+libtpm2_la_SOURCES=e_tpm2.c tpm2-common.c
+libtpm2_la_CFLAGS=-g -Werror
+
 create_tpm_key_SOURCES=create_tpm_key.c
 create_tpm_key_LDADD=-lcrypto -ltspi
+
+create_tpm2_key_SOURCES=create_tpm2_key.c tpm2-common.c
+create_tpm2_key_LDADD=-lcrypto -ltss
+create_tpm2_key_CFLAGS=-Werror
diff --git a/create_tpm2_key.c b/create_tpm2_key.c
new file mode 100644
index 0000000..001bf1d
--- /dev/null
+++ b/create_tpm2_key.c
@@ -0,0 +1,381 @@
+/*
+ *
+ *   Copyright (C) 2016 James Bottomley <James.Bottomley at HansenPartnership.com>
+ *
+ *   GPLv2
+ */
+
+
+#include <stdio.h>
+#include <getopt.h>
+#include <string.h>
+#include <strings.h>
+#include <errno.h>
+
+#include <openssl/rsa.h>
+#include <openssl/pem.h>
+#include <openssl/evp.h>
+#include <openssl/err.h>
+#include <openssl/rand.h>
+
+#include <tss2/tss.h>
+#include <tss2/tssutils.h>
+#include <tss2/tssmarshal.h>
+
+#include "tpm2-asn.h"
+#include "tpm2-common.h"
+
+static struct option long_options[] = {
+	{"enc-scheme", 1, 0, 'e'},
+	{"name-scheme", 1, 0, 'n'},
+	{"key-size", 1, 0, 's'},
+	{"auth", 0, 0, 'a'},
+	{"popup", 0, 0, 'p'},
+	{"wrap", 1, 0, 'w'},
+	{"help", 0, 0, 'h'},
+	{0, 0, 0, 0}
+};
+
+static TPM_ALG_ID name_alg = TPM_ALG_SHA256;
+static int name_alg_size = SHA256_DIGEST_SIZE;
+
+void
+usage(char *argv0)
+{
+	fprintf(stderr, "\t%s: create a TPM key and write it to disk\n"
+		"\tusage: %s [options] <filename>\n\n"
+		"\tOptions:\n"
+		"\t\t-e|--enc-scheme  encryption scheme to use [PKCSV15] or OAEP\n"
+		"\t\t-n|--name-scheme  name algorithm to use sha1 [sha256] sha384 sha512\n"
+		"\t\t-s|--key-size    key size in bits [2048]\n"
+		"\t\t-a|--auth        require a password for the key [NO]\n"
+		"\t\t-p|--popup       use TSS GUI popup dialogs to get the password "
+		"for the\n\t\t\t\t key [NO] (implies --auth)\n"
+		"\t\t-w|--wrap [file] wrap an existing openssl PEM key\n"
+		"\t\t-h|--help        print this help message\n"
+		"\nReport bugs to %s\n",
+		argv0, argv0, PACKAGE_BUGREPORT);
+	exit(-1);
+}
+
+void
+openssl_print_errors()
+{
+	ERR_load_ERR_strings();
+	ERR_load_crypto_strings();
+	ERR_print_errors_fp(stderr);
+}
+
+int
+openssl_write_tpmfile(const char *file, BYTE *pubkey, int pubkey_len,
+		   BYTE *privkey, int privkey_len)
+{
+	TSSLOADABLE tssl;
+	BIO *outb;
+
+	if ((outb = BIO_new_file(file, "w")) == NULL) {
+                fprintf(stderr, "Error opening file for write: %s\n", file);
+		return 1;
+	}
+	tssl.pubkey = ASN1_OCTET_STRING_new();
+	tssl.privkey = ASN1_OCTET_STRING_new();
+	printf("setting pubkey len %d\n", pubkey_len);
+	ASN1_STRING_set(tssl.pubkey, pubkey, pubkey_len);
+	printf("setting privkey len %d\n", privkey_len);
+	ASN1_STRING_set(tssl.privkey, privkey, privkey_len);
+
+	PEM_write_bio_TSSLOADABLE(outb, &tssl);
+	BIO_free(outb);
+	return 0;
+}
+
+EVP_PKEY *
+openssl_read_key(char *filename)
+{
+        BIO *b = NULL;
+	EVP_PKEY *pkey;
+
+        b = BIO_new_file(filename, "r");
+        if (b == NULL) {
+                fprintf(stderr, "Error opening file for read: %s\n", filename);
+                return NULL;
+        }
+
+        if ((pkey = PEM_read_bio_PrivateKey(b, NULL, PEM_def_callback, NULL)) == NULL) {
+                fprintf(stderr, "Reading key %s from disk failed.\n", filename);
+                openssl_print_errors();
+        }
+	BIO_free(b);
+
+        return pkey;
+}
+
+TPM_RC openssl_to_tpm_public_rsa(TPMT_PUBLIC *pub, EVP_PKEY *pkey)
+{
+	RSA *rsa = EVP_PKEY_get1_RSA(pkey);
+	BIGNUM *n, *e;
+	int size = RSA_size(rsa);
+	unsigned long exp;
+
+	if (size > MAX_RSA_KEY_BYTES)
+		return TPM_RC_KEY_SIZE;
+
+#if OPENSSL_VERSION_NUMBER < 0x10100000
+	n = rsa->n;
+	e = rsa->e;
+#else
+	RSA_get0_key(&n, &e, NULL);
+#endif
+	exp = BN_get_word(e);
+	/* TPM limitations means exponents must be under a word in size */
+	if (exp == 0xffffffffL)
+		return TPM_RC_KEY_SIZE;
+
+	pub->type = TPM_ALG_RSA;
+	pub->nameAlg = name_alg;
+	pub->objectAttributes.val = TPMA_OBJECT_NODA |
+		TPMA_OBJECT_SIGN |
+		TPMA_OBJECT_DECRYPT |
+		TPMA_OBJECT_USERWITHAUTH;
+	pub->authPolicy.t.size = 0;
+	pub->parameters.rsaDetail.symmetric.algorithm = TPM_ALG_NULL;
+	pub->parameters.rsaDetail.scheme.scheme = TPM_ALG_NULL;
+	pub->parameters.rsaDetail.keyBits = size*8;
+	if (exp == 0x10001)
+		pub->parameters.rsaDetail.exponent = 0;
+	else
+		pub->parameters.rsaDetail.exponent = exp;
+
+	pub->unique.rsa.t.size = BN_bn2bin(n, pub->unique.rsa.t.buffer);
+
+	return 0;
+}
+
+TPM_RC openssl_to_tpm_public(TPM2B_PUBLIC *pub, EVP_PKEY *pkey)
+{
+	TPMT_PUBLIC *tpub = &pub->publicArea;
+	pub->size = sizeof(*pub);
+
+	switch (EVP_PKEY_type(pkey->type)) {
+	case EVP_PKEY_RSA:
+		return openssl_to_tpm_public_rsa(tpub, pkey);
+	default:
+		break;
+	}
+	return TPM_RC_ASYMMETRIC;
+}
+
+TPM_RC openssl_to_tpm_private_rsa(TPMT_SENSITIVE *s, EVP_PKEY *pkey)
+{
+	BIGNUM *q;
+	TPM2B_PRIVATE_KEY_RSA *t2brsa = &s->sensitive.rsa;
+	RSA *rsa = EVP_PKEY_get1_RSA(pkey);
+
+#if OPENSSL_VERSION_NUMBER < 0x10100000
+	q = rsa->q;
+#else
+	BIGNUM *p;
+
+	RSA_get0_factors(rsa, &p, &q);
+#endif
+
+	if (!q)
+		return TPM_RC_ASYMMETRIC;
+
+	s->sensitiveType = TPM_ALG_RSA;
+	s->seedValue.b.size = 0;
+
+	t2brsa->t.size = BN_bn2bin(q, t2brsa->t.buffer);
+	return 0;
+}
+
+TPM_RC openssl_to_tpm_private(TPMT_SENSITIVE *priv, EVP_PKEY *pkey)
+{
+	switch (EVP_PKEY_type(pkey->type)) {
+	case EVP_PKEY_RSA:
+		return openssl_to_tpm_private_rsa(priv, pkey);
+	default:
+		break;
+	}
+	return TPM_RC_ASYMMETRIC;
+}
+
+TPM_RC wrap_key(TPM2B_PRIVATE *priv, const char *password, EVP_PKEY *pkey)
+{
+	TPMT_SENSITIVE s;
+	TPM2B_SENSITIVE b;
+	BYTE *buf;
+	int32_t size;
+	TPM_RC rc;
+
+	memset(&b, 0, sizeof(b));
+	memset(&s, 0, sizeof(s));
+
+	openssl_to_tpm_private(&s, pkey);
+
+	if (password) {
+		int len = strlen(password);
+
+		memcpy(s.authValue.b.buffer, password, len);
+		s.authValue.b.size = len;
+	} else {
+		s.authValue.b.size = 0;
+	}
+	size = sizeof(s);
+	buf = b.b.buffer;
+	rc = TSS_TPMT_SENSITIVE_Marshal(&s, &b.b.size, &buf, &size);
+	if (rc)
+		tpm2_error(rc, "TSS_TPMT_SENSITIVE_Marshal");
+
+	size = sizeof(*priv);
+	buf = priv->b.buffer;
+	priv->b.size = 0;
+	/* no encryption means innerIntegrity and outerIntegrity are
+	* absent, so the TPM2B_PRIVATE is a TPMT_SENSITIVE*/
+	rc = TSS_TPM2B_PRIVATE_Marshal((TPM2B_PRIVATE *)&b, &priv->b.size, &buf, &size);
+	if (rc)
+		tpm2_error(rc, "TSS_TPM2B_PRIVATE_Marshal");
+
+	return TPM_RC_ASYMMETRIC;
+}
+
+int main(int argc, char **argv)
+{
+	char *filename, c, *wrap = NULL, *auth = NULL;
+	int option_index;
+	const char *reason;
+	TSS_CONTEXT *tssContext = NULL;
+	TPM_HANDLE parent = 0;
+	TPM_RC rc = 0;
+	BYTE pubkey[sizeof(TPM2B_PUBLIC)],privkey[sizeof(TPM2B_PRIVATE)], *buffer;
+	uint16_t pubkey_len, privkey_len;
+	int32_t size;
+
+
+	while (1) {
+		option_index = 0;
+		c = getopt_long(argc, argv, "n:ahw:",
+				long_options, &option_index);
+		if (c == -1)
+			break;
+
+		switch (c) {
+			case 'a':
+				auth = malloc(128);
+				break;
+			case 'h':
+				usage(argv[0]);
+				break;
+			case 'n':
+				if (!strcasecmp("sha1", optarg)) {
+					name_alg = TPM_ALG_SHA1;
+					name_alg_size = SHA1_DIGEST_SIZE;
+				} else if (strcasecmp("sha256", optarg)) {
+					/* default, do nothing */
+				} else if (strcasecmp("sha384", optarg)) {
+					name_alg = TPM_ALG_SHA384;
+					name_alg_size = SHA384_DIGEST_SIZE;
+#ifdef TPM_ALG_SHA512
+				} else if (strcasecmp("sha512", optarg)) {
+					name_alg = TPM_ALG_SHA512;
+					name_alg_size = SHA512_DIGEST_SIZE;
+#endif
+				} else {
+					usage(argv[0]);
+				}
+				break;
+			case 'w':
+				wrap = optarg;
+				break;
+			default:
+				usage(argv[0]);
+				break;
+		}
+	}
+
+	filename = argv[argc - 1];
+
+	if (argc < 2)
+		usage(argv[0]);
+
+	if (auth) {
+		if (EVP_read_pw_string(auth, 128, "Enter TPM key authority: ", 1)) {
+			fprintf(stderr, "Passwords do not match\n");
+			exit(1);
+		}
+	}
+
+	rc = TSS_Create(&tssContext);
+	if (rc) {
+		reason = "TSS_Create";
+		goto out_err;
+	}
+
+	if (wrap) {
+		Import_In iin;
+		Import_Out iout;
+		EVP_PKEY *pkey;
+ 
+		/* may be needed to decrypt the key */
+		OpenSSL_add_all_ciphers();
+		pkey = openssl_read_key(wrap);
+		if (!pkey) {
+			reason = "unable to read key";
+			goto out_delete;
+		}
+
+		rc = tpm2_load_srk(tssContext, &parent, NULL, NULL);
+		if (rc) {
+			reason = "tpm2_load_srk";
+			goto out_delete;
+		}
+		iin.parentHandle = parent;
+		iin.encryptionKey.t.size = 0;
+		openssl_to_tpm_public(&iin.objectPublic, pkey);
+		/* set random iin.symSeed */
+		iin.inSymSeed.t.size = 0;
+		iin.symmetricAlg.algorithm = TPM_ALG_NULL;
+		wrap_key(&iin.duplicate, auth, pkey);
+		openssl_to_tpm_public(&iin.objectPublic, pkey);
+		rc = TSS_Execute(tssContext,
+				 (RESPONSE_PARAMETERS *)&iout,
+				 (COMMAND_PARAMETERS *)&iin,
+				 NULL,
+				 TPM_CC_Import,
+				 TPM_RS_PW, NULL, 0,
+				 TPM_RH_NULL, NULL, 0,
+				 TPM_RH_NULL, NULL, 0,
+				 TPM_RH_NULL, NULL, 0);
+		if (rc) {
+			reason = "TPM2_Import";
+			goto out_flush;
+		}
+		tpm2_flush_handle(tssContext, parent);
+		buffer = pubkey;
+		pubkey_len = 0;
+		size = sizeof(pubkey);
+		TSS_TPM2B_PUBLIC_Marshal(&iin.objectPublic, &pubkey_len, &buffer, &size);
+		printf("MARSHAL to %d of %ld\n", (pubkey[0]*256) + pubkey[1],
+		       sizeof(pubkey));
+		buffer = privkey;
+		privkey_len = 0;
+		size = sizeof(privkey);
+		TSS_TPM2B_PRIVATE_Marshal(&iout.outPrivate, &privkey_len, &buffer, &size);
+		printf("MARSHAL to %d of %ld\n", (privkey[0]*256) + privkey[1],
+		       sizeof(privkey));
+ 	} else {
+		pubkey_len = 0;
+		privkey_len = 0;
+	}
+	openssl_write_tpmfile(filename, pubkey, pubkey_len, privkey, privkey_len);
+	exit(0);
+
+ out_flush:
+	tpm2_flush_handle(tssContext, parent);
+ out_delete:
+	TSS_Delete(tssContext);
+ out_err:
+	tpm2_error(rc, reason);
+
+	exit(1);
+}
diff --git a/e_tpm2.c b/e_tpm2.c
new file mode 100644
index 0000000..298282c
--- /dev/null
+++ b/e_tpm2.c
@@ -0,0 +1,482 @@
+
+/*
+ * Copyright (C) 2016 James.Bottomley at HansenPartnership.com
+ *
+ * GPLv2
+ *
+ */
+
+#include <stdio.h>
+#include <string.h>
+
+#include <openssl/crypto.h>
+#include <openssl/dso.h>
+#include <openssl/engine.h>
+#include <openssl/evp.h>
+#include <openssl/objects.h>
+#include <openssl/sha.h>
+#include <openssl/bn.h>
+#include <openssl/pem.h>
+#include <openssl/x509.h>
+
+#include <tss2/tss.h>
+#include <tss2/tssutils.h>
+#include <tss2/tssmarshal.h>
+#include <tss2/tssresponsecode.h>
+#include <tss2/Unmarshal_fp.h>
+
+#include "tpm2-asn.h"
+#include "tpm2-common.h"
+
+#define TPM2_ENGINE_EX_DATA_UNINIT		-1
+
+/* structure pointed to by the RSA object's app_data pointer */
+struct rsa_app_data
+{
+	TPM_HANDLE hKey;
+};
+
+static TSS_CONTEXT *tssContext;
+static char *srk_auth;
+
+static int tpm2_engine_init(ENGINE * e)
+{
+	TPM_RC rc;
+
+	rc = TSS_Create(&tssContext);
+	if (!rc)
+		return 1;
+
+	tpm2_error(rc, "TSS_Create");
+	return 0;
+}
+
+static int tpm2_engine_finish(ENGINE * e)
+{
+	tpm2_flush_srk(tssContext);
+	if (tssContext)
+		TSS_Delete(tssContext);
+
+	return 1;
+}
+
+static int tpm2_create_srk_policy(char *secret)
+{
+	int len;
+
+	if (!secret) {
+		OPENSSL_free(srk_auth);
+		srk_auth = NULL;
+	} else {
+		len = strlen(secret);
+		srk_auth = OPENSSL_malloc(len);
+		strcpy(srk_auth, secret);
+	}
+	return 1;
+}
+
+#define TPM_CMD_PIN ENGINE_CMD_BASE
+
+static int tpm2_engine_ctrl(ENGINE * e, int cmd, long i, void *p, void (*f) ())
+{
+	if (!tssContext) {
+		fprintf(stderr, "tpm2: engine not initialized\n");
+		return 0;
+	}
+
+
+	switch (cmd) {
+		case TPM_CMD_PIN:
+			return tpm2_create_srk_policy(p);
+		default:
+			break;
+	}
+	fprintf(stderr, "tpm2: engine command not implemented\n");
+
+	return 0;
+}
+
+
+#ifndef OPENSSL_NO_RSA
+/* rsa functions */
+static int tpm2_rsa_init(RSA *rsa);
+static int tpm2_rsa_finish(RSA *rsa);
+static int tpm2_rsa_pub_dec(int, const unsigned char *, unsigned char *, RSA *, int);
+static int tpm2_rsa_pub_enc(int, const unsigned char *, unsigned char *, RSA *, int);
+static int tpm2_rsa_priv_dec(int, const unsigned char *, unsigned char *, RSA *, int);
+static int tpm2_rsa_priv_enc(int, const unsigned char *, unsigned char *, RSA *, int);
+//static int tpm2_rsa_sign(int, const unsigned char *, unsigned int, unsigned char *, unsigned int *, const RSA *);
+#endif
+
+/* The definitions for control commands specific to this engine */
+#define TPM2_CMD_PIN		ENGINE_CMD_BASE
+static const ENGINE_CMD_DEFN tpm2_cmd_defns[] = {
+	{TPM2_CMD_PIN,
+	 "PIN",
+	 "Specifies the secret for the SRK (default is plaintext, else set SECRET_MODE)",
+	 ENGINE_CMD_FLAG_STRING},
+	/* end */
+	{0, NULL, NULL, 0}
+};
+
+#ifndef OPENSSL_NO_RSA
+static RSA_METHOD tpm2_rsa = {
+	"TPM RSA method",
+	tpm2_rsa_pub_enc,
+	tpm2_rsa_pub_dec,
+	tpm2_rsa_priv_enc,
+	tpm2_rsa_priv_dec,
+	NULL, /* set in tpm2_engine_init */
+	BN_mod_exp_mont,
+	tpm2_rsa_init,
+	tpm2_rsa_finish,
+	(RSA_FLAG_SIGN_VER | RSA_FLAG_NO_BLINDING),
+	NULL,
+	NULL, /* sign */
+	NULL, /* verify */
+	NULL, /* keygen */
+};
+#endif
+
+/* varibles used to get/set CRYPTO_EX_DATA values */
+static int ex_app_data = TPM2_ENGINE_EX_DATA_UNINIT;
+
+static EVP_PKEY *tpm2_engine_load_key(ENGINE *e, const char *key_id,
+				     UI_METHOD *ui, void *cb_data)
+{
+	TPM_HANDLE key,srk;
+	TPM_RC rc;
+	EVP_PKEY *pkey;
+	RSA *rsa;
+	BIO *bf;
+	TSSLOADABLE *tssl;
+	Load_In in;
+	Load_Out out;
+	struct rsa_app_data *app_data;
+	BYTE *buffer;
+	INT32 size;
+
+	if (!key_id) {
+		fprintf(stderr, "key_id is NULL\n");
+		return NULL;
+	}
+
+	rc = tpm2_load_srk(tssContext, &srk, srk_auth, NULL);
+	if (rc) {
+		tpm2_error(rc, "tpm2_load_srk");
+		return NULL;
+	}
+
+	bf = BIO_new_file(key_id, "r");
+	if (!bf) {
+		fprintf(stderr, "File %s does not exist or cannot be read\n", key_id); 
+		goto err;
+	}
+
+	tssl = PEM_read_bio_TSSLOADABLE(bf, NULL, NULL, NULL);
+	if (!tssl) {
+		fprintf(stderr, "Failed to parse file %s\n", key_id);
+		BIO_free(bf);
+		goto err;
+	}
+
+	BIO_free(bf);
+
+	in.parentHandle = srk;
+	buffer = tssl->privkey->data;
+	size = tssl->privkey->length;
+	TPM2B_PRIVATE_Unmarshal(&in.inPrivate, &buffer, &size);
+	buffer = tssl->pubkey->data;
+	size = tssl->pubkey->length;
+	TPM2B_PUBLIC_Unmarshal(&in.inPublic, &buffer, &size, FALSE);
+
+	rc = TSS_Execute(tssContext,
+			 (RESPONSE_PARAMETERS *)&out,
+			 (COMMAND_PARAMETERS *)&in,
+			 NULL,
+			 TPM_CC_Load,
+			 TPM_RS_PW, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0);
+	TSSLOADABLE_free(tssl);
+	if (rc) {
+		tpm2_error(rc, "TPM2_Load");
+		goto err;
+	}
+	key = out.objectHandle;
+
+	app_data = OPENSSL_malloc(sizeof(struct rsa_app_data));
+	if (!app_data) {
+		fprintf(stderr, "Failed to allocate app_data\n");
+		goto err_key;
+	}
+	/* create the new objects to return */
+	pkey = tpm2_to_openssl_public(&in.inPublic.publicArea);
+	if (!pkey) {
+		fprintf(stderr, "Failed to allocate a new EVP_KEY\n");
+		goto err_key;
+	}
+	app_data->hKey = key;
+
+	rsa = EVP_PKEY_get1_RSA(pkey);
+	RSA_set_ex_data(rsa, ex_app_data, app_data);
+	rsa->meth = &tpm2_rsa;
+	/* call our local init function here */
+	rsa->meth->init(rsa);
+
+	/* release the reference EVP_PKEY_get1_RSA obtained */
+	RSA_free(rsa);
+	return pkey;
+ err_key:
+	tpm2_flush_handle(tssContext, key);
+ err:
+	tpm2_flush_handle(tssContext, srk);
+
+	return NULL;
+}
+
+/* Constants used when creating the ENGINE */
+static const char *engine_tpm2_id = "tpm2";
+static const char *engine_tpm2_name = "TPM2 hardware engine support";
+
+/* This internal function is used by ENGINE_tpm() and possibly by the
+ * "dynamic" ENGINE support too */
+static int tpm2_bind_helper(ENGINE * e)
+{
+	if (!ENGINE_set_id(e, engine_tpm2_id) ||
+	    !ENGINE_set_name(e, engine_tpm2_name) ||
+#ifndef OPENSSL_NO_RSA
+	    !ENGINE_set_RSA(e, &tpm2_rsa) ||
+#endif
+	    !ENGINE_set_init_function(e, tpm2_engine_init) ||
+	    !ENGINE_set_finish_function(e, tpm2_engine_finish) ||
+	    !ENGINE_set_ctrl_function(e, tpm2_engine_ctrl) ||
+	    !ENGINE_set_load_pubkey_function(e, tpm2_engine_load_key) ||
+	    !ENGINE_set_load_privkey_function(e, tpm2_engine_load_key) ||
+	    !ENGINE_set_cmd_defns(e, tpm2_cmd_defns))
+		return 0;
+
+	return 1;
+}
+
+
+#ifndef OPENSSL_NO_RSA
+static int tpm2_rsa_init(RSA *rsa)
+{
+	if (ex_app_data == TPM2_ENGINE_EX_DATA_UNINIT)
+		ex_app_data = RSA_get_ex_new_index(0, NULL, NULL, NULL, NULL);
+
+	if (ex_app_data == TPM2_ENGINE_EX_DATA_UNINIT) {
+		fprintf(stderr, "Failed to get memory for external data\n");
+		return 0;
+	}
+
+	return 1;
+}
+
+static int tpm2_rsa_finish(RSA *rsa)
+{
+	struct rsa_app_data *app_data = RSA_get_ex_data(rsa, ex_app_data);
+
+	if (!app_data)
+		return 1;
+
+	if (app_data->hKey) {
+		tpm2_flush_handle(tssContext, app_data->hKey);
+		tpm2_flush_srk(tssContext);
+		app_data->hKey = 0;
+	}
+
+	OPENSSL_free(app_data);
+
+	return 1;
+}
+
+static int tpm2_rsa_pub_dec(int flen,
+			   const unsigned char *from,
+			   unsigned char *to,
+			   RSA *rsa,
+			   int padding)
+{
+	int rv;
+
+	rv = RSA_PKCS1_SSLeay()->rsa_pub_dec(flen, from, to, rsa,
+					     padding);
+	if (rv < 0) {
+		fprintf(stderr, "rsa_pub_dec failed\n");
+		return 0;
+	}
+
+	return rv;
+}
+
+static int tpm2_rsa_priv_dec(int flen,
+			    const unsigned char *from,
+			    unsigned char *to,
+			    RSA *rsa,
+			    int padding)
+{
+	struct rsa_app_data *app_data = RSA_get_ex_data(rsa, ex_app_data);
+	int rv;
+
+	if (!app_data) {
+		rv = RSA_PKCS1_SSLeay()->rsa_priv_dec(flen, from, to, rsa,
+						      padding);
+		if (rv < 0)
+			fprintf(stderr, "rsa_priv_dec failed\n");
+
+		return rv;
+	}
+
+	if (!app_data->hKey) {
+		fprintf(stderr, "No TPM key defined\n");
+		return 0;
+	}
+
+	fprintf(stderr, "rsa_priv_dec currently unimplemented\n");
+	return 0;
+}
+
+static int tpm2_rsa_pub_enc(int flen,
+			   const unsigned char *from,
+			   unsigned char *to,
+			   RSA *rsa,
+			   int padding)
+{
+	struct rsa_app_data *app_data = RSA_get_ex_data(rsa, ex_app_data);
+	int rv;
+
+	if (!app_data) {
+		rv = RSA_PKCS1_SSLeay()->rsa_pub_enc(flen, from, to, rsa,
+						     padding);
+		if (rv < 0)
+			fprintf(stderr, "rsa_pub_enc failed\n");
+
+		return rv;
+	}
+	fprintf(stderr, "rsa_pub_enc not implemented");
+	return 0;
+}
+
+static int tpm2_rsa_priv_enc(int flen,
+			    const unsigned char *from,
+			    unsigned char *to,
+			    RSA *rsa,
+			    int padding)
+{
+	struct rsa_app_data *app_data = RSA_get_ex_data(rsa, ex_app_data);
+	TPM_RC rc;
+	int rv;
+	Sign_In in;
+	Sign_Out out;
+	X509_SIG *x509_sig;
+	const unsigned char *buf = from;
+	TPM_ALG_ID hash_alg;
+
+	if (!app_data) {
+		rv = RSA_PKCS1_SSLeay()->rsa_priv_enc(flen, from, to, rsa,
+						      padding);
+		if (rv < 0)
+			fprintf(stderr, "pass through signing failed\n");
+
+		return rv;
+	}
+
+	rv = -1;
+	if (padding != RSA_PKCS1_PADDING) {
+		fprintf(stderr, "Non PKCS1 padding asked for\n");
+		return rv;
+	}
+
+	if (!app_data->hKey) {
+		fprintf(stderr, "No RSA key set for signature\n");
+		return rv;
+	}
+
+	x509_sig = d2i_X509_SIG(NULL, &buf, flen);
+	if (!x509_sig) {
+		fprintf(stderr, "buffer for signing is not an X509_SIG type\n");
+		return rv;
+	}
+
+	switch (OBJ_obj2nid(x509_sig->algor->algorithm)) {
+	case NID_sha1:
+		hash_alg = TPM_ALG_SHA1;
+		break;
+	case NID_sha256:
+		hash_alg = TPM_ALG_SHA256;
+		break;
+	case NID_sha384:
+		hash_alg = TPM_ALG_SHA384;
+		break;
+#ifdef TPM_ALG_SHA512
+	case NID_sha512:
+		hash_alg = TPM_ALG_SHA512;
+		break;
+#endif
+	default: {
+		char buf[512];
+		OBJ_obj2txt(buf, sizeof(buf), x509_sig->algor->algorithm, 0);
+		fprintf(stderr, "unrecognised signature algorithm %s\n", buf);
+		goto out_free;
+	}
+	}
+
+	in.keyHandle = app_data->hKey;
+	in.digest.t.size = x509_sig->digest->length;
+	memcpy(&in.digest.t.buffer, x509_sig->digest->data,
+	       x509_sig->digest->length);
+	in.inScheme.scheme = TPM_ALG_RSASSA;
+	in.inScheme.details.any.hashAlg = hash_alg;
+	/* no proof means NULL validation ticket */
+	in.validation.tag = TPM_ST_HASHCHECK;
+	in.validation.hierarchy = TPM_RH_NULL;
+	in.validation.digest.t.size = 0;
+
+	rc = TSS_Execute(tssContext,
+			 (RESPONSE_PARAMETERS *)&out,
+			 (COMMAND_PARAMETERS *)&in,
+			 NULL,
+			 TPM_CC_Sign,
+			 TPM_RS_PW, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0);
+
+	if (rc) {
+		tpm2_error(rc, "TPM2_Sign");
+		goto out_free;
+	}
+ 
+
+	memcpy(to, out.signature.signature.rsassa.sig.t.buffer,
+	       out.signature.signature.rsassa.sig.t.size);
+
+	rv = out.signature.signature.rsassa.sig.t.size;
+
+ out_free:
+	X509_SIG_free(x509_sig);
+	return rv;
+}
+
+#endif
+
+/* This stuff is needed if this ENGINE is being compiled into a self-contained
+ * shared-library. */
+static int tpm2_bind_fn(ENGINE * e, const char *id)
+{
+	if (id && (strcmp(id, engine_tpm2_id) != 0)) {
+		fprintf(stderr, "Called for id %s != my id %s\n",
+		       id, engine_tpm2_id);
+		return 0;
+	}
+	if (!tpm2_bind_helper(e)) {
+		fprintf(stderr, "tpm2_bind_helper failed\n");
+		return 0;
+	}
+	return 1;
+}
+
+IMPLEMENT_DYNAMIC_CHECK_FN()
+IMPLEMENT_DYNAMIC_BIND_FN(tpm2_bind_fn)
diff --git a/tpm2-asn.h b/tpm2-asn.h
new file mode 100644
index 0000000..abbe294
--- /dev/null
+++ b/tpm2-asn.h
@@ -0,0 +1,35 @@
+/* Copyright (C) 2016 James Bottomley <James.Bottomley at HansenPartnership.com>
+ *
+ * GPLv2
+ */
+#ifndef _TPM2_ASN_H
+#define _TPM2_ASN_H
+
+#include <openssl/asn1t.h>
+
+/*
+ * Define the format of a TSS2 key file.  The current format is a 
+ * symmetrically encrypted private key produced by TSS2_Import and 
+ * the TPM2 format public key which contains things like the policy but
+ * which is cryptographically tied to the private key
+ */
+
+typedef struct {
+	ASN1_OCTET_STRING *pubkey;
+	ASN1_OCTET_STRING *privkey;
+} TSSLOADABLE;
+
+ASN1_SEQUENCE(TSSLOADABLE) = {
+	ASN1_SIMPLE(TSSLOADABLE, pubkey, ASN1_OCTET_STRING),
+	ASN1_SIMPLE(TSSLOADABLE, privkey, ASN1_OCTET_STRING)
+} ASN1_SEQUENCE_END(TSSLOADABLE)
+
+IMPLEMENT_ASN1_FUNCTIONS(TSSLOADABLE);
+
+/* This is the PEM guard tag */
+#define TSSLOADABLE_PEM_STRING "TSS2 KEY BLOB"
+
+static IMPLEMENT_PEM_write_bio(TSSLOADABLE, TSSLOADABLE, TSSLOADABLE_PEM_STRING, TSSLOADABLE)
+static IMPLEMENT_PEM_read_bio(TSSLOADABLE, TSSLOADABLE, TSSLOADABLE_PEM_STRING, TSSLOADABLE)
+
+#endif
diff --git a/tpm2-common.c b/tpm2-common.c
new file mode 100644
index 0000000..b544f2f
--- /dev/null
+++ b/tpm2-common.c
@@ -0,0 +1,172 @@
+/*
+ * Copyright (C) 2016 James Bottomley <James.Bottomley at HansenPartnership.com>
+ *
+ * GPLv2
+ */
+
+#include <stdio.h>
+
+#include <openssl/evp.h>
+#include <openssl/rsa.h>
+
+#include <tss2/tss.h>
+#include <tss2/tssresponsecode.h>
+
+#include "tpm2-common.h"
+
+void tpm2_error(TPM_RC rc, const char *reason)
+{
+	const char *msg, *submsg, *num;
+
+	fprintf(stderr, "%s failed with %d\n", reason, rc);
+	TSS_ResponseCode_toString(&msg, &submsg, &num, rc);
+	fprintf(stderr, "%s%s%s\n", msg, submsg, num);
+}
+
+
+static TPM_HANDLE hSRK = 0;
+
+TPM_HANDLE tpm2_load_srk(TSS_CONTEXT *tssContext, TPM_HANDLE *h, const char *auth,TPM2B_PUBLIC *pub)
+{
+	static TPM2B_PUBLIC srk_pub;
+	TPM_RC rc;
+	CreatePrimary_In in;
+	CreatePrimary_Out out;
+
+	if (hSRK)
+		goto out;
+
+	/* SPS owner */
+	in.primaryHandle = TPM_RH_OWNER;
+	/* assume no owner password */
+	in.inSensitive.sensitive.userAuth.t.size = 0;
+	/* no sensitive date for storage keys */
+	in.inSensitive.sensitive.data.t.size = 0;
+	/* no outside info */
+	in.outsideInfo.t.size = 0;
+	/* no PCR state */
+	in.creationPCR.count = 0;
+
+	/* public parameters for an RSA2048 key  */
+	in.inPublic.publicArea.type = TPM_ALG_RSA;
+	in.inPublic.publicArea.nameAlg = TPM_ALG_SHA256;
+	in.inPublic.publicArea.objectAttributes.val =
+		TPMA_OBJECT_NODA |
+		TPMA_OBJECT_SENSITIVEDATAORIGIN |
+		TPMA_OBJECT_USERWITHAUTH |
+		TPMA_OBJECT_DECRYPT |
+		TPMA_OBJECT_RESTRICTED;
+	in.inPublic.publicArea.parameters.rsaDetail.symmetric.algorithm = TPM_ALG_AES;
+	in.inPublic.publicArea.parameters.rsaDetail.symmetric.keyBits.aes = 128;
+	in.inPublic.publicArea.parameters.rsaDetail.symmetric.mode.aes = TPM_ALG_CFB;
+	in.inPublic.publicArea.parameters.rsaDetail.scheme.scheme = TPM_ALG_NULL;
+	in.inPublic.publicArea.parameters.rsaDetail.keyBits = 2048;
+	/* means conventional 2^16+1 */
+	in.inPublic.publicArea.parameters.rsaDetail.exponent = 0;
+	in.inPublic.publicArea.unique.rsa.t.size = 0;
+	in.inPublic.publicArea.authPolicy.t.size = 0;
+
+	rc = TSS_Execute(tssContext,
+			 (RESPONSE_PARAMETERS *)&out,
+			 (COMMAND_PARAMETERS *)&in,
+			 NULL,
+			 TPM_CC_CreatePrimary,
+			 TPM_RS_PW, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0);
+	if (rc)
+		return rc;
+
+	hSRK = out.objectHandle;
+	srk_pub = out.outPublic;
+ out:
+	*h = hSRK;
+	if (pub)
+		*pub = srk_pub;
+
+	return 0;
+}
+
+void tpm2_flush_srk(TSS_CONTEXT *tssContext)
+{
+	if (hSRK)
+		tpm2_flush_handle(tssContext, hSRK);
+	hSRK = 0;
+}
+
+void tpm2_flush_handle(TSS_CONTEXT *tssContext, TPM_HANDLE h)
+{
+	FlushContext_In in;
+
+	if (!h)
+		return;
+
+	in.flushHandle = h;
+	TSS_Execute(tssContext, NULL, 
+		    (COMMAND_PARAMETERS *)&in,
+		    NULL,
+		    TPM_CC_FlushContext,
+		    TPM_RH_NULL, NULL, 0);
+}
+
+static EVP_PKEY *tpm2_to_openssl_public_rsa(TPMT_PUBLIC *pub)
+{
+	RSA *rsa = RSA_new();
+	EVP_PKEY *pkey;
+	unsigned long exp;
+	BIGNUM *n, *e;
+
+	if (!rsa)
+		return NULL;
+	pkey = EVP_PKEY_new();
+	if (!pkey)
+		goto err_free_rsa;
+	e = BN_new();
+	if (!e)
+		goto err_free_pkey;
+	n = BN_new();
+	if (!n)
+		goto err_free_e;
+	if (pub->parameters.rsaDetail.exponent == 0)
+		exp = 0x10001;
+	else
+		exp = pub->parameters.rsaDetail.exponent;
+	if (!BN_set_word(e, exp))
+		goto err_free;
+	if (!BN_bin2bn(pub->unique.rsa.t.buffer, pub->unique.rsa.t.size, n))
+		goto err_free;
+#if OPENSSL_VERSION_NUMBER < 0x10100000
+	rsa->n = n;
+	rsa->e = e;
+#else
+	RSA_set0_key(rsa, n, e, NULL);
+#endif
+	if (!EVP_PKEY_assign_RSA(pkey, rsa))
+		goto err_free;
+
+	return pkey;
+
+ err_free:
+	BN_free(n);
+ err_free_e:
+	BN_free(e);
+ err_free_pkey:
+	EVP_PKEY_free(pkey);
+ err_free_rsa:
+	RSA_free(rsa);
+
+	return NULL;
+}
+
+EVP_PKEY *tpm2_to_openssl_public(TPMT_PUBLIC *pub)
+{
+	switch (pub->type) {
+	case TPM_ALG_RSA:
+		return tpm2_to_openssl_public_rsa(pub);
+	default:
+		break;
+	}
+	return NULL;
+}
+
diff --git a/tpm2-common.h b/tpm2-common.h
new file mode 100644
index 0000000..197e552
--- /dev/null
+++ b/tpm2-common.h
@@ -0,0 +1,10 @@
+#ifndef _TPM2_COMMON_H
+#define _TPM2_COMMON_H
+
+void tpm2_error(TPM_RC rc, const char *reason);
+TPM_HANDLE tpm2_load_srk(TSS_CONTEXT *tssContext, TPM_HANDLE *h, const char *auth, TPM2B_PUBLIC *pub);
+void tpm2_flush_handle(TSS_CONTEXT *tssContext, TPM_HANDLE h);
+EVP_PKEY *tpm2_to_openssl_public(TPMT_PUBLIC *pub);
+void tpm2_flush_srk(TSS_CONTEXT *tssContext);
+
+#endif
-- 
2.6.6


From changzheng.wei at intel.com  Thu Dec 22 13:12:36 2016
From: changzheng.wei at intel.com (Wei, Changzheng)
Date: Thu, 22 Dec 2016 13:12:36 +0000
Subject: [openssl-dev]  Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
Message-ID: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>

Hi,
I want to implement some new algorithm. To make my future work smoothly, I want to add a new algorithm method like "RSA_METHOD" in OpenSSL framework so as to I can use an "engine" to support such algorithm.
So I add a new subdir in "crypto" and implement the code and build.info refer to "crypto/rsa".
My question is how to add my new source code into the build system?

Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161222/46dafb30/attachment.html>

From tshort at akamai.com  Thu Dec 22 21:14:14 2016
From: tshort at akamai.com (Short, Todd)
Date: Thu, 22 Dec 2016 21:14:14 +0000
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
Message-ID: <D81FDE6E-4B4D-477A-ACB9-432D5B3CF95C@akamai.com>

Easiest way is to fork the OpenSSL Github repo and then clone it down to your local machine where you can do the work locally. Once you are happy, push it back up to your forked Github repo, and then make a pull request back to the OpenSSL repo.

There are lots of places you can get information on git and Github; but this list isn?t one of them.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Dec 22, 2016, at 8:12 AM, Wei, Changzheng <changzheng.wei at intel.com<mailto:changzheng.wei at intel.com>> wrote:

Hi,
I want to implement some new algorithm. To make my future work smoothly, I want to add a new algorithm method like ?RSA_METHOD? in OpenSSL framework so as to I can use an ?engine? to support such algorithm.
So I add a new subdir in ?crypto? and implement the code and build.info<http://build.info/> refer to ?crypto/rsa?.
My question is how to add my new source code into the build system?

Thanks in advance!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161222/54f38855/attachment.html>

From levitte at openssl.org  Thu Dec 22 21:20:53 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 22 Dec 2016 22:20:53 +0100 (CET)
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
Message-ID: <20161222.222053.215132172178924489.levitte@openssl.org>

In message <936BE946F26E274A8595DBF91A05BD767C4FAA87 at SHSMSX101.ccr.corp.intel.com> on Thu, 22 Dec 2016 13:12:36 +0000, "Wei, Changzheng" <changzheng.wei at intel.com> said:

changzheng.wei> Hi,
changzheng.wei> 
changzheng.wei> I want to implement some new algorithm. To make my future work
changzheng.wei> smoothly, I want to add a new algorithm method like ?RSA_METHOD? in
changzheng.wei> OpenSSL framework so as to I can use an ?engine? to support such
changzheng.wei> algorithm.
changzheng.wei> 
changzheng.wei> So I add a new subdir in ?crypto? and implement the code and
changzheng.wei> build.info refer to ?crypto/rsa?.
changzheng.wei> 
changzheng.wei> My question is how to add my new source code into the build system?

A note here: if you're implementing a new algo, OpenSSL doesn't need
to know anything at all, everything can be added dynamically from the
engine and be reachable through the EVP API.

The only exception for now is the code in libssl.

May I suggest you have a look at the GOST engine?  It does implement
the algorithm entirely in the engine.  The only things added in the
OpenSSL code are the OIDs (not strictly necessary) and the TLS
ciphersuites (I don't think that can be done dynamically at all, at
least yet).

https://github.com/gost-engine/engine

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From xoloki at gmail.com  Thu Dec 22 21:33:16 2016
From: xoloki at gmail.com (Joey Yandle)
Date: Thu, 22 Dec 2016 13:33:16 -0800
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <20161222.222053.215132172178924489.levitte@openssl.org>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
 <20161222.222053.215132172178924489.levitte@openssl.org>
Message-ID: <e6400041-6133-8b74-2ff9-043ec6dcbfab@gmail.com>

> May I suggest you have a look at the GOST engine?  It does implement
> the algorithm entirely in the engine.  The only things added in the
> OpenSSL code are the OIDs (not strictly necessary) and the TLS
> ciphersuites (I don't think that can be done dynamically at all, at
> least yet).

How are the OIDs not necessary?  What about the NIDs?

I've been working on an engine to add support for SIDH, using GOST as a  
template:

   https://github.com/xoloki/openssl-sidh/

GOST already had NID support in the base openssl.  I had to add at least  
one line to crypto/objects/objects.txt to get my NID:

+# NIDs for SIDH
+1 3 102 100                 : SIDH         : Supersingular isogeny  
Diffie?Hellman

Is there some way to add the NID dynamically?  If not, how can an  
algorithm be added?  The build system in 1.1.0 at least makes this  
relatively simple.  In 1.0.x it is far more difficult.

cheers,

Joey

From levitte at openssl.org  Thu Dec 22 21:53:35 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 22 Dec 2016 22:53:35 +0100 (CET)
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <e6400041-6133-8b74-2ff9-043ec6dcbfab@gmail.com>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
 <20161222.222053.215132172178924489.levitte@openssl.org>
 <e6400041-6133-8b74-2ff9-043ec6dcbfab@gmail.com>
Message-ID: <20161222.225335.92995302056231655.levitte@openssl.org>

In message <e6400041-6133-8b74-2ff9-043ec6dcbfab at gmail.com> on Thu, 22 Dec 2016 13:33:16 -0800, Joey Yandle <xoloki at gmail.com> said:

xoloki> > May I suggest you have a look at the GOST engine?  It does implement
xoloki> > the algorithm entirely in the engine.  The only things added in the
xoloki> > OpenSSL code are the OIDs (not strictly necessary) and the TLS
xoloki> > ciphersuites (I don't think that can be done dynamically at all, at
xoloki> > least yet).
xoloki> 
xoloki> How are the OIDs not necessary?  What about the NIDs?

It's not stricly necessary to add them statically in the libcrypto
code.  They can be added dynamically by the engine by calling
OBJ_create() with the correct arguments.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Thu Dec 22 21:59:50 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 22 Dec 2016 22:59:50 +0100 (CET)
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <20161222.225335.92995302056231655.levitte@openssl.org>
References: <20161222.222053.215132172178924489.levitte@openssl.org>
 <e6400041-6133-8b74-2ff9-043ec6dcbfab@gmail.com>
 <20161222.225335.92995302056231655.levitte@openssl.org>
Message-ID: <20161222.225950.430365013526119055.levitte@openssl.org>

In message <20161222.225335.92995302056231655.levitte at openssl.org> on Thu, 22 Dec 2016 22:53:35 +0100 (CET), Richard Levitte <levitte at openssl.org> said:

levitte> In message <e6400041-6133-8b74-2ff9-043ec6dcbfab at gmail.com> on Thu, 22 Dec 2016 13:33:16 -0800, Joey Yandle <xoloki at gmail.com> said:
levitte> 
levitte> xoloki> > May I suggest you have a look at the GOST engine?  It does implement
levitte> xoloki> > the algorithm entirely in the engine.  The only things added in the
levitte> xoloki> > OpenSSL code are the OIDs (not strictly necessary) and the TLS
levitte> xoloki> > ciphersuites (I don't think that can be done dynamically at all, at
levitte> xoloki> > least yet).
levitte> xoloki> 
levitte> xoloki> How are the OIDs not necessary?  What about the NIDs?
levitte> 
levitte> It's not stricly necessary to add them statically in the libcrypto
levitte> code.  They can be added dynamically by the engine by calling
levitte> OBJ_create() with the correct arguments.

Applications will then have to find out the nid by calling
OBJ_txt2nid, OBJ_sn2nid or OBJ_ln2nid, depending on the data they
have.  Note: this can already be done for the built in OIDs.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From changzheng.wei at intel.com  Fri Dec 23 00:40:30 2016
From: changzheng.wei at intel.com (Wei, Changzheng)
Date: Fri, 23 Dec 2016 00:40:30 +0000
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <D81FDE6E-4B4D-477A-ACB9-432D5B3CF95C@akamai.com>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
 <D81FDE6E-4B4D-477A-ACB9-432D5B3CF95C@akamai.com>
Message-ID: <936BE946F26E274A8595DBF91A05BD767C4FAFA0@SHSMSX101.ccr.corp.intel.com>

Hi
Thanks for your reply.
My question is that, I add a new subdir(named abc) in openssl/crypto/abc, and implement codes , Makefile and build.info in the crypt/abc directory, but when I re-build OpenSSL, I found that this new added sub dir is not involved into the build system, any source file in this subdir is not compiled. So I want to know how to compile these new added files in OpenSSL build system.

Thanks

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Short, Todd
Sent: Friday, December 23, 2016 5:14 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

Easiest way is to fork the OpenSSL Github repo and then clone it down to your local machine where you can do the work locally. Once you are happy, push it back up to your forked Github repo, and then make a pull request back to the OpenSSL repo.

There are lots of places you can get information on git and Github; but this list isn?t one of them.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Dec 22, 2016, at 8:12 AM, Wei, Changzheng <changzheng.wei at intel.com<mailto:changzheng.wei at intel.com>> wrote:

Hi,
I want to implement some new algorithm. To make my future work smoothly, I want to add a new algorithm method like ?RSA_METHOD? in OpenSSL framework so as to I can use an ?engine? to support such algorithm.
So I add a new subdir in ?crypto? and implement the code and build.info<http://build.info/> refer to ?crypto/rsa?.
My question is how to add my new source code into the build system?

Thanks in advance!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161223/d64251b8/attachment.html>

From pwalten at au1.ibm.com  Fri Dec 23 00:56:07 2016
From: pwalten at au1.ibm.com (Peter Waltenberg)
Date: Fri, 23 Dec 2016 10:56:07 +1000
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <936BE946F26E274A8595DBF91A05BD767C4FAFA0@SHSMSX101.ccr.corp.intel.com>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
 <D81FDE6E-4B4D-477A-ACB9-432D5B3CF95C@akamai.com>
 <936BE946F26E274A8595DBF91A05BD767C4FAFA0@SHSMSX101.ccr.corp.intel.com>
Message-ID: <OFF772A450.4BB0ED6F-ON00258092.0004E66C-4A258092.000523B9@notes.na.collabserv.com>

It's changed in recent OpenSSL.

1.1.0c the directories are in Configure. 

# Top level directories to build
$config{dirs} = [ "crypto", "ssl", "engines", "apps", "test", "util", 
"tools", "
fuzz" ];
# crypto/ subdirectories to build
$config{sdirs} = [
    "objects",
    "md2", "md4", "md5", "sha", "mdc2", "hmac", "ripemd", "whrlpool", 
"poly1305"
, "blake2",
    "des", "aes", "rc2", "rc4", "rc5", "idea", "bf", "cast", "camellia", 
"seed",
 "chacha", "modes",
    "bn", "ec", "rsa", "dsa", "dh", "dso", "engine",
    "buffer", "bio", "stack", "lhash", "rand", "err",
    "evp", "asn1", "pem", "x509", "x509v3", "conf", "txt_db", "pkcs7", 
"pkcs12",
 "comp", "ocsp", "ui",
    "cms", "ts", "srp", "cmac", "ct", "async", "kdf", "sha3"  <====  Added 
sha3 to the list
    ];

Persist, it can be done but there was quite a bit of trial and error 
before I got it working.

Peter



From:   "Wei, Changzheng" <changzheng.wei at intel.com>
To:     "openssl-dev at openssl.org" <openssl-dev at openssl.org>
Date:   23/12/2016 10:41
Subject:        Re: [openssl-dev] Add a new algorithm in "crypto" dir, how 
to add the source code into the build system
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org>



Hi
Thanks for your reply. 
My question is that, I add a new subdir(named abc) in openssl/crypto/abc, 
and implement codes , Makefile and build.info in the crypt/abc directory, 
but when I re-build OpenSSL, I found that this new added sub dir is not 
involved into the build system, any source file in this subdir is not 
compiled. So I want to know how to compile these new added files in 
OpenSSL build system.
 
Thanks
 
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of 
Short, Todd
Sent: Friday, December 23, 2016 5:14 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add 
the source code into the build system
 
Easiest way is to fork the OpenSSL Github repo and then clone it down to 
your local machine where you can do the work locally. Once you are happy, 
push it back up to your forked Github repo, and then make a pull request 
back to the OpenSSL repo. 
 
There are lots of places you can get information on git and Github; but 
this list isn?t one of them.
--
-Todd Short
// tshort at akamai.com
// "One if by land, two if by sea, three if by the Internet."
 
On Dec 22, 2016, at 8:12 AM, Wei, Changzheng <changzheng.wei at intel.com> 
wrote:
 
Hi, 
I want to implement some new algorithm. To make my future work smoothly, I 
want to add a new algorithm method like ?RSA_METHOD? in OpenSSL framework 
so as to I can use an ?engine? to support such algorithm.
So I add a new subdir in ?crypto? and implement the code and build.info 
refer to ?crypto/rsa?.
My question is how to add my new source code into the build system?
 
Thanks in advance!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
 -- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161223/36ee774f/attachment-0001.html>

From changzheng.wei at intel.com  Fri Dec 23 02:28:25 2016
From: changzheng.wei at intel.com (Wei, Changzheng)
Date: Fri, 23 Dec 2016 02:28:25 +0000
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <OFF772A450.4BB0ED6F-ON00258092.0004E66C-4A258092.000523B9@notes.na.collabserv.com>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
 <D81FDE6E-4B4D-477A-ACB9-432D5B3CF95C@akamai.com>
 <936BE946F26E274A8595DBF91A05BD767C4FAFA0@SHSMSX101.ccr.corp.intel.com>
 <OFF772A450.4BB0ED6F-ON00258092.0004E66C-4A258092.000523B9@notes.na.collabserv.com>
Message-ID: <936BE946F26E274A8595DBF91A05BD767C4FB165@SHSMSX101.ccr.corp.intel.com>

It works. Thanks a lot!

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Peter Waltenberg
Sent: Friday, December 23, 2016 8:56 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

It's changed in recent OpenSSL.

1.1.0c the directories are in Configure.

# Top level directories to build
$config{dirs} = [ "crypto", "ssl", "engines", "apps", "test", "util", "tools", "
fuzz" ];
# crypto/ subdirectories to build
$config{sdirs} = [
    "objects",
    "md2", "md4", "md5", "sha", "mdc2", "hmac", "ripemd", "whrlpool", "poly1305"
, "blake2",
    "des", "aes", "rc2", "rc4", "rc5", "idea", "bf", "cast", "camellia", "seed",
 "chacha", "modes",
    "bn", "ec", "rsa", "dsa", "dh", "dso", "engine",
    "buffer", "bio", "stack", "lhash", "rand", "err",
    "evp", "asn1", "pem", "x509", "x509v3", "conf", "txt_db", "pkcs7", "pkcs12",
 "comp", "ocsp", "ui",
    "cms", "ts", "srp", "cmac", "ct", "async", "kdf", "sha3"  <====  Added sha3 to the list
    ];

Persist, it can be done but there was quite a bit of trial and error before I got it working.

Peter



From:        "Wei, Changzheng" <changzheng.wei at intel.com<mailto:changzheng.wei at intel.com>>
To:        "openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>" <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
Date:        23/12/2016 10:41
Subject:        Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>>
________________________________



Hi
Thanks for your reply.
My question is that, I add a new subdir(named abc) in openssl/crypto/abc, and implement codes , Makefile and build.info in the crypt/abc directory, but when I re-build OpenSSL, I found that this new added sub dir is not involved into the build system, any source file in this subdir is not compiled. So I want to know how to compile these new added files in OpenSSL build system.

Thanks

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Short, Todd
Sent: Friday, December 23, 2016 5:14 AM
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

Easiest way is to fork the OpenSSL Github repo and then clone it down to your local machine where you can do the work locally. Once you are happy, push it back up to your forked Github repo, and then make a pull request back to the OpenSSL repo.

There are lots of places you can get information on git and Github; but this list isn?t one of them.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Dec 22, 2016, at 8:12 AM, Wei, Changzheng <changzheng.wei at intel.com<mailto:changzheng.wei at intel.com>> wrote:

Hi,
I want to implement some new algorithm. To make my future work smoothly, I want to add a new algorithm method like ?RSA_METHOD? in OpenSSL framework so as to I can use an ?engine? to support such algorithm.
So I add a new subdir in ?crypto? and implement the code and build.info<http://build.info/>refer to ?crypto/rsa?.
My question is how to add my new source code into the build system?

Thanks in advance!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
 --
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161223/0f03f62c/attachment.html>

From beldmit at gmail.com  Fri Dec 23 07:26:24 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 23 Dec 2016 10:26:24 +0300
Subject: [openssl-dev] Add a new algorithm in "crypto" dir,
 how to add the source code into the build system
In-Reply-To: <936BE946F26E274A8595DBF91A05BD767C4FB165@SHSMSX101.ccr.corp.intel.com>
References: <936BE946F26E274A8595DBF91A05BD767C4FAA87@SHSMSX101.ccr.corp.intel.com>
 <D81FDE6E-4B4D-477A-ACB9-432D5B3CF95C@akamai.com>
 <936BE946F26E274A8595DBF91A05BD767C4FAFA0@SHSMSX101.ccr.corp.intel.com>
 <OFF772A450.4BB0ED6F-ON00258092.0004E66C-4A258092.000523B9@notes.na.collabserv.com>
 <936BE946F26E274A8595DBF91A05BD767C4FB165@SHSMSX101.ccr.corp.intel.com>
Message-ID: <CADqLbzJ6e2RS6sELdY6TFJENDV7hLuLerxeqYGZ+Fo-0ya3ALw@mail.gmail.com>

Dear Wei,

You will need hardcoded NIDs for many protocols implemented in OpenSSL
(TLS, PKCS12).

For most other purposes the dynamic allocation of objects using OBJ_
functions works fine,
but some years ago I had problems with some applications when I used engine
that allocated objects dynamically.
I hope that it was my fault.


On Fri, Dec 23, 2016 at 5:28 AM, Wei, Changzheng <changzheng.wei at intel.com>
wrote:

> It works. Thanks a lot!
>
>
>
> *From:* openssl-dev [mailto:openssl-dev-bounces at openssl.org] *On Behalf
> Of *Peter Waltenberg
> *Sent:* Friday, December 23, 2016 8:56 AM
>
> *To:* openssl-dev at openssl.org
> *Subject:* Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to
> add the source code into the build system
>
>
>
> It's changed in recent OpenSSL.
>
> 1.1.0c the directories are in Configure.
>
> # Top level directories to build
> $config{dirs} = [ "crypto", "ssl", "engines", "apps", "test", "util",
> "tools", "
> fuzz" ];
> # crypto/ subdirectories to build
> $config{sdirs} = [
>     "objects",
>     "md2", "md4", "md5", "sha", "mdc2", "hmac", "ripemd", "whrlpool",
> "poly1305"
> , "blake2",
>     "des", "aes", "rc2", "rc4", "rc5", "idea", "bf", "cast", "camellia",
> "seed",
>  "chacha", "modes",
>     "bn", "ec", "rsa", "dsa", "dh", "dso", "engine",
>     "buffer", "bio", "stack", "lhash", "rand", "err",
>     "evp", "asn1", "pem", "x509", "x509v3", "conf", "txt_db", "pkcs7",
> "pkcs12",
>  "comp", "ocsp", "ui",
>     "cms", "ts", "srp", "cmac", "ct", "async", "kdf", "sha3"  <====  Added
> sha3 to the list
>     ];
>
> Persist, it can be done but there was quite a bit of trial and error
> before I got it working.
>
> Peter
>
>
>
> From:        "Wei, Changzheng" <changzheng.wei at intel.com>
> To:        "openssl-dev at openssl.org" <openssl-dev at openssl.org>
> Date:        23/12/2016 10:41
> Subject:        Re: [openssl-dev] Add a new algorithm in "crypto" dir,
> how to add the source code into the build system
> Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org>
> ------------------------------
>
>
>
>
> Hi
> Thanks for your reply.
> My question is that, I add a new subdir(named *abc*) in openssl/crypto/
> *abc*, and implement codes , Makefile and build.info in the crypt/abc
> directory, but when I re-build OpenSSL, I found that this new added sub dir
> is not involved into the build system, any source file in this subdir is
> not compiled. So I want to know how to compile these new added files in
> OpenSSL build system.
>
> Thanks
>
> *From:* openssl-dev [mailto:openssl-dev-bounces at openssl.org
> <openssl-dev-bounces at openssl.org>] *On Behalf Of *Short, Todd
> * Sent:* Friday, December 23, 2016 5:14 AM
> * To:* openssl-dev at openssl.org
> * Subject:* Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to
> add the source code into the build system
>
> Easiest way is to fork the OpenSSL Github repo and then clone it down to
> your local machine where you can do the work locally. Once you are happy,
> push it back up to your forked Github repo, and then make a pull request
> back to the OpenSSL repo.
>
> There are lots of places you can get information on git and Github; but
> this list isn?t one of them.
> --
> -Todd Short
> // tshort at akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Dec 22, 2016, at 8:12 AM, Wei, Changzheng <changzheng.wei at intel.com>
> wrote:
>
> Hi,
> I want to implement some new algorithm. To make my future work smoothly, I
> want to add a new algorithm method like ?RSA_METHOD? in OpenSSL framework
> so as to I can use an ?engine? to support such algorithm.
> So I add a new subdir in ?crypto? and implement the code and build.inforefer
> to ?crypto/rsa?.
> My question is how to add my new source code into the build system?
>
> Thanks in advance!
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>  --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161223/6f9cb5ae/attachment-0001.html>

From James.Bottomley at HansenPartnership.com  Fri Dec 23 18:06:03 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Fri, 23 Dec 2016 10:06:03 -0800
Subject: [openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys
Message-ID: <1482516363.2501.34.camel@HansenPartnership.com>

The reason this comes about is because we already have a standard form
for TPM 1.2 keys here:

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ident-tpm

However, since I'm working on TPM2 enabling for openssl and gnutls, I
need to come up with a new key format because TPM2 requires some extra
parameters and the original TSS KEY BLOB, being a single
ASN1_OCTET_STRING isn't expandable.

As a digression, the extra parameters that TPM2 needs are:

   1. A public key blob. ?In TPM12 the key complex was a joint
      public/private part. ?In TPM2, the public and private key structures
      have variable length and are supplied separately.
   2. a boolean for emptyAuth. ?In TPM12 there's a way to tell if a
      structure has no authorization. ?In TPM2 there's no such thing as no
      authorization, but there's a conventional empty authorization to
      replace it but no way of querying whether any given key is using it,
      so we need to know explicitly whether to prompt for a password or
      not.
   3. There are different forms a TPM private key could be in. ?One is
      symmetrically encrypted with a TPM private key, which makes it
      loadable, meaning it must be produced on the TPM itself and the
      other is asymmetrically encrypted meaning it can be produced away
      from the TPM but must be imported before being loaded.

I think there's value in having a universal structure for the key
representations, so I'm proposing an ASN1 representation that will work
for both TPM1.2 and TPM2 keys.  I'd also like it to be self describing,
so I think we should use an OID as the initial parameter of the
sequence.  With that, I think the format that works is

TPMKey ::= SEQUENCE {
	type		OBJECT IDENTIFIER
	version		[0] IMPLICIT INTEGER OPTIONAL
	emptyAuth	[1] IMPLICIT BOOLEAN OPTIONAL
	parent		[2] IMPLICIT INTEGER OPTIONAL
	publicKey	[3] IMPLICIT OCTET STRING OPTIONAL
	privateKey	OCTET STRING
}

Where TPM12 keys would have a TPM12Key type and use no optional fields
(meaning only privateKey) and TPM2 keys would have type TPM2LoadableKey
or TPM2ImportableKey type and then make use of all the optional fields
(except version).

Version is there for future expansion, but is unused in the initial
incarnation.

I'm torn on where to get the OIDs from.  Since this is a TPM key, it
might make sense to use the TCG OID (2.23.133) and just add something
they haven't already used, like 10 for key formats, or we could go with
a pkcs OID (1.2.840.113549.1)

If we can agree on this, we can update David's document and make it a
formal RFC.

Thoughts?

James


From levitte at openssl.org  Fri Dec 23 20:12:18 2016
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 23 Dec 2016 21:12:18 +0100 (CET)
Subject: [openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2
 keys
In-Reply-To: <1482516363.2501.34.camel@HansenPartnership.com>
References: <1482516363.2501.34.camel@HansenPartnership.com>
Message-ID: <20161223.211218.817856866219152234.levitte@openssl.org>

In message <1482516363.2501.34.camel at HansenPartnership.com> on Fri, 23 Dec 2016 10:06:03 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> The reason this comes about is because we already have a standard form
James.Bottomley> for TPM 1.2 keys here:
James.Bottomley> 
James.Bottomley> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ident-tpm
James.Bottomley> 
James.Bottomley> However, since I'm working on TPM2 enabling for openssl and gnutls, I
James.Bottomley> need to come up with a new key format because TPM2 requires some extra
James.Bottomley> parameters and the original TSS KEY BLOB, being a single
James.Bottomley> ASN1_OCTET_STRING isn't expandable.
James.Bottomley> 
James.Bottomley> As a digression, the extra parameters that TPM2 needs are:
James.Bottomley> 
James.Bottomley>    1. A public key blob. ?In TPM12 the key complex was a joint
James.Bottomley>       public/private part. ?In TPM2, the public and private key structures
James.Bottomley>       have variable length and are supplied separately.
James.Bottomley>    2. a boolean for emptyAuth. ?In TPM12 there's a way to tell if a
James.Bottomley>       structure has no authorization. ?In TPM2 there's no such thing as no
James.Bottomley>       authorization, but there's a conventional empty authorization to
James.Bottomley>       replace it but no way of querying whether any given key is using it,
James.Bottomley>       so we need to know explicitly whether to prompt for a password or
James.Bottomley>       not.
James.Bottomley>    3. There are different forms a TPM private key could be in. ?One is
James.Bottomley>       symmetrically encrypted with a TPM private key, which makes it
James.Bottomley>       loadable, meaning it must be produced on the TPM itself and the
James.Bottomley>       other is asymmetrically encrypted meaning it can be produced away
James.Bottomley>       from the TPM but must be imported before being loaded.
James.Bottomley> 
James.Bottomley> I think there's value in having a universal structure for the key
James.Bottomley> representations, so I'm proposing an ASN1 representation that will work
James.Bottomley> for both TPM1.2 and TPM2 keys.  I'd also like it to be self describing,
James.Bottomley> so I think we should use an OID as the initial parameter of the
James.Bottomley> sequence.  With that, I think the format that works is
James.Bottomley> 
James.Bottomley> TPMKey ::= SEQUENCE {
James.Bottomley> 	type		OBJECT IDENTIFIER
James.Bottomley> 	version		[0] IMPLICIT INTEGER OPTIONAL
James.Bottomley> 	emptyAuth	[1] IMPLICIT BOOLEAN OPTIONAL
James.Bottomley> 	parent		[2] IMPLICIT INTEGER OPTIONAL
James.Bottomley> 	publicKey	[3] IMPLICIT OCTET STRING OPTIONAL
James.Bottomley> 	privateKey	OCTET STRING
James.Bottomley> }
James.Bottomley> 
James.Bottomley> Where TPM12 keys would have a TPM12Key type and use no optional fields
James.Bottomley> (meaning only privateKey) and TPM2 keys would have type TPM2LoadableKey
James.Bottomley> or TPM2ImportableKey type and then make use of all the optional fields
James.Bottomley> (except version).
James.Bottomley> 
James.Bottomley> Version is there for future expansion, but is unused in the initial
James.Bottomley> incarnation.
James.Bottomley> 
James.Bottomley> I'm torn on where to get the OIDs from.  Since this is a TPM key, it
James.Bottomley> might make sense to use the TCG OID (2.23.133) and just add something
James.Bottomley> they haven't already used, like 10 for key formats, or we could go with
James.Bottomley> a pkcs OID (1.2.840.113549.1)
James.Bottomley> 
James.Bottomley> If we can agree on this, we can update David's document and make it a
James.Bottomley> formal RFC.
James.Bottomley> 
James.Bottomley> Thoughts?

First reaction is +1, at least for actually making a universally
parsable description.

One detail that escapes me, though, is why you don't use version for,
well, TPM versions?  So, something like this?

TCG OBJECT IDENTIFIER ::=
	{ joint-iso-itu-t(2) international-organizations(23) TCG(133)  }

TPMKey ::= SEQUENCE {
       type        OBJECT IDENTIFIER	-- always TCG
       version     [0] INTEGER { v1_2(0), v2(1) } DEFAULT v1_2
       emptyAuth   [1] IMPLICIT BOOLEAN OPTIONAL	-- v2 only
       parent      [2] IMPLICIT INTEGER OPTIONAL	-- v2 only
       publicKey   [3] IMPLICIT OCTET STRING OPTIONAL	-- v2 only
       privateKey  OCTET STRING
}

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From James.Bottomley at HansenPartnership.com  Fri Dec 23 20:22:35 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Fri, 23 Dec 2016 12:22:35 -0800
Subject: [openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2
 keys
In-Reply-To: <20161223.211218.817856866219152234.levitte@openssl.org>
References: <1482516363.2501.34.camel@HansenPartnership.com>
 <20161223.211218.817856866219152234.levitte@openssl.org>
Message-ID: <1482524555.2501.59.camel@HansenPartnership.com>

On Fri, 2016-12-23 at 21:12 +0100, Richard Levitte wrote:
> In message <1482516363.2501.34.camel at HansenPartnership.com> on Fri,
> 23 Dec 2016 10:06:03 -0800, James Bottomley <
> James.Bottomley at HansenPartnership.com> said:
> 
> James.Bottomley> The reason this comes about is because we already
> have a standard form
> James.Bottomley> for TPM 1.2 keys here:
> James.Bottomley> 
> James.Bottomley> http://david.woodhou.se/draft-woodhouse-cert-best-pr
> actice.html#ident-tpm
> James.Bottomley> 
> James.Bottomley> However, since I'm working on TPM2 enabling for
> openssl and gnutls, I
> James.Bottomley> need to come up with a new key format because TPM2
> requires some extra
> James.Bottomley> parameters and the original TSS KEY BLOB, being a
> single
> James.Bottomley> ASN1_OCTET_STRING isn't expandable.
> James.Bottomley> 
> James.Bottomley> As a digression, the extra parameters that TPM2
> needs are:
> James.Bottomley> 
> James.Bottomley>    1. A public key blob.  In TPM12 the key complex
> was a joint
> James.Bottomley>       public/private part.  In TPM2, the public and
> private key structures
> James.Bottomley>       have variable length and are supplied
> separately.
> James.Bottomley>    2. a boolean for emptyAuth.  In TPM12 there's a
> way to tell if a
> James.Bottomley>       structure has no authorization.  In TPM2
> there's no such thing as no
> James.Bottomley>       authorization, but there's a conventional
> empty authorization to
> James.Bottomley>       replace it but no way of querying whether any
> given key is using it,
> James.Bottomley>       so we need to know explicitly whether to
> prompt for a password or
> James.Bottomley>       not.
> James.Bottomley>    3. There are different forms a TPM private key
> could be in.  One is
> James.Bottomley>       symmetrically encrypted with a TPM private
> key, which makes it
> James.Bottomley>       loadable, meaning it must be produced on the
> TPM itself and the
> James.Bottomley>       other is asymmetrically encrypted meaning it
> can be produced away
> James.Bottomley>       from the TPM but must be imported before being
> loaded.
> James.Bottomley> 
> James.Bottomley> I think there's value in having a universal
> structure for the key
> James.Bottomley> representations, so I'm proposing an ASN1
> representation that will work
> James.Bottomley> for both TPM1.2 and TPM2 keys.  I'd also like it to
> be self describing,
> James.Bottomley> so I think we should use an OID as the initial
> parameter of the
> James.Bottomley> sequence.  With that, I think the format that works
> is
> James.Bottomley> 
> James.Bottomley> TPMKey ::= SEQUENCE {
> James.Bottomley>        type            OBJECT IDENTIFIER
> James.Bottomley>        version         [0] IMPLICIT INTEGER OPTIONAL
> James.Bottomley>        emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
> James.Bottomley>        parent          [2] IMPLICIT INTEGER OPTIONAL
> James.Bottomley>        publicKey       [3] IMPLICIT OCTET STRING
> OPTIONAL
> James.Bottomley>        privateKey      OCTET STRING
> James.Bottomley> }
> James.Bottomley> 
> James.Bottomley> Where TPM12 keys would have a TPM12Key type and use
> no optional fields
> James.Bottomley> (meaning only privateKey) and TPM2 keys would have
> type TPM2LoadableKey
> James.Bottomley> or TPM2ImportableKey type and then make use of all
> the optional fields
> James.Bottomley> (except version).
> James.Bottomley> 
> James.Bottomley> Version is there for future expansion, but is unused
> in the initial
> James.Bottomley> incarnation.
> James.Bottomley> 
> James.Bottomley> I'm torn on where to get the OIDs from.  Since this
> is a TPM key, it
> James.Bottomley> might make sense to use the TCG OID (2.23.133) and
> just add something
> James.Bottomley> they haven't already used, like 10 for key formats,
> or we could go with
> James.Bottomley> a pkcs OID (1.2.840.113549.1)
> James.Bottomley> 
> James.Bottomley> If we can agree on this, we can update David's
> document and make it a
> James.Bottomley> formal RFC.
> James.Bottomley> 
> James.Bottomley> Thoughts?
> 
> First reaction is +1, at least for actually making a universally
> parsable description.

Thanks.  After playing more I think I'd like to make the tags explicit
rather than implicit so I can see the contents easily with asn1parse
(and we're not in any way pressed for space, which is the usual reason
for implicit tags).

> One detail that escapes me, though, is why you don't use version for,
> well, TPM versions?  So, something like this?
> 
> TCG OBJECT IDENTIFIER ::=
>         { joint-iso-itu-t(2) international-organizations(23) TCG(133)
>   }

Because what OID to use is part of the discussion.  Perhaps I wasn't
clear about what I want: the OID needs to identify what the structure
describes, so one OID for each of the three key types, so it would have
a prefix either in the TCG or pkcs space (or something else if that's
what we agree), then three OID postfixes.

> TPMKey ::= SEQUENCE {
>        type        OBJECT IDENTIFIER    -- always TCG
>        version     [0] INTEGER { v1_2(0), v2(1) } DEFAULT v1_2

Version, I'm envisaging is for expansion of the structure in a
compatible way.  For TPM2 keys, I think we're going to need additional
policy descriptors eventually when people start using a policy to
authorise instead of an authorisation value.  We'd use the version
number to indicate a future expanded structure.

So the OID identifies the object structure and version is for
versioning the actual structure.

James

>        emptyAuth   [1] IMPLICIT BOOLEAN OPTIONAL        -- v2 only
>        parent      [2] IMPLICIT INTEGER OPTIONAL        -- v2 only
>        publicKey   [3] IMPLICIT OCTET STRING OPTIONAL   -- v2 only
>        privateKey  OCTET STRING
> }
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> 


From James.Bottomley at HansenPartnership.com  Sat Dec 24 16:13:50 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Sat, 24 Dec 2016 08:13:50 -0800
Subject: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of
 TPM1.2 and TPM2 keys
In-Reply-To: <CAJU7zaKjXhKJ-3PJD6XrLW2hTixEqL0B56epbqG3trw3jmXjVg@mail.gmail.com>
References: <1482516363.2501.34.camel@HansenPartnership.com>
 <CAJU7zaKjXhKJ-3PJD6XrLW2hTixEqL0B56epbqG3trw3jmXjVg@mail.gmail.com>
Message-ID: <1482596030.2316.4.camel@HansenPartnership.com>

On Sat, 2016-12-24 at 14:25 +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, Dec 23, 2016 at 7:06 PM, James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> > The reason this comes about is because we already have a standard 
> > form for TPM 1.2 keys here:
> > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ide
> > nt-tpm
> > However, since I'm working on TPM2 enabling for openssl and gnutls, 
> > I need to come up with a new key format because TPM2 requires some
> > extra parameters and the original TSS KEY BLOB, being a single
> > ASN1_OCTET_STRING isn't expandable.
> [...]
> > I'm torn on where to get the OIDs from.  Since this is a TPM key, 
> > it might make sense to use the TCG OID (2.23.133) and just add
> > something they haven't already used, like 10 for key formats, or we 
> > could go with a pkcs OID (1.2.840.113549.1)
> 
> OIDs under some umbrella normally need to be registered within the
> organization they belong to. If you cannot find a suitable
> organization to get these OIDs from I'll check whether we can get
> something under redhat's OIDs.

I think, since it's a key format, the two above are the potential ones.
 It would be TCG if they want to take it into their standard, otherwise
PKCS is RSA Inc.

> > If we can agree on this, we can update David's document and make it 
> > a formal RFC.
> 
> Shouldn't version be first?

I put OID first because that's what makes the structure self
describing.  You simply need to look for the SEQUENCE OBJECT OID
prefix.  We can easily register our own, of course as well.  If version
goes first, you have a variable prefix.

>  However, I'm not sure how expandable is ASN.1 using version fields 
> (I've seen no structure being able to be re-used using a different 
> version). An alternative approach would to allow for future 
> extensions, i.e., something like the PKIX Extension field, which is
> an OID+data.

As long as the expansion fields are optional, it works nicely.  X509
and X509v3 are examples of version expanded ASN.1

James


From James.Bottomley at HansenPartnership.com  Sun Dec 25 18:44:51 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Sun, 25 Dec 2016 10:44:51 -0800
Subject: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of
 TPM1.2 and TPM2 keys
In-Reply-To: <CAJU7za+PdjfKqtrEoJMhUK6Mm9Hsa98G8RGNRx-qMFwenMG9yg@mail.gmail.com>
References: <1482516363.2501.34.camel@HansenPartnership.com>
 <CAJU7zaKjXhKJ-3PJD6XrLW2hTixEqL0B56epbqG3trw3jmXjVg@mail.gmail.com>
 <1482596030.2316.4.camel@HansenPartnership.com>
 <CAJU7za+PdjfKqtrEoJMhUK6Mm9Hsa98G8RGNRx-qMFwenMG9yg@mail.gmail.com>
Message-ID: <1482691491.3394.8.camel@HansenPartnership.com>

On Sun, 2016-12-25 at 10:18 +0100, Nikos Mavrogiannopoulos wrote:
> On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> 
> > I think, since it's a key format, the two above are the potential 
> > ones.  It would be TCG if they want to take it into their standard,
> > otherwise PKCS is RSA Inc.
> 
> I wouldn't expect RSA inc to be involved into this as part of PKCS.
> They are dead long time ago and have moved to IETF.

I think I should give TCG first crack at wanting to own the OID.  The
IETF ones are easy: once you codify it in an RFC, the oid registry auto
extracts it.

> > >  However, I'm not sure how expandable is ASN.1 using version
> > > fields (I've seen no structure being able to be re-used using a
> > > different version). An alternative approach would to allow for 
> > > future extensions, i.e., something like the PKIX Extension field, 
> > > which is an OID+data.
> > 
> > As long as the expansion fields are optional, it works nicely. 
> >  X509 and X509v3 are examples of version expanded ASN.1
> 
> Only if they are defined in the structure early. Otherwise the early
> versions of the implementations wouldn't cope with extensions. To 
> make it early extendable you'd have to use something lilke
>  
> TPMKey ::= SEQUENCE {
>         type            OBJECT IDENTIFIER
>         version         [0] IMPLICIT INTEGER OPTIONAL
>         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
>         parent          [2] IMPLICIT INTEGER OPTIONAL
>         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
>         privateKey      OCTET STRING
>          extensions      [4]  EXPLICIT Extensions OPTIONAL
> }

Actually, that's the utility of ASN.1, once you use tagging, you don't
have to do this.  The structure above is identical to:

TPMKey ::= SEQUENCE {
        type            OBJECT IDENTIFIER
        version         [0] IMPLICIT INTEGER OPTIONAL
        emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
        parent          [2] IMPLICIT INTEGER OPTIONAL
        publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
        privateKey      OCTET STRING
 }

If tag 4 isn't present because optional tags are not coded when not
present, so you can expand any ASN.1 structure as long as you have a
clue from the version number that you should be looking for the
optional extras.  The point being I don't have to specify the expansion
now, I can wait until we need it.

I'm pretty certain the next expansion is actually SEQUENCE OF
TPM2Policy but I'm still playing with the format.

James


From James.Bottomley at HansenPartnership.com  Sun Dec 25 23:47:32 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Sun, 25 Dec 2016 15:47:32 -0800
Subject: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of
 TPM1.2 and TPM2 keys
In-Reply-To: <CAJU7zaL2WGnBgCnx_EQ7wNnaYpaUK8BfbX40Gm85zamnFYfhgA@mail.gmail.com>
References: <1482516363.2501.34.camel@HansenPartnership.com>
 <CAJU7zaKjXhKJ-3PJD6XrLW2hTixEqL0B56epbqG3trw3jmXjVg@mail.gmail.com>
 <1482596030.2316.4.camel@HansenPartnership.com>
 <CAJU7za+PdjfKqtrEoJMhUK6Mm9Hsa98G8RGNRx-qMFwenMG9yg@mail.gmail.com>
 <1482691491.3394.8.camel@HansenPartnership.com>
 <CAJU7zaL2WGnBgCnx_EQ7wNnaYpaUK8BfbX40Gm85zamnFYfhgA@mail.gmail.com>
Message-ID: <1482709652.3394.15.camel@HansenPartnership.com>

On Sun, 2016-12-25 at 22:08 +0100, Nikos Mavrogiannopoulos wrote:
> On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> > > TPMKey ::= SEQUENCE {
> > >         type            OBJECT IDENTIFIER
> > >         version         [0] IMPLICIT INTEGER OPTIONAL
> > >         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
> > >         parent          [2] IMPLICIT INTEGER OPTIONAL
> > >         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
> > >         privateKey      OCTET STRING
> > >          extensions      [4]  EXPLICIT Extensions OPTIONAL
> > > }
> > 
> > Actually, that's the utility of ASN.1, once you use tagging, you 
> > don't have to do this.  The structure above is identical to:
> > 
> > TPMKey ::= SEQUENCE {
> >         type            OBJECT IDENTIFIER
> >         version         [0] IMPLICIT INTEGER OPTIONAL
> >         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
> >         parent          [2] IMPLICIT INTEGER OPTIONAL
> >         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
> >         privateKey      OCTET STRING
> >  }
> > 
> > If tag 4 isn't present because optional tags are not coded when not
> > present, so you can expand any ASN.1 structure as long as you have 
> > a clue from the version number that you should be looking for the
> > optional extras.  The point being I don't have to specify the 
> > expansion now, I can wait until we need it.
> 
> How would that work for example if you want to add an additional 
> field with information on the type of the key for example (key 
> usage)? You would add the tag 4 as you say, and then all the previous 
> parsers written with the initial description will fail parsing the 
> new structure. X.509 (==PKIX) is only expandable via the extensions 
> field which is already defined. If you add a field to it, no parser 
> would be able to read the certificate.

Um, well, you only want backwards compatibility, you don't really want
forward compatibility.  Assuming something extends the structure and
adds version v2, why would it matter that an old v1 application can't
read a v2 structure because it doesn't understand the tag 4?  Even if
it could it can't make use of the extra fields and something nasty will
happen.  What you want is that the new v2 application can parse both
the v2 structure and the old v1 one, but it's advantageous that a v1
application fails with a v2 structure because it prevents cockups.

James


From James.Bottomley at HansenPartnership.com  Mon Dec 26 18:13:40 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Mon, 26 Dec 2016 10:13:40 -0800
Subject: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of
 TPM1.2 and TPM2 keys
In-Reply-To: <F37418F5-0ECC-4F8B-981A-2ED74FAADA51@gmail.com>
References: <1482516363.2501.34.camel@HansenPartnership.com>
 <CAJU7zaKjXhKJ-3PJD6XrLW2hTixEqL0B56epbqG3trw3jmXjVg@mail.gmail.com>
 <1482596030.2316.4.camel@HansenPartnership.com>
 <CAJU7za+PdjfKqtrEoJMhUK6Mm9Hsa98G8RGNRx-qMFwenMG9yg@mail.gmail.com>
 <1482691491.3394.8.camel@HansenPartnership.com>
 <CAJU7zaL2WGnBgCnx_EQ7wNnaYpaUK8BfbX40Gm85zamnFYfhgA@mail.gmail.com>
 <1482709652.3394.15.camel@HansenPartnership.com>
 <F37418F5-0ECC-4F8B-981A-2ED74FAADA51@gmail.com>
Message-ID: <1482776020.2430.19.camel@HansenPartnership.com>

On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote:
> I'd like both backwards and forward compatibility actually, exactly
> like x509. If an informational field is added like the key usage that
> I mentioned, I doubt you'd like all the previous consumers
> incompatible.

OK, so there's a fundamental difference between a v3 X509 certificate
and a TPM key: An X509 certificate is a signature over a set of v1 TBS
data, a public key and a bundle of attributes.  To verify the
certificate or extract the key, you don't need to know what the
attributes are, so you can still "use" the certificate in that form. 
 However, you can't get the v1 tool to obey the v3 constraints on the
certificate because it doesn't understand them.

The ASN.1 description of a TPM key contains the actual binary
representation of the key plus a set of information which explains to
the consuming code how to use the key.  Since I can't think of a way of
making use of the key without understanding all of the information
about how to use it, I think it is beneficial that v1 consumers don't
try to use v2 key information because the resulting failure will excite
the TPM's dictionary attack protection.

I gave an example of one such extension: policy authorisations, but
they're definitely of the "if you don't understand these, you can't use
the key" variety.  Perhaps if you can give an example of a potentially
compatible extensions it would help me to see your point and give us a
means of moving forwards.

Thanks,

James

>  For other extensions which make the structure totally incompatible
> you can use the critical flag. Anyway even the original struct is OK,
> it is exactly like any other key structs we have.


From Erwann.Abalea at docusign.com  Tue Dec 27 15:35:45 2016
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Tue, 27 Dec 2016 15:35:45 +0000
Subject: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of
 TPM1.2 and TPM2 keys
In-Reply-To: <1482691491.3394.8.camel@HansenPartnership.com>
References: <1482516363.2501.34.camel@HansenPartnership.com>
 <CAJU7zaKjXhKJ-3PJD6XrLW2hTixEqL0B56epbqG3trw3jmXjVg@mail.gmail.com>
 <1482596030.2316.4.camel@HansenPartnership.com>
 <CAJU7za+PdjfKqtrEoJMhUK6Mm9Hsa98G8RGNRx-qMFwenMG9yg@mail.gmail.com>
 <1482691491.3394.8.camel@HansenPartnership.com>
Message-ID: <230FF510-B616-4D1F-8CC5-5F2877A1FFB4@docusign.com>

Bonjour,

> Le 25 d?c. 2016 ? 19:44, James Bottomley <James.Bottomley at HansenPartnership.com> a ?crit :
> 
> On Sun, 2016-12-25 at 10:18 +0100, Nikos Mavrogiannopoulos wrote:
>> On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley
>> <James.Bottomley at hansenpartnership.com> wrote:
>> 
>>> I think, since it's a key format, the two above are the potential 
>>> ones.  It would be TCG if they want to take it into their standard,
>>> otherwise PKCS is RSA Inc.
>> 
>> I wouldn't expect RSA inc to be involved into this as part of PKCS.
>> They are dead long time ago and have moved to IETF.
> 
> I think I should give TCG first crack at wanting to own the OID.  The
> IETF ones are easy: once you codify it in an RFC, the oid registry auto
> extracts it.

Which OID registry are you talking about?

>>>> However, I'm not sure how expandable is ASN.1 using version
>>>> fields (I've seen no structure being able to be re-used using a
>>>> different version). An alternative approach would to allow for 
>>>> future extensions, i.e., something like the PKIX Extension field, 
>>>> which is an OID+data.
>>> 
>>> As long as the expansion fields are optional, it works nicely. 
>>> X509 and X509v3 are examples of version expanded ASN.1
>> 
>> Only if they are defined in the structure early. Otherwise the early
>> versions of the implementations wouldn't cope with extensions. To 
>> make it early extendable you'd have to use something lilke
>> 
>> TPMKey ::= SEQUENCE {
>>        type            OBJECT IDENTIFIER
>>        version         [0] IMPLICIT INTEGER OPTIONAL
>>        emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
>>        parent          [2] IMPLICIT INTEGER OPTIONAL
>>        publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
>>        privateKey      OCTET STRING
>>         extensions      [4]  EXPLICIT Extensions OPTIONAL
>> }
> 
> Actually, that's the utility of ASN.1, once you use tagging, you don't
> have to do this.  The structure above is identical to:
> 
> TPMKey ::= SEQUENCE {
>        type            OBJECT IDENTIFIER
>        version         [0] IMPLICIT INTEGER OPTIONAL
>        emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
>        parent          [2] IMPLICIT INTEGER OPTIONAL
>        publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
>        privateKey      OCTET STRING
> }

These structures can be considered identical if and only if one the following conditions is true:
 - they?re defined in a module declared with ? EXTENSIBILITY IMPLIED ?
 - they both include the extensibility marker (i.e. they?re slightly modified)

If you plan to use BER, CER or DER (and only these), then the parser MUST ignore the extensibility markers (present or not), and work as if they?re present. But that won?t change the ASN.1 definition, only the decoder behaviour.

Cordialement,
Erwann Abalea


From matt at openssl.org  Wed Dec 28 10:28:57 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 28 Dec 2016 10:28:57 +0000
Subject: [openssl-dev] backporting CVE-2016-8610 fix to 1.0.1 branch
In-Reply-To: <E5635C9F-BE67-428C-A8D6-69BA3CBBEE54@symantec.com>
References: <E5635C9F-BE67-428C-A8D6-69BA3CBBEE54@symantec.com>
Message-ID: <b4c0ff3a-748e-2653-9f05-8a70816cd37d@openssl.org>



On 17/12/16 01:59, Peter Djalaliev (CS) wrote:
> Hello,
> 
>  
> 
> Will commit
> 
>  
> 
> Don't allow too many consecutive warning alerts
> 
>  
> 
> author   Matt Caswell <matt at openssl.org>              
> 
>                 Wed, 21 Sep 2016 08:07:31 -0500 (14:07 +0100)
> 
> committer            Matt Caswell <matt at openssl.org>              
> 
>                 Wed, 21 Sep 2016 14:17:04 -0500 (20:17 +0100)
> 
> commit  af58be768ebb690f78530f796e92b8ae5c9a4401
> 
> tree        087701bd731382d1933438bcd73cb7029264e16b
> 
> parent   7dc0ad4d6dca81a003be7fa1fbd58a55f4be8646
> 
>  
> 
> be backported to 1.0.1? This has been assigned CVE-2016-8610. I
> understand that OpenSSL 1.0.1 is going EOL on Dec 31.

I've been asked this a few times. CVE-2016-8610 was not issued by the
OpenSSL Project and is not recognised as a security issue by us (it does
not appear in any OpenSSL Security Advisory). The referenced commit is
viewed as a bug fix and for that reason will not be backported to 1.0.1
(the 1.0.1 series only receives security fixes).

Matt


From James.Bottomley at HansenPartnership.com  Thu Dec 29 23:57:17 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 29 Dec 2016 15:57:17 -0800
Subject: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of
 TPM1.2 and TPM2 keys
In-Reply-To: <671CBF50-E114-4FD1-995A-523C7B63F8D5@gmail.com>
References: <1482516363.2501.34.camel@HansenPartnership.com>
 <CAJU7zaKjXhKJ-3PJD6XrLW2hTixEqL0B56epbqG3trw3jmXjVg@mail.gmail.com>
 <1482596030.2316.4.camel@HansenPartnership.com>
 <CAJU7za+PdjfKqtrEoJMhUK6Mm9Hsa98G8RGNRx-qMFwenMG9yg@mail.gmail.com>
 <1482691491.3394.8.camel@HansenPartnership.com>
 <CAJU7zaL2WGnBgCnx_EQ7wNnaYpaUK8BfbX40Gm85zamnFYfhgA@mail.gmail.com>
 <1482709652.3394.15.camel@HansenPartnership.com>
 <F37418F5-0ECC-4F8B-981A-2ED74FAADA51@gmail.com>
 <1482776020.2430.19.camel@HansenPartnership.com>
 <671CBF50-E114-4FD1-995A-523C7B63F8D5@gmail.com>
Message-ID: <1483055837.2561.51.camel@HansenPartnership.com>

On Mon, 2016-12-26 at 21:13 +0100, Nikos Mavrogianopoulos wrote:
> My comment was on the claim of extendability of the format which as I
> explained it is simply not true. As for example I already gave the
> key usage extension. I am fine however with a non extendable format
> as you proposed. 

OK, so I think the version is now superfluous, since if anything gets
added it can be recognised by the tag and things not ready to parse
that tag can reject it.

That makes the final form

 TPMKey ::= SEQUENCE {
	type		OBJECT IDENTIFIER
	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL
	parent		[1] EXPLICIT INTEGER OPTIONAL
	pubkey		[2] EXPLICIT OCTET STRING OPTIONAL
	privkey		OCTET STRING
 }

I'll code the v2 patch using this form.

James

> On December 26, 2016 7:13:40 PM GMT+01:00, James Bottomley <
> James.Bottomley at HansenPartnership.com> wrote:
> > On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote:
> > > I'd like both backwards and forward compatibility actually,
> > > exactly
> > > like x509. If an informational field is added like the key usage
> > > that
> > > I mentioned, I doubt you'd like all the previous consumers
> > > incompatible.
> > 
> > OK, so there's a fundamental difference between a v3 X509
> > certificate
> > and a TPM key: An X509 certificate is a signature over a set of v1
> > TBS
> > data, a public key and a bundle of attributes.  To verify the
> > certificate or extract the key, you don't need to know what the
> > attributes are, so you can still "use" the certificate in that
> > form. 
> > However, you can't get the v1 tool to obey the v3 constraints on
> > the
> > certificate because it doesn't understand them.
> > 
> > The ASN.1 description of a TPM key contains the actual binary
> > representation of the key plus a set of information which explains
> > to
> > the consuming code how to use the key.  Since I can't think of a
> > way of
> > making use of the key without understanding all of the information
> > about how to use it, I think it is beneficial that v1 consumers
> > don't
> > try to use v2 key information because the resulting failure will
> > excite
> > the TPM's dictionary attack protection.
> > 
> > I gave an example of one such extension: policy authorisations, but
> > they're definitely of the "if you don't understand these, you can't
> > use
> > the key" variety.  Perhaps if you can give an example of a
> > potentially
> > compatible extensions it would help me to see your point and give
> > us a
> > means of moving forwards.
> > 
> > Thanks,
> > 
> > James
> > 
> > >  For other extensions which make the structure totally
> > > incompatible
> > > you can use the critical flag. Anyway even the original struct is
> > > OK,
> > > it is exactly like any other key structs we have.
> 


From rschm2 at unh.newhaven.edu  Fri Dec 30 02:36:45 2016
From: rschm2 at unh.newhaven.edu (Schmicker, Robert)
Date: Fri, 30 Dec 2016 02:36:45 +0000
Subject: [openssl-dev] Linker error when adding new cipher in crypto folder
Message-ID: <B5AC3FBD-33F9-4377-AEB3-E2671DE0926F@unh.newhaven.edu>

Hello,

I am attempting to add a new cipher into the crypto library. I have done the following so far?

1. Added my code to the openssl/crypto folder
2. Created a build.info<http://build.info> for make to compile my code (created this based off of openssl/crypto/dh?s build.info<http://build.info>)
3. Added my cipher name to the list of ciphers to compile in Configure
4. Compiled and installed all code without errors and object files for my new cipher are created in openssl/crypto/mycipher/
5. Created a test.c file that verifies that the library is installed and working properly by generating a MD5 hash of a string
Compiled as:
gcc test.c -I/usr/local/openssl/include/openssl/ -o test -lcrypto -lssl -Wall
6. I am able to properly include <openssl/mycipher.h> in my test.c file

However, as soon as I make a call to my cipher in test.c I get a linker error and gcc is unable to find any of my functions.

It seems that the header file I have in the openssl/include folder isn?t being linked somehow to my code in the openssl/cypto folder.

I feel like I?m missing a step here?

Any help is much appreciated!

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161230/c470e947/attachment.html>

From openssl-users at dukhovni.org  Fri Dec 30 06:31:05 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 30 Dec 2016 01:31:05 -0500
Subject: [openssl-dev] Linker error when adding new cipher in crypto
 folder
In-Reply-To: <B5AC3FBD-33F9-4377-AEB3-E2671DE0926F@unh.newhaven.edu>
References: <B5AC3FBD-33F9-4377-AEB3-E2671DE0926F@unh.newhaven.edu>
Message-ID: <1D776DB4-7A38-4C27-A668-3AD19979FFF4@dukhovni.org>


> On Dec 29, 2016, at 9:36 PM, Schmicker, Robert <rschm2 at unh.newhaven.edu> wrote:
> 
> However, as soon as I make a call to my cipher in test.c I get a linker error and gcc is unable to find any of my functions.

Edit util/libcrypto.num and/or util/libssl.num, only the symbols listed there
are exported by the library shared objects.

-- 
	Viktor.


From levitte at openssl.org  Fri Dec 30 12:47:40 2016
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 30 Dec 2016 13:47:40 +0100 (CET)
Subject: [openssl-dev] Linker error when adding new cipher in crypto
 folder
In-Reply-To: <B5AC3FBD-33F9-4377-AEB3-E2671DE0926F@unh.newhaven.edu>
References: <B5AC3FBD-33F9-4377-AEB3-E2671DE0926F@unh.newhaven.edu>
Message-ID: <20161230.134740.815359569639060966.levitte@openssl.org>

In message <B5AC3FBD-33F9-4377-AEB3-E2671DE0926F at unh.newhaven.edu> on Fri, 30 Dec 2016 02:36:45 +0000, "Schmicker, Robert" <rschm2 at unh.newhaven.edu> said:

rschm2> Hello,
rschm2> 
rschm2> I am attempting to add a new cipher into the crypto library. I have
rschm2> done the following so far?
rschm2> 
rschm2> 1. Added my code to the openssl/crypto folder
rschm2> 2. Created a build.info for make to compile my code (created this
rschm2> based off of openssl/crypto/dh?s build.info)
rschm2> 3. Added my cipher name to the list of ciphers to compile in Configure
rschm2> 4. Compiled and installed all code without errors and object files for
rschm2> my new cipher are created in openssl/crypto/mycipher/
rschm2> 5. Created a test.c file that verifies that the library is installed
rschm2> and working properly by generating a MD5 hash of a string
rschm2> Compiled as:
rschm2> gcc test.c -I/usr/local/openssl/include/openssl/ -o test -lcrypto -
rschm2> lssl -Wall
rschm2> 6. I am able to properly include <openssl/mycipher.h> in my test.c
rschm2> file
rschm2> 
rschm2> However, as soon as I make a call to my cipher in test.c I get a
rschm2> linker error and gcc is unable to find any of my functions.
rschm2> 
rschm2> It seems that the header file I have in the openssl/include folder
rschm2> isn?t being linked somehow to my code in the openssl/cypto folder.
rschm2> 
rschm2> I feel like I?m missing a step here?
rschm2> 
rschm2> Any help is much appreciated!

On way is to, as already mentioned, edit util/libcrypto.num.  The
other is to edit util/mkdef.pl and then run 'make update'.  In
mkdef.pl, you'll find a bunch of lines like this:

    $crypto.="include/openssl/whatever.h"

Simply add a line like that for mycipher.h.

(note: mkdef.pl might be a bit picky sometimes)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From James.Bottomley at HansenPartnership.com  Sat Dec 31 22:48:05 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Sat, 31 Dec 2016 14:48:05 -0800
Subject: [openssl-dev] [PATCH 0/1] TPM2 engine support for openssl
Message-ID: <1483224485.2518.20.camel@HansenPartnership.com>

This is a completed version of the original RFC.  It's working now both
on the TPM2 simulator and on real hardware (I've converted my laptop to
TPM2).  I've updated it to use the latest version of the ASN.1 for the
key format (still using a TCG OID).

I have it building here (it's what I'm currently using for my laptop
VPNs):

https://build.opensuse.org/package/show/home:jejb1:Tumbleweed/openssl_tpm_engine

But note that this version also has experimental patches to activate
the in-kernel TPM Resource Manager because for multiple applications
TPM2 really doesn't work well without one.  Since the patch for the RM
is currently not upstream (yet), it's not going to work unless you have
a patched kernel.

James

---

James Bottomley (1):
  add TPM2 version of create_tpm2_key and libtpm2.so engine

 Makefile.am       |  12 +-
 create_tpm2_key.c | 451 +++++++++++++++++++++++++++++++++++++++++++
 e_tpm2.c          | 559 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tpm2-asn.h        |  59 ++++++
 tpm2-common.c     | 175 +++++++++++++++++
 tpm2-common.h     |  10 +
 6 files changed, 1264 insertions(+), 2 deletions(-)
 create mode 100644 create_tpm2_key.c
 create mode 100644 e_tpm2.c
 create mode 100644 tpm2-asn.h
 create mode 100644 tpm2-common.c
 create mode 100644 tpm2-common.h

-- 
2.6.6


From James.Bottomley at HansenPartnership.com  Sat Dec 31 22:52:43 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Sat, 31 Dec 2016 14:52:43 -0800
Subject: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and
 libtpm2.so engine
In-Reply-To: <1483224485.2518.20.camel@HansenPartnership.com>
References: <1483224485.2518.20.camel@HansenPartnership.com>
Message-ID: <1483224763.2518.24.camel@HansenPartnership.com>

This patch adds RSA signing for TPM2 keys.  There's a limitation to the
way TPM2 does signing: it must recognise the OID for the signature. 
 That fails for the MD5-SHA1 signatures of the TLS/SSL certificate
verification protocol, so I'm using RSA_Decrypt for both signing
(encryption) and decryption ... meaning that this only works with TPM
decryption keys.  It is possible to use the prior code, which preserved
the distinction of signing and decryption keys, but only at the expense
of not being able to support SSL or TLS lower than 1.2

Signed-off-by: James Bottomley <James.Bottomley at HansenPartnership.com>

---
v2: - use TPM2_RSA_Decrypt for both decryption and signing operations
    - Add authority processing
    - Add TPM internal key creation
    - allow persistent parents
    - update to use transient connections to the TPM
---
 Makefile.am       |  12 +-
 create_tpm2_key.c | 451 +++++++++++++++++++++++++++++++++++++++++++
 e_tpm2.c          | 559 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tpm2-asn.h        |  59 ++++++
 tpm2-common.c     | 175 +++++++++++++++++
 tpm2-common.h     |  10 +
 6 files changed, 1264 insertions(+), 2 deletions(-)
 create mode 100644 create_tpm2_key.c
 create mode 100644 e_tpm2.c
 create mode 100644 tpm2-asn.h
 create mode 100644 tpm2-common.c
 create mode 100644 tpm2-common.h

diff --git a/Makefile.am b/Makefile.am
index 6695656..fb4f529 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,12 +2,20 @@ SUBDIRS=. test
 
 EXTRA_DIST = README  openssl.cnf.sample
 
-openssl_engine_LTLIBRARIES=libtpm.la
-bin_PROGRAMS=create_tpm_key
+openssl_engine_LTLIBRARIES=libtpm.la libtpm2.la
+bin_PROGRAMS=create_tpm_key create_tpm2_key
 openssl_enginedir=@libdir@/openssl/engines
 
 libtpm_la_LIBADD=-lcrypto -lc -ltspi
 libtpm_la_SOURCES=e_tpm.c e_tpm.h e_tpm_err.c
 
+libtpm2_la_LIBADD=-lcrypto -lc -ltss
+libtpm2_la_SOURCES=e_tpm2.c tpm2-common.c
+libtpm2_la_CFLAGS=-g -Werror
+
 create_tpm_key_SOURCES=create_tpm_key.c
 create_tpm_key_LDADD=-ltspi
+
+create_tpm2_key_SOURCES=create_tpm2_key.c tpm2-common.c
+create_tpm2_key_LDADD=-lcrypto -ltss
+create_tpm2_key_CFLAGS=-Werror
diff --git a/create_tpm2_key.c b/create_tpm2_key.c
new file mode 100644
index 0000000..ca3b38f
--- /dev/null
+++ b/create_tpm2_key.c
@@ -0,0 +1,451 @@
+/*
+ *
+ *   Copyright (C) 2016 James Bottomley <James.Bottomley at HansenPartnership.com>
+ *
+ *   GPLv2
+ */
+
+
+#include <stdio.h>
+#include <getopt.h>
+#include <string.h>
+#include <strings.h>
+#include <errno.h>
+
+#include <openssl/rsa.h>
+#include <openssl/pem.h>
+#include <openssl/evp.h>
+#include <openssl/err.h>
+#include <openssl/rand.h>
+
+#include <tss2/tss.h>
+#include <tss2/tssutils.h>
+#include <tss2/tssmarshal.h>
+
+#include "tpm2-asn.h"
+#include "tpm2-common.h"
+
+static struct option long_options[] = {
+	{"auth", 0, 0, 'a'},
+	{"help", 0, 0, 'h'},
+	{"key-size", 1, 0, 's'},
+	{"name-scheme", 1, 0, 'n'},
+	{"parent-handle", 1, 0, 'p'},
+	{"wrap", 1, 0, 'w'},
+	{0, 0, 0, 0}
+};
+
+static TPM_ALG_ID name_alg = TPM_ALG_SHA256;
+static int name_alg_size = SHA256_DIGEST_SIZE;
+
+void
+usage(char *argv0)
+{
+	fprintf(stderr, "\t%s: create a TPM key and write it to disk\n"
+		"\tusage: %s [options] <filename>\n\n"
+		"\tOptions:\n"
+		"\t\t-a|--auth          require a password for the key [NO]\n"
+		"\t\t-h|--help          print this help message\n"
+		"\t\t-s|--key-size      key size in bits [2048]\n"
+		"\t\t-n|--name-scheme   name algorithm to use sha1 [sha256] sha384 sha512\n"
+		"\t\t-p|--parent-handle persistent handle of parent key\n"
+		"\t\t-w|--wrap [file]   wrap an existing openssl PEM key\n"
+		"\nReport bugs to %s\n",
+		argv0, argv0, PACKAGE_BUGREPORT);
+	exit(-1);
+}
+
+void
+openssl_print_errors()
+{
+	ERR_load_ERR_strings();
+	ERR_load_crypto_strings();
+	ERR_print_errors_fp(stderr);
+}
+
+int
+openssl_write_tpmfile(const char *file, BYTE *pubkey, int pubkey_len,
+		      BYTE *privkey, int privkey_len, int empty_auth,
+		      TPM_HANDLE parent)
+{
+	TSSLOADABLE tssl;
+	BIO *outb;
+
+	/* clear structure so as not to have to set optional parameters */
+	memset(&tssl, 0, sizeof(tssl));
+	if ((outb = BIO_new_file(file, "w")) == NULL) {
+                fprintf(stderr, "Error opening file for write: %s\n", file);
+		return 1;
+	}
+	tssl.type = OBJ_txt2obj(OID_loadableKey, 1);
+	tssl.emptyAuth = empty_auth;
+	if ((parent & 0xff000000) == 0x81000000) {
+		tssl.parent = ASN1_INTEGER_new();
+		ASN1_INTEGER_set(tssl.parent, parent);
+	}
+	tssl.pubkey = ASN1_OCTET_STRING_new();
+	ASN1_STRING_set(tssl.pubkey, pubkey, pubkey_len);
+	tssl.privkey = ASN1_OCTET_STRING_new();
+	ASN1_STRING_set(tssl.privkey, privkey, privkey_len);
+
+	PEM_write_bio_TSSLOADABLE(outb, &tssl);
+	BIO_free(outb);
+	return 0;
+}
+
+EVP_PKEY *
+openssl_read_key(char *filename)
+{
+        BIO *b = NULL;
+	EVP_PKEY *pkey;
+
+        b = BIO_new_file(filename, "r");
+        if (b == NULL) {
+                fprintf(stderr, "Error opening file for read: %s\n", filename);
+                return NULL;
+        }
+
+        if ((pkey = PEM_read_bio_PrivateKey(b, NULL, PEM_def_callback, NULL)) == NULL) {
+                fprintf(stderr, "Reading key %s from disk failed.\n", filename);
+                openssl_print_errors();
+        }
+	BIO_free(b);
+
+        return pkey;
+}
+
+void tpm2_public_template_rsa(TPMT_PUBLIC *pub)
+{
+	pub->type = TPM_ALG_RSA;
+	pub->nameAlg = name_alg;
+	/* note: all our keys are decrypt only.  This is because
+	 * we use the TPM2_RSA_Decrypt operation for both signing
+	 * and decryption (see e_tpm2.c for details) */
+	pub->objectAttributes.val = TPMA_OBJECT_NODA |
+		TPMA_OBJECT_DECRYPT |
+		TPMA_OBJECT_USERWITHAUTH;
+	pub->authPolicy.t.size = 0;
+	pub->parameters.rsaDetail.symmetric.algorithm = TPM_ALG_NULL;
+	pub->parameters.rsaDetail.scheme.scheme = TPM_ALG_NULL;
+}
+
+TPM_RC openssl_to_tpm_public_rsa(TPMT_PUBLIC *pub, EVP_PKEY *pkey)
+{
+	RSA *rsa = EVP_PKEY_get1_RSA(pkey);
+	BIGNUM *n, *e;
+	int size = RSA_size(rsa);
+	unsigned long exp;
+
+	if (size > MAX_RSA_KEY_BYTES)
+		return TPM_RC_KEY_SIZE;
+
+#if OPENSSL_VERSION_NUMBER < 0x10100000
+	n = rsa->n;
+	e = rsa->e;
+#else
+	RSA_get0_key(&n, &e, NULL);
+#endif
+	exp = BN_get_word(e);
+	/* TPM limitations means exponents must be under a word in size */
+	if (exp == 0xffffffffL)
+		return TPM_RC_KEY_SIZE;
+	tpm2_public_template_rsa(pub);
+	pub->parameters.rsaDetail.keyBits = size*8;
+	if (exp == 0x10001)
+		pub->parameters.rsaDetail.exponent = 0;
+	else
+		pub->parameters.rsaDetail.exponent = exp;
+
+	pub->unique.rsa.t.size = BN_bn2bin(n, pub->unique.rsa.t.buffer);
+
+	return 0;
+}
+
+TPM_RC openssl_to_tpm_public(TPM2B_PUBLIC *pub, EVP_PKEY *pkey)
+{
+	TPMT_PUBLIC *tpub = &pub->publicArea;
+	pub->size = sizeof(*pub);
+
+	switch (EVP_PKEY_type(pkey->type)) {
+	case EVP_PKEY_RSA:
+		return openssl_to_tpm_public_rsa(tpub, pkey);
+	default:
+		break;
+	}
+	return TPM_RC_ASYMMETRIC;
+}
+
+TPM_RC openssl_to_tpm_private_rsa(TPMT_SENSITIVE *s, EVP_PKEY *pkey)
+{
+	BIGNUM *q;
+	TPM2B_PRIVATE_KEY_RSA *t2brsa = &s->sensitive.rsa;
+	RSA *rsa = EVP_PKEY_get1_RSA(pkey);
+
+#if OPENSSL_VERSION_NUMBER < 0x10100000
+	q = rsa->q;
+#else
+	BIGNUM *p;
+
+	RSA_get0_factors(rsa, &p, &q);
+#endif
+
+	if (!q)
+		return TPM_RC_ASYMMETRIC;
+
+	s->sensitiveType = TPM_ALG_RSA;
+	s->seedValue.b.size = 0;
+
+	t2brsa->t.size = BN_bn2bin(q, t2brsa->t.buffer);
+	return 0;
+}
+
+TPM_RC openssl_to_tpm_private(TPMT_SENSITIVE *priv, EVP_PKEY *pkey)
+{
+	switch (EVP_PKEY_type(pkey->type)) {
+	case EVP_PKEY_RSA:
+		return openssl_to_tpm_private_rsa(priv, pkey);
+	default:
+		break;
+	}
+	return TPM_RC_ASYMMETRIC;
+}
+
+TPM_RC wrap_key(TPM2B_PRIVATE *priv, const char *password, EVP_PKEY *pkey)
+{
+	TPMT_SENSITIVE s;
+	TPM2B_SENSITIVE b;
+	BYTE *buf;
+	int32_t size;
+	TPM_RC rc;
+
+	memset(&b, 0, sizeof(b));
+	memset(&s, 0, sizeof(s));
+
+	openssl_to_tpm_private(&s, pkey);
+
+	if (password) {
+		int len = strlen(password);
+
+		memcpy(s.authValue.b.buffer, password, len);
+		s.authValue.b.size = len;
+	} else {
+		s.authValue.b.size = 0;
+	}
+	size = sizeof(s);
+	buf = b.b.buffer;
+	rc = TSS_TPMT_SENSITIVE_Marshal(&s, &b.b.size, &buf, &size);
+	if (rc)
+		tpm2_error(rc, "TSS_TPMT_SENSITIVE_Marshal");
+
+	size = sizeof(*priv);
+	buf = priv->b.buffer;
+	priv->b.size = 0;
+	/* no encryption means innerIntegrity and outerIntegrity are
+	* absent, so the TPM2B_PRIVATE is a TPMT_SENSITIVE*/
+	rc = TSS_TPM2B_PRIVATE_Marshal((TPM2B_PRIVATE *)&b, &priv->b.size, &buf, &size);
+	if (rc)
+		tpm2_error(rc, "TSS_TPM2B_PRIVATE_Marshal");
+
+	return TPM_RC_ASYMMETRIC;
+}
+
+int main(int argc, char **argv)
+{
+	char *filename, c, *wrap = NULL, *auth = NULL;
+	int option_index;
+	const char *reason;
+	TSS_CONTEXT *tssContext = NULL;
+	TPM_HANDLE parent = 0;
+	TPM_RC rc = 0;
+	BYTE pubkey[sizeof(TPM2B_PUBLIC)],privkey[sizeof(TPM2B_PRIVATE)], *buffer;
+	uint16_t pubkey_len, privkey_len;
+	int32_t size, key_size = 0;
+	TPM2B_PUBLIC *pub;
+	TPM2B_PRIVATE *priv;
+
+
+	while (1) {
+		option_index = 0;
+		c = getopt_long(argc, argv, "n:s:ap:hw:",
+				long_options, &option_index);
+		if (c == -1)
+			break;
+
+		switch (c) {
+			case 'a':
+				auth = malloc(128);
+				break;
+			case 'h':
+				usage(argv[0]);
+				break;
+			case 'n':
+				if (!strcasecmp("sha1", optarg)) {
+					name_alg = TPM_ALG_SHA1;
+					name_alg_size = SHA1_DIGEST_SIZE;
+				} else if (strcasecmp("sha256", optarg)) {
+					/* default, do nothing */
+				} else if (strcasecmp("sha384", optarg)) {
+					name_alg = TPM_ALG_SHA384;
+					name_alg_size = SHA384_DIGEST_SIZE;
+#ifdef TPM_ALG_SHA512
+				} else if (strcasecmp("sha512", optarg)) {
+					name_alg = TPM_ALG_SHA512;
+					name_alg_size = SHA512_DIGEST_SIZE;
+#endif
+				} else {
+					usage(argv[0]);
+				}
+				break;
+			case 'p':
+				parent = strtol(optarg, NULL, 16);
+				break;
+			case's':
+				key_size = atoi(optarg);
+				break;
+			case 'w':
+				wrap = optarg;
+				break;
+			default:
+				usage(argv[0]);
+				break;
+		}
+	}
+
+	filename = argv[argc - 1];
+
+	if (argc < 2)
+		usage(argv[0]);
+
+	if (key_size && wrap) {
+		fprintf(stderr, "key-size and wrap are mutually exclusive\n");
+		usage(argv[0]);
+	} else if (!key_size && !wrap) {
+		/* for internal create, use default key size */
+		key_size = 2048;
+	}
+
+	if (parent && (parent & 0xff000000) != 0x81000000) {
+		fprintf(stderr, "you must specify a persistent parent handle\n");
+		usage(argv[0]);
+	}
+
+	if (auth) {
+		if (EVP_read_pw_string(auth, 128, "Enter TPM key authority: ", 1)) {
+			fprintf(stderr, "Passwords do not match\n");
+			exit(1);
+		}
+	}
+
+	rc = TSS_Create(&tssContext);
+	if (rc) {
+		reason = "TSS_Create";
+		goto out_err;
+	}
+
+	if (parent == 0) {
+		rc = tpm2_load_srk(tssContext, &parent, NULL, NULL);
+		if (rc) {
+			reason = "tpm2_load_srk";
+			goto out_delete;
+		}
+	}
+
+	if (wrap) {
+		Import_In iin;
+		Import_Out iout;
+		EVP_PKEY *pkey;
+
+		/* may be needed to decrypt the key */
+		OpenSSL_add_all_ciphers();
+		pkey = openssl_read_key(wrap);
+		if (!pkey) {
+			reason = "unable to read key";
+			goto out_delete;
+		}
+
+		iin.parentHandle = parent;
+		iin.encryptionKey.t.size = 0;
+		openssl_to_tpm_public(&iin.objectPublic, pkey);
+		/* set random iin.symSeed */
+		iin.inSymSeed.t.size = 0;
+		iin.symmetricAlg.algorithm = TPM_ALG_NULL;
+		wrap_key(&iin.duplicate, auth, pkey);
+		openssl_to_tpm_public(&iin.objectPublic, pkey);
+		rc = TSS_Execute(tssContext,
+				 (RESPONSE_PARAMETERS *)&iout,
+				 (COMMAND_PARAMETERS *)&iin,
+				 NULL,
+				 TPM_CC_Import,
+				 TPM_RS_PW, NULL, 0,
+				 TPM_RH_NULL, NULL, 0,
+				 TPM_RH_NULL, NULL, 0,
+				 TPM_RH_NULL, NULL, 0);
+		if (rc) {
+			reason = "TPM2_Import";
+			goto out_flush;
+		}
+		pub = &iin.objectPublic;
+		priv = &iout.outPrivate;
+	} else {
+		/* create a TPM resident key */
+		Create_In cin;
+		Create_Out cout;
+
+		tpm2_public_template_rsa(&cin.inPublic.publicArea);
+		cin.inPublic.publicArea.objectAttributes.val |=
+			TPMA_OBJECT_SENSITIVEDATAORIGIN;
+		if (auth) {
+			int len = strlen(auth);
+			memcpy(&cin.inSensitive.sensitive.userAuth.b,
+			       auth, len);
+			cin.inSensitive.sensitive.userAuth.b.size = len;
+		} else {
+			cin.inSensitive.sensitive.userAuth.b.size = 0;
+		}
+		cin.inSensitive.sensitive.data.t.size = 0;
+		cin.parentHandle = parent;
+		cin.outsideInfo.t.size = 0;
+		cin.creationPCR.count = 0;
+		cin.inPublic.publicArea.parameters.rsaDetail.keyBits = key_size;
+		cin.inPublic.publicArea.parameters.rsaDetail.exponent = 0;
+		cin.inPublic.publicArea.unique.rsa.t.size = 0;
+
+		rc = TSS_Execute(tssContext,
+				 (RESPONSE_PARAMETERS *)&cout,
+				 (COMMAND_PARAMETERS *)&cin,
+				 NULL,
+				 TPM_CC_Create,
+				 TPM_RS_PW, NULL, 0,
+				 TPM_RH_NULL, NULL, 0,
+				 TPM_RH_NULL, NULL, 0,
+				 TPM_RH_NULL, NULL, 0);
+		if (rc) {
+			reason = "TPM2_Create";
+			goto out_flush;
+		}
+
+		pub = &cout.outPublic;
+		priv = &cout.outPrivate;
+	}
+	tpm2_flush_srk(tssContext);
+	buffer = pubkey;
+	pubkey_len = 0;
+	size = sizeof(pubkey);
+	TSS_TPM2B_PUBLIC_Marshal(pub, &pubkey_len, &buffer, &size);
+	buffer = privkey;
+	privkey_len = 0;
+	size = sizeof(privkey);
+	TSS_TPM2B_PRIVATE_Marshal(priv, &privkey_len, &buffer, &size);
+	openssl_write_tpmfile(filename, pubkey, pubkey_len, privkey, privkey_len, auth == NULL, parent);
+	TSS_Delete(tssContext);
+	exit(0);
+
+ out_flush:
+	tpm2_flush_srk(tssContext);
+ out_delete:
+	TSS_Delete(tssContext);
+ out_err:
+	tpm2_error(rc, reason);
+
+	exit(1);
+}
diff --git a/e_tpm2.c b/e_tpm2.c
new file mode 100644
index 0000000..18e94fe
--- /dev/null
+++ b/e_tpm2.c
@@ -0,0 +1,559 @@
+
+/*
+ * Copyright (C) 2016 James.Bottomley at HansenPartnership.com
+ *
+ * GPLv2
+ *
+ */
+
+#include <stdio.h>
+#include <string.h>
+
+#include <openssl/crypto.h>
+#include <openssl/dso.h>
+#include <openssl/engine.h>
+#include <openssl/evp.h>
+#include <openssl/objects.h>
+#include <openssl/sha.h>
+#include <openssl/bn.h>
+#include <openssl/pem.h>
+#include <openssl/x509.h>
+
+#include <tss2/tss.h>
+#include <tss2/tssutils.h>
+#include <tss2/tssmarshal.h>
+#include <tss2/tssresponsecode.h>
+#include <tss2/Unmarshal_fp.h>
+
+#include "tpm2-asn.h"
+#include "tpm2-common.h"
+
+#define TPM2_ENGINE_EX_DATA_UNINIT		-1
+
+/* structure pointed to by the RSA object's app_data pointer */
+struct rsa_app_data
+{
+	TSS_CONTEXT *tssContext;
+	TPM_HANDLE parent;
+	TPM_HANDLE key;
+	char *auth;
+};
+
+static char *srk_auth;
+
+static int tpm2_engine_init(ENGINE * e)
+{
+	return 1;
+}
+
+static int tpm2_engine_finish(ENGINE * e)
+{
+	return 1;
+}
+
+static int tpm2_create_srk_policy(char *secret)
+{
+	int len;
+
+	if (!secret) {
+		OPENSSL_free(srk_auth);
+		srk_auth = NULL;
+	} else {
+		len = strlen(secret);
+		srk_auth = OPENSSL_malloc(len);
+		strcpy(srk_auth, secret);
+	}
+	return 1;
+}
+
+#define TPM_CMD_PIN ENGINE_CMD_BASE
+
+static int tpm2_engine_ctrl(ENGINE * e, int cmd, long i, void *p, void (*f) ())
+{
+	switch (cmd) {
+		case TPM_CMD_PIN:
+			return tpm2_create_srk_policy(p);
+		default:
+			break;
+	}
+	fprintf(stderr, "tpm2: engine command not implemented\n");
+
+	return 0;
+}
+
+
+#ifndef OPENSSL_NO_RSA
+/* rsa functions */
+static int tpm2_rsa_init(RSA *rsa);
+static int tpm2_rsa_finish(RSA *rsa);
+static int tpm2_rsa_pub_dec(int, const unsigned char *, unsigned char *, RSA *, int);
+static int tpm2_rsa_pub_enc(int, const unsigned char *, unsigned char *, RSA *, int);
+static int tpm2_rsa_priv_dec(int, const unsigned char *, unsigned char *, RSA *, int);
+static int tpm2_rsa_priv_enc(int, const unsigned char *, unsigned char *, RSA *, int);
+//static int tpm2_rsa_sign(int, const unsigned char *, unsigned int, unsigned char *, unsigned int *, const RSA *);
+#endif
+
+/* The definitions for control commands specific to this engine */
+#define TPM2_CMD_PIN		ENGINE_CMD_BASE
+static const ENGINE_CMD_DEFN tpm2_cmd_defns[] = {
+	{TPM2_CMD_PIN,
+	 "PIN",
+	 "Specifies the secret for the SRK (default is plaintext, else set SECRET_MODE)",
+	 ENGINE_CMD_FLAG_STRING},
+	/* end */
+	{0, NULL, NULL, 0}
+};
+
+#ifndef OPENSSL_NO_RSA
+static RSA_METHOD tpm2_rsa = {
+	"TPM2 RSA method",
+	tpm2_rsa_pub_enc,
+	tpm2_rsa_pub_dec,
+	tpm2_rsa_priv_enc,
+	tpm2_rsa_priv_dec,
+	NULL, /* set in tpm2_engine_init */
+	BN_mod_exp_mont,
+	tpm2_rsa_init,
+	tpm2_rsa_finish,
+	(RSA_FLAG_SIGN_VER | RSA_FLAG_NO_BLINDING),
+	NULL,
+	NULL, /* sign */
+	NULL, /* verify */
+	NULL, /* keygen */
+};
+#endif
+
+/* varibles used to get/set CRYPTO_EX_DATA values */
+static int ex_app_data = TPM2_ENGINE_EX_DATA_UNINIT;
+
+static TPM_HANDLE tpm2_load_key_from_rsa(RSA *rsa, TSS_CONTEXT **tssContext, char **auth)
+{
+	struct rsa_app_data *app_data = RSA_get_ex_data(rsa, ex_app_data);
+
+	if (!app_data)
+		return 0;
+
+	*auth = app_data->auth;
+	*tssContext = app_data->tssContext;
+
+	return app_data->key;
+}
+
+static char *tpm2_get_auth(UI_METHOD *ui_method, char *prompt, void *cb_data)
+{
+	UI *ui = UI_new();
+	/* Max auth size is name algorithm hash length, so this
+	 * is way bigger than necessary */
+	char auth[256], *ret = NULL;
+	int len;
+
+	if (ui_method)
+		UI_set_method(ui, ui_method);
+
+	UI_add_user_data(ui, cb_data);
+
+	if (UI_add_input_string(ui, prompt, 0, auth, 0, sizeof(auth)) == 0) {
+		fprintf(stderr, "UI_add_input_string failed\n");
+		goto out;
+	}
+
+	if (UI_process(ui)) {
+		fprintf(stderr, "UI_process failed\n");
+		goto out;
+	}
+
+	len = strlen(auth);
+	ret = OPENSSL_malloc(len + 1);
+	if (!ret)
+		goto out;
+
+	strcpy(ret, auth);
+
+ out:
+	UI_free(ui);
+
+	return ret;
+}
+
+static EVP_PKEY *tpm2_engine_load_key(ENGINE *e, const char *key_id,
+				      UI_METHOD *ui, void *cb_data)
+{
+	Load_In in;
+	Load_Out out;
+	TSS_CONTEXT *tssContext;
+	TPM_RC rc;
+	EVP_PKEY *pkey;
+	RSA *rsa;
+	BIO *bf;
+	TSSLOADABLE *tssl;
+	BYTE *buffer;
+	INT32 size;
+	struct rsa_app_data *app_data;
+	char oid[128];
+	int empty_auth;
+
+	if (!key_id) {
+		fprintf(stderr, "key_id is NULL\n");
+		return NULL;
+	}
+
+	bf = BIO_new_file(key_id, "r");
+	if (!bf) {
+		fprintf(stderr, "File %s does not exist or cannot be read\n", key_id);
+		return NULL;
+	}
+
+	tssl = PEM_read_bio_TSSLOADABLE(bf, NULL, NULL, NULL);
+
+	BIO_free(bf);
+
+	if (!tssl) {
+		fprintf(stderr, "Failed to parse file %s\n", key_id);
+		return NULL;
+	}
+
+	if (OBJ_obj2txt(oid, sizeof(oid), tssl->type, 1) == 0) {
+		fprintf(stderr, "Failed to parse object type\n");
+		goto err;
+	}
+
+	if (strcmp(OID_loadableKey, oid) == 0) {
+		;
+	} else if (strcmp(OID_12Key, oid) == 0) {
+		fprintf(stderr, "TPM1.2 key is not importable by TPM2.0\n");
+		goto err;
+	} else if (strcmp(OID_importableKey, oid) == 0) {
+		fprintf(stderr, "Importable keys currently unsupported\n");
+		goto err;
+	} else {
+		fprintf(stderr, "Unrecognised object type\n");
+		goto err;
+	}
+
+	app_data = OPENSSL_malloc(sizeof(struct rsa_app_data));
+
+	if (!app_data) {
+		fprintf(stderr, "Failed to allocate app_data\n");
+		goto err;
+	}
+
+	rc = TSS_Create(&tssContext);
+	if (rc) {
+		tpm2_error(rc, "TSS_Create");
+		goto err_free;
+	}
+
+	app_data->tssContext = tssContext;
+
+	app_data->parent = 0;
+	if (tssl->parent)
+		app_data->parent = ASN1_INTEGER_get(tssl->parent);
+
+	if (app_data->parent)
+		in.parentHandle = app_data->parent;
+	else
+		tpm2_load_srk(tssContext, &in.parentHandle, srk_auth, NULL);
+
+	empty_auth = tssl->emptyAuth;
+
+	buffer = tssl->privkey->data;
+	size = tssl->privkey->length;
+	TPM2B_PRIVATE_Unmarshal(&in.inPrivate, &buffer, &size);
+	buffer = tssl->pubkey->data;
+	size = tssl->pubkey->length;
+	TPM2B_PUBLIC_Unmarshal(&in.inPublic, &buffer, &size, FALSE);
+
+	/* create the new objects to return */
+	pkey = tpm2_to_openssl_public(&in.inPublic.publicArea);
+	if (!pkey) {
+		fprintf(stderr, "Failed to allocate a new EVP_KEY\n");
+		goto err_free_del;
+	}
+
+	rc = TSS_Execute(tssContext,
+			 (RESPONSE_PARAMETERS *)&out,
+			 (COMMAND_PARAMETERS *)&in,
+			 NULL,
+			 TPM_CC_Load,
+			 TPM_RS_PW, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0);
+
+	if (rc) {
+		tpm2_error(rc, "TPM2_Load");
+		goto err_free_key;
+	}
+
+	app_data->key = out.objectHandle;
+
+	app_data->auth = NULL;
+	if (empty_auth == 0) {
+		app_data->auth = tpm2_get_auth(ui, "TPM Key Password: ", cb_data);
+		if (!app_data->auth)
+			goto err_unload;
+	}
+
+	TSSLOADABLE_free(tssl);
+	rsa = EVP_PKEY_get1_RSA(pkey);
+	rsa->meth = &tpm2_rsa;
+	/* call our local init function here */
+	rsa->meth->init(rsa);
+
+	RSA_set_ex_data(rsa, ex_app_data, app_data);
+
+	/* release the reference EVP_PKEY_get1_RSA obtained */
+	RSA_free(rsa);
+	return pkey;
+
+ err_unload:
+	tpm2_flush_handle(tssContext, app_data->key);
+ err_free_key:
+	EVP_PKEY_free(pkey);
+ err_free_del:
+	TSS_Delete(tssContext);
+ err_free:
+	OPENSSL_free(app_data);
+	tpm2_flush_srk(tssContext);
+ err:
+	TSSLOADABLE_free(tssl);
+
+	return NULL;
+}
+
+/* Constants used when creating the ENGINE */
+static const char *engine_tpm2_id = "tpm2";
+static const char *engine_tpm2_name = "TPM2 hardware engine support";
+
+/* This internal function is used by ENGINE_tpm() and possibly by the
+ * "dynamic" ENGINE support too */
+static int tpm2_bind_helper(ENGINE * e)
+{
+	if (!ENGINE_set_id(e, engine_tpm2_id) ||
+	    !ENGINE_set_name(e, engine_tpm2_name) ||
+#ifndef OPENSSL_NO_RSA
+	    !ENGINE_set_RSA(e, &tpm2_rsa) ||
+#endif
+	    !ENGINE_set_init_function(e, tpm2_engine_init) ||
+	    !ENGINE_set_finish_function(e, tpm2_engine_finish) ||
+	    !ENGINE_set_ctrl_function(e, tpm2_engine_ctrl) ||
+	    !ENGINE_set_load_pubkey_function(e, tpm2_engine_load_key) ||
+	    !ENGINE_set_load_privkey_function(e, tpm2_engine_load_key) ||
+	    !ENGINE_set_cmd_defns(e, tpm2_cmd_defns))
+		return 0;
+
+	return 1;
+}
+
+
+#ifndef OPENSSL_NO_RSA
+static int tpm2_rsa_init(RSA *rsa)
+{
+	if (ex_app_data == TPM2_ENGINE_EX_DATA_UNINIT)
+		ex_app_data = RSA_get_ex_new_index(0, NULL, NULL, NULL, NULL);
+
+	if (ex_app_data == TPM2_ENGINE_EX_DATA_UNINIT) {
+		fprintf(stderr, "Failed to get memory for external data\n");
+		return 0;
+	}
+
+	return 1;
+}
+
+static int tpm2_rsa_finish(RSA *rsa)
+{
+	struct rsa_app_data *app_data = RSA_get_ex_data(rsa, ex_app_data);
+	TSS_CONTEXT *tssContext;
+
+	if (!app_data)
+		return 1;
+
+	tssContext = app_data->tssContext;
+
+	tpm2_flush_handle(tssContext, app_data->key);
+	if (app_data->parent == 0)
+		tpm2_flush_srk(tssContext);
+
+	OPENSSL_free(app_data);
+
+	TSS_Delete(tssContext);
+
+	return 1;
+}
+
+static int tpm2_rsa_pub_dec(int flen,
+			   const unsigned char *from,
+			   unsigned char *to,
+			   RSA *rsa,
+			   int padding)
+{
+	int rv;
+
+	rv = RSA_PKCS1_SSLeay()->rsa_pub_dec(flen, from, to, rsa,
+					     padding);
+	if (rv < 0) {
+		fprintf(stderr, "rsa_pub_dec failed\n");
+		return 0;
+	}
+
+	return rv;
+}
+
+static int tpm2_rsa_priv_dec(int flen,
+			    const unsigned char *from,
+			    unsigned char *to,
+			    RSA *rsa,
+			    int padding)
+{
+	TPM_RC rc;
+	int rv;
+	RSA_Decrypt_In in;
+	RSA_Decrypt_Out out;
+	TSS_CONTEXT *tssContext;
+	char *auth;
+
+	in.keyHandle = tpm2_load_key_from_rsa(rsa, &tssContext, &auth);
+
+	if (in.keyHandle == 0) {
+		rv = RSA_PKCS1_SSLeay()->rsa_priv_dec(flen, from, to, rsa,
+						      padding);
+		if (rv < 0)
+			fprintf(stderr, "rsa_priv_dec failed\n");
+
+		return rv;
+	}
+
+	rv = -1;
+	if (padding != RSA_PKCS1_PADDING) {
+		fprintf(stderr, "Non PKCS1 padding asked for\n");
+		return rv;
+	}
+
+	in.inScheme.scheme = TPM_ALG_RSAES;
+	in.cipherText.t.size = flen;
+	memcpy(in.cipherText.t.buffer, from, flen);
+	in.label.t.size = 0;
+
+	rc = TSS_Execute(tssContext,
+			 (RESPONSE_PARAMETERS *)&out,
+			 (COMMAND_PARAMETERS *)&in,
+			 NULL,
+			 TPM_CC_RSA_Decrypt,
+			 TPM_RS_PW, auth, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0);
+	if (rc) {
+		tpm2_error(rc, "TPM2_RSA_Decrypt");
+		return rv;
+	}
+
+	memcpy(to, out.message.t.buffer,
+	       out.message.t.size);
+
+	rv = out.message.t.size;
+
+	return rv;
+}
+
+static int tpm2_rsa_pub_enc(int flen,
+			   const unsigned char *from,
+			   unsigned char *to,
+			   RSA *rsa,
+			   int padding)
+{
+	int rv;
+
+	rv = RSA_PKCS1_SSLeay()->rsa_pub_enc(flen, from, to, rsa,
+					     padding);
+	if (rv < 0)
+		fprintf(stderr, "rsa_pub_enc failed\n");
+
+	return rv;
+}
+
+static int tpm2_rsa_priv_enc(int flen,
+			    const unsigned char *from,
+			    unsigned char *to,
+			    RSA *rsa,
+			    int padding)
+{
+	TPM_RC rc;
+	int rv, size;
+	RSA_Decrypt_In in;
+	RSA_Decrypt_Out out;
+	TSS_CONTEXT *tssContext;
+	char *auth;
+
+	in.keyHandle = tpm2_load_key_from_rsa(rsa, &tssContext, &auth);
+
+	if (in.keyHandle == 0) {
+		rv = RSA_PKCS1_SSLeay()->rsa_priv_enc(flen, from, to, rsa,
+						      padding);
+		if (rv < 0)
+			fprintf(stderr, "pass through signing failed\n");
+
+		return rv;
+	}
+
+	rv = -1;
+	if (padding != RSA_PKCS1_PADDING) {
+		fprintf(stderr, "Non PKCS1 padding asked for\n");
+		return rv;
+	}
+
+	/* this is slightly paradoxical that we're doing a Decrypt
+	 * operation: the only material difference between decrypt and
+	 * encrypt is where the padding is applied or checked, so if
+	 * you apply your own padding up to the RSA block size and use
+	 * TPM_ALG_NULL, which means no padding check, a decrypt
+	 * operation effectively becomes an encrypt */
+	size = RSA_size(rsa);
+	in.inScheme.scheme = TPM_ALG_NULL;
+	in.cipherText.t.size = size;
+	RSA_padding_add_PKCS1_type_1(in.cipherText.t.buffer, size, from, flen);
+	in.label.t.size = 0;
+
+	rc = TSS_Execute(tssContext,
+			 (RESPONSE_PARAMETERS *)&out,
+			 (COMMAND_PARAMETERS *)&in,
+			 NULL,
+			 TPM_CC_RSA_Decrypt,
+			 TPM_RS_PW, auth, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0);
+
+	if (rc) {
+		tpm2_error(rc, "TPM2_RSA_Decrypt");
+		return rv;
+	}
+
+	memcpy(to, out.message.t.buffer,
+	       out.message.t.size);
+
+	rv = out.message.t.size;
+
+	return rv;
+}
+
+#endif
+
+/* This stuff is needed if this ENGINE is being compiled into a self-contained
+ * shared-library. */
+static int tpm2_bind_fn(ENGINE * e, const char *id)
+{
+	if (id && (strcmp(id, engine_tpm2_id) != 0)) {
+		fprintf(stderr, "Called for id %s != my id %s\n",
+		       id, engine_tpm2_id);
+		return 0;
+	}
+	if (!tpm2_bind_helper(e)) {
+		fprintf(stderr, "tpm2_bind_helper failed\n");
+		return 0;
+	}
+	return 1;
+}
+
+IMPLEMENT_DYNAMIC_CHECK_FN()
+IMPLEMENT_DYNAMIC_BIND_FN(tpm2_bind_fn)
diff --git a/tpm2-asn.h b/tpm2-asn.h
new file mode 100644
index 0000000..2a08e3a
--- /dev/null
+++ b/tpm2-asn.h
@@ -0,0 +1,59 @@
+/* Copyright (C) 2016 James Bottomley <James.Bottomley at HansenPartnership.com>
+ *
+ * GPLv2
+ */
+#ifndef _TPM2_ASN_H
+#define _TPM2_ASN_H
+
+#include <openssl/asn1t.h>
+
+/*
+ * Define the format of a TPM key file.  The current format covers
+ * both TPM1.2 keys as well as symmetrically encrypted private keys
+ * produced by TSS2_Import and the TPM2 format public key which
+ * contains things like the policy but which is cryptographically tied
+ * to the private key.
+ *
+ * TPMKey ::= SEQUENCE {
+ *	type		OBJECT IDENTIFIER
+ *	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL
+ *	parent		[1] EXPLICIT INTEGER OPTIONAL
+ *	pubkey		[2] EXPLICIT OCTET STRING OPTIONAL
+ *	privkey		OCTET STRING
+ * }
+ */
+
+typedef struct {
+	ASN1_OBJECT *type;
+	ASN1_BOOLEAN emptyAuth;
+	ASN1_INTEGER *parent;
+	ASN1_OCTET_STRING *pubkey;
+	ASN1_OCTET_STRING *privkey;
+} TSSLOADABLE;
+
+/* the two type oids are in the TCG namespace 2.23.133; we choose an
+ *  unoccupied child (10) for keytype file and two values:
+ *    1 : Key that is directly loadable
+ *    2 : Key that must first be imported then loaded
+ */
+#define OID_12Key		"2.23.133.10.1"
+#define OID_loadableKey		"2.23.133.10.2"
+#define OID_importableKey	"2.23.133.10.3"
+
+ASN1_SEQUENCE(TSSLOADABLE) = {
+	ASN1_SIMPLE(TSSLOADABLE, type, ASN1_OBJECT),
+	ASN1_EXP_OPT(TSSLOADABLE, emptyAuth, ASN1_BOOLEAN, 0),
+	ASN1_EXP_OPT(TSSLOADABLE, parent, ASN1_INTEGER, 1),
+	ASN1_EXP_OPT(TSSLOADABLE, pubkey, ASN1_OCTET_STRING, 2),
+	ASN1_SIMPLE(TSSLOADABLE, privkey, ASN1_OCTET_STRING)
+} ASN1_SEQUENCE_END(TSSLOADABLE)
+
+IMPLEMENT_ASN1_FUNCTIONS(TSSLOADABLE);
+
+/* This is the PEM guard tag */
+#define TSSLOADABLE_PEM_STRING "TSS2 KEY BLOB"
+
+static IMPLEMENT_PEM_write_bio(TSSLOADABLE, TSSLOADABLE, TSSLOADABLE_PEM_STRING, TSSLOADABLE)
+static IMPLEMENT_PEM_read_bio(TSSLOADABLE, TSSLOADABLE, TSSLOADABLE_PEM_STRING, TSSLOADABLE)
+
+#endif
diff --git a/tpm2-common.c b/tpm2-common.c
new file mode 100644
index 0000000..1b6569c
--- /dev/null
+++ b/tpm2-common.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (C) 2016 James Bottomley <James.Bottomley at HansenPartnership.com>
+ *
+ * GPLv2
+ */
+
+#include <stdio.h>
+
+#include <openssl/evp.h>
+#include <openssl/rsa.h>
+
+#include <tss2/tss.h>
+#include <tss2/tssresponsecode.h>
+
+#include "tpm2-common.h"
+
+void tpm2_error(TPM_RC rc, const char *reason)
+{
+	const char *msg, *submsg, *num;
+
+	fprintf(stderr, "%s failed with %d\n", reason, rc);
+	TSS_ResponseCode_toString(&msg, &submsg, &num, rc);
+	fprintf(stderr, "%s%s%s\n", msg, submsg, num);
+}
+
+
+static TPM_HANDLE hSRK = 0;
+
+TPM_RC tpm2_load_srk(TSS_CONTEXT *tssContext, TPM_HANDLE *h, const char *auth,TPM2B_PUBLIC *pub)
+{
+	static TPM2B_PUBLIC srk_pub;
+	TPM_RC rc;
+	CreatePrimary_In in;
+	CreatePrimary_Out out;
+
+	if (hSRK)
+		goto out;
+
+	/* SPS owner */
+	in.primaryHandle = TPM_RH_OWNER;
+	/* assume no owner password */
+	in.inSensitive.sensitive.userAuth.t.size = 0;
+	/* no sensitive date for storage keys */
+	in.inSensitive.sensitive.data.t.size = 0;
+	/* no outside info */
+	in.outsideInfo.t.size = 0;
+	/* no PCR state */
+	in.creationPCR.count = 0;
+
+	/* public parameters for an RSA2048 key  */
+	in.inPublic.publicArea.type = TPM_ALG_RSA;
+	in.inPublic.publicArea.nameAlg = TPM_ALG_SHA256;
+	in.inPublic.publicArea.objectAttributes.val =
+		TPMA_OBJECT_NODA |
+		TPMA_OBJECT_SENSITIVEDATAORIGIN |
+		TPMA_OBJECT_USERWITHAUTH |
+		TPMA_OBJECT_DECRYPT |
+		TPMA_OBJECT_RESTRICTED;
+	in.inPublic.publicArea.parameters.rsaDetail.symmetric.algorithm = TPM_ALG_AES;
+	in.inPublic.publicArea.parameters.rsaDetail.symmetric.keyBits.aes = 128;
+	in.inPublic.publicArea.parameters.rsaDetail.symmetric.mode.aes = TPM_ALG_CFB;
+	in.inPublic.publicArea.parameters.rsaDetail.scheme.scheme = TPM_ALG_NULL;
+	in.inPublic.publicArea.parameters.rsaDetail.keyBits = 2048;
+	/* means conventional 2^16+1 */
+	in.inPublic.publicArea.parameters.rsaDetail.exponent = 0;
+	in.inPublic.publicArea.unique.rsa.t.size = 0;
+	in.inPublic.publicArea.authPolicy.t.size = 0;
+
+	rc = TSS_Execute(tssContext,
+			 (RESPONSE_PARAMETERS *)&out,
+			 (COMMAND_PARAMETERS *)&in,
+			 NULL,
+			 TPM_CC_CreatePrimary,
+			 TPM_RS_PW, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0,
+			 TPM_RH_NULL, NULL, 0);
+
+	if (rc) {
+		tpm2_error(rc, "TSS_CreatePrimarhy");
+		return rc;
+	}
+
+	hSRK = out.objectHandle;
+	srk_pub = out.outPublic;
+ out:
+	*h = hSRK;
+	if (pub)
+		*pub = srk_pub;
+
+	return 0;
+}
+
+void tpm2_flush_srk(TSS_CONTEXT *tssContext)
+{
+	if (hSRK)
+		tpm2_flush_handle(tssContext, hSRK);
+	hSRK = 0;
+}
+
+void tpm2_flush_handle(TSS_CONTEXT *tssContext, TPM_HANDLE h)
+{
+	FlushContext_In in;
+
+	if (!h)
+		return;
+
+	in.flushHandle = h;
+	TSS_Execute(tssContext, NULL,
+		    (COMMAND_PARAMETERS *)&in,
+		    NULL,
+		    TPM_CC_FlushContext,
+		    TPM_RH_NULL, NULL, 0);
+}
+
+static EVP_PKEY *tpm2_to_openssl_public_rsa(TPMT_PUBLIC *pub)
+{
+	RSA *rsa = RSA_new();
+	EVP_PKEY *pkey;
+	unsigned long exp;
+	BIGNUM *n, *e;
+
+	if (!rsa)
+		return NULL;
+	pkey = EVP_PKEY_new();
+	if (!pkey)
+		goto err_free_rsa;
+	e = BN_new();
+	if (!e)
+		goto err_free_pkey;
+	n = BN_new();
+	if (!n)
+		goto err_free_e;
+	if (pub->parameters.rsaDetail.exponent == 0)
+		exp = 0x10001;
+	else
+		exp = pub->parameters.rsaDetail.exponent;
+	if (!BN_set_word(e, exp))
+		goto err_free;
+	if (!BN_bin2bn(pub->unique.rsa.t.buffer, pub->unique.rsa.t.size, n))
+		goto err_free;
+#if OPENSSL_VERSION_NUMBER < 0x10100000
+	rsa->n = n;
+	rsa->e = e;
+#else
+	RSA_set0_key(rsa, n, e, NULL);
+#endif
+	if (!EVP_PKEY_assign_RSA(pkey, rsa))
+		goto err_free;
+
+	return pkey;
+
+ err_free:
+	BN_free(n);
+ err_free_e:
+	BN_free(e);
+ err_free_pkey:
+	EVP_PKEY_free(pkey);
+ err_free_rsa:
+	RSA_free(rsa);
+
+	return NULL;
+}
+
+EVP_PKEY *tpm2_to_openssl_public(TPMT_PUBLIC *pub)
+{
+	switch (pub->type) {
+	case TPM_ALG_RSA:
+		return tpm2_to_openssl_public_rsa(pub);
+	default:
+		break;
+	}
+	return NULL;
+}
+
diff --git a/tpm2-common.h b/tpm2-common.h
new file mode 100644
index 0000000..abd750b
--- /dev/null
+++ b/tpm2-common.h
@@ -0,0 +1,10 @@
+#ifndef _TPM2_COMMON_H
+#define _TPM2_COMMON_H
+
+void tpm2_error(TPM_RC rc, const char *reason);
+TPM_RC tpm2_load_srk(TSS_CONTEXT *tssContext, TPM_HANDLE *h, const char *auth, TPM2B_PUBLIC *pub);
+void tpm2_flush_handle(TSS_CONTEXT *tssContext, TPM_HANDLE h);
+EVP_PKEY *tpm2_to_openssl_public(TPMT_PUBLIC *pub);
+void tpm2_flush_srk(TSS_CONTEXT *tssContext);
+
+#endif
-- 
2.6.6