[whatwg] The <keygen> element

Anders Rundgren anders.rundgren at telia.com
Fri Apr 17 14:42:37 PDT 2009


I understand what you are saying, but without a "buy-in" from
Microsoft there is little point in elevating <keygen> to some kind
of standard since it will fail in the majority of cases.

Anyway, it seems that the security people are uninterested in
on-line key provisioning so you can go ahead without regrets :-)

As a web-CA writer I know that I will have to check User-Agent
etc. because this isn't going to be _the_ solution :-(

When you have added the missing 5-10 attributes including repeated
keys (!) to reach generateCRMFRequest level (easy according to Nelson...)
https://developer.mozilla.org/en/GenerateCRMFRequest
please give drop me a line  :-)

Anders

----- Original Message ----- 
From: "Jonas Sicking" <jonas at sicking.cc>
To: "Anders Rundgren" <anders.rundgren at telia.com>
Cc: <whatwg at lists.whatwg.org>; "Nelson B Bolyard" <nelson at bolyard.me>; 
<dev-tech-crypto at lists.mozilla.org>
Sent: Friday, April 17, 2009 23:16
Subject: Re: [whatwg] The <keygen> element


On Thu, Apr 16, 2009 at 9:22 PM, Anders Rundgren
<anders.rundgren at telia.com> wrote:
> "Nelson B Bolyard" wrote [to the WHATWG list]:
> Based on WHATWG comments, this it is not really about standardization
> but about documenting the current practice for key generation in the HTML
> layer without comparing this to other ways of achieving the similar goals
> including generateCRMFRequest. JavaScript is thus outside of the
> scope AFAICT.

The <keygen> discussion is not about creating a new standard, that is
correct. It is about standardizing current practices that are required
by *todays* browsers in order to be compatible with the web and thus
considered by users.

As for coming up with a new, better standard for accomplishing what
keygen was originally envisioned to do, way back when, I think this
would be a great idea.

Nothing is out of scope for such a new standard. However the
apropriate standards organization and working group should be used. So
for example if the new solution is a pure javascript API, then either
the webapps wg in w3c, or some security related standards org seems
more apropriate than whatwg.

If on the other hand a new HTML element is proposed, then this list
seems like a fine place for such a discussion.

Hope that makes sense?

/ Jonas 




More information about the whatwg mailing list