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

On Sep 1, 2009, at 8:13 AM, Adrian Bateman wrote:

> 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 true that <keygen> is limited in its capabilities. There needs to  
be a standards-based successor that has a wider range of capabilities  
(probably in the form of an API rather than a form control element):

>  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.

We added <keygen> to Safari after much lobbying from personal  
certificate vendors such as this one (which does use <keygen> in  
Safari and Firefox):

http://www.verisign.com/authentication/individual-authentication/digital-id/

To support such websites, a newly implemented browser would have to  
either implement <keygen> or implement a surprisingly wide range of  
Microsoft proprietary technologies (in the case of this particular  
site including VBScript). Currently every such site has to have at  
least two code paths, even if it needs are basic.

Note: we would have preferred to copy the IE approach instead of the  
Mozilla approach to this, but it seemed infeasible to reverse engineer  
and duplicate enough of the IE feature set to do so. In particular, we  
were not willing to implement VBScript.

[... snip deficiencies and limitations of <keygen> ...]

>
> 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.

I think it would be good to pursue this as a separate work item. A  
more powerful standard API would be valuable for the Web, and I think  
many of the sites still using <keygen> would be motivated to migrate.  
I think Web API WG would probably be the proper venue, if it's purely  
an API and does not involve new HTML elements.

Regards,
Maciej

Received on Tuesday, 1 September 2009 17:50:03 UTC