New wiki page: generating the Authority Key

[tilsammans]

Hey gang

I tried setting up GPG Sync but noticed I needed a little more hand-holding with the Authority Key generation. I decided to add a page to the Wiki but I cannot add id. I will post the entire Markdown text in the next comment. I have cloned your Wiki as well.

I hope you'll be able to use my contribution. If something needs changed, I'm your man.

[tilsammans]

GPG Sync encrypts the information that it communicates between computers. To
configure the app for the first time, generate what we call an Authority Key.
You can go naieve but simple, or do it properly, which is more work.

Option 1: naieve but simple

Generate a new keypair:

$ gpg2 --full-generate-key

• (1) RSA and RSA (default)
• What keysize do you want? 4096
• Expiration: 0 (never) or consider a period (you can always extend)
• Real name: your name, organisation name or "GPG Sync Example Authority"
• Email address: fill in a working one that makes sense for you
• Leave the comment blank
• Enter a passphrase. I recommend using the Diceware method.

The result:

pub   rsa4096 2018-08-25 [SC]
      7E964EB8685149584756E968A5DEA5900CC36E50
uid                      GPG Sync Example Authority <info@example.com>
sub   rsa4096 2018-08-25 [E]

Option 2: One Key that binds them

Generating a totally new keypair for each purpose is fine, but they have no
strong relation to each other, where in fact they were all generated by a
single person; you. And since each keypair has full capabilities, you need
to use the nuclear option when you lose any single one.

It would be better to have one key—let's call it Master—that we'll use to generate
many subkeys, which are our worker keys that can be used for a single thing,
and when they get lost you don't have to press the panic button right away.

The ultimate end game here is moving your Master Key to a secure hardware device
like a yubikey, which means it will be gone from the relative hostile
environment that bred it. This will not be discussed here, as there are plenty
of good documents online that describe exactly how that works.

####$ Generate Master Key

$ gpg2 --full-generate-key

• (1) RSA and RSA (default)
• What keysize do you want? 4096
• Expiration: 0 (never)
• Set your organization name
• Set your organization email address
• Leave the comment blank
• Use a new, unique passphrase based on Diceware.

Make a note of the fingerprint and the key ID.

Generate a single-purpose subkey

Follow this procedure to generate as many keys as you need. One key typically
has a single use: being an Authority Key, one for GitHub, one for BitBucket, and
you can even use one to open SSH connections.

$ gpg2 --edit-key KEYID

gpg> addkey

• (4) RSA (sign only)
• What keysize do you want? 4096
• Expiration: 5y or never if you prefer

gpg> save

Make a note of the fingerprint and the key ID.

Add your other identities

You should add all other identities (email most importantly) directly under your
control to your Master Key. Use adduid to make it happen. Also, consider
setting your profile photo using addphoto. It will get distributed along
with the public key details, making your key easier to spot.

Create a revoking certificate

This will become your nuclear option in case Master Key is compromised.

$ gpg2 --gen-revoke NAME

You don't use this when one of your subkeys needs to be decommissioned. Edit
your key instead and use revkey.

Create a backup for safe keeping

Time to copy everything we created so far and move it to a secure location.
Don't keep these backups on your computer and don't upload them to S3 either!
Make sure access to it is as restricted as possible.

Using --armor is optional; it creates rugged ASCII output that handles
transmission throughh various mediums better than the default, binary, output.

$ gpg2 --armor --export --export-options backup
$ gpg2 --armor --export-secret-keys --export-options backup

[tilsammans]

My clone of your Wiki is here: https://github.com/tilsammans/gpgsync-wiki

[micahflee]

Thanks for working on this. I'm hesitant to include such specific instructions though without thinking them through thoroughly first. There are so many different permutations for managing a PGP key, and like threat modeling, I think the right choice really depends on the organization.

Some might choose to include the authority key on a Yubikey, and even only ever using it on an airgapped computer. But for other organizations, it might be fine (and definitely more usable) to store it in the techie's GPG keyring with a passphrase. All of these choices have security and usability trade-offs.

I think a more useful document would list what the options are for generating the authority key and what the trade-offs are, so people can make an educated choice on how they want to protect their authority key. One way of doing this, maybe, would be to offer 3 different options, each with a list of pros and cons, and step-by-step instructions for generating key in those ways.

I think things to consider would include:

• Should you store your authority key on a smart card?
• Should use generate a default PGP key, or use subkeys?
• Should the key expire, and you regularly push the expiration date, or should it not expire?
• Should you compartmentalize your use of this key? -- e.g., maybe you should have an air-gapped Tails USB that you boot to in order to make digital signatures, so if your main computer gets compromised the authority key is still safe.
• How should you create, and where should you store, a backup of the authority key?
• Where should you store the PGP passphrase, or the smartcard PIN, in case you forget it?