[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