[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!
Regards
Anders Rundgren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090416/3e5d30f6/attachment.htm>
More information about the whatwg
mailing list