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
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 Bottomle
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
---
crypto/pem/pem_pkey.
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
---
configure.in | 2 +
e_tpm.c | 139 +++--
Thanks for working to improve openssl.
It is probably easier for you to do a GitHub pull request and then have
discussion here, pointing to that PR.
And also, before any of this code could be used, we'll need the appropriate CLA.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.or
> 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, plu
> Actually, being a kernel developer, email is far easier. I'll send a pull
> request
> when everyone's OK with the mechanism, plus it will need tests and other
> things.
Well... okay. I don't know how the community will react. But I *do* know that
the team prefers things as PR's.
> Groan
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 the
> 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.
:)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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?
Jam
> 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.
The OpenSSL Software Foundation is incorporated in the the state of Delaware,
Uni
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 if
> I suspect IBM will need to sign a CCLA ... they'll definitely need to know who
> your lawyers are.
We have a CCLA from IBM; contact Christopher Barrett.
> I did check those links ... they don't have any governance information about
> the actual openssl foundation that I can find.
If you want p
On 11/30/16, 10:24 AM, "openssl-dev on behalf of 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.
Why should token- and/or TPM-based keys be integrated with file-based keys?
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 principle problems of using TPM based
>> So why is it better to say “…engine –key /some/weird/path/weird
>> -file.pem” than “…engine –key pkcs11:id=02” (or such)?
>
> There appears to be some confusion here. pkcs11 is a representation
> for defined tokens.
Well, I did not mean *specifically* pkcs11 – just as an e
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
I confirm that this fix (currently in the master) resolves the issue.
Thanks!
—
Regards,
Uri
On 11/29/16, 4:53 AM, "openssl-dev on behalf of Matt Caswell"
wrote:
On 28/11/16 23:00, Blumenthal, Uri - 0553 - MITLL wrote:
> > The problem is in the test. Version negotiation
This patch doesn't fit the rest...
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.
Cheers
Richard
On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley
wrote:
>
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. To allow engines to load PEM encoded
engine keys in place of machine processed ones, the hook into the
loader has to be in somewhere. This seems to be the most generic
James Bottomley 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 late
On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
>
> James Bottomley 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 *.
22 matches
Mail list logo