Re: <keygen> element

On Tue, 1 Sep 2009, Adrian Bateman wrote:
> 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.

I don't think anyone is arguing that <keygen> is an especially great 
element. The point is just that all major browsers except one implement 
this feature, and in practice you can't write a Web browser that doesn't 
support ActiveX without implementing this feature.

As I understand it, unless we're interested in speccing ActiveX, the Win32 
API, and VBScript, and unless browser vendors are willing to implement 
ActiveX, the Win32 API (on non-Win32 platforms) and VBScript, <keygen> is 
a required part of the platform.

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

Browser vendor, singular, as far as I'm aware.

On Tue, 1 Sep 2009, Jonas Sicking wrote:
> However, I wonder if implementing <keygen> would actually help a 
> newcomer. The problem is that I think this is one area where pages do so 
> much browser detection that it's unlikely that any newcomer will work 
> out of the box.

Based on WebKit's experience, the answer appears to be "yes".

On Tue, 1 Sep 2009, Maciej Stachowiak wrote:
> On Sep 1, 2009, at 3:34 PM, Jonas Sicking wrote:
> > 
> > One thing we could do is to add a note that this feature is known to 
> > be bad and is intended to be deprecated as soon as alternative 
> > proposals arise. That would give any UA a pretty good story for not 
> > implementing the feature for now.

Pretty much everything in the spec will be obsoleted when better solutions 
arise. Why would we single out <keygen> here? Do we have reason to believe 
that new solutions will arrive any time soon? (I'm not aware of any 
working group working on an alternative API that any browser vendors are 
interested in implementing.)

> > Hopefully this won't be a problem for microsoft either way. Before 
> > <keygen> is becomes the last holdout for HTML5 compliance in a 
> > microsoft product I hope that there are alternative proposals that can 
> > replace <keygen>, allowing us to deprecate it. (Not because the former 
> > is far away, but because I hope the latter happens soon).
> I agree with the last two paragraphs. I think the main thing is to 
> provide a good crypto API so we can relegate <keygen> and 
> browser-specific solutions to the dustbin of history.

Is such a proposal under way?

On Wed, 2 Sep 2009, Adrian Bateman wrote:
> [keygen] should be documented but not in HTML5 itself - the HTML5 spec 
> supports loading unknown elements that are defined elsewhere. Since it 
> wasn't included in previous versions of HTML and the desire is not to 
> include it in future versions, not adding it at this stage seems 
> preferable.

It's part of the HTML language at this point, whether we like it or not -- 
and it seems sensible to me to define the HTML language in the HTML spec.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 4 September 2009 08:53:34 UTC