Managing PGP Keys with Partners

The encryption part of PGP is about ten percent of the job. Two commands, well documented, done in an afternoon. The other ninety percent is everything around the keys: generating them sensibly, getting public keys to partners without an impostor slipping into the middle, keeping private keys somewhere defensible, noticing expiry dates before they take down a production feed, and knowing — actually knowing, not guessing — which key belongs to which partner and who verified it.

Most organizations learn this the messy way. Keys arrive as email attachments and stay in the mailbox. Fingerprints go unverified because nobody knew they should be checked. Somebody keeps a spreadsheet, the spreadsheet drifts, and one morning a nightly job fails because a partner's key expired and the only person who understood the setup left last year. None of this is a cryptography failure; all of it is a management failure, and all of it is preventable with a small amount of process applied consistently.

This article is that process. It walks the full life of a key — generation, exchange, daily protection, expiry, revocation, rotation, and retirement — with the exact commands and the honest realities at each step. It assumes you know the basics of key pairs from how PGP file encryption works, and it is part of our PGP and at-rest encryption series.

The Key Lifecycle at a Glance

Every key you or a partner will ever use moves through the same five stages, and every key-related incident traces back to skipping the care one of them deserves:

1. Generate — create the key pair with deliberate choices about identity, expiry, and passphrase.
2. Exchange and verify — swap public keys with the partner and confirm authenticity through a second channel.
3. Use and guard — encrypt daily while the private key stays protected and the public keys stay inventoried.
4. Renew or rotate — extend or replace keys on a schedule you chose, not one an expiry surprise chooses for you.
5. Revoke and retire — end a key's life cleanly when it is compromised, superseded, or no longer needed.

Keep that arc in mind; the rest of the article walks it in order.

Generating a Key Pair Worth Keeping

Generation takes one command, but three decisions made before running it determine whether the key ages well.

Decision one: whose name goes on it. A key's user ID should describe a role, not a person: Acme Outbound Transfers <transfers@example.com>, not Bob Martinez <bob@example.com>. Keys outlive job assignments. A role-named key with a monitored mailbox survives Bob's promotion; a personal key becomes an awkward orphan that partners still encrypt to years after Bob left.

Decision two: the expiry date. Set one at creation — a horizon of a few years is a common, sensible choice. An expiry date is a dead-man switch: if the key is ever forgotten, leaked in some unnoticed way, or left behind by staff turnover, it stops being usable for new encryption on a known date instead of remaining a live risk forever. Expiry can always be extended later by the key's owner (covered below), so the date costs you nothing except a calendar entry.

Decision three: the passphrase. A passphrase encrypts the private key itself on disk, so a copied keyring file alone is useless without it. For keys a human uses interactively, a strong passphrase is non-negotiable. For keys used by unattended automation the answer is more nuanced — a job that runs at 2 a.m. cannot type — and the honest options are discussed in the private-key section below.

With decisions made, the commands are short. Generate on the machine where the key will actually be used, logged in as the account that will use it:

# Create the key pair (interactive prompts: role name, email,
# expiry, passphrase)
gpg --gen-key

# Confirm what was created, with fingerprints
gpg --list-keys --fingerprint

# Export the PUBLIC half for partners (safe to send to anyone)
gpg --armor --export transfers@example.com > acme-transfers-public.asc

# Create a revocation certificate NOW, while everything works,
# and store it OFFLINE — you will want it on the worst day
gpg --output acme-transfers-revoke.asc --gen-revoke transfers@example.com

That last command matters more than it looks. A revocation certificate is a small pre-signed statement that says "this key is no longer valid." You can only create it while you control the private key and know the passphrase — which is exactly what you may have lost on the day you need to revoke. Generate it at birth, print it or store it on offline media in a safe, and treat it like the spare key to a safe-deposit box: powerful in the wrong hands (anyone holding it can declare your key dead), essential in yours.

Exchanging Public Keys Safely

Public keys are public — sending one over plain email leaks nothing. So why does exchange deserve a whole section? Because the risk in key exchange is not disclosure, it is substitution. If an attacker can get you to import a key they generated — one whose user ID reads exactly like your partner's — then every file you "encrypt to the partner" is actually encrypted to the attacker. Encryption to the wrong key is worse than no encryption, because it comes with misplaced confidence.

Nothing in a key file defends against this by itself: anyone can generate a key bearing any name and any email address. The defense is the fingerprint — the short unique string derived from the key — checked through a second channel: a different communication path that an attacker sitting on the first one is unlikely to also control.

The working procedure, in full:

# 1. Receive the partner's public key file (email is fine for this)
gpg --import partner-payments-public.asc

# 2. Display the imported key's fingerprint
gpg --fingerprint payments@partner-example.com

# 3. Verify that fingerprint via a SECOND channel, e.g.:
#    - read it aloud on a phone call to a known contact
#    - compare with the fingerprint in the partner's onboarding
#      portal or printed in the signed trading agreement
# 4. Record: who verified, with whom, via what channel
# 5. Only then use the key for production encryption

Send your own public key with the same courtesy: attach the .asc export, and publish or communicate your fingerprint through a channel the partner can independently check. Public keyservers — searchable directories of uploaded keys — are best treated with caution in business exchange: anyone can upload a key under any name, so a keyserver result is a convenience for locating a candidate key, never a substitute for fingerprint verification with the partner directly. Partners who exchange files through structured B2B channels will recognize this ritual — it is the same trust-establishment step that certificate exchange plays in AS2 trading-partner setups.

Guarding the Private Key

Your private key is the single secret the whole arrangement depends on. Whoever holds it can read every file partners ever encrypt to you. The guarding rules are few and absolute:

• It never travels. Not by email, not in a chat message, not in a shared drive, not in a code repository. There is no legitimate workflow in which a private key is transmitted to a partner — any request to do so is a misunderstanding or an attack.
• It lives in the fewest possible places. Ideally: the one machine that performs decryption, plus a sealed offline backup. Every additional copy is another door. Resist the convenience of syncing a keyring across servers "just in case."
• The backup is deliberate. Export the secret key once, store it on offline media in a physically secured location (two locations if the data justifies it), and record where. A lost private key makes every file encrypted to it permanently unreadable — including your archives.
• Access is an account decision. On the machine itself, the keyring should be readable only by the specific service account that runs decryption — not by every administrator, not by the backup account, not by a shared operations login.

Automation forces one honest tradeoff. An unattended decrypt-on-arrival job cannot type a passphrase, so automation keys either run with no passphrase or with a passphrase supplied from stored configuration — which is protection theater if the configuration sits next to the keyring. The clean resolution is to accept the passphrase-less key and move the protection outward: a dedicated service account, a locked-down keyring directory, a hardened host, and monitoring on access. This mirrors the reasoning for unattended SSH keys, which the SSH key management series treats in depth — the same logic transfers directly.

Expiry: the Safety Net You Set in Advance

Expiry is the most misunderstood part of the lifecycle, so it is worth stating precisely what an expired key does and does not do.

• Encrypting to an expired key: partner tools will refuse or warn. This is the intended effect — the key stops accumulating new traffic on a known date.
• Decrypting with an expired key: still works. Expiry does not disable the private key, so your archive of old files remains readable. Expiry limits the future, not the past.
• Extending expiry: the key's owner can move the expiry date forward at any time — before or even after it passes — without generating a new key. The catch is distribution: the extension only helps once partners re-import your updated public key.

The extension commands, for the day your own key approaches its horizon:

# Open the key for editing, select expiry, follow the prompts
gpg --edit-key transfers@example.com
gpg> expire
gpg> save

# Re-export the updated public key and send it to every partner
gpg --armor --export transfers@example.com > acme-transfers-public.asc

Operationally, treat key expiry exactly like certificate expiry: an inventory with dates, a reminder that fires well ahead (60 to 90 days gives partner bureaucracies time to move), and a named owner for the renewal. The failure mode is identical too — a perfectly healthy system refusing to work at a date that was knowable years in advance. The certificate management series covers that discipline for TLS; borrow its calendar habits wholesale.

Revocation: How It Works, and Its Honest Limits

Revocation is the emergency exit: a declaration that a key must no longer be used, ahead of any expiry date. You reach for it when a private key may have been exposed — a compromised server, a stolen laptop, a departed insider with a copy — or when a key is simply superseded and you want no straggler traffic.

Mechanically, revoking means importing the revocation certificate you generated at key creation, which marks the key revoked on your keyring, and then distributing the revoked public key exactly as you distributed the original:

# Apply the stored revocation certificate to your keyring
gpg --import acme-transfers-revoke.asc

# Export the now-revoked public key and send it to all partners;
# their tools will refuse to encrypt to it once imported
gpg --armor --export transfers@example.com > acme-transfers-REVOKED.asc

Now the honest limits, because revocation is weaker than people assume. There is no central kill switch: a partner who never receives and imports the revoked key will keep encrypting to the old one indefinitely, with no error. Revocation is therefore a communication task wearing a cryptographic costume. The real sequence on a compromise day is: revoke locally, notify every affected partner directly with the replacement key and fingerprint, confirm each has switched, and treat everything encrypted to the old key during the exposure window as potentially read. The partner list you need at that moment is exactly the inventory described below — which is the strongest argument for building it on a calm day.

Rotation Without Breaking Partners

Sooner or later you will replace a key deliberately — approaching expiry, staff turnover, tightened policy. Rotation done abruptly breaks partner feeds; done with an overlap window, nobody notices. The sequence:

1. Generate the new key with the same role-based user ID and a fresh expiry.
2. Distribute the new public key to every partner who encrypts to you, with its fingerprint, and have each verify it as at first onboarding.
3. Run the overlap: keep the old private key available while partners migrate on their own change schedules. Inbound files encrypted to either key still decrypt.
4. Confirm migration partner by partner — the arriving files themselves tell you which key they were encrypted to.
5. Close out: revoke or let the old key expire for new use, but archive its private key securely rather than destroying it if any retained files are encrypted to it. A destroyed key turns your own archive into noise.

The reverse direction — a partner rotating the key you encrypt to — is easier, but only if it reaches the right place. Import the new key, verify its fingerprint through the second channel, and update every automated job that encrypts for that partner. In a workflow tool such as Sysax FTP Automation, where a scheduled task performs OpenPGP encryption before sending, that means updating the recipient key the task uses — one deliberate change in one place, which is precisely why encryption settings belong in defined workflow tasks rather than scattered across ad-hoc scripts.

Escaping the Partner-Key Spreadsheet

The typical organically grown state: public keys scattered across mailboxes and home directories, verification status unknown, expiry dates unrecorded, and one stale spreadsheet nobody fully trusts. The escape is not a fancier tool; it is a minimal inventory with an owner, reviewed on a schedule. One row per key you hold — yours and partners' — with these columns:

Two habits keep the inventory honest. First, no key enters production without a row — make the inventory update part of the same change that deploys the key into the encrypting job. Second, review it on a recurring calendar entry: check approaching expiries, confirm listed flows still exist, and delete rows for retired partners (after confirming no retained archives depend on their keys). Fifteen minutes a quarter buys you a clean answer to the two questions that otherwise cause panic: "which key does this partner use?" and "what breaks if we lose this key today?"

A Calm Key Practice, Summarized

Everything above compresses to a short creed. Generate keys with role names, expiry dates, and a revocation certificate stored offline. Trust no imported key until its fingerprint is verified through a second channel and the verification is recorded. Let the private key live in one guarded place plus one sealed backup, and never let it travel. Treat expiry like certificate expiry — calendared, owned, renewed early. Treat revocation as a communication exercise with a partner list you built in advance. Rotate with overlap windows, and never destroy a private key that your own archives still depend on.

With keys under control, the next article in the series puts them to work: encrypt-before-send workflows that don't break automation. If you are still weighing whether file-level encryption is warranted for a given flow at all, when file-level encryption is worth the overhead is the decision guide, and how PGP works remains the reference for the mechanics underneath it all.

Frequently Asked Questions