On Apr 15, 2009, at 7:53 PM, Anders Rundgren wrote:
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.
I don't know how I could be any more clear on this. A new browser
engine that came out today would have to implement <keygen> to support
existing Web content. That doesn't mean <keygen> is the world's best
solution to its problem domain, or that no one will have proprietary
alternatives. But it does mean that to have a spec you could use to
build a browser, you have to specify how <keygen> works.
OTOH, if the motivation is rather "elevating" Apple's *existing
implementation* to full standard, then you are all set :-)
We don't think <keygen> is awesome. We implemented it as a direct copy
of what Mozilla had because certificate issuers asked for it. We
didn't care whether <keygen> was a "full standard" then, and we don't
really care now, except to the extent that it helps interoperability
and competitiveness in the browser space to clearly specify it. And we
think it is a crappy design which leads to ugly code in our engine,
but regrettably it is needed for compatibility. So I'm really not sure
what point you are trying to make.
>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!
Based on this it sounds to me like it would be worthwhile to start a
separate standardization effort for a newer, better way to handle key
generation and cert requests. We don't want to hold HTML5 2-3 years
for a new feature. But nothing prevents working on it in parallel.
Regards,
Maciej
