I am not a cryptographer. I just futzed around until stuff worked. Some of this stuff might be wrong.
openssl's command line API is balls.
nss-tools are ... not well thought through.
You can create a private key or a private key + cert. If you create just a private key, there is no way to reference it (ie, you can't delete it, sign with it etc).
nss-tools require you to provide an "entropy file" which has to be of "sufficient size". If you try and use /dev/random, then it will try and read the entire file, which ends poorly. This must be a file, as it is read multiple times(!), which seems like a bad plan to me.
nss-tools will interatively ask for a password on /dev/tty, or it will take a password on the commandline. No other options. Sigh.
The nss-tools however does let you get a key in/out of chrome/mozilla's
key store, which means you can write simple wrapper scripts around
wget/curl to use client certs from your browser.
pk12util -d sql:$HOME/.pki/nssdb -n "$NAME" -o "$FILENAME".p12
The gnutls tools are actually pretty good. Easy to use.
SSH has side stepped most of the annoying problems. Full props to them.
But you can't use an X.509 cert as an SSH cert. You can however convert between ssh private/public keys and their X.509 equivilents.
The ssh story for revoking a cert exists, but feels like it could be refined a little. How do you, as a user, list a cert as revoked? Does anyone have a story for how to distribute CRLs? The best story at the moment appears to be puppet/chef/cfengine.
CRL's (Certificate Revocation List) in the SSH world are called KRLs (Key Revocation List).
KRL files aren't signed, (but the keys inside them are), so if you have a cert, you can create a KRL, or an empty KRL and it's difficult to tell them apart.
Unlike most of the other SSH files, KRL's are binary instead of plain text, with base64 encoded data. There doesn't appear to be a tool to dump the contents of the KRL, so you can't get at most of the useful information to help with verifying it.
pkcs11 is a nice standardised C API crypto layer. You should use it for your crypto needs. This means you can require the use of a hardware token without which you can't access your private keys, thus making stealing keys far more difficult.
p11-kit provides a central registry for pkcs11 modules, and provides a p11-kit-proxy.so pkcs11 module that will work as a proxy to talk to all the other registered pkcs11 modules on the system.
Some tools require you to put the pkcs11 module on the commandline, rather than use p11-kit. You should use the p11-kit-proxy module on the commandline in this case.
Some things (bind?) appear to require the pkcs stuff linked in at compile time, because... wat?
Some things like which CA's should be trusted, can, and are distributed by pkcs11. Don't have yet another CA registry, use pkcs11!
openssl is rather behind on pkcs11 support. Don't use it. Use gnutls instead which knows about pkcs11 and p11-kit by default.
You could in theory avoid linking any crypto libraries and use pkcs11 as your crypto "library". Apart from the critical failure that would be building your own crypto system out of pkcs11 crypto primatives, this seems like not a bad idea.
gnome-keyring is just a software pkcs11 token provider. If you don't have a TPM gnome-keyring will take care of all the details for you. It will however only encrypt keys with a password given to it, rather than having a proper hardware token to store the secrets in.
Nobody has any decent tools that I can find for doing things like managing a CA, including handling revoking keys, CRLs and OCSP. Sure openssl has a ca command, it, like the rest of openssl's command line, is balls.
Browsers support <keygen> elements (Except IE), which can be used for a
reasonable way of distributing signed tls client certs to relatively
advanced end users.
opencryptoki is a pkcs11 module that knows how to talk to trousers (the TPM daemon). It is however pretty overengineered, and creates keys as "exportable" which means you can get hte private key out of the TPM! What's the point! Thomas Habets has written a better pkcs11 module, but it's currently very limited.
opensc is a much nicer to use pkcs11 framework, however it doesn't support talking to trousers, so no TPM support. If your token is supported by opensc, then I recommend using it. The opensc command line tools are much nicer, and thus what I use for tinkering with pkcs11 stuff.
You should be using 2048 bit keys
The TPM has two keys:
A EK (Endorsement Key), which is used to prove that you're talking to a real trusted TPM for use cases like DRM. Generally I ignore this key.
A SRK (Storage Root Key). This key is usually generated when you initialise the TPM. When you ask the TPM to create a new key, the TPM generates the key, then encrypts it with the SRK and gives it back to you. It's up to you to store this encrypted blob somewhere. When you want to do an operation (such as decrypt some data), you present the data and the encrypted private key blob, and the TPM decrypts the key using the SRK, then performs the operation on the data.
This means that keys aren't really stored in the TPM, but without the TPM you can't use those keys. Very clever.
TPM's are very very slow. Only supporting about 1.1 operations per second.
p11-kit starts slots at 0x10 not 0x00. This is why you're getting
CKR_SLOT_ID_INVALID errors. Use
pkcs11-tool -L --module /usr/lib/p11-kit-proxy.so to list all the slots,
and use the ID (the number in brackets), not the slot number.