<keygen> element (was RE: Implementor feedback on new elements in HTML5)

On Monday, August 31, 2009 9:46 PM, Maciej Stachowiak wrote:
> - Newly standard legacy elements: <keygen>, <embed>
>   We had these for a long time before they were in HTML5. It seems like a
> good idea to cover them in the spec, even though they are kind of crufty.

Ian Hickson wrote:
> Opera, Firefox, and Safari all support this element, so we need to define 
> how it works.

Henri Sivonen wrote:
> It appears that a browser needs to support either Netscape's or  
> Microsoft's certificate enrollment mechanism in order to be compatible  
> with enrollment pages out there. The Netscape mechanism is implemented  
> in 3 out of the top 4 browser engines. As such, it seems like a part  
> of the platform that needs to be specced.

The problem with <keygen> is that it fails to address the requirements that people have for certificate enrolment today. We see two main use cases for client-side certificate auth on the web today. One is some kind of web access to a financial institution like a bank or brokerage firm or to e-government sites. Another is enterprise remote access (although we commonly see the enterprise scenario handled with something like a smart card requiring offline provisioning). It's hard to find examples of <keygen> being actively used today. Most commercial and government implementations use proprietary enrolment mechanisms often based on Java applets, Mozilla's custom generateCRMFRequest, or Microsoft's scriptable APIs such as CertEnroll.

Here are some of the limitations with <keygen>:

1. <keygen> typically requires the user to select the appropriate key length from a list. Most users are not equipped to make this decision. In general, the server should be able to indicate what type of key pair it wants including acceptable key length, algorithm, etc. For example, RSA 512 may not be something a bank wants to deal with. <keygen> doesn't support this.

2. Creating the key pair (with <keygen>) and then having a certificate returned from the server to be installed on the client appear to the user as two separate actions. This is a poor user experience and there is no way to avoid this with <keygen>. A better approach would have the key submission and certificate response integrated into the same control.

3. <keygen> does not provide a mechanism for managing certificate expiry. This forces the user to repeat the initial key creation process whenever certificates expire.

4. The format used by <keygen> is not standard and only provides a subset of already established protocols like PKCS10 (http://tools.ietf.org/html/rfc2986), CMC (http://tools.ietf.org/html/rfc5272), and CRMF (http://tools.ietf.org/html/rfc4211). This prevents <keygen> from supporting non-RSA based certificates, extensions for additional client information, and key escrow.

These deficiencies mean that browser vendors have introduced alternative mechanisms for managing certificate enrolment.

Given these issues with <keygen> we think that requiring support in order to be a conforming HTML 5 user agent is problematic. At the very least, we believe that <keygen> should be marked as obsolete in the spec. We would prefer that this was removed from the HTML 5 spec and documented elsewhere if necessary. <keygen> only supports part of the old Netscape protocol - the rest of the process isn't documented in the spec.

It is extremely unlikely that Microsoft will ever implement support for <keygen> - we do not believe it provides value for our customers. We are prepared to consider creating common APIs that allow interoperability across browsers and also address customers' real needs either in a future version of the spec or as a separate work item.

Cheers,

Adrian.

Received on Tuesday, 1 September 2009 15:16:08 UTC