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
