Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Mon, 2016-11-21 at 13:50 +, Blumenthal, Uri - 0553 - MITLL wrote: > Frankly, I think this approach of specially-encoded PEM or DER files > telling the app what key to ask from the engine is madness, compared > to the straightforward URI approach (no pun intended :). Right. There are two separate things that the TPM can do for keys. There is storage in the TPM itself, and you can reference a key therein by its UUID. In Nikos's draft, and in GnuTLS, you end up with something like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user To use a PEM file for that does seem like madness; I agree. However, Nikos's draft also supports a URI of the form: tpmkey:file=/foo/bar/key.pem This, I do not like. It runs entirely contrary to my assertion in http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that applications should Just Bloody Work with whatever file they're handed, without needing to be *told* what the file contains. Besides, it requires files in the form described by the Portable Data section of the TSS (1.2) spec. That's a SEQUENCE with a blob type (which is mostly redundant as in this case we're always talking about key blobs), the blob length (which is entirely redundant) and then the actual blob as an OCTET STRING. I don't know of any tool which actually creates such files. The -BEGIN TSS KEY BLOB- PEM files which are created and used by both GnuTLS and OpenSSL TPM engine contain *just* the OCTET STRING containing the blob itself. I assert that if the application is given such a PEM blob (by filename, or just text embedded in a configuration file, or whatever), then it MUST NOT require any further information about the contents of that blob, except perhaps a password. I have updated my draft with a section about TPM keys: http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4 We should probably consolidate Nikos's now-expired draft with a documentation of the -BEGIN TSS KEY BLOB- PEM format, as well as bringing it up to date with the v2.0 specifications as appropriate. I'd *like* to think that we can punt it to PKCS#11 at least for TPM2, but I'm not sure. PKCS#11 doesn't make it easy to deal with the fact that there can be multiple PINs for the various keys in the chain, and doesn't easily cope with the fact that the key material might not be stored in the TPM and accessible by reference; it actually has to be *loaded*. I do not want to inflict another horror like nss-pem on the world... :) -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479744347.2309.21.ca...@hansenpartnership.com> on Mon, 21 Nov 2016 08:05:47 -0800, James Bottomley said: James.Bottomley> On Mon, 2016-11-21 at 13:42 +, David Woodhouse wrote: James.Bottomley> > On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote: James.Bottomley> > > James.Bottomley> > > Many years ago, I was thinking of something along the same lines, James.Bottomley> > > but with a .pem file that would just have a few headers, holding James.Bottomley> > > the name of the intended engine and the key identity, something James.Bottomley> > > like this: James.Bottomley> > > James.Bottomley> > > -BEGIN PRIVATE KEY- James.Bottomley> > > X-key-id: flarflarflar James.Bottomley> > > X-key-engine: foo James.Bottomley> > > -END PRIVATE KEY- James.Bottomley> > > James.Bottomley> > > The intent was that the PEM code would be massaged to recognise James.Bottomley> > > these headers and would then use ENGINE_by_id() / James.Bottomley> > > ENGINE_load_private_key() with those data and that would be it. James.Bottomley> > > James.Bottomley> > > James, did I catch your intention about right? I think that's James.Bottomley> > > essentially what e_tpm.c does for loading keys, right? James.Bottomley> James.Bottomley> Yes, that's right. When any SSL program sees a TPM wrapped key, it James.Bottomley> should just do the right thing if it has the engine capability without James.Bottomley> needing the user to add any options to the command line. Mm... I'm not sure I agree with the method, passing a BIO for the key_id. I would much rather have seen a patch where OpenSSL's PEM module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing it somehow (since key_id is expected to be be NUL terminated) and pass that to the engine. James.Bottomley> > Once the dust settles on TPMv2.0 we should probably put together an I James.Bottomley> > -D for the TPM-wrapped blob PEM files. And I should definitely add James.Bottomley> > something about them to ¹. James.Bottomley> James.Bottomley> Once we agree, I'll be happy to write up something. We can use the pem James.Bottomley> header concept to extend this format if it becomes necessary. My vote goes to a URI based spec rather than bastardising PEM files. I understand this kinda throws years of developmemt out the window, but there you have it. -- 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 13:48 +0100, Richard Levitte wrote: > Mm... I'm not sure I agree with the method, passing a BIO for the > key_id. I would much rather have seen a patch where OpenSSL's PEM > module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob > from it, securing it somehow (since key_id is expected to be be NUL > terminated) and pass that to the engine. Agreed. > My vote goes to a URI based spec rather than bastardising PEM files. > I understand this kinda throws years of developmemt out the window, > but there you have it. I think we need both. We need the URI for the keys stored *in* the TPM where we just need to reference them. And we need (non-bastardised) PEM files with TPM-wrapped key blobs. The latter is what the engine supports right now (by filename only). -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
> would much rather have seen a patch where OpenSSL's PEM module is > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing Yes, that would be much more consistent with the existing OpenSSL code which -- like it or not -- works that way. > My vote goes to a URI based spec rather than bastardising PEM files. Sure, if you can figure out which URI scheme to use; there are many of them. :) /r$ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 11:57:42 +, David Woodhouse said: dwmw2> On Mon, 2016-11-21 at 13:50 +, Blumenthal, Uri - 0553 - MITLL dwmw2> wrote: dwmw2> > Frankly, I think this approach of specially-encoded PEM or DER files dwmw2> > telling the app what key to ask from the engine is madness, compared dwmw2> > to the straightforward URI approach (no pun intended :). dwmw2> dwmw2> Right. There are two separate things that the TPM can do for keys. dwmw2> dwmw2> There is storage in the TPM itself, and you can reference a key therein dwmw2> by its UUID. In Nikos's draft, and in GnuTLS, you end up with something dwmw2> like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user dwmw2> dwmw2> To use a PEM file for that does seem like madness; I agree. dwmw2> dwmw2> However, Nikos's draft also supports a URI of the form: dwmw2> tpmkey:file=/foo/bar/key.pem dwmw2> dwmw2> This, I do not like. It runs entirely contrary to my assertion in dwmw2> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that dwmw2> applications should Just Bloody Work with whatever file they're handed, dwmw2> without needing to be *told* what the file contains. Not sure I follow... 'file=/foo/bar/key.pem' is just a path / parameter that the 'tpmkey' handler is free to interpret in whatever way it sees fit. For me as a user, it's just a string. For all I care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ==' That doesn't say anything about the contents of /foo/bar/key.pem, not more than file:/foo/bar/key.pem does, or even if there actually is a file /foo/bar/key.pem. Maybe I misunderstand what you're after... -- 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote: > > would much rather have seen a patch where OpenSSL's PEM module is > > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, > > securing > > Yes, that would be much more consistent with the existing OpenSSL > code which -- like it or not -- works that way. Yeah. Although I'd note that the OpenSSL code only works that way for PEM files. I really want to make it work the same way for DER files too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't have to call different functions for PEM vs. DER files anyway. > > My vote goes to a URI based spec rather than bastardising PEM files. > > Sure, if you can figure out which URI scheme to use; there are many > of them. :) For TPM I am not aware of any scheme other than the one set out in https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01 -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote: > > Not sure I follow... 'file=/foo/bar/key.pem' is just a path / > parameter that the 'tpmkey' handler is free to interpret in whatever > way it sees fit. For me as a user, it's just a string. For all I > care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ==' > That doesn't say anything about the contents of /foo/bar/key.pem, not > more than file:/foo/bar/key.pem does, or even if there actually is a > file /foo/bar/key.pem. Maybe I misunderstand what you're after... Where files are involved, I do not want the application to be told: pkcs8:/foo/bar/key pkcs1:/foo/bar/key pkcs12:/foo/bar/key or tpmkey:/foo/bar/key I only want the application to be told "/foo/bar/key" It should work out what the contents are for *itself*. Whether they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. And if the string it's given *isn't* a filename but is instead a PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just Work too. User pass string identifying key. Application Just Work™. dwmw2 happy. -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479820158.8937.29.ca...@infradead.org> on Tue, 22 Nov 2016 13:09:18 +, David Woodhouse said: dwmw2> On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote: dwmw2> > > would much rather have seen a patch where OpenSSL's PEM module is dwmw2> > > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing dwmw2> > dwmw2> > Yes, that would be much more consistent with the existing OpenSSL dwmw2> > code which -- like it or not -- works that way. dwmw2> dwmw2> Yeah. Although I'd note that the OpenSSL code only works that way for dwmw2> PEM files. I really want to make it work the same way for DER files dwmw2> too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't dwmw2> handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't dwmw2> have to call different functions for PEM vs. DER files anyway. Just let me shamelessly mention my STORE effort again ;-) Among others, it does attempt to solve that very problem (in the 'file' scheme handler). -- 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016 13:12:14 +, David Woodhouse said: dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Not sure I follow... 'file=/foo/bar/key.pem' is just a path / dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever dwmw2> > way it sees fit. For me as a user, it's just a string. For all I dwmw2> > care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ==' dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a dwmw2> > file /foo/bar/key.pem. Maybe I misunderstand what you're after... dwmw2> dwmw2> Where files are involved, I do not want the application to be told: dwmw2> pkcs8:/foo/bar/key dwmw2> pkcs1:/foo/bar/key dwmw2> pkcs12:/foo/bar/key or dwmw2> tpmkey:/foo/bar/key dwmw2> dwmw2> I only want the application to be told "/foo/bar/key" Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM type would be a way to go, wouldn't you say? That, or add functionality to have PEM content handlers added dynamically, one for each PEM content type. Just please, that "pass the BIO" hack... sorry, I'm not a supporter. dwmw2> It should work out what the contents are for *itself*. Whether they be dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. Yeah, got it... my thinking was on a tachnical level, that 'whatever.pem' would have to be handled by OpenSSL itself (or in URI terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem' would be handled by the 'tpmkey' scheme handler, which is a different story to me. I dunno about you, but to me, the URI scheme is not the same as an indication of what contents I'll get. But i guess that's a matter of interpretation. dwmw2> And if the string it's given *isn't* a filename but is instead a dwmw2> PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just dwmw2> Work too. You *do* indicate those with a URI scheme, though ;-) dwmw2> User pass string identifying key. Application Just Work™. dwmw2 happy. :-) Cheers, Richard ( who'd be *much* happier if his fingers didn't constantly want to typ tmpkey ;-) ) -- 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 14:32 +0100, Richard Levitte wrote: > In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016 > 13:12:14 +, David Woodhouse said: > > dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote: > dwmw2> > > dwmw2> > Not sure I follow... 'file=/foo/bar/key.pem' is just a path / > dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever > dwmw2> > way it sees fit. For me as a user, it's just a string. For all I > dwmw2> > care, the URI could just as well be > 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ==' > dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not > dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a > dwmw2> > file /foo/bar/key.pem. Maybe I misunderstand what you're after... > dwmw2> > dwmw2> Where files are involved, I do not want the application to be told: > dwmw2> pkcs8:/foo/bar/key > dwmw2> pkcs1:/foo/bar/key > dwmw2> pkcs12:/foo/bar/key or > dwmw2> tpmkey:/foo/bar/key > dwmw2> > dwmw2> I only want the application to be told "/foo/bar/key" > > Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM > type would be a way to go, wouldn't you say? That, or add functionality > to have PEM content handlers added dynamically, one for each PEM > content type. > Just please, that "pass the BIO" hack... sorry, I'm not a supporter. I think the number of "new" PEM formats is going to be vanishingly small, and it's OK to have knowledge of them hard-coded in OpenSSL rather than having a fully dynamic mechanism. Doing it dynamically would be painful — either the appropriate engine needs to be loaded already, or we need a mapping from PEM 'BEGIN' string to the engine name somehow. > dwmw2> It should work out what the contents are for *itself*. Whether they be > dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. > > Yeah, got it... my thinking was on a tachnical level, that > 'whatever.pem' would have to be handled by OpenSSL itself (or in URI > terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem' > would be handled by the 'tpmkey' scheme handler, which is a different > story to me. Yes, they end up being routed to the same engine via entirely different paths. Both need resolving, and we need not to conflate the two. -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: > > Just let me shamelessly mention my STORE effort again ;-) > Among others, it does attempt to solve that very problem (in the > 'file' scheme handler). Neat. Note that I have a ready-made test suite for you in OpenConnect: http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am For every one of the key files therein, does your current implementation work? :) (Yeah, I need to sort out the tpm emulator in the test environment, then add some -BEGIN TSS KEY BLOB- files too :) -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
> dwmw2> It should work out what the contents are for *itself*. Whether > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. I disagree with this approach, but that's just my opinion. I am worried about "keep trying something until it works" because you'll get strange errors you can't decode, 'only allow N tries' devices will lock you out, and the order in which you try things could result in needless long delays. But don't let that stop you. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message on Tue, 22 Nov 2016 14:42:35 +, "Salz, Rich" said: rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. rsalz> rsalz> I disagree with this approach, but that's just my opinion. I am worried about "keep trying something until it works" because you'll get strange errors you can't decode, 'only allow N tries' devices will lock you out, and the order in which you try things could result in needless long delays. rsalz> rsalz> But don't let that stop you. I *think* the guessing part is just about the step of loading the file content and transparently understanding what type of content it is. That's basically looking at a bunch of bytes and recognising it for what it is. When that's done, the trial and error phase is over, and for stuff that libcrypto has support for, libcrypto will be able to act, deterministically. >From the application point of view, this would be just one call, but we are talking OpenSSL internals now, aren't we? David, correct me if I got you wrong. 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
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? :) dwmw2> dwmw2> (Yeah, I need to sort out the tpm emulator in the test environment, dwmw2> then add some -BEGIN TSS KEY BLOB- files too :) All I can see is PEM files... For any PEM content that OpenSSL supports, the STORE 'file' scheme loader does as well. That's just a one liner, quite precisely this one: https://github.com/openssl/openssl/pull/1962/files#diff-34958ca30387ac75fa5011f98c18b3baR69 The more interesting part is when it tries to load files it guesses are raw DER. It's currently only trying a few chosen content types, I'm happy to add more as time goes. However, I suspect that nothing in your test suite will trigger that part. TSS KEY BLOBs is a different thing. That needs added PEM support, and the STORE 'file' scheme loader will not have to be changed at all. 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
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 the TSS (1.2) spec. That's a SEQUENCE with a blob type dwmw2> (which is mostly redundant as in this case we're always talking about dwmw2> key blobs), the blob length (which is entirely redundant) and then the dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually dwmw2> creates such files. I'm just having a look at the spec (page 151 in http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf), and am a bit confused by the TssBlobType type. Which is it in practice, an ENUMERATED or an INTEGER? -- 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
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 the TSS (1.2) spec. That's a SEQUENCE with a blob > type > dwmw2> (which is mostly redundant as in this case we're always > talking about > dwmw2> key blobs), the blob length (which is entirely redundant) and > then the > dwmw2> actual blob as an OCTET STRING. I don't know of any tool which > actually > dwmw2> creates such files. > > I'm just having a look at the spec (page 151 in > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat > a_A-final.pdf), and am a bit confused by the TssBlobType type. Which > is it in practice, an ENUMERATED or an INTEGER? It's actually here: http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf It's around page 101, section 10.3 the TPM_KEY12 structure. That tells you what to encrypt and how to construct the encrypted part of the blob. It refers to other structures, so you end up doing a bit of a pointer chase through the document. James -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote: > The more interesting part is when it tries to load files it guesses > are raw DER. It's currently only trying a few chosen content types, > I'm happy to add more as time goes. However, I suspect that nothing > in your test suite will trigger that part. There's a selection of .der and .p12 files there too. Adding non-ASCII passwords and running in different locales (and stress-testing both the old and the new PKCS#12 BMPstring bugs) is still on my TODO list. -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 16:07 +0100, Richard Levitte wrote: > In message > on > Tue, 22 Nov 2016 14:42:35 +, "Salz, Rich" said: > > rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether > rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. > rsalz> > rsalz> I disagree with this approach, but that's just my opinion. I am > worried about "keep trying something until it works" because you'll get > strange errors you can't decode, 'only allow N tries' devices will lock you > out, and the order in which you try things could result in needless long > delays. > rsalz> > rsalz> But don't let that stop you. > > I *think* the guessing part is just about the step of loading the file > content and transparently understanding what type of content it is. > That's basically looking at a bunch of bytes and recognising it for > what it is. When that's done, the trial and error phase is over, and > for stuff that libcrypto has support for, libcrypto will be able to > act, deterministically. > > From the application point of view, this would be just one call, but > we are talking OpenSSL internals now, aren't we? > > David, correct me if I got you wrong. You have it entirely correct. Rich has a valid concern for the general case, but it doesn't apply *here* because we're just talking about interpreting files. No hardware token is going to get upset and lock you out, just because you actually look inside the file and work out what type it is, then treat it as that — instead of forcing the *application* to look inside the file first, then invoke the crypto library differently for each type of file (or URI), as shown at http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c#l827 Basically, for every line in that load_certificate() function and the subfunctions it calls, I hate you :) When it comes to talking to real hardware, Rich is absolutely right. You don't just keep trying there. So if you look at the 'Locating objects in PKCS#11' section of my best practice draft¹ you'll see that you're only supposed to log into a given token if you *know* that's the one you need — either because you're looking for a key and you've already found the corresponding certificate in that token without having to log in, or because the PKCS#11 URI actually *specified* the token unambiguously. But that's a separate issue. -- dwmw2 ¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.8 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 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 the TSS (1.2) spec. That's a SEQUENCE with a blob type > dwmw2> (which is mostly redundant as in this case we're always talking about > dwmw2> key blobs), the blob length (which is entirely redundant) and then the > dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually > dwmw2> creates such files. > > I'm just having a look at the spec (page 151 in > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf), > and am a bit confused by the TssBlobType type. Which is it in > practice, an ENUMERATED or an INTEGER? In practice, it doesn't get used at all. The object encoded with -BEGIN TSS KEY BLOB- and used by both the OpenSSL TPM ENGINE and by GnuTLS is not the TssBlob object that you're looking at. It is *only* the OCTET STRING of the blob itself. Everything else is redundant anyway. $ openssl asn1parse -i -in tpmkey.pem -inform pem 0:d=0 hl=4 l= 559 prim: OCTET STRING [HEX DUMP]:0101001500060100020003000C0802000 00100D6791E892D6B93830F026C6C66B365A0B61B3CBB5B36EA1A13 C67111D49711719E665B5EBAAB5F9CB04D7CC87C78DE56700CD6A8F9B94C92DF029983F 2DA8883841090CEAACD53453516843FEF6689AC5E7D8102B85141B86B2F0E8C99124A70 90C5FB35A902D672E56D2BC2654317DCF578692B8CC441E08E3CCEF8CE86219822250CA 3A23A70EF69B3A092B3DFA70F049B712B885B8EA576C9F3F4E54107DB8F8D678CCF376D 9299BB47013318999FA8099180815D99F90646588508AACF7527E7A6D38C6C53B78C9BA 6F693069F2906B82E5500D5209489E48C29A4B487564AC64CED3FC61D88EF0C27C0E5EE 5AFEB861E3B104F8FCABDBE07DBE4FE42D2B010091175251D67BE97DB4A4F48EF5D 515E9ED64287BF2DFCCCDD6E6791AADC7E6752F2A2DCD3CBC29AB8660947B78C1F15C30 26369AC4A6B5434996CDB3CA659A2A2F48BE26B7E3C5AEBD75A6B6BCB376650138DCAD0 00E46BD94139A9DD596355C0469463E0E7D68C9997724EC7CFACDDC8EFA3C81045F5076 284BA2CA0B935DCFC28793D1BC9E8D2F4F141788B92DA93D3B370C8A24AFF59DEAAC81F 5A96C2299CBA74AA651E0AF92122B4F7524D08027DA71EDB191B115722AEB7F97817346 4484778FF88BC56815420791D7F9FB1ADD781D979A85D69F31970F228A6A12C6FD4FC3C AF7A9F8F933818D436C5552D7B60A1E48CDEC7E38FC452A359C6E1609EC $ openconnect -c cert.pem -k tpmkey.pem auth.startssl.com -v POST https://auth.startssl.com/ Attempting to connect to server 104.192.110.244:443 Connected to 104.192.110.244:443 Using certificate file cert.pem Using private key file tpmkey.pem TPM sign function called for 35 bytes. Using client certificate '192.168.123.1' TPM sign function called for 51 bytes. SSL negotiation with auth.startssl.com ... -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 07:44 -0800, James Bottomley wrote: > > > I'm just having a look at the spec (page 151 in > > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat > > a_A-final.pdf), and am a bit confused by the TssBlobType type. Which > > is it in practice, an ENUMERATED or an INTEGER? > > It's actually here: > > http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf > > It's around page 101, section 10.3 the TPM_KEY12 structure. That tells > you what to encrypt and how to construct the encrypted part of the > blob. It refers to other structures, so you end up doing a bit of a > pointer chase through the document. The TPM_KEY12 structure is what's in the OCTET STRING (that I just showed). But I believe we're looking at the ASN.1 on page 151 (§3.23 "Portable Data") of the TSS spec: TssBlobType ::= ENUMERATED { Key-Blob (1),-- TCPA_KEY as returned from TPM PubKey-Blob (2), -- TCPA_PUBKEY as returned from TPM MigKey-Blob (3), -- TCPA_KEY as return from the TSP Tspi_Key_CreateMigrationBlob In dedicated mode (see the command for details) SealedData-Blob (4), -- TCPA_STORED_DATA as returned from TPM ... } TssBlobType ::= INTEGER TssBlob ::= SEQUENCE { StructVersion INTEGER, -- Version of this structure; at the moment 1 BlobType TssBlobType, -- Type of Blob; see enum BlobLength INTEGER,-- Length of Blob Blob OCTET STRING -- Blob as returned from TPM (no ASN1 encoding) } To my knowledge nothing actually *implements* this TssBlob. Those PEM files (like the one I just showed) only contain the OCTET STRING. -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479829450.2376.10.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 07:44:10 -0800, James Bottomley said: James.Bottomley> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote: James.Bottomley> > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov James.Bottomley> > 2016 11:57:42 +, David Woodhouse said: James.Bottomley> > James.Bottomley> > dwmw2> Besides, it requires files in the form described by the James.Bottomley> > Portable Data James.Bottomley> > dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob James.Bottomley> > type James.Bottomley> > dwmw2> (which is mostly redundant as in this case we're always James.Bottomley> > talking about James.Bottomley> > dwmw2> key blobs), the blob length (which is entirely redundant) and James.Bottomley> > then the James.Bottomley> > dwmw2> actual blob as an OCTET STRING. I don't know of any tool which James.Bottomley> > actually James.Bottomley> > dwmw2> creates such files. James.Bottomley> > James.Bottomley> > I'm just having a look at the spec (page 151 in James.Bottomley> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat James.Bottomley> > a_A-final.pdf), and am a bit confused by the TssBlobType type. Which James.Bottomley> > is it in practice, an ENUMERATED or an INTEGER? James.Bottomley> James.Bottomley> It's actually here: James.Bottomley> James.Bottomley> http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf James.Bottomley> James.Bottomley> It's around page 101, section 10.3 the TPM_KEY12 structure. That tells James.Bottomley> you what to encrypt and how to construct the encrypted part of the James.Bottomley> blob. It refers to other structures, so you end up doing a bit of a James.Bottomley> pointer chase through the document. I'm sorry, I have obviously had you a bit confused. What I'm currently interested in is decoding the content of a 'TSS KEY BLOB' PEM file, and I assume that's a TssBlob type, yeah? 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 17:14 +0100, Richard Levitte wrote: > > I'm sorry, I have obviously had you a bit confused. What I'm > currently interested in is decoding the content of a 'TSS KEY BLOB' > PEM file, and I assume that's a TssBlob type, yeah? No, it's not. (Sorry!) -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479830167.8937.43.ca...@infradead.org> on Tue, 22 Nov 2016 15:56:07 +, David Woodhouse said: dwmw2> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote: dwmw2> > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 11:57:42 +, David Woodhouse said: dwmw2> > dwmw2> > dwmw2> Besides, it requires files in the form described by the Portable Data dwmw2> > dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type dwmw2> > dwmw2> (which is mostly redundant as in this case we're always talking about dwmw2> > dwmw2> key blobs), the blob length (which is entirely redundant) and then the dwmw2> > dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually dwmw2> > dwmw2> creates such files. dwmw2> > dwmw2> > I'm just having a look at the spec (page 151 in dwmw2> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf), dwmw2> > and am a bit confused by the TssBlobType type. Which is it in dwmw2> > practice, an ENUMERATED or an INTEGER? dwmw2> dwmw2> In practice, it doesn't get used at all. The object encoded with dwmw2> -BEGIN TSS KEY BLOB- and used by both the OpenSSL TPM ENGINE dwmw2> and by GnuTLS is not the TssBlob object that you're looking at. dwmw2> 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 a way) -- 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
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 a way) Kind of. But then again, there's an argument that it was none of your business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to the TPM engine and after that you really don't care about what's in it. Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary files (no ASN.1 at all). For some reason it didn't use the TssBlob object type, although perhaps it should. When I started looking at it, I used the -BEGIN TSS KEY BLOB- for an OCTET STRING containing *just* that the code had previously been writing into its binary files. If I'd been aware of the TssBlob definition at that time, I suppose I would have used it instead of just the OCTET STRING. But I didn't. If we write an I-D covering the TPM keys, perhaps the PEM contents should be permitted to be *either* a raw OCTET STRING with the key blob, OR a TssBlob object. Or maybe we should add a BEGIN TSS BLOB- (without 'KEY' in it) instead? -- 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 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 a way) > > Kind of. But then again, there's an argument that it was none of your > business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to > the > TPM engine and after that you really don't care about what's in it. > > Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary > files (no ASN.1 at all). For some reason it didn't use the TssBlob > object type, although perhaps it should. > > When I started looking at it, I used the -BEGIN TSS KEY BLOB- > for an OCTET STRING containing *just* that the code had previously > been > writing into its binary files. > > If I'd been aware of the TssBlob definition at that time, I suppose I > would have used it instead of just the OCTET STRING. But I didn't. > > If we write an I-D covering the TPM keys, perhaps the PEM contents > should be permitted to be *either* a raw OCTET STRING with the key > blob, OR a TssBlob object. Or maybe we should add a > BEGIN TSS BLOB- (without 'KEY' in it) instead? Before we rathole on this: if we use the current code to just hand off to the engine, openssl never needs to know the format of the key files or even what they mean. If we hard code recognising TPM keys into openssl, we are going to have to agree (and stick to) a key format. This is one of the decisions that needs making to transform the RFC into a real patch. I will note that gnutls does hard code recognising TPM keys so there's precedent for doing it that way. However, I have a marginal preference for letting the loaded engines do it because that's the way that gives most flexibility with regard to new engines as they come along. This problem isn't theoretical: TPM 2.0 keys are very different from TPM 1.2 ones, so they'll likely have a new engine to handle them and a new file format. James 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479833048.2376.21.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 08:44:08 -0800, James Bottomley said: James.Bottomley> On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote: James.Bottomley> > On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote: James.Bottomley> > > James.Bottomley> > > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything James.Bottomley> > > else is James.Bottomley> > > dwmw2> redundant anyway. James.Bottomley> > > James.Bottomley> > > Oh! Ok, that makes things much simpler (at least in a way) James.Bottomley> > James.Bottomley> > Kind of. But then again, there's an argument that it was none of your James.Bottomley> > business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to James.Bottomley> > the James.Bottomley> > TPM engine and after that you really don't care about what's in it. James.Bottomley> > James.Bottomley> > Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary James.Bottomley> > files (no ASN.1 at all). For some reason it didn't use the TssBlob James.Bottomley> > object type, although perhaps it should. James.Bottomley> > James.Bottomley> > When I started looking at it, I used the -BEGIN TSS KEY BLOB- James.Bottomley> > for an OCTET STRING containing *just* that the code had previously James.Bottomley> > been James.Bottomley> > writing into its binary files. James.Bottomley> > James.Bottomley> > If I'd been aware of the TssBlob definition at that time, I suppose I James.Bottomley> > would have used it instead of just the OCTET STRING. But I didn't. James.Bottomley> > James.Bottomley> > If we write an I-D covering the TPM keys, perhaps the PEM contents James.Bottomley> > should be permitted to be *either* a raw OCTET STRING with the key James.Bottomley> > blob, OR a TssBlob object. Or maybe we should add a James.Bottomley> > BEGIN TSS BLOB- (without 'KEY' in it) instead? James.Bottomley> James.Bottomley> Before we rathole on this: if we use the current code to just hand off James.Bottomley> to the engine, openssl never needs to know the format of the key files James.Bottomley> or even what they mean. If we hard code recognising TPM keys into James.Bottomley> openssl, we are going to have to agree (and stick to) a key format. James.Bottomley> This is one of the decisions that needs making to transform the RFC James.Bottomley> into a real patch. James.Bottomley> James.Bottomley> I will note that gnutls does hard code recognising TPM keys so there's James.Bottomley> precedent for doing it that way. However, I have a marginal preference James.Bottomley> for letting the loaded engines do it because that's the way that gives James.Bottomley> most flexibility with regard to new engines as they come along. This James.Bottomley> problem isn't theoretical: TPM 2.0 keys are very different from TPM 1.2 James.Bottomley> ones, so they'll likely have a new engine to handle them and a new file James.Bottomley> format. Actually, I agree with this, and that goes along with how our PEM routines work (specifically, PEM_X509_INFO_read_bio()), it just treats the data as an octet string and hands it down to a d2i routine of choice, with a pointer to where to place the result. It's not very hard to imagine adding the possibility for external handlers for specific PEM content types, which could be handed an octet string and a pointer to a X509_INFO (which is the structure used to collect the data in), or something like that (I can also imagine having one separate handler for each type of data that can be returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL, and so on and so forth). That would make it possible for an engine to declare its own handler during the binding call, along with all other information it feeds back to libcrypto. 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
> The more interesting part is when it tries to load files it guesses are raw > DER. And this part worries me. I do not think a "security library" should be guessing. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 17:40:54 +, "Salz, Rich" said: rsalz> > The more interesting part is when it tries to load files it guesses are raw DER. rsalz> rsalz> And this part worries me. I do not think a "security library" should be guessing. 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... -- 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 18:46 +0100, Richard Levitte wrote: > In message > <489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on > Tue, 22 Nov 2016 17:40:54 +, "Salz, Rich" said: > > rsalz> > The more interesting part is when it tries to load files it guesses > are raw DER. > rsalz> > rsalz> And this part worries me. I do not think a "security library" should > be guessing. > > 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... And even if you were, you should be *more* worried about making *applications* do it for themselves :) -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
> > 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 text/binary are probably long gone. And if any ASN.1 definition has extensibility in it, then we have to be concerned about things being wrapped, something like prefix attacks, and so on. > And even if you were, you should be *more* worried about making > *applications* do it for themselves :) I cannot control what an application does, and I am not responsible for any other application's reputation. I do have a strongly vested stake in OpenSSL's. It is already possible to write a utility library that tries everything in turn, and returns an enumeration that says "seems to be an X509 certificate" etc. And then another routine that takes that enumeration and the blob and calls the right decoder. I would be okay with that, even if it were part of OpenSSL. I am opposed to guessing and parsing in one step, and would -1 any PR for that, forcing a team discussion. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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 text/binary are > probably long gone. And if any ASN.1 definition has extensibility in > it, then we have to be concerned about things being wrapped, > something like prefix attacks, and so on. > > > And even if you were, you should be *more* worried about making > > *applications* do it for themselves :) > > I cannot control what an application does, and I am not responsible > for any other application's reputation. I do have a strongly vested > stake in OpenSSL's. > > It is already possible to write a utility library that tries > everything in turn, and returns an enumeration that says "seems to be > an X509 certificate" etc. And then another routine that takes that > enumeration and the blob and calls the right decoder. I would be > okay with that, even if it were part of OpenSSL. I am opposed to > guessing and parsing in one step, and would -1 any PR for that, > forcing a team discussion. That's not the proposal. The proposal is to use PEM form because we can make it uniquely self describing using the guard tags which obviates the problem above. On the larger issue of non-self describing formats like ASN.1: if your theory that there's a security hole by allowing opportunistic format detection is correct, simply making the user specify is palming our bug off on to the user and abdicating responsibility because now when they're tricked into an exploit they can be blamed not openssl. If such a bug exists, doing opportunistic format detection the better guarantor of overall system security because if such a bug is found, it would have to be fixed within openssl to everyone's benefit. James -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
> That's not the proposal. The proposal is to use PEM form because we can > make it uniquely self describing using the guard tags which obviates the > problem above. Well that's what you want. David wants more than that :) > On the larger issue of non-self describing formats like ASN.1: if your theory > that there's a security hole by allowing opportunistic format detection is > correct, simply making the user specify is palming our bug off on to the user > and abdicating responsibility because now when they're tricked into an > exploit they can be blamed not openssl. If such a bug exists, doing > opportunistic format detection the better guarantor of overall system > security because if such a bug is found, it would have to be fixed within > openssl to everyone's benefit. We differ. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
James.Bottomley> Yes, that's right. When any SSL program sees a TPM wrapped key, it James.Bottomley> should just do the right thing if it has the engine capability without James.Bottomley> needing the user to add any options to the command line. Mm... I'm not sure I agree with the method, passing a BIO for the key_id. I’m sure I rather disagree, and rather strongly. I would much rather have seen a patch where OpenSSL's PEM module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing it somehow (since key_id is expected to be be NUL terminated) and pass that to the engine. I would much rather use PEM only to contain keys/certs instead of “pointing” at them in some weird way. My vote goes to a URI based spec rather than bastardising PEM files. +10^101. ☺ I understand this kinda throws years of developmemt out the window, but there you have it. “It’s never too late to turn back on a wrong road” 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote: > > That's not the proposal. The proposal is to use PEM form because we can > > make it uniquely self describing using the guard tags which obviates the > > problem above. > > Well that's what you want. David wants more than that :) S'true :) > > On the larger issue of non-self describing formats like ASN.1: if your > > theory > > that there's a security hole by allowing opportunistic format detection is > > correct, simply making the user specify is palming our bug off on to the > > user > > and abdicating responsibility because now when they're tricked into an > > exploit they can be blamed not openssl. If such a bug exists, doing > > opportunistic format detection the better guarantor of overall system > > security because if such a bug is found, it would have to be fixed within > > openssl to everyone's benefit. > > We differ. We do. I think James put it well though, when he talked of "palming our bug off onto the user and abdicating responsibility". The library doesn't get to sit in its ivory tower of perfection; you are responsible for the API you inflict on users and how they actually *use* it. And besides, even if we force applications to iterate over the possible formats for themselves, they aren't going to have a bug *there*. Any bug will be in our parser for one specific format or another. We didn't even *save* our reputation by forcing the application authors to jump through hoops. And more to the point, you already *do* this, in d2i_AutoPrivateKey(). It's just that you only handle *some* of the known key formats, so the application has to explicitly try the others. What's being proposed here is merely that we fix that up to have full coverage — not a radical new approach at all. Oh, and that we automatically distinguish between PEM and DER forms, but *that* much is fairly trivial and safe. And the locale / character set issue is not relevant here. ASN.1 is binary, PEM is ASCII. When we come to talk about passwords, *sure* we can look at character sets. But that is a somewhat orthogonal issue. -- 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 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
On 11/22/16 2:37 PM, David Woodhouse wrote: On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote: And the locale / character set issue is not relevant here. ASN.1 is binary, PEM is ASCII. PEM should be ASCII; in practice it is not necessarily ASCII. There are several products that produce "PEM files" in various EBCDIC character sets. Other products produce them in ASCII, but then transfer them with an EBCDIC to ASCII conversion. And in still others, it's the customer who transfers it manually, converting from EBCDIC to ASCII when the file was ASCII. These latter two are less common in my limited experience, which is fortunate, because recovering from that is very difficult. I've also seen some windows products that will produce "unicode" pem files, which may or may not have a BOM at the beginning, and other products which produce the files with the UTF-8 BOM at the beginning, too. While it's easy for me to say these files are malformed, the customer doesn't care. They have the file; they expect it to work. In most of those cases, the user will open the file, and see exactly what they expect, a PEM header, followed by what looks like base64 encoded data, and a matching footer. It's very difficult to convince a customer the file is incorrect in the face of that. Even if you get them to acknowledge the file isn't in the expected format, again they don't care. They have the file, usually from some very expensive software or process, your much less important software had better use it (yup, I've had those conversations with customers, fortunately with tech support filtering my side of the conversation :) ). In any event, I don't think it's OpenSSL's job to detect and fix these kinds of issues. Although probably 90% of them could be fixed with a simple EBCDIC->ASCII converter, ignoring BOMs and recognizing the Windows "unicode" format. :) TOM -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 18:03:31 +, "Salz, Rich" said: rsalz> It is already possible to write a utility library that tries rsalz> everything in turn, and returns an enumeration that says "seems rsalz> to be an X509 certificate" etc. And then another routine that rsalz> takes that enumeration and the blob and calls the right rsalz> decoder. I would be okay with that, even if it were part of rsalz> OpenSSL. I am opposed to guessing and parsing in one step, and rsalz> would -1 any PR for that, forcing a team discussion. Uh... the d2i functions are already both in one. Are you saying they should be split in two, one part that does all the checking and the other that just decodes, trusting that all checks are already done? What you're gonna do there is double part of the work. But, what I get from you is "what if a octet stream matches two different ASN.1 types? Is that it? -- 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
Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
In message <1479839148.2376.31.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 10:25:48 -0800, James Bottomley said: James.Bottomley> On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote: James.Bottomley> > > > It does this by trying to interpret the blob against known ASN.1 James.Bottomley> > > > definitions, and will only succeed when there's a complete match. James.Bottomley> > > > I'm James.Bottomley> > > > not terribly worried... James.Bottomley> > James.Bottomley> > I am. With locales and UTF8, the old simple days of text/binary are James.Bottomley> > probably long gone. And if any ASN.1 definition has extensibility in James.Bottomley> > it, then we have to be concerned about things being wrapped, James.Bottomley> > something like prefix attacks, and so on. James.Bottomley> > James.Bottomley> > > And even if you were, you should be *more* worried about making James.Bottomley> > > *applications* do it for themselves :) James.Bottomley> > James.Bottomley> > I cannot control what an application does, and I am not responsible James.Bottomley> > for any other application's reputation. I do have a strongly vested James.Bottomley> > stake in OpenSSL's. James.Bottomley> > James.Bottomley> > It is already possible to write a utility library that tries James.Bottomley> > everything in turn, and returns an enumeration that says "seems to be James.Bottomley> > an X509 certificate" etc. And then another routine that takes that James.Bottomley> > enumeration and the blob and calls the right decoder. I would be James.Bottomley> > okay with that, even if it were part of OpenSSL. I am opposed to James.Bottomley> > guessing and parsing in one step, and would -1 any PR for that, James.Bottomley> > forcing a team discussion. James.Bottomley> James.Bottomley> That's not the proposal. The proposal is to use PEM form because we James.Bottomley> can make it uniquely self describing using the guard tags which James.Bottomley> obviates the problem above. This is a side thread that discusses the 'file' scheme loader in my STORE effort. So, uhmmm, we're a bit away from just PEM here. However, if we go back to the discussion about TSS KEY BLOBs, yeah, I've only seen a PEM proposal, and that's a mch easier case. James.Bottomley> On the larger issue of non-self describing formats like ASN.1: if your James.Bottomley> theory that there's a security hole by allowing opportunistic format James.Bottomley> detection is correct, simply making the user specify is palming our bug James.Bottomley> off on to the user and abdicating responsibility because now when James.Bottomley> they're tricked into an exploit they can be blamed not openssl. If James.Bottomley> such a bug exists, doing opportunistic format detection the better James.Bottomley> guarantor of overall system security because if such a bug is found, it James.Bottomley> would have to be fixed within openssl to everyone's benefit. I agree with that sentiment. -- 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