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 at 09:30 +0100, Richard Levitte wrote: James.Bottomley> > James.Bottomley> > James Bottomley <james.bottom...@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.bottom...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
