I am trying to create a secured policy for storing and maintaining keys between users of my company.
The following answer is based on those requirements I assume based on your post (I'll call your users employees in the following):
- You need to be able to revoke employee keys.
- You want to be able to decrypt information encrypted for employee.
Employees should not be able to change anything on their keys on their own.
Be aware this also stops your employees from participating in the web of trust, as they are not able to issue certifications any more (you might want or not want this). Consider letting the employees create the keys, but handing you over an encryption subkey if you require so and have them add your company key as a designated revoker. This is comparable to key handling with a company-owned X.509 PKI infrastructure.
Currently, the idea is:
- Generate a master key per user with only the certify capability. Backup this key in a physical vault.
The certification restriction seems reasonable, so nobody is (should be) by accident encrypting for the primary key and your employees are not able to read the message.
- Generate a revocation certificate for this master key, and also store it in a physical vault.
Alternatively, you could also add some company as designated revoker. This might make handling a bunch of revocation certificates easier, and maps to what actually happens (the company revokes the employee's key):
gpg --desig-revoke [key-id]
- Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
This seems required if you want to stay capable of reading the employee's messages. Might be a legal issue in some jurisdictions or require you to prevent any private usage of company mail addresses.
- Generate an auth subkey (for ssh) directly on the Yubikey.
Both authentication and signature subkeys can simply be exchanged if not used any more. Not holding a copy seems reasonable security-wise, all effort you have to do is distributing the new key (and possibly switch keys on servers).
Especially if you have shared infrastructure, you might even consider using monkeysphere on the servers authenticated against. Monkeysphere relies on the OpenPGP web of trust (ie., signatures by a trusted company key) on the employee's primary keys, and adds their subkeys to sshd, so you can even escrow authentication subkeys without changes to the individual servers, but it is rather uncommon and rarely used, but integrates well with GnuPG authentication subkeys used for SSH.
Now I have a bunch of questions:
- What happens if someone leaves the company? I guess I should use the master key revocation certificate to cancel the master key and all
its subkeys.
You only need to revoke the primary key, the subkeys are automatically invalidated if the primary key is. Remember to invalidate authentication subkeys for sshd!
Instead of using pregenerated revocation certificates (which do not include the current date, and no specific revocation reason), better use the primary key for revocation (GnuPG generates a new revocation certificate on the go).
- What happens if a user loses his Yubikey? Should I revoke the whole master key, or only the subkeys?
The primary key is safely stored in your vault, so why revoke it? Revoke the subkeys, generate a new set, and hand out a new Yubikey. The advantage is, that all incoming certifications stay valid, and you don't have to distribute a new primary key. In fact, all that need to be done is an update of the employee's key for all users.
- In case the key is lost, I would need to provide a new one to the user. Can I just import the old master+encryption key on it? and then
what, generate a new auth ssh key? In this case why bother
differentiating master/encryption key?
You didn't yet describe storing the primary key on your employee's YubiKeys. They're not required for day-to-day usage, better don't put it there anyway.
- How do I handle the fact that some users should share the same key? For example, the key for signing packages, or the key for
encrypting some shared files.
OpenPGP allows to add multiple recipients for encrypted messages. Is this an alternative? Signatures might be verified through a company key that signed employee keys.
You cannot withdraw a shared key easily, all you can do is revoke it. Otherwise, you have several options:
- Have some signing/decryption service. This might be a build server also signing packages for some authenticated users. There are also OpenPGP mail transfer agents that encrypt/decrypt on the go, you might use it for mapping a group encryption key to multiple users (the MTA decrypts with the private group encryption key, and reencrypts for all employee encryption keys).
- Distribute the subkey to all employees as files. This will get annoying if you need to revoke a subkey (for example, one of the employees leaves), as you have to escrow the distributed key.
- Distribute the subkey on OpenPGP smart cards (or YubiKeys, which implement the OpenPGP smart card protocol), so you can actually withdraw the smart card (as the key cannot be exported from the smart card). Disadvantage is, if one employee loses the key or does not hand it back after leaving the company, you still have to revoke. Managing safety of physical devices is easier, as they cannot be copied easily.
- Have a shared key on a single, well-guarded smart card (which cannot get lost or stolen easily) multiple people have access to.
