Managing Dual Key Pairs
In PKI, most use-cases include the use of a single key pair (one public, in a certificate and one private) for authentication, secure messaging, etc. This requires having both the Digital Signature and Key Enciphering usage flags set. Then a single certificate can be used for both signing and encryption. This normally works fine, until you do key escrow.
There are several “Key Usage” flags in a certificate that determine what that certificate and corresponding private key can be used for.
The “Digital Signature” flag if set means you can use the private key to create a digital signature, by producing a message digest of the thing being signed (e.g. with SHA-256) then encrypting that digest with an asymmetric key algorithm (e.g. RSA) using the private key. Also, the certificate can be used to validate a digital signature. Certificates with this flag set can be used to digitally sign things to authenticate the signer and detect tampering.
The “Key Enciphering” flag if set means you can encrypt a symmetric session key (which in turn was used to encrypt the actual message), using the public key in the certificate. The corresponding private key could then be used to decrypt the symmetric session key, which would then be used to decrypt the actual message. Certificates with this flag set can be used to provide privacy by way of a digital envelope.
A certificate with both flags set can be used to digitally sign a message and to protect the message in a digital envelope. You can call such a certificate a “dual purpose” certificate. A certificate with only the Digital Signature flag set is called a “signing certificate”. A certificate with only the Key Enciphering flag set is called an “encryption certificate”.
You only ever need to escrow encryption certificates (or actually the private key associated with the certificate), in case the private key needed to decrypt files or messages is lost. There is never a valid reason to escrow signing certificates, as that would allow the escrow agent to assume any user’s identity (not a good thing).
This requires splitting the roles between two certificates, one for signing and one for encrypting. Each certificate has a corresponding private key. The two key pairs must also be different (otherwise there would be no point to having two different certs). The SubjectDN is the same in the signing and encrypting certs. The Issuer DN is the same in the signing and encrypting certificates if both are issued by the same CA (which is usually the case). The only differences are the usage flags (one has only the Digital Signature flag, and the other has only the Key Enciphering flag) and the public key. Of course each certificate (with public key) has a corresponding private key.
Most CAs today only allow creating a single key pair and one dual-purpose (signing and encrypting) certificate for each user. This means if you do key escrow then you are escrowing signing keys, which is not a good thing.
Obtaining certificates via web browser does not support requesting or retrieving separate signing and encrypting certificates or specifying the usage flags for a given certificate request.
Most software does not support using dual key pairs. Microsoft Outlook is one of the few exceptions, but virtually everyone provides the same (dual-use) certificate in both roles:
The SixWallet app is currently requesting and retrieving a single dual-use certificate from an IRP-enabled CA. However, it has now been modified to allow requesting a signing-only cert and an encryption-only cert, and to keep track of them (by adding a “(S)” or “(E)” after the common name in the Subject Distinguished name. Basically, in addition to “User (Client)” and “Node (Server)” certificates, there are now “User (Client) Signing” and “User (Client) Encrypting” certificates.
To create a single “dual purpose” client certificate, select certificate type “User (Client)”:
In this case, the User’s Name is left unmodified.
To create a “signing only” certificate, select certificate type “User (Client) Signing”:
Note that this adds the “(S)” after the user name, which will also be in the Subject DN.
To create an “encrypting only” certificate, select certificate type “User (Client) Encrypting”:
Note that this adds the “(E)” after the username, which will also be in the Subject DN.
Once requested and retrieved, both certificates and private keys will be found in the local certificate store, marked with the “(S)” or “(E)” to keep track of them:
Even though SixWallet sets the appropriate usage flags in the CSR, most CAs ignore this and set flags as they see fit. We include the certificate type in the IRP message to the CA, so that it can set the flags correctly. Any CA that we graft IRP onto would need to be able to set usage flags corrected based on certificate type.
The SixEscrow app can easily be modified to escrow only certs that have only the Key Enciphering flag set (or optionally also dual-purpose certificates, with a warning about escrowing a signing key).
The SixMail add-in can easily obtain both signing cert and encrypting cert and install them in Outlook, putting the appropriate certificate (signing or encrypting) in the right place. The user would never even see the multiple IRP requests – it would be completely seamless.
We can furthermore create other apps (for file signing and encrypting, secure messaging, etc) that use dual key pair certificates as well. This issue is irrelevant to applications that do only authentication r digital signing, as there is never a need to escrow signing keys. Applications such as SixToken would use only the signing certificate (no need for an encrypting certificate).
The SixTalk application (end-to-end direct messaging over IPv6) can also be modified to use two single-purpose certificates for mutual strong authentication and key exchange (for privacy). We will be adding S/MIME messaging later this year, at which point dual-key pairs become significant in its operation.
The SixFile application (for sending files securely through DropBox using S/MIME) is currently being updated to manage dual key pairs.