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: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 16 Sep 2015 14:16:44 -0400
To: www-tag@w3.org
Message-ID: <55F9B20C.5090902@openlinksw.com>
On 9/16/15 12:20 PM, Ryan Sleevi wrote:
> On Wed, Sep 16, 2015 at 3:08 AM, Graham Leggett <minfrin@sharp.fm
> <mailto:minfrin@sharp.fm>> wrote:
>     On 15 Sep 2015, at 11:29 AM, Ryan Sleevi <sleevi@google.com
>     <mailto: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.

Ryan & Graham,

I have a page [1] that demonstrates the matter at hand i.e., the fact
that <keygen/> tag is a mechanism for adding cryto data (e.g.,
Certificate and Private Key) to most keystores.

To Graham's point:

In my example, you don't have a control explicitly invoking the
"generate" action.

To Ryan's point:

You can place such a control in an Web page, so we end up back at the
critical point of concern i.e., surreptitious generation and storage of
crypto data.


I assume your fundamental point is that <keygen/> support is going to be
dropped from Chrome, as is the case with IE and Edge, right? I ask
because I was of the opinion that removal of <keygen/> from HTML5 spec
was/is the issue of contention.


[1] https://plus.google.com/109693896432057207496/posts/CUXfxNN2CFp


Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Received on Wednesday, 16 September 2015 18:17:09 UTC

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