W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2009

[whatwg] <keygen>

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 06 Jan 2009 11:41:13 -0800
Message-ID: <39804F4C-9EB3-44AE-ACA8-36BF9C849061@apple.com>

On Jan 6, 2009, at 4:40 AM, Ian Hickson wrote:

>
> Over the years, several people (most of them bcc'ed) have asked for  
> HTML5
> to include a definition of <keygen>. Some have even gone as far as  
> finding
> documentation on the element -- thank you.
>
> As I understand it based on the documentation, <keygen> basically
> generates a public/private asymmetric cryptographic key pair, and then
> sends the public component as its form value.
>
> Unfortunately, this seems completely and utterly useless, as at no  
> point
> does there seem to be any way to ever use the private component  
> either for
> signing or for decrypting anything, nor does there appear to be a  
> way to
> use the certificate for authentication.
>
> Without further information along these lines describing how to  
> actually
> make practical use of the element, I do not intend to document  
> <keygen> in
> the HTML5 specification. If anyone can fill in these holes that  
> would be
> very helpful.

In the case of Safari, we store the generated private key in the  
Keychain, and sites using <keygen> typically respond with a signed  
certificate, which is downloaded and automatically added to the  
Keychain. Depending on the valid purposes of the key, users can then  
do the following automatically:

1) Browse to SSL sites that require client-side certificates for  
authentication, in Safari.
2) Send email with strong authentication via a cryptographic  
signature, in Mail.
3) Receive encrypted email from users who have received a copy of  
their public key, in Mail.

I imagine other browsers store the private key and received signed  
certificate in similar ways.

This is certainly a useful feature, and we added it at the request of  
both end users and CAs.

Regards,
Maciej
Received on Tuesday, 6 January 2009 11:41:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:09 UTC