W3C home > Mailing lists > Public > www-tag@w3.org > September 2015

Re: Same Origin Policy - Re: Agenda: <keygen> being destroyed when we need it

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 16 Sep 2015 09:20:26 -0700
Message-ID: <CACvaWva3cg7_c=SpNzcBE_cjBoThb10vjg-SO3we9zx=ANxwnA@mail.gmail.com>
To: Graham Leggett <minfrin@sharp.fm>
Cc: "www-tag@w3.org List" <www-tag@w3.org>
On Wed, Sep 16, 2015 at 3:08 AM, Graham Leggett <minfrin@sharp.fm> wrote:

> On 15 Sep 2015, at 11:29 AM, Ryan Sleevi <sleevi@google.com> wrote:
> > Go to a site with a <keygen> tag in Safari or Chrome. See that it
> inserts a key in your (OS) key store.
>
> That’s not how keygen works. The keygen tag has to be part of a form, and
> renders a visible indication of the key size.


https://drafts.csswg.org/css2/visuren.html#display-prop


> The end user has to actively click on something before the key is
> generated.
>

https://html.spec.whatwg.org/multipage/forms.html#dom-form-submit


> At the very least (Firefox) you have to explicit submit a form to generate
> a key. At the most (Safari) you are explicitly prompted to choose a
> certificate before using that certificate to connect to a site.
>

You're mixing apples and oranges, and calling them steaks. What you
describe in Firefox is <keygen> What you describe in Safari is irrelevant
to <keygen> (no prompt) or application/x-x509-user-cert (no handling), but
instead TLS client auth - which is not the topic either Kingsley and I are
talking about. It's as relevant as the price of tea in China to the issues
at hand.
Received on Wednesday, 16 September 2015 16:20:54 UTC

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