- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 30 Mar 2016 19:24:28 +0200
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Dave Longley <dlongley@digitalbazaar.com>, Graham Leggett <minfrin@sharp.fm>, TAG List <www-tag@w3.org>, Tim Berners-Lee <timbl@w3.org>, Henry Story <henry.story@bblfish.net>
- Message-ID: <CAKaEYh+Mji9DsD6cHfGFV++4q-2fu_Gry70ijZO3op6XiqXx+w@mail.gmail.com>
On 30 March 2016 at 19:17, Eric Rescorla <ekr@rtfm.com> wrote: > > > On Wed, Mar 30, 2016 at 10:09 AM, Melvin Carvalho < > melvincarvalho@gmail.com> wrote: > >> >> >> On 30 March 2016 at 18:23, Dave Longley <dlongley@digitalbazaar.com> >> wrote: >> >>> On 03/30/2016 12:09 PM, Graham Leggett wrote: >>> >>>> On 30 Mar 2016, at 6:00 PM, Dave Longley <dlongley@digitalbazaar.com> >>>> wrote: >>>> >>>> As a quick, temporary replacement for keygen, you should be able to >>>>> use forge (or forge + WebCrypto) to generate a keypair and wrap it >>>>> in a PKCS#12 container that can be downloaded via a link that, when >>>>> clicked, may bring up an import dialog in the user's browser. They >>>>> may have to save the file first before importing, I'm not sure. >>>>> >>>>> forge: https://github.com/digitalbazaar/forge >>>>> >>>>> There's some somewhat messy X.509 cert creation and PKCS#12 code >>>>> that could be adapted from this issue: >>>>> >>>>> https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100 >>>>> >>>> >>>> >>>>> >>>>> Does this guarantee that the key was a) generated on the client side >>>> only (and not anywhere else and injected into the conversation), and >>>> b) that this key cannot be subsequently exported and uploaded to >>>> some third party location under the control of third party server >>>> code? >>>> >>> >>> The short answer is "No", as there is presently no direct replacement >>> for keygen. I was just offering a quick temporary fix. If it's true that >>> keygen has now been removed (not just deprecated), I would expect that >>> systems that relied upon it need *something* that they can throw >>> together quickly in the interim (meaning, until some other replacement >>> can solve their problem long term). >>> >> >> As I understand it keygen is NOT removed in firefox (or most versions of >> other browsers). >> > > Correct. > Great! > > > >> What I heard (perhaps someone will confirm) is that Mozilla will take >> the TAG advice, to remove existing functionality that is in use, only after >> it has been adequately replaced. >> > > I don't believe we've made any public statements to this effect. We still > intend to remove <keygen> but we don't presently have a published schedule > for it. > Thanks for the clarification. As an independent developer (that currently uses this technology) I am happy to see Mozilla offer this functionality. > > -Ekr > > >> >>> >>> The longer answer is that the key pair is, in fact, generated >>> client-side, however, using code that is controlled by the website. That >>> site must be trusted not to do anything nefarious with the private key >>> while the site has access to it. Once the key pair has been exported to >>> a PKCS#12 and imported into the user's local key store, and the site has >>> been navigated away from, the website has no access to the private key, >>> should, for example, the site become compromised in the future. >>> >>> >>> >>> -- >>> Dave Longley >>> CTO >>> Digital Bazaar, Inc. >>> http://digitalbazaar.com >>> >> >> >
Received on Wednesday, 30 March 2016 17:24:59 UTC