Background information: A certificate can have one or more user IDs. These have the following form at the most: My Name (Comment) <email@address.test>

If the name or email address associated with an OpenPGP key changes, we recommend adding a new user ID to the key or certificate. This will automatically become the primary user ID and will be displayed more prominently.

The advantage of another new user ID over creating a new OpenPGP key is that the original fingerprint is retained, so that it does not have to be compared again by the communication partners during the certification of the new user ID. In addition, existing encrypted documents and mails can continue to be decrypted with the same key that is currently in use.

If necessary, you can revoke the old user ID, which makes sense if an old mail address is not redirected.

In the following example, the domain name of the mail address changes.

Open Kleopatra.

Right-click on your own OpenPGP key in the certificate list and select "Add User ID".

Then enter the desired new name and the new e-mail address. Usually, the information from the previous user ID is used by default, so that only the domain name has to be changed in the example. After making the change, confirm with OK.

Enter the password for the key in the “Passphrase” dialog box and confirm by clicking “OK”.

The new user ID is now displayed in the certificate list, but the old user ID is still listed in the certificate details:

Right-click on the certificate that has been modified in order to save it as a file. The suggested name always ends in "public.asc".

Then send the exported file to the communication partners in the way you have decided on. This can be done, for example, via a simple e-mail, since it is a public key.

There are several options for importing.

Normally, you can simply double-click on the received file to import it into Kleopatra. Or you can drag and drop it onto the Kleopatra window.

The following is the import method from within Kleopatra, with the certificate file located in the recipient's file system:

Open Kleopatra.

Click on “Import” in the toolbar.

Select the certificate file you have received and confirm by clicking “Open”.

If the "old" certificate was already present in the recipient's certificate list, no automatic prompt asking whether the certificate should be certified appears during the import.

Therefore, it is displayed as "non-compliant" (highlighted in red) after the import:

Now the new user ID needs to be certified:

Since the fingerprint of the old user ID has already been verified in the past, you now only need to check that the changed user ID is plausible before you carry out the certification:

After certification, the certificate is displayed again as “VS-NfD compliant” (green background):

You should not delete old keys, but keep them. Even if they have expired or been revoked, you can still use them to decrypt old data.

The same applies to other people's certificates: you can still use them to verify old signatures.

There are no guidelines as to when you should replace your key.

The BSI merely recommends that key pairs should have a maximum validity period of three years. If there is no reason to suspect that a key has been compromised, you can simply extend it (again and again) instead of creating a new one.

An expiration date ensures that a lost key will no longer be used after some time, even if it can no longer be revoked.

If you want to avoid having too much data encrypted with the same (sub)key, you can periodically add a new encryption subkey to your key and only extend the signature key. This is based on the assumption that an attacker gains knowledge of the key and password and that changing the encryption material then excludes the attacker from further access to the communication. This assumption and approach have a number of further implications that we cannot discuss here. If the key material is handled with care, this approach is not necessary.

The key material does not age.

Current algorithms are not expected to be breakable by brute force methods even after thousands of years.

As long as the security of the algorithm used is not questioned by the security community, it can continue to be used. We and the BSI would of course provide information if an algorithm should no longer be used and new key pairs should be created.

Yes, if the key is changed, the public key (= certificate) must be distributed to the communication partners, who then have to re-import it. This also applies if the expiry date is changed.

Only if the user ID has been changed, a new certification is required (see “Procedure for changing name or email”.)

There are several options.

Please take a look at our website at “GnuPG Infrastructure Services” and “GnuPG actium”.

We recommend either reading our whitepaper “Certificate management with GnuPG” on the subject or the document “Certification management with GnuPG VS-Desktop” (can be found in Kleopatra under Help -> More documentation). The latter focuses more on the practical part of the whitepaper.

You can then inquire about the procedure that seems most appropriate for your organization.

One option is to copy the secret key onto a USB stick marked VS-NfD (RESTRICTED, FOR INTERNAL USE ONLY) and hand it over in person. Another possibility would be to send it by post with guaranteed personal delivery. We recommend that the corresponding password be handed over separately by a different method in this case.

You can also store the secret key encrypted in a shared folder in a way that complies with the German regulation for VS-NfD (RESTRICTED, FOR INTERNAL USE ONLY) or send it by email like other VS-NfD data. To do this, the people who need the key of the functional mailbox must also have their own OpenPGP key to which the secret key file is encrypted.

In this way, passwords for symmetrically encrypted files can also be distributed securely and easily instead of sending them by courier.

For project groups, the use of the Kleopatra group function is usually recommended. The size of the group is (more or less) irrelevant. The data is encrypted for each of the participants when the group is selected as the recipient.

The groups are managed in Kleopatra. A group name should be given that corresponds to a team or project. If there is an email address for the project group, this should be used as the name. Then an email sent to this address is encrypted with all the certificates belonging to the group.

Care should be taken to ensure that one person is responsible for maintaining the group, so that only authorized persons are included in the group and that the new group definition is quickly made available to all participants when the list is changed.

Detailed documentation can be found in Kleopatra under "Help".