[whatwg] Questions about the keygen element specification

[Ian Hickson]

On Sun, 11 Apr 2010, Mounir Lamouri wrote:
> 
> First of all, the keytype attribute should specify which algorithm to
> use but it can be in the 'unknown state' and "it is possible for a user
> agent to not support any key types at all.". I do not understand why the
> keygen element would be implemented with no supported keytype.

On Tue, 13 Apr 2010, Anne van Kesteren wrote:
> 
> This was done as a compromise to Microsoft. That the element is parsed
> consistently and exposes the correct API was considered to be the most
> important if I remember correctly.

Indeed.

On Sun, 11 Apr 2010, Mounir Lamouri wrote:
>
> Also I do not understand why the keytype list is not exhaustive.

I specified all the values I could find definitions for. I'm open to 
adding others if (a) browsers support them and (b) there are clear 
definitions I can reference.


> It would lead to situations where UA X introduce a new keytype (and to 
> make it worses with patents to make it impossible to use by other UA). 
> If this keytype becomes a de-facto standard, it would be very bad.

Not much we can do about this regardless of what the spec says.


> Moreover, with the present specification, a website can't seriously use 
> the keygen element because it wouldn't know if the algorithm it wants to 
> use will be supported, even RSA.

People do use it, apparently. That's why browsers keep supporting it, 
which is why I specified it.


> Then, there is the UI aspect of the element. This element is an 
> 'Interactive content' and accept the 'autofocus' attribute but there is 
> no really UI aspects mentioned in the specifications. The keygen element 
> description mentions this: "The user agent may expose a user interface 
> for each keygen element to allow the user to configure settings of the 
> element's key pair generator, e.g. the key length." and the "represents" 
> section mentions: "When the keygen binding applies to a keygen element, 
> the element is expected to render as an 'inline-block' box containing a 
> user interface to configure the key pair to be generated.".
>
> I'm wondering if the specifications consider the UI aspect as out of the 
> specifications because the key is generated locally and only the result 
> is sent with the form values. Most current implementation of the keygen 
> element (which are not folowing this specification) lets the user choose 
> a key length and a text field. Do you think this should be specified ? 
> In addition, the key length (and maybe other variables used to generate 
> the key) may be exposed with an IDL attribute. It may help websites to 
> check the key is secured enough.

User interfaces in general are up to the browser. After all, browsers 
could be screen-based, or speech-based, or based on smoke signals...


On Thu, 15 Apr 2010, Mounir Lamouri wrote:
>
> http://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
> 
> Actually, it looks like it is ending with the intervention of Alan
> Dundas [1] which was interesting.
> I'm wondering if points 5 and 6 could be added to the specs. In my
> opinion, point 5 would be interesting (and trivial) and point 6 is a
> matter of time, isn't it ?
> 
> [1] http://lists.w3.org/Archives/Public/public-html/2009Sep/1025.html

I'd rather we make improvements via a JS API that all browsers can 
implement rather than use <keygen>. <keygen> is a historical artefact.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'