W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: <keygen> element

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 23 Sep 2009 01:39:30 -0700
Cc: public-html@w3.org
Message-id: <56D8C17A-CD50-421D-8D04-972FD98BB958@apple.com>
To: "Dundas, Alan" <adundas@verisign.com>

This is really valuable feedback.

On Sep 22, 2009, at 1:29 PM, Dundas, Alan wrote:

> Sorry to come late to this conversation.  I've just read this entire  
> thread and as VeriSign's Client PKI Architect I thought I would give  
> you some additional perspective on this discussion.   VeriSign's out  
> of the box client enrollment uses x/cenroll for MS or keygen for any  
> other platform (including Firefox, Safari and Opera).
>
> I agree with the general limitation discussion about Keygen, it is a  
> poor interface and needs to be revamped, but Ian's comments that  
> there is no consistent alternative is an important one.
>
> Most of VeriSign's client certificate customers are enterprise  
> customers and many have forced their employees to limit enrollment  
> within IE browsers because Keygen does not offer certain functions  
> (algorithm, hardcoded keysize, non-exportable private key, require  
> password protection with password policy, keygen on hardware  
> required).    It is the lack of a more complete and interoperable  
> set of requirements for keygen that have stopped enterprises from  
> being able to adopt PKI solutions.  There are situations where Mac,  
> and the many versions of Unix based OS's must go through an  
> expensive kiosk IE issuance process before hardware tokens can be  
> used on these other platforms.  There would be more adoption of this  
> technology across heterogeneous environments if Keygen was enhanced  
> to offer a similar feature set as Microsoft provides today.
>
> VeriSign is pleased to see that non-exportability is making its way  
> to Mac OS10.6 and having this functionality exposed to a Keygen in  
> the browser would be great progress.

I'm sadly not an expert on Mac OS X crytpo APIs - could you clarify  
what specifically should be exposed to <keygen>?

>
> Lastly, there is one area where the current poor implementation of  
> Keygen shines far above the Microsoft solution.  That is with  
> partners and customers where the issuing party can not guarantee the  
> end user has Admin rights.  Here it can be very difficult to use the  
> MS process of generating or installing keys.  Active X controls can  
> be disabled and IE browser settings can make key generation  
> impossible on tightly controlled systems.   In this situation the  
> current Keygen in non-IE browsers is often the only error free  
> method to generate and use Client certificates.
>
> Personally I'd like to see Keygen improved, not removed, as a  
> consistent way of using this technology that is browser agnostic  
> would benefit everyone, with the possible exception of Microsoft.    
> I'm concerned that failure to support a consistent approach in non- 
> IE browsers will in fact solidify that Microsoft is the only browser  
> that can be used if you have the requirements in your enterprise to  
> use client based PKI.

What specific improvements do you think should be made to <keygen>?

Regards,
Maciej
Received on Wednesday, 23 September 2009 08:40:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT