I've just created a new off-line GPG-key with a sign/certify master-key and two sub-keys - one for signing and one for encrypting. 5 yr expiration for the master, 2 yr for the subs. My master-key got just my name and my dob as UID... The sub-keys(?) got 5 UIDs, with pairs of my name and an email.

BTW, are the UIDs associated with one sub-key, with all sub-keys, with the master, or with the whole chain? Is it possible to connect one ID to one particular sub-key - eg. a sub-key used only for signing software-packages, and with an UID reflecting this. ...Or is it better to make a separate key for this purpose, and sign/cross-sign it with my normal (above) key?

I also have several old keys - some expired - uploaded to keyservers. I would like to revoke these keys.


If I understood correctly, I should sign my new (offline) key with my old keys, to certify that the new key is mine...

But should I also use my new key to sign my old keys, and upload them to a keyserver (even the already expired keys)?

Finally I would revoke all but my newest key... Will it be enough to revoke the main-key, or will I have to revoke all sub-keys too (where applicable)?

Can I do all this locally before uploading my modified keys to the key-server - or will the fact I've already revoked them be an issue when uploading my new key with their signatures?
My suggested workflow: Create new key, sign new key with old, sign old keys with new(?), revoke old keys, update all keys to server.

BTW, when having an offline key with sub-keys for encrypting and signing... I get that I use the sign sub-key to sign files and messages... And that I must use the complete key (with the usually offline parts) to self-sign changes to my key with my master-key... But what about other peoples keys? Can I sign their keys with my sign sub-key - or must I use the master-key (the complete key)? Can I do both, but one is recommended?

  • 1
    I have to ask, did you really need to generate a new key? Most PGP keys (for individuals) have expiration measured in appreciable percentages of lifetimes; basically you have one master PGP key forever, which is helpful since (MIT keyserver aside) you still have to manually coordinate key replacement with all expected counter-parties. I'm working up a full answer for you (which is underpinned by the desire to revoke the old key), but have to ask if you've fully considered this course of action. – Ruscal Feb 27 at 18:40
  • Probably not - but it hadn't been used much (as in, at all) nor been signed by anyone (AFAIK), and since it's now long expired, I decided to make a "clean break". Originally I'd intended to extend the expiration date of the master-key and just create new sub-keys every other year, but I forgot about it so it seriously expired. (I'm also currently not quite sure if I'll find the off-line parts of the old key - I know it's on an USB-pen, and I know I put somewhere "smart and safe"... obviously, that was my first mistake.) – Baard Kopperud Feb 28 at 10:58

Thanks for the comment response, that helped a little bit.

These are general recommendations, YMMV and you can always tweak them to your own needs. This is just a good place to start and things to keep in mind, but proper security posture is an individual endeavor, not a one-for-all thing.

First off, don't sign your new key with your old one. If you haven't used the old key before then it doesn't have an existing chain of trust, so using it to sign something isn't adding much (if any) weight to the identity assertion. And once you revoke the old key (our next step) then it will add zero weight to any claim made. This is only useful if your old key has been previously used as it helps assure other folks that the new key isn't a scam (they trusted the old key, which is telling them to trust [signing] the new one)

Note: whenever I say "key" I mean the same as what you seem to be calling "main key". I will specify "sub-key" when talking about a use-specific descendant of the "key".

Secondly, revoke your old key -- make sure to put the reasons in the revocation (reason is either "no longer used" or "superseded"), and put in a description that includes your new key ID "Key has been replaced for logistic reasons, new KeyID is 12BC-A29D". Once you have the revocation certificate created, publish it to the public key servers (really, just send it to MIT, it'll make it from there). This takes care of turning off the old key; you've revoked it and listed it as unused in the public servers (with a hint and how to find/validate your new key). At this point you can totally forget about your old key.

Always Remember :: When removing keys from public key servers you MUST issue a revocation certificate and submit that to the server. Even if some servers include a "delete this key" field, they're lying at it won't fully delete it. The only way to truly cancel a previously published key is to issue a revoke.

Now, on to your new key.

You've got a decent start here. The normal recommendations are these:

  1. Make your key time-limited.

Normally this results in people making 1-year (I use 13 months) expiration dates on their keys. Then they will perform maintenance yearly, during which they'll extend the expiration and send the updated key to the public servers. This provides protection against lost/unused keys, they'll automatically expire unless you take a regular action to refresh them.

  1. Make a revocation certificate up front

This is in case of loss. The general recommendation is to have either a "no reason" or "key compromised" revocation certificate made just after you make the new key (before you submit it to public servers even). Then to print this certificate (I highly recommend an OCR font) and throw it in your physical safe keeping location (a safe at home, a bank deposit box, where ever you'd keep important & hard-to replace documents like original birth certificates or original social security cards and passports). Should something happen that causes you to lose control of the key, you will still have a way of revoking it; that makes it a really good just in case item.

  1. Don't worry yourself about the sub-keys

I'm not saying don't use sub-keys. I'm just saying that you are using a well made PGP implementation (I have GPG on all my machines, regardless of OS) that handles all of that for you. You raise several points regarding Sub-Key IDs or sub-key attestation and management, and while those are things that we have to worry about on the design and implementation side they aren't things an end-user need to fret over. The GPG software has created a Key Pair for you, and (at your instruction) created a set of managed sub-keys for specific purposes. When you use GPG to sign something, it will automatically use the proper sub-key; same for encryption & authentication (if you create an auth key and have something that'll use it). If you want to dive into how PGP works, that is a whole deeper pond, but for just using it all you need to worry about is "your key" (what you seem to be referring to as the master) in GPG -- the software will handle the rest from there.

  1. Your key is you

That PGP key is now leveraged as an identity source. People can verify something was done by you simply by checking a signature. Don't muddy up the waters by creating entirely separate keys. If you need, you can add more User-IDs to the existing key (useful if you get a new email address, or if you need to attest to a new persona you carry). If you want to sign something, use the signing sub-key of your key; that's the whole reason for sub keys. If you ever get something that was handled by a PGP key with the master ID of 6742F54F27B19AC2 then you know it was from me. The key is you, don't fragment your identity into multiple keys, but also protect your key just as surly as you'd protect your birth certificate and passport. Your protection can vary from adding a passcode to the PGP key (GPG should have prompted you to create one, but you could have chosen not to) up to offloading the private-key component onto a smartcard (I do this, with a YubiKey) to give you that multi-factor and physical possession safety net; this is very much one of the "what is best for you personally" items.

TLDR -- Don't sign the new key with the old one. Issue a revocation certificate for the old key and submit it to the public servers. Make sure your new key has an expiration date, you can make it not-to-far-out and just extend it regularly. Don't worry about manually managing which sub-key to use. Don't create 2nd (or 3rd) keys for different purposes. Do protect your key as if it was enough information to steal your identity (because it is).

  • Thanks - great answer! So just to clarify; 1) if I had more actively used my old keys and they'd been signed by many people, then signing my new key with the old key(s) would've been a good idea? 2) Should I then still have revoked the old key(s) (after switching)? 3) So you think it's a bad idea to make a separate key for signing software I create (to GitHub, LaunchPad &c) - I should just use my usual key? TBC – Baard Kopperud Mar 2 at 11:51
  • Cont. 4) But what if my programming was kept more separate - eg. I created a one-man firm for it, and used it as uploader... Would it be more appropriate to make a separate key? 5) And should this key be signed by my personal key - and perhaps my personal key with my software key? – Baard Kopperud Mar 2 at 11:57
  • @BaardKopperud 1) yes, if your old key had trust them it'd make sense to use it to sign the new, people who already trust the old key will carry that trust to the new. But once revoked the old key can't gain new trust, so it offers no benefit to the new key. 2) yes, never leave a key active if you don't want to use it to receive new PGP messages right now. You've stopped using the old key, revoke it as no longer in use. 3) yes, I do. That is still you doing that code work, then you should sign it as you (but this is one of those, look at what works best for you point - some companies... – Ruscal Mar 2 at 19:07
  • ... you to use a company generated key for work output (you aren't the coder, the company is, and the coffee doesn't belong to you it belongs to company) 4) yeah, that's an edge case you'll have to consider for yourself. Nominally, who is the one that gets to take credit for the code - you or the company. Might sound the same now, but if you bring in more coders or sell the company in the future it'll make a world of difference. 5) signing a key is offering an extension of the casino of trust. It says "if you trust me, and I trust this other key, you should trust it to". They will all... – Ruscal Mar 2 at 19:14
  • ... work without signing. Signing is just an extension of trust. Everyone treats it a little different, but the original training was to treat it like a Notary validating signatures on contracts. I don't sign someone else's key unless I first verify official documents verifying their ID (which means I meet them in person at least once to check a photo ID); even people I've worked with online for years have to get a face 2 face first. In the crypto world "trust" is a HUGE thing. Feel free to give it if it makes sense, but don't just go trusting anyone (you've vouched for them at that point) – Ruscal Mar 2 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.