W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: <keygen> element

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 14 Sep 2009 14:43:09 -0700
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Anne van Kesteren <annevk@opera.com>, Henri Sivonen <hsivonen@iki.fi>, Jonas Sicking <jonas@sicking.cc>, Sam Ruby <rubys@intertwingly.net>, Adrian Bateman <adrianba@microsoft.com>, HTMLWG WG <public-html@w3.org>
Message-id: <3BA4CBFD-29F0-4362-81DC-FF7A098BC989@apple.com>
To: Ian Hickson <ian@hixie.ch>

On Sep 14, 2009, at 3:32 AM, Ian Hickson wrote:

> On Tue, 8 Sep 2009, Adrian Bateman wrote:
>>
>> Sorry if I wasn't clear. What I was trying to say is that optional is
>> good enough but not my preference. My preference would be that  
>> <keygen>
>> be specified in a separate document. I agree that browsers that  
>> choose
>> to support <keygen> should work the same way. I think that  
>> introducing
>> optional features into the main HTML5 spec isn't ideal but I don't  
>> have
>> strong feelings against this.
>
> I don't think it makes sense to put it in another spec, since it  
> interacts
> with the parser (it has special parsing rules), the form controls  
> model
> (it is submittable), the DOM of other elements (it's in  
> form.elements),
> and so on.
>
>
> I've made the encryption parts of <keygen> optional.

That sounds reasonable to me, especially in light of the parsing and  
form.elements aspects. Those details could cause interoperability  
problems even for content that's willing to use a different approach  
for IE. What's the Microsoft opinion on this?

Once concern: using this approach, is there a way to feature test to  
determine whether a user agent supports <keygen> encryption features?  
I can't think of one. That seems like a problem. This matters not only  
for IE but also for mobile browsers that don't support <keygen> (since  
it may be difficult or impossible to implement on mobile platforms).  
In the latter case especially, the site should be able to tell the  
user up front that they shouldn't bother trying to generate a key on  
their current device. And sites shouldn't have to do that based on UA  
detection.

I'd suggest there should be at least one DOM attribute or method that  
is missing or returns a different value when <keygen> encryption is  
not supported. One possibility is to make keytype return the empty  
string instead of "rsa" by default, if no algorithms are supported.  
I'm sure there are many other possibilities.

Regards,
Maciej
Received on Monday, 14 September 2009 21:43:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC