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

[Maciej Stachowiak]

On Apr 15, 2009, at 12:13 PM, Anders Rundgren wrote:

> Dear list,
> I may indeed be biased since I run a private standardization effort  
> coined KeyGen2 which is designed to replace <keygen>.
> Anyway, it might be of some general interest knowing why I have  
> started this thing.
>
> Microsoft does not support <keygen>.  If I were Microsoft I wouldn't  
> bother since all CAs have adapted themselves to Microsoft's scheme.   
> Microsoft's scheme (CertEnroll) is more flexible than <keygen>,  
> albeit much more complex as well.
>
> Now to the really problematic stuff:  <keygen> is not really an HTML  
> tag, it is actually 2 phases of a 3-phase key provisioning  
> protocol.  I don't see why a protocol should be plugged into a page  
> GUI.  The alternatives all use APIs or specific plugins that indeed  
> may be spawned from an HTML page but that's something completely  
> different.
>
> Just as a comparison I would like to mention the fact that the  
> KeyGen2 schema is about 25 times the size of the <keygen>  
> specification.   Although that could indicate a major design error  
> in KeyGen2, the truth (according to me of course...) is that  
> <keygen> is way too limited to be used by serious issuers like banks  
> and governments.
>
> I would also consider the "market" for <keygen>.  For PCs, physical  
> token distribution is the standard, that's why there has been so  
> little interest in on-line provisioning.  However, for mobile  
> phones, on-line provisioning is really the only good method unless  
> you are a government and buy into $200+ solutions like the following:
> http://www.trustdigital.com/downloads/TD_EMM_CAC_Pack_101008.pdf
>
> A difference with mobile phones is that when the phone=token you can  
> do much cooler things than you can on a PC, including trusted  
> execution and provisioning.  It seems a bit short-sighted to build  
> on a 15 year old design without at least having investigated what is  
> possible.
>
> HTML5 looks great but I think you should stick to page layout and  
> leave protocols either to JavaScript or to some other extension  
> mechanism.


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>. However, none of this rules out the possibility of putting  
more advanced crypto functionality into browsers, either via HTML or a  
separate spec. So I would recommend that you focus on promoting your  
preferred solution rather than opposing <keygen>.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090415/708b18ba/attachment.htm>