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

Re: <keygen> element

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 6 Sep 2009 01:28:28 +0000 (UTC)
To: Maciej Stachowiak <mjs@apple.com>
Cc: Sam Ruby <rubys@intertwingly.net>, Anne van Kesteren <annevk@opera.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0909060119340.26930@hixie.dreamhostps.com>
On Sat, 5 Sep 2009, Maciej Stachowiak wrote:
> On Sep 5, 2009, at 1:45 PM, Maciej Stachowiak wrote:
> > 
> > So far, no one but Ian has come out against the separate spec option, 
> > and at least some people strongly prefer it to the status quo.
> 
> I reviewed the email on this and it looks like I overstated Ian's 
> position. What he said was: ""It's part of the HTML language at this 
> point, whether we like it or not -- and it seems sensible to me to 
> define the HTML language in the HTML spec."[1] That sounds to me like a 
> preference to keep <keygen> in the main spec, rather than a strong 
> position against splitting it out.

Putting part of HTML in a different spec than the rest of HTML would be 
a political decision, not a technical decision. I object to making spec 
design decisions on political grounds.

Prevously, we have only split sections out where doing so has made logical 
sense, e.g. because said features are self-contained, or are orthogonal, 
or are language-agnostic.

<keygen> is none of these things. It integrates tightly with the form 
submission model, it affects the DOM APIs of other elements, it affects 
the parser, it affects the form control validity model -- it's not a 
feature that can be sensibly considered "optional" if our goal is cross- 
browser interoperability.

However, there is an alternative that I think would still satisfy 
Microsoft's desires to not implement <keygen>'s cryptographic features 
while still bringing interoperability to the platform in every other 
respect: we could make the support of each individual signature algorithm 
optional. In fact, if we have a volunteer editor to do this, we could even 
make this externally extensible such that HTML5 doesn't list any signature 
algorithms but another spec defines the integration with RSA.

This would have another advantage, which is that it would allow new types, 
such as the eliptical signature algorithm supported by several user agents 
but not currently specified, to be added independent of HTML5 itself.

If someone would like to volunteer to edit such a specification, please 
let me know. It would be a remarkably simple task -- the specification 
need not be much longer than a page, including the boilerplate.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 6 September 2009 01:25:24 UTC

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