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

Anders Rundgren anders.rundgren at telia.com
Wed Apr 15 19:53:35 PDT 2009

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.

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

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

Anders Rundgren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090416/3e5d30f6/attachment-0002.htm>

More information about the whatwg mailing list