W3C home > Mailing lists > Public > www-tag@w3.org > March 2016

Re: What we were using public key authentication for

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Wed, 30 Mar 2016 19:24:28 +0200
Message-ID: <CAKaEYh+Mji9DsD6cHfGFV++4q-2fu_Gry70ijZO3op6XiqXx+w@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:13 UTC