RE: <keygen> element

 

What specific improvements do you think should be made to
<keygen>? 
  
>> I will send another email and provide a list.   
 
Ok, here are features in a prioritized order.  This is my personal
prioritization based on being responsible for multiple enterprise PKI
solutions for the past several years as well as being responsible for
VeriSign's client architecture for the last year.
 
1. Hardware protected keygen flag - some way to specify that the keygen
must occur via a hardware protected device (smartcard, usb fob, TPM).
Current keygen implementation allows user to select location of private
key.   Microsoft provides this by allowing CSP selection to be hardcoded
or limited to only approved known hardware CSP providers.   As a side
note when the "Smartcard Login EKU" value is requested there should be
an additional check that the private key is on hardware.   
 
2. Non-Exportable keygen flag - again a flag to specify that the keygen
must protect the private key from being able to be exported and/or
copied to a different machine.  If you can copy the key.db and cert.db
files to another box, then this is not sufficient even if export is
disabled.  Microsoft provides this support natively in their Keygen
 
3. Password protection required - Microsoft has a mechanism to require a
password for each non-cached use of the private key.  The XP
implementation has flaws (including a "remember my password option that
defeats this protection") which are finally solved on Windows 7 where a
per credential password that must meet a required password policy can be
enforced.
 
4. PKCS#10 / Keygen binding.   -   The easiest way to defeat the
requested keygen options is to copy the source of your keygen page to
your harddrive and to modify the keygen options and then issue the
keygen from your modified copy.   There needs to be some protection
against this.  The protection need not be genius proof, just complicated
enough to make it very difficult.  If you need genius proof protection,
then face to face enrollment is your option.   One way of doing this is
to sign a container that has both the PKCS#10 and the keygen options
used.  This way the issuance party would see that the keygen options
were different than those original served in the request page.   There
are other alternatives that can provide this level of protection.
Microsoft offers some limited protection here via its template model as
the keyflags are not part of the page source.
 
5. Keysize selection should come from the form, not user selectable.
6. Algorithm support is missing (RSA, DSA, ECC, etc)
 
On the PKCS#10 side.
 
SubjectAltName support is currently problematic and not done in a
standard way by vendors, and the aforementioned "SmartCard Login EKU"
needs some additional validation wrt the private key.
 
I've got more to add, but let's see if the above sparks a discussion.
 
=Alan
 
 
 
 
=Alan Dundas