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">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</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">&lt;<a href=3D"mai=
lto:[email protected]" target=3D"_blank">[email protected]</a=
>&gt;</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">&lt;<a href=3D"mailto:dlongl=
[email protected]" target=3D"_blank">[email protected]</a>&gt;<=
/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 &lt;<a href=3D"mailto:dlongley@dig=
italbazaar.com" target=3D"_blank">[email protected]</a>&gt;<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&#39;s browser. They<br>
may have to save the file first before importing, I&#39;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&#39;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 &quot;No&quot;, as there is presently no direct replace=
ment<br>
for keygen. I was just offering a quick temporary fix. If it&#39;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&#39;t believe we&#39;ve made any public stat=
ements to this effect. We still intend to remove &lt;keygen&gt; 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&#39;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--