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

On Wed, 2016-11-23 at 10:53 +, David Woodhouse wrote: > On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote: > > > > Right... > > > > But then, embedding everything in an OCTET STRING isn't exactly a > > novel idea either. How do we discern a DER encoded TSS KEY BLOB > > from whatever

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

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote: > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov > 2016 11:57:42 +, David Woodhouse said: > > dwmw2> Besides, it requires files in the form described by the > Portable Data > dwmw2> section of

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

On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote: > On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote: > > > > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything > > else is > > dwmw2> redundant anyway. > > > > Oh! Ok, that makes things much simpler (at least in

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

On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote: > > > It does this by trying to interpret the blob against known ASN.1 > > > definitions, and will only succeed when there's a complete match. > > > I'm > > > not terribly worried... > > I am. With locales and UTF8, the old simple days of

[openssl-dev] [RFC 1/2] engine: add new flag based method for loading engine keys

that the key_id is actually a bio pointer. Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com> --- crypto/engine/eng_int.h | 1 + crypto/engine/eng_pkey.c | 38 ++ crypto/engine/engine.h | 26 ++ 3 files changed, 65 inse

[openssl-dev] [PATCH] openssl tpm engine: add new openssl bio method for seamless loading of tpm keys

Permits this engine to be used as part of the openssl pem routines for loading TPM based keys. To use this, the tpm engine must be preloaded via the openssl.cnf file Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com> diff --git a/e_tpm.c b/e_tpm.c index 3e20f8e..9cb1d6c

[openssl-dev] [RFC 2/2] pem: load engine keys

Before trying to process the PEM file, hand it to each of the loaded engines to see if they can load it. This uses the new bio based callback, so the engine must be loaded and implement this callback to be considered. Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com> --- cryp

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

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: https://build.opensuse.org/project/show/home:jejb1:Tumbleweed James --- James Bottomley (2): engine: add new flag based method for loading engine

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

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

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

On Tue, 2016-12-13 at 22:28 +, David Woodhouse wrote: > On Tue, 2016-12-13 at 13:09 +, 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.

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Tue, 2016-12-06 at 17:47 +0100, Richard Levitte wrote: > In message <1481042048.4406.14.ca...@hansenpartnership.com> on Tue, > 06 Dec 2016 08:34:08 -0800, James Bottomley < > james.bottom...@hansenpartnership.com> said: > > James.Bottomley> On Tue, 2016-12-06 a

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote: > In message <1480697558.2410.33.ca...@hansenpartnership.com> on Fri, > 02 Dec 2016 08:52:38 -0800, James Bottomley < > james.bottom...@hansenpartnership.com> said: > > James.Bottomley> On Thu, 2016-12-01 a

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

On Wed, 2016-12-14 at 17:05 +, 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 > > > attem

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

On Wed, 2016-12-14 at 09:07 +, 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

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Thu, 2016-12-08 at 23:44 +, 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

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Thu, 2016-12-08 at 15:56 -0800, James Bottomley wrote: > On Thu, 2016-12-08 at 23:44 +, 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 heade

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Fri, 2016-12-09 at 00:25 +, 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 >

[openssl-dev] [PATCH] openssl tpm engine: add new openssl bio method for seamless loading of tpm keys

Permits this engine to be used as part of the openssl pem routines for loading TPM based keys. To use this, the tpm engine must be preloaded via the openssl.cnf file Signed-off-by: James Bottomley <j...@linux.vnet.ibm.com> --- configure.in | 2 + e_tpm.c

[openssl-dev] [RFC v2 2/2] pem: load engine keys

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 <j...@linux.vnet.ibm.

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

> Thanks for working to improve openssl. You're welcome. > It is probably easier for you to do a GitHub pull request and then > have discussion here, pointing to that PR. Actually, being a kernel developer, email is far easier. I'll send a pull request when everyone's OK with the mechanism,

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Wed, 2016-11-30 at 16:04 +, Salz, Rich wrote: > > Groan ... since you're changing licences, I don't suppose you'd > > consider moving to a DCO model. > > Sorry, no. Legal advice and best practices. Interesting: whose legal advice? I assumed you were talking to the SFLC and I thought

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

://build.opensuse.org/project/show/home:jejb1:Tumbleweed James --- v2: make bio callback explicit vi new method rather than overloading keyid --- James Bottomley (2): engine: add new bio based method for loading engine keys pem: load engine keys crypto/engine/eng_int.h | 1 + crypto

[openssl-dev] [RFC v2 1/2] engine: add new bio based method for loading engine keys

Some engines have a PEM format for their keys, so add a mechanism whereby these keys can be read in to EVP_PKEY structures backed by the engine methods. The expectation is that each engine that wants to use this will define its own unique guard tags for the PEM file. Signed-off-by: James

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Wed, 2016-11-30 at 17:59 +, Salz, Rich wrote: > > > Plus the DCO is industry best practice: even OpenStack is adopting > > it after a > > long struggle. > > Great. Good for them. > > This is what we're doing. > > :) OK, so where is the foundation charter and who are your lawyers?

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Wed, 2016-11-30 at 19:32 +, Salz, Rich wrote: > > OK, so where is the foundation charter and who are your lawyers? > > Wow, this seems to have taken a turn to the unfriendly. I apologize > if I added to that. Sometimes a smiley doesn't wipe out all bad > impressions. No, it's standard

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

On Wed, 2016-11-30 at 21:41 +, Blumenthal, Uri - 0553 - MITLL wrote: > >> So why is it better to say “…engine –key > /some/weird/path/weird > >> -file.pem” than “…engine –key pkcs11:id=02” (or such)? > > > > There appears to be some confusion here. pkcs11 is a > representation

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

On Wed, 2016-11-30 at 21:18 +, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" < > openssl-dev-boun...@openssl.org on behalf of > james.bottom...@hansenpartnership.com> wrote: > > > One of the pri

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

le, 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. James > Cheers > Richard > > On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley < > james.bottom...@hansenpartnership

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote: > > James Bottomley <james.bottom...@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...

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote: > > James Bottomley <james.bottom...@hansenpartnership.com> skrev: (1 > december 2016 07:36:26 CET) > > On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote: > > > > > > James Bottomley <ja

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

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 u

Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Tue, 2017-01-03 at 16:11 -0700, Jason Gunthorpe wrote: > On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote: > > 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 > > s

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Mon, 2017-01-02 at 18:22 +, Salz, Rich wrote: > > I'm still waiting on a reply ... I assume holidays are contributing > > to the delay. However, openssl_tpm_engine is a DCO project, so that > > concern is irrelevant here. > > Sorry, I'll push to get the bylaws made public, is that what

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Tue, 2017-01-03 at 12:19 +0100, Richard Levitte wrote: > ⁣There seems to be some confusion here. > > James, I understand the tpm engine as an external project, not part > of the OpenSSL source proper and not intended to be. > > However, openssl-dev@openssl.org is a list focused on the

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Wed, 2017-01-04 at 00:04 +, Matt Caswell wrote: > > On 03/01/17 12:44, Salz, Rich wrote: > > > > I'm still waiting on a reply ... I assume holidays are > > > > contributing to the delay. > > > > However, openssl_tpm_engine is a DCO project, so that concern > > > > is > > > > irrelevant

Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Tue, 2017-01-03 at 16:40 -0700, Jason Gunthorpe wrote: > On Tue, Jan 03, 2017 at 03:22:56PM -0800, James Bottomley wrote: > > > I think it is very important to natively support the sign-only > > > key usage restriction. TPM1.2 goes so far as to declare keys that > >

[openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

) 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.bot

[openssl-dev] [PATCH 0/1] TPM2 engine support for openssl

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

Re: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

ICIT 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 &

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Mon, 2017-01-02 at 17:53 +, Salz, Rich wrote: > > Um, that's not really possible given that openssl_tpm_engine is a > > sourceforge project. > > Sure it is. Really, how? By pull request, you mean one against the openssl github account so people subscribing to that account see it, I

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Mon, 2017-01-02 at 17:38 +0100, Kurt Roeckx wrote: > On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote: > > 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. T

Re: [openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

On Fri, 2016-12-23 at 21:12 +0100, Richard Levitte wrote: > In message <1482516363.2501.34.ca...@hansenpartnership.com> on Fri, > 23 Dec 2016 10:06:03 -0800, James Bottomley < > james.bottom...@hansenpartnership.com> said: > > James.Bottomley> The reason this com

[openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

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

Re: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

On Sat, 2016-12-24 at 14:25 +0100, Nikos Mavrogiannopoulos wrote: > On Fri, Dec 23, 2016 at 7:06 PM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > The reason this comes about is because we already have a standard > > form for TPM 1.2 keys here: >

Re: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

On Sun, 2016-12-25 at 10:18 +0100, Nikos Mavrogiannopoulos wrote: > On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > I think, since it's a key format, the two above are the potential > > ones. It would

Re: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

On Sun, 2016-12-25 at 22:08 +0100, Nikos Mavrogiannopoulos wrote: > On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > TPMKey ::= SEQUENCE { > > > typeOBJECT IDENTIFIER > > >

[openssl-dev] [RFC 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

to. That's also why the signature has to be parsed into an X509_SIG before signing. Signed-off-by: James Bottomley <james.bottom...@hansenpartnership.com> --- Makefile.am | 12 +- create_tpm2_key.c | 381 ++ e_tpm2.c

[openssl-dev] [RFC 0/1] TPM2 engine support for openssl

he 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

Re: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

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

Re: [openssl-dev] License change agreement

On Fri, 2017-03-24 at 13:17 +, Salz, Rich via openssl-dev wrote: > > As was noted back when this was brought up in 2015, there are > > other, better, licenses than the APLv2 which are also GPLv2 > > compatible. The MPLv2 being an example of such a license. There > > is also BSD, MIT/X11,

Re: [openssl-dev] License change agreement

On Fri, 2017-03-24 at 10:06 +0100, Otto Moerbeek wrote: > On Fri, Mar 24, 2017 at 09:40:16AM +0100, Kurt Roeckx wrote: > > > On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote: > > > On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: > > > > > > > On Fri, Mar 24, 2017 at

Re: [openssl-dev] License change agreement

On Fri, 2017-03-24 at 20:02 +0100, Florian Weimer wrote: > * Quanah Gibson-Mount: > > > Zero people that I know of are saying to switch to the GPL. What > > is being pointed out is that the incompatibility with the current > > OpenSSL license with the GPLv2 has been a major problem. > > The

Re: [openssl-dev] License change agreement

On Fri, 2017-03-24 at 20:24 +0100, Kurt Roeckx wrote: > On Fri, Mar 24, 2017 at 12:22:14PM -0700, James Bottomley wrote: > > > > This is my understanding as well. From the GPL side, for both > > dynamic > > and static linking of openssl to GPLv2 code, the section 3 s

Re: [openssl-dev] License change agreement

On Fri, 2017-03-24 at 12:03 -0700, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 12:30 PM -0700 James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > > > Probably illegal and definitely immoral, in my opinion. Copyright > > > law

Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible

On Sat, 2017-03-25 at 16:10 +, Salz, Rich via openssl-dev wrote: > > > Please, in the final OpenSSL license text add the paragraph linked > > in the above LLVM mailing list as an exception to the Apache > > license. > > > > We should make sure using OpenSSL in GPLv2-only projects its > >

Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible

On Sat, 2017-03-25 at 21:48 +0100, Florian Weimer wrote: > * James Bottomley: > > > On Sat, 2017-03-25 at 16:10 +, Salz, Rich via openssl-dev > > wrote: > > > > > > > Please, in the final OpenSSL license text add the paragraph > > > > li

Re: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.

On Thu, 2017-10-26 at 13:57 +0200, Richard Levitte wrote: > In message