Note: My Web pages are best viewed with style sheets enabled.

PGP: Key Management

Copyright © 2008, 2010, 2020, 2022 by David E. Ross

Distributing a Public Key

As explained elsewhere, using OpenPGP to exchange encrypted messages or files requires that others possess the user's public key and that the user possesses the public keys of others. Also explained elsewhere, using OpenPGP to verify someone's digital signature requires possession of the signer's public key. Finally, as explained elsewhere, you do not care who has your public key; you actually want your public key to be widely distributed.

Distributing Via a Public Key Server

The simplest way to distribute a public key is to upload it to a public key server. Be aware of the following when using a key server:

Once you upload a public key to a key server, the key cannot be removed. You can create the key with an expiration date; it will indeed show on a key server as "expired" on and after that date. You can revoke the key; it will indeed show on a key server as "revoked" and will be unusable if downloaded. But you cannot remove the key — even an expired or revoked key — from the server.
If you really want your public key to be "widely distributed", you should upload to a key server that synchronizes with other key servers. You might upload your public key to PGP Corporation's keyserver.pgp.com (certserver.pgp.com), but that server does not synchronize with other servers and thus fails to distribute your key widely. NOTE: Because of hostile attacks against key servers, many no longer synchronize with other servers. That means that, for wide distribution, you must upload your public key individually to several servers.

Distributing Via a Web Page

Another way to distribute a public key is to put it on a Web page of your own.

This requires that you have a Web site.
This also requires that you know how to create Web pages.
The key block — the ASCII representation of the key from
-----BEGIN PGP PUBLIC KEY BLOCK-----
through
-----END PGP PUBLIC KEY BLOCK-----
— must be set as preformatted text between <pre> and </pre> tags.
If you use a tool to create Web pages instead of hand-coding them in a text editor, you should test the results after uploading the page to your Web server to make sure the tool has not altered the key.

Distributing Via E-Mail

Distributing a public key via E-mail generally fails to make the key "widely distributed". If you nevertheless wish to distribute your public key via E-mail, it should not be embedded within the message. E-mail clients too often make subtle changes (e.g., line-breaks) in messages, changes that corrupt OpenPGP keys.

Export your public key from your keyring into an ASCII file. The file should have a .asc extension. Be sure you export only the public key and not the entire key-pair.
Send an E-mail message with the exported key as an external attachment, not an in-line attachment.

Replacing a Key Pair

Some users generate their key-pairs with an expiration date; after that date, a new key-pair is needed because the old one is no longer valid. Other users decide to replace an existing key-pair when changing E-mail address, although a new address can easily be added to an existing key-pair. Then there is the situation when a key-pair must be revoked because it has been compromised, again requiring the generation of a new key-pair. An RSA v.3 key signed by a DH/DSS or RSA v.4 key will be treated as invalid by an OpenPGP application that handles only RSA v.3 keys (e.g., PGP v.2.6) and should be replaced.

Generating a new key-pair is simple. Just follow the user instructions for whatever OpenPGP application you are using. However, additional considerations apply beyond merely generating a new key-pair.

When an existing key-pair has an expiration date, a new key-pair should be generated about a month before that date. Put the new key-pair into use immediately. This overlap will provide continuity.
The new key-pair should be signed by the old key-pair. This must be done before the old key-pair expires or is revoked. This will aid others to validate your new key-pair.
(Do not do this if the old key-pair was compromised and you know that it was already used improperly.)
If your old private key was used to sign your other keys that are still in use, sign those other keys with your new private key. This will aid others to validate your other keys if they obtain those keys after the old key expires or is revoked. If those other keys were uploaded to public key servers, they should again be uploaded with the new signature.
If you previously sent your old public key to others, notify them about your new key. (If you uploaded the new key to a public key server, you don't have to send the key itself.) For the first month or two after the old key expired or was revoked, include a note in any message signed with the new key.

Note that an expired or revoked key can still be used to verify a message or file signature made before key's expiration or revocation. However, an expired or revoked key cannot be used to verify another key.

A Case Study

If you don't want to wade through a lengthy, tedious description, just go to the summary at the end of this section.

US-CERT (United States Computer Emergency Readiness Team) is an agency of the U.S. Department of Homeland Security. Among other activities, US-CERT tracks and reports on computer vulnerabilities, such as viruses and susceptibility to hacking attacks. US-CERT failed to heed any of the points above, causing problems for users of its reports.

To allow verification of the authenticity of its reports on vulnerabilities (since many such reports are hoaxes written by others) and the integrity of those reports (since some hackers might want to alter the reports), US-CERT uses OpenPGP to digitally sign its reports. The signature is generated by US-CERT's Publications Key. To aid users in validating its various keys, US-CERT also has a Master Key-Signing Key, which is used to sign all other US-CERT keys — including the Publications Key. Having verified the authenticity of the Master Key-Signing Key, I signed it when I added it to my keyring.

On or about 16 September 2008, US-CERT released "Technical Cyber Security Alert TA08-260A". This report described a vulnerability affecting Apple computers, which my daughter uses. Before reading the report, I decided to verify the signature on it. The verification failed because the report was signed by a relatively new Publications Key that I did not have. I downloaded the new Publications Key from the US-CERT Web site; but I could not verify the new key it because it had been signed by the Master Key-Signing Key, which had expired.

*** Begin Right Sidebar ***

Why did I call the US-CERT "hotline"? After all, the fingerprint on the Web page matched the fingerprint on the Master Key-Signing Key that I downloaded from a public key server.

The Web page was defective. The link to the Master Key-Signing Key was broken. That made me suspect the authenticity and integrity of the entire page, including the fingerprint documented there.

*** End Right Sidebar ***

Returning to the US-CERT Web site, I then attempted to download the new Master Key-Signing Key cited there. However, the link was 404 (a broken link to a non-existent Web page). I finally downloaded the new Master Key-Signing Key from a public key server. For two reasons, the new Master Key-Signing Key was useless to me. First of all, the Publications Key had not been signed by the new Master Key-Signing Key. More important, I could not verify the new Master Key-Signing Key. The Web page for downloading US-CERT keys (the page with the 404 link) contained a toll-free phone number for a "hotline" through which I could obtain the key's fingerprint (a 32-digit hexadecimal number). However, no one at that phone number knew anything about PGP keys.

To summarize:

US-CERT failed to issue any bulletin when it replaced its Publications Key and again when it replaced its Master Key-Signing Key. The intended audience for US-CERT reports had no knowledge of key replacements until attempting to verify signatures on those reports.
The old Master Key-Signing Key expired on 14 September 2008. The new Master Key-Signing Key was not generated until 26 September 2008, more than a week later. There was no overlap for continuity.
The new Master Key-Signing Key was not signed by the old one. The lack of any overlap prevented such signing. Validation of the new key was thus impaired.
Not all current keys were signed by the new Master Key-Signing Key. Although I had signed the old Master Key-Signing Key long before it expired and the old Master Key-Signing Key had signed the new Publications Key (generated 22 May 2008), PGP (the OpenPGP application that I use) nonetheless indicated that the new Publications Key was not valid.
The US-CERT Web page from which keys could be downloaded was not properly maintained. A broken link to the new Master Key-Signing Key could be a symptom of someone hacking the page; the same person could have also uploaded a bogus new Master Key-Signing Key to public key servers, putting that key's fingerprint on the hacked Web page.
US-CERT personnel at a phone number where keys were supposed to be verified knew nothing about OpenPGP. These are the people on whom we rely for the security of the nation?

A government agency involved in keeping the United States secure was very slipshod in maintaining its own infrastructure for the security of its Internet communications.

Transferring a Key Pair

The following assumes that both the source and target computers are physically and electronically secure even if communication between them is not secure.

You have a computer at home and another one at work. You would like to use the same key-pair at both locations. How do you safely transfer the key-pair from the computer where it was generated to the other computer without compromising it? Different computer configurations require different methods.

The three methods below provide a secure process for transferring a key-pair. The first two involve the owner of the key-pair physically carrying removable media from the source computer to the target computer without allowing anyone else access to the media. The third involves encrypting the key-pair so that it may be sent over a non-secure communication channel (generally an electronic channel but also by another person carrying removable media).

Two Similar Computers With Removable Media

Both computers are of the same type (e.g., both PCs or both Macs), and both have equivalent operating systems (e.g., both Windows). Both can use the same type of removable media (e.g., floppy disc, flash drive (memory stick)).

There are two simple ways to transfer:

Locate the files on the source computer for your public keyring and your private keys. Copy both files to some removable medium. Take the medium to the target computer. Copy the files from the medium to the target computer. Configure your OpenPGP application to use those files. NOTE: This assumes you did not already have a keyring on the target computer.
Using an OpenPGP application on the source computer, export your key-pair to the removable medium, ensuring that you specify inclusion of your private key. Take the medium to the target computer. Using an OpenPGP application on the target computer, import your key-pair. This works when you want to keep an existing keyring on the target computer.

When the transfer is completed, several issues must be addressed:

NEVER allow the removable medium out of your physical possession. It must remain in your hand or pocket at all times. If you must pass through a security checkpoint and have the medium scanned, you must keep your eyes on it.
When the transfer is completed, the removable medium must be thoroughly and securely erased or destroyed.
The key-pair on the target computer needs to be marked by your OpenPGP application as "implicitly trusted". This is generally not automatic.

Two Dissimilar Computers With Removable Media

The computers are of a different type (e.g., one a PC and the other a Mac) or have different operating systems (e.g., one with Windows and the other with Linux). Both can use the same type of removable media.

The method is the same as in the second bullet under Two Similar Computers With Removable Media. However, when exporting the key-pair from the source computer, it must be done in ASCII format (the default for some OpenPGP applications). The first bullet under Two Similar Computers With Removable Media cannot be used because file formats might be different.

When the transfer is completed, the same issues must be addressed as under Two Similar Computers With Removable Media.

Two Computers Without Removable Media

The computers might be of the same type with the equivalent operating systems, or they might not. Here the issue is that removable media cannot be used. There might not be any medium that is common and compatible between the two computers. One computer (or both) might have all capabilities for removable media disabled because of security concerns. One computer (or both) might not be physically accessible (accessible only via a remote terminal). Instead, communication between the two computers is over the Internet, an intranet, or a local-area network (LAN) none of which is secure.

The following sequence of steps will provide secure transfer of a key-pair from the source computer to the target computer through non-secure electronic communication:

If there is no key-pair already existing on the target computer, use the OpenPGP application to create a key-pair there.
Using the OpenPGP application on the target computer, export only the public key from that computer's key pair to that same computer's local hard drive.
Transmit the target computer's exported public key to the source computer. Since this is a public key, it can be done via a non-secure method (e.g., E-mail, FTP, parking it on a LAN's file server).
Using the OpenPGP application on the source computer, import the public key from the target computer into the source computer's keyring.
Using OpenPGP applications on both the source and target computers, verify that the correct public key was imported by comparing the fingerprints of the key on both computers.
Using the OpenPGP application on the source computer, export the desired key-pair to the hard drive of that same computer. Be sure to include the private key. The option for an ASCII-formatted file should be selected.
Rename the export file on the source computer to remove the file extension.
Using the OpenPGP application on the source computer, encrypt the export file using the public key from the target computer. This should be in ASCII format (not the default with some OpenPGP applications).
On the source computer, thoroughly and securely erase the unencrypted export file.
Transmit the encrypted export file from the source computer to the target computer. Since the file is encrypted, this can be done via a non-secure method.
Using the OpenPGP application on the target computer, decrypt the transferred file using the private key related to the public key cited in step #2.
On the target computer, rename the decrypted export file to restore the file extension.
Using the OpenPGP application on the target computer, import the renamed export file into that same computer's keyring.
On the target computer, thoroughly and securely erase the unencrypted export file.

(I actually used this method more than once where the two computers were dissimilar and where I could access one of them only through a remote terminal.)

When the transfer is completed, the issues to be addressed in this case are:

If a key-pair was generated on the target computer for this process in step #1, it may be erased as it was intended to be used only temporarily.
The imported key-pair on the target computer needs to be marked as "implicitly trusted". This is generally not automatic.

This third method may also be used with a removable medium if another person must be involved in carrying the medium between the two computers. In this case, to ensure that a bogus key-pair was not substituted for the actual key-pair, a test message should be signed on one computer and the signature verified on the other computer, both operations using the same key-pair. While the fingerprints of the two keys may be compared, the use of the keys for signing and verifying the signature gives far more assurance that the keys are identical.

29 October 2008
Updated 29 January 2022