<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 15, 2009, at 12:13 PM, Anders Rundgren wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div bgcolor="#ffffff"><div><font face="Arial" size="2">Dear list,</font></div><div><font face="Arial" size="2">I may indeed be biased since I run a private standardization effort coined KeyGen2 which is designed to replace <keygen>.</font></div><div><font face="Arial" size="2">Anyway, it might be of some general interest knowing why I have started this thing.</font></div><div><font face="Arial" size="2"></font> </div><div><font face="Arial" size="2">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.</font></div><div><font face="Arial" size="2"></font> </div><div><font face="Arial" size="2">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.</font></div><div><font face="Arial" size="2"></font> </div><div><font face="Arial" size="2">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.</font></div><div><font face="Arial" size="2"></font> </div><div><font face="Arial" size="2">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:</font></div><div><a href="http://www.trustdigital.com/downloads/TD_EMM_CAC_Pack_101008.pdf">http://www.trustdigital.com/downloads/TD_EMM_CAC_Pack_101008.pdf</a></div><div><font face="Arial" size="2"></font> </div><div><font face="Arial" size="2">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.</font></div><div><font face="Arial" size="2"></font> </div><div><font face="Arial" size="2">HTML5 looks great but I think you should stick to page layout and leave protocols either to JavaScript or to some other extension mechanism.</font></div><div><font face="Arial" size="2"></font></div></div></span></blockquote></div><div><br></div><div>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>.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>