Re: Digital ID's for signing request forms, etc ...

[Joe St Sauver <joe () OREGON UOREGON EDU>]

Richard writes:

#            I am looking at using the PKCS#12 digital ID method.  From 
#what I can determine, the PKCS#12 digital ID provides two major 
#capabilities/enhancements over the "Windows Certificate Store" digital ID.

Just to be clear, are you talking abhout using certificate-based signatures
in Acrobat (that is, the sort of thing discussed at page 297 in 
http://helpx.adobe.com/en/pdf/acrobat_reference.pdf ), or something else? 

#            The user provides the same type of identification information;
#name, department, company, and email address, but with the PKCS#12 version:
#
#1.      The creator/user must provide a storage location for the created 
#PKCS#12 digital ID file.  This digital ID file can be stored on a removable 
#storage device, such as a flash drive or a more secure location, such as a 
#common server/shared folder.

My strong preference, when it comes to digital certificates (and associated
private keys) is to see them stored on a smartcard or USB-format PKI hard 
token, so that they can be used but not exported, and so that they can travel
with the user from system to system. (While these devices may look similar
to regular thumb drives, they actually are considerably more sophisticated
and include both protected storage and federally certified cryptographic
processing capabilities...)

Credentials stored on local user systems, or on servers, just aren't as
robustly protected against some types of attacks.

#2.      The creator/user must provide a password in order to create and 
#then use this PKCS#12 digital ID file.  This ensures, as long as the 
#password is not shared, that the owner of the digital ID authenticates 
#it is them that is using this digital ID to sign the document or encrypt 
#the file.

A couple of things to confirm:

-- What exactly are you binding to the digital identity? At least some
broadly available client certificates only bind the cert to the email
identity, they do NOT bind it to a person's actual name, for example.
If you actually need to strongly bind an actual identity to a cryptographic
credential, you face greater challenges than if an email address is 
"good enough."

-- Is revocation an issue?

-- What about key escrow? If you're just signing, that's not as much of an
issue, but if you're encrypting, too, I think that this is something worth
consciously thinking about, whichever route you go.

-- Anytime I hear about something that's only protected by a password
these days, I worry. Passwords are just too easy to crack, sniff, or 
otherwise subvert. That's why I really like the idea of storing critical
cryptographic credentials on a hardware token, rather than somewhere that
might be more generally accessible, secured only by a password.

#The other route we could go is to use a certificate authority (CA) to 
#generate a certificate for each and every employee.  This seems to be 
#a bit of over kill, but not impossible.

Very doable, actually.

My recommendation would be to actually do some tests with client certs,
if you've got the time and inclination. I did a preconference seminar for 
Security Professionals a year ago that walks you through the process of 
getting a free client cert, and then using it for a variety of purposes. 
See http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf
if you're interested.

Regards,

Joe