[whatwg] A few comments on the <keygen> tag

[Maciej Stachowiak]

On Apr 15, 2009, at 7:53 PM, Anders Rundgren wrote:

> Maciej Stachowiak  wrote:
> >HTML5 is meant to specify every HTML feature that you need to
> >implement a browser than can handle the real-world Web. At this  
> point,
> anyone implementing a new browser engine would have to support  
> <keygen>.
>
> Microsoft would unlikely support something they already have a  
> better (and by every CA product worth mentioning supported)   
> solution for.  This could IMO reduce the value of HTML5.
>
> In addition to that, Mozilla's generateCRMFRequest () is superior to  
> <keygen>; otherwise they wouldn't have added it, since Mozilla  
> already had <keygen> through their Netscape heritage.
>
> Anyway, the existing <keygen> will probably not survive so you end- 
> up doing a major redesign.   One of the things that you MUST change  
> is the GUI where *users* have to select key strength.  That's  
> ridiculous, in the majority of cases it is the *issuer* that has a  
> policy that it tries to enforce.   I doubt that <keygen> will come  
> out as a simple solution if such considerations are taken in account.

I don't know how I could be any more clear on this. A new browser  
engine that came out today would have to implement <keygen> to support  
existing Web content. That doesn't mean <keygen> is the world's best  
solution to its problem domain, or that no one will have proprietary  
alternatives. But it does mean that to have a spec you could use to  
build a browser, you have to specify how <keygen> works.

>
> OTOH, if the motivation is rather "elevating" Apple's *existing  
> implementation* to full standard, then you are all set :-)

We don't think <keygen> is awesome. We implemented it as a direct copy  
of what Mozilla had because certificate issuers asked for it. We  
didn't care whether <keygen> was a "full standard" then, and we don't  
really care now, except to the extent that it helps interoperability  
and competitiveness in the browser space to clearly specify it. And we  
think it is a crappy design which leads to ugly code in our engine,  
but regrettably it is needed for compatibility. So I'm really not sure  
what point you are trying to make.

>
> >However, none of this rules out the possibility of putting more  
> advanced
> >crypto functionality into browsers, either via HTML or a separate  
> spec.
>
> I'm happy about that :-)
>
> >So I would recommend that you focus on promoting your preferred
> >solution rather than opposing <keygen>.
> I just took my experience in this field and explained why *I* felt  
> that <keygen> needed a successor.
>
> If WHATWG took <keygen> to for example IETF-PKIX, a *real'  
> standardization effort on this minor feature could easily take 2-3  
> years to complete!

Based on this it sounds to me like it would be worthwhile to start a  
separate standardization effort for a newer, better way to handle key  
generation and cert requests. We don't want to hold HTML5 2-3 years  
for a new feature. But nothing prevents working on it in parallel.

Regards,
Maciej