Re: <keygen> element

On Sat, 5 Sep 2009, Lachlan Hunt wrote:
> Ian Hickson wrote:
> > > On Sep 1, 2009, at 3:34 PM, Jonas Sicking wrote:
> > > > One thing we could do is to add a note that this feature is known 
> > > > to be bad and is intended to be deprecated as soon as alternative 
> > > > proposals arise. That would give any UA a pretty good story for 
> > > > not implementing the feature for now.
> > 
> > Pretty much everything in the spec will be obsoleted when better 
> > solutions arise. Why would we single out <keygen> here? Do we have 
> > reason to believe that new solutions will arrive any time soon?
> 
> What is the justification for making the element conforming to use? 

It provides a useful service for which no better alternative exists.


On Sat, 5 Sep 2009, Maciej Stachowiak wrote:
> > 
> > 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?

Yes.


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

On the contrary, all implementations do in fact extend it beyond what 
HTML5 describes, in various ways. Of relevance here, several UAs support 
the "ec" algorithm (eliptical curves) which I have not specced.


On Mon, 7 Sep 2009, Henri Sivonen wrote:
>
> It seems to me that the least damaging solution to avoiding requiring 
> things that a vendor has vetoed would be keeping <keygen> conforming and 
> in the HTML5 spec but making implementing it optional in the sense that 
> it must parse the same way in all UAs but whether it on layers above the 
> parser acts as HTMLKeygenElement or as HTMLUnknownElement is up to the 
> implementation.

I think we need it to be an HTMLKeygenElement, since it affects 
form.elements, <label>, and other DOM APIs.


On Sat, 5 Sep 2009, Jonas Sicking wrote:
> 
> Putting just the <keygen> element, but none of the actual functionality, 
> thus allowing microsoft (or anyone else) to just implement a very small 
> amount of stubbed code seems like a political solution. It wouldn't 
> actually help any website authors, and it would force UAs to still 
> implement (and test) the stubbed code.

The stubbed code in question is more or less the same as for all the other 
form controls, so it is not an undue burden.

It would help authors in that they could continue to index into 
form.element, etc, without risking different results.


On Mon, 7 Sep 2009, Jonas Sicking wrote:
> 
> I do think it would also be good to make validators give authors a 
> warning when <keygen> is used. This would serve two purposes. First of 
> all it would warn people to not exclusively depend on <keygen> as it 
> doesn't (and likely never will) work in IE. Second, it would let them 
> know that it might stop working in other browsers in the future.

I'll leave that up to the validator vendors.


On Tue, 8 Sep 2009, Adrian Bateman wrote:
> 
> I don't think obsolete or deprecated yet still required really helps us. 
> Our goal is a spec that helps us all be interoperable. Optional would be 
> a possibility but I worry about complicating this spec with features of 
> a different status. I'd personally prefer the spec to stick to things 
> that are requirements (even if obsolete) for all user agents.

The criteria I've used in determining if something should be in the spec 
or not is "would a new browser vendor need to know how to implement this 
to compete in the browser space". In the case of <keygen>, the answer is 
"yes" -- IE only gets away with not supporting it because people are 
willing to support IE specifically (using a combination of ActiveX and 
VBScript, as I understand it).


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.

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

Received on Monday, 14 September 2009 10:27:49 UTC