RE: <keygen> element

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

The security command with the -k option allows users to import their
keys such that the private key is not exportable.  What is very much
desired is a way to do this at key generation, and in a way where the
user doesn't have to participate (no dialog boxes about where they want
the private key). 

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

So I think there has been good discussion earlier in this thread about
all the problems with Keygen.  I will send another email and provide a
list.   Our customers most vocal request is on the algorithm support and
non-exportability of the key.   More technically savvy customers also
ask about password protection and establishing their own password policy
(length, complexity and require changing interval).  In this policy area
MS's XP platform offers some of this, Vista more, and Windows 7 even
more.
 
In general the browsers interface with PKCS #11 well so hardware tokens
can be used once issued, but as I said before most enterprises will
exclusively use windows for issuance.  This means users of IE can do
things like self renewal and Mac/(x)nix have to go through more
expensive and lengthy processes.
 
=Alan Dundas