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

2016-12-02 Thread David Woodhouse
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

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


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

2016-12-02 Thread James Bottomley
On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote:
> 
> James Bottomley  skrev: (1
> december 2016 07:36:26 CET)
> > 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:
> > > > > 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

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


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

2016-12-02 Thread James Bottomley
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


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


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

2016-12-02 Thread Richard Levitte
In message <1479823032.8937.37.ca...@infradead.org> on Tue, 22 Nov 2016 
13:57:12 +, David Woodhouse  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev