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

Re: <keygen> element

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 05 Sep 2009 20:07:51 -0700
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: <C5209DFE-8669-40FF-ABAA-4F649B17E1E0@apple.com>
To: Ian Hickson <ian@hixie.ch>

On Sep 5, 2009, at 6:28 PM, Ian Hickson wrote:

> 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.

The relevant technical questions are:

(1) Is use of <keygen> conforming?
(2) Is implementation of the behavior of <keygen> mandatory, optional  
or forbidden?

You are right that beyond these two questions, the spec factoring  
issue is political; specifically, it is independent of the answer to  
the above two technical questions. Fortunately, I think the two  
technical questions are the only ones that anyone actually cares  
about. It seems that many people want <keygen> to be conforming, and  
no one objects to that. It also seems that many people want the  
behavior of <keygen> to be documented and at the very least allowed  
for implementations. And Microsoft specifically would like the  
<keygen> behavior not to be mandatory, because they don't want to  
implement it.

Side note: Safari on iPhone does not currently support <keygen>. It's  
not clear to me at this time whether it will ever be supported. I have  
a query pending.

>
> 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.

Would it be possible to make the algorithm implementations optional  
without splitting them into a separate spec?

Query for Microsoft: would this be an acceptable solution for IE?  
Specifically, <keygen> itself mandatory, but you don't have to  
implement any of the actual crypto parts.

> 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.

I don't think anyone is interested in further extending <keygen>, so  
making the algorithm set extensible would not be very useful.

> 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.

That being said, I don't think it would be a problem to put the crypto  
parts in a separate spec, if anyone wanted to do the work.

Regards,
Maciej
Received on Sunday, 6 September 2009 03:08:33 UTC

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