Re: What we were using public key authentication for
Melvin Carvalho <[email protected]> Wed, 30 Mar 2016 19:24:28 +0200
| Newsgroups | gmane.org.w3c.tag |
|---|---|
| Message-ID | <CAKaEYh+Mji9DsD6cHfGFV++4q-2fu_Gry70ijZO3op6XiqXx+w@mail.gmail.com> |
--001a11418d1e0ed6f1052f476bfc Content-Type: text/plain; charset=UTF-8 On 30 March 2016 at 19:17, Eric Rescorla <[email protected]> wrote: > > > On Wed, Mar 30, 2016 at 10:09 AM, Melvin Carvalho < > [email protected]> wrote: > >> >> >> On 30 March 2016 at 18:23, Dave Longley <[email protected]> >> wrote: >> >>> On 03/30/2016 12:09 PM, Graham Leggett wrote: >>> >>>> On 30 Mar 2016, at 6:00 PM, Dave Longley <[email protected]> >>>> 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 >>> >> >> > --001a11418d1e0ed6f1052f476bfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On 30 March 2016 at 19:17, Eric Rescorla <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>></span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gma= il_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Wed, Mar= 30, 2016 at 10:09 AM, Melvin Carvalho <span dir=3D"ltr"><<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a= >></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>= <div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On 30 March= 2016 at 18:23, Dave Longley <span dir=3D"ltr"><<a href=3D"mailto:dlongl= [email protected]" target=3D"_blank">[email protected]</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 03/30/2016 12:09 P= M, Graham Leggett wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 30 Mar 2016, at 6:00 PM, Dave Longley <<a href=3D"mailto:dlongley@dig= italbazaar.com" target=3D"_blank">[email protected]</a>><br> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> As a quick, temporary replacement for keygen, you should be able to<br> use forge (or forge + WebCrypto) to generate a keypair and wrap it<br> in a PKCS#12 container that can be downloaded via a link that, when<br> clicked, may bring up an import dialog in the user's browser. They<br> may have to save the file first before importing, I'm not sure.<br> <br> forge: <a href=3D"https://github.com/digitalbazaar/forge" rel=3D"noreferrer= " target=3D"_blank">https://github.com/digitalbazaar/forge</a><br> <br> There's some somewhat messy X.509 cert creation and PKCS#12 code<br> that could be adapted from this issue:<br> <br> <a href=3D"https://github.com/digitalbazaar/forge/issues/211#issuecomment-8= 5447100" rel=3D"noreferrer" target=3D"_blank">https://github.com/digitalbaz= aar/forge/issues/211#issuecomment-85447100</a><br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> <br> </blockquote> Does this guarantee that the key was a) generated on the client side<br> =C2=A0only (and not anywhere else and injected into the conversation), and<= br> =C2=A0b) that this key cannot be subsequently exported and uploaded to<br> some third party location under the control of third party server<br> code?<br> </blockquote> <br></span> The short answer is "No", as there is presently no direct replace= ment<br> for keygen. I was just offering a quick temporary fix. If it's true tha= t<br> keygen has now been removed (not just deprecated), I would expect that<br> systems that relied upon it need *something* that they can throw<br> together quickly in the interim (meaning, until some other replacement<br> can solve their problem long term).<br></blockquote><div><br></div></span><= div>As I understand it keygen is NOT removed in firefox (or most versions o= f other browsers).</div></div></div></div></blockquote><div><br></div></div= ></div><div>Correct.</div></div></div></div></blockquote><div><br></div><di= v>Great!<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir= =3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class= =3D""><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d= ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2= =A0 What I heard (perhaps someone will confirm) is that Mozilla will take t= he TAG advice, to remove existing functionality that is in use, only after = it has been adequately replaced.<br></div></div></div></div></blockquote><d= iv><br></div></span><div>I don't believe we've made any public stat= ements to this effect. We still intend to remove <keygen> but we don&= #39;t presently have a published schedule for it.</div></div></div></div></= blockquote><div><br></div><div>Thanks for the clarification.=C2=A0 As an in= dependent developer (that currently uses this technology) I am happy to see= Mozilla offer this functionality.<br></div><div>=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"= gmail_quote"><div><br></div><div>-Ekr</div><span class=3D""><div><br></div>= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">= <div class=3D"gmail_quote"><div></div><span><div>=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> <br> The longer answer is that the key pair is, in fact, generated<br> client-side, however, using code that is controlled by the website. That<br= > site must be trusted not to do anything nefarious with the private key<br> while the site has access to it. Once the key pair has been exported to<br> a PKCS#12 and imported into the user's local key store, and the site ha= s<br> been navigated away from, the website has no access to the private key,<br> should, for example, the site become compromised in the future.<div><div><b= r> <br> <br> -- <br> Dave Longley<br> CTO<br> Digital Bazaar, Inc.<br> <a href=3D"http://digitalbazaar.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://digitalbazaar.com</a><br> </div></div></blockquote></span></div><br></div></div> </blockquote></span></div><br></div></div> </blockquote></div><br></div></div> --001a11418d1e0ed6f1052f476bfc--