I am trying to create a secured policy for storing and maintaining keys between users of my company.

I am rather new to GPG and thus need some advice.

Currently, the idea is:

• Generate a master key per user with only the certify capability. Backup this key in a physical vault.
• Generate a revocation certificate for this master key, and also store it in a physical vault.
• Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
• Generate an auth subkey (for ssh) directly on the Yubikey.

This is a sort of summary of what I found on the internet as the proper way to manage user keys with GPG.

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.
• What happens if a user loses his Yubikey? Should I revoke the whole master key, or only the subkeys?
• 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?
• 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.

I'm also open to any good documentation on the subject. I dug through the docs on the GnuPG website, but the manuals, handbooks and wikis are more like "usage sheets" rather than explaining the whole process. I do understand asymmetric cryptography, but there is a mental gap between understanding the concept, and doing mumbo-jumbo with these concepts to have a clean process.

I am trying to create a secured policy for storing and maintaining keys between users of my company.

I am rather new to OpenPGP and thus need some advice.

Currently, the idea is:

• Generate a master key per user with only the certify capability. Backup this key in a physical vault.
• Generate a revocation certificate for this master key, and also store it in a physical vault.
• Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
• Generate an auth subkey (for ssh) directly on the Yubikey.

This is a sort of summary of what I found on the internet as the proper way to manage user keys with GnuPG.

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.
• What happens if a user loses his Yubikey? Should I revoke the whole master key, or only the subkeys?
• 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 authentication SSH key? In this case why bother differentiating master/encryption key?
• 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.

I'm also open to any good documentation on the subject. I dug through the docs on the GnuPG website, but the manuals, handbooks and wikis are more like "usage sheets" rather than explaining the whole process. I do understand asymmetric cryptography, but there is a mental gap between understanding the concept, and doing mumbo-jumbo with these concepts to have a clean process.

I am trying to create a secured policy for storing and maintaining keys between users of my company.

I am rather new to GPG and thus would need some advices.

Currently, the idea is:

• Generate a master key per user with only the certify capability. Backup this key in a physical vault.
• Generate a revocation certificate for this master key, and also store it in a physical vault.
• Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
• Generate an auth subkey (for ssh) directly on the Yubikey.

This is a sort of summary of what I found on the internet as the proper way to manage user keys with GPG.

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.
• What happens if a user looses his Yubikey? Should I revoke the whole master key? or only the subkeys?
• 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?
• How do I handle the fact that some users should share the same key? like, the key for signing packages, or the key for encrypting some shared files?

I'm also open on any good documentation on the subject. I digged through the docs on the GnuPG website, but the manuals, handbooks and wikis are more like "usage sheets" rather than explaining the whole process. I do understand asymmetric cryptography, but there is a mental gap between understanding the concept, and doing mumbo jumbo with these concepts of have a clean process.

I am trying to create a secured policy for storing and maintaining keys between users of my company.

I am rather new to GPG and thus need some advice.

Currently, the idea is:

• Generate a master key per user with only the certify capability. Backup this key in a physical vault.
• Generate a revocation certificate for this master key, and also store it in a physical vault.
• Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
• Generate an auth subkey (for ssh) directly on the Yubikey.

This is a sort of summary of what I found on the internet as the proper way to manage user keys with GPG.

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.
• What happens if a user loses his Yubikey? Should I revoke the whole master key, or only the subkeys?
• 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?
• 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.

I'm also open to any good documentation on the subject. I dug through the docs on the GnuPG website, but the manuals, handbooks and wikis are more like "usage sheets" rather than explaining the whole process. I do understand asymmetric cryptography, but there is a mental gap between understanding the concept, and doing mumbo-jumbo with these concepts to have a clean process.

I am trying to create a secured policy for storing and maintaining keys between users of my company.

I am rather new to GPG and thus would need some advices.

Currently, the idea is:

• Generate a master key per user with only the certify capability. Backup this key in a physical vault, and move it to a Yubikey.
• Generate a revocation certificate for this master key, and also store it in a physical vault.
• Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
• Generate an auth subkey (for ssh) directly on the Yubikey.

This is a sort of summary of what I found on the internet as the proper way to manage user keys with GPG.

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.
• What happens if a user looses his Yubikey? Should I revoke the whole master key? or only the subkeys?
• 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?
• How do I handle the fact that some users should share the same key? like, the key for signing packages, or the key for encrypting some shared files?

I'm also open on any good documentation on the subject. I digged through the docs on the GnuPG website, but the manuals, handbooks and wikis are more like "usage sheets" rather than explaining the whole process. I do understand asymmetric cryptography, but there is a mental gap between understanding the concept, and doing mumbo jumbo with these concepts of have a clean process.

I am trying to create a secured policy for storing and maintaining keys between users of my company.

I am rather new to GPG and thus would need some advices.

Currently, the idea is:

• Generate a master key per user with only the certify capability. Backup this key in a physical vault.
• Generate a revocation certificate for this master key, and also store it in a physical vault.
• Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
• Generate an auth subkey (for ssh) directly on the Yubikey.

This is a sort of summary of what I found on the internet as the proper way to manage user keys with GPG.

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.
• What happens if a user looses his Yubikey? Should I revoke the whole master key? or only the subkeys?
• 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?
• How do I handle the fact that some users should share the same key? like, the key for signing packages, or the key for encrypting some shared files?

I'm also open on any good documentation on the subject. I digged through the docs on the GnuPG website, but the manuals, handbooks and wikis are more like "usage sheets" rather than explaining the whole process. I do understand asymmetric cryptography, but there is a mental gap between understanding the concept, and doing mumbo jumbo with these concepts of have a clean process.