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
