The default algorithms and key lengths follow current best practices. In most cases, there is no need to change them.

Using stronger algorithms, for example, RSA with 4096 instead of 3072 bits, does not offer a meaningful security advantage in practice, but can have drawbacks. Encryption and decryption with RSA-4096 is significantly slower, and some smartcards do not support such key lengths.

If you plan to use OpenPGP keys on a smartcard, it may be worth switching from RSA-3072 to ECDSA/EdDSA (or Brainpool) for better performance and security properties. However, this can lead to compatibility issues with older or non–VS-NfD-compliant software.

International communication also requires some caution: not all countries permit the same algorithms. RSA is generally the most compatible choice.

Technically, it is also possible to include multiple algorithms in a single certificate to meet different requirements. However, in a VS-NfD context, all algorithms used (for both signing and encryption) must be VS-NfD compliant for the certificate to be accepted. Subkeys for authentication are not taken into account in this evaluation.

Background information: A certificate can include one or more user IDs. These usually follow this format:

My Name (Comment) <email@example.test>

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

The advantage over creating a new key: the original fingerprint remains unchanged. Your communication partners don't need to verify it again when certifying the new user ID. You can also continue decrypting previously encrypted files and emails, using the same key as before.

If needed, you can revoke the old user ID, for example, if the previous email address is no longer forwarded.

In the example below, the domain part of the email address has been changed.

1. Open Kleopatra.

2. Right-click your own OpenPGP certificate in the certificate list.

3. Select Add User ID from the context menu.

4. Enter the desired new name and email address. Usually, the fields are pre-filled with the values of your existing user ID. In this example, only the domain name needs to be updated.

5. Confirm the changes by clicking OK.

6. In the password dialog, enter your key's password and confirm by clicking OK.

7. The certificate list now shows the new user ID. The old user ID is still visible in the certificate details.

8. If you haven't integrated your own keyserver into your Active Directory: Right-click the modified certificate and select Export to save it to a file. The suggested filename usually ends with public.asc.

9. Then send the exported file to your communication partners using the method they expect – for example, via plain email, since it's a public key.

Note: If the old email address is no longer reachable, you can revoke the corresponding user ID.

There are several ways to import a certificate: Usually, you can just double-click the received file – Kleopatra will import the certificate automatically. Alternatively, you can drag and drop the file into the Kleopatra window.

Below is the method for importing directly from within Kleopatra, assuming the certificate file is already saved on the recipient's system:

1. Open Kleopatra.

2. Click Import in the toolbar.

3. Select the received certificate file and confirm by clicking Open.

4. If the "old" certificate is already listed in the recipient's certificate list, Kleopatra does not automatically ask whether the certificate should be certified during import. As a result, the updated certificate will initially appear as non-compliant (highlighted in red).

5. Now the new user ID needs to be certified:

6. Since the fingerprint of the old user ID was already verified in the past, you now only need to check whether the updated user ID looks plausible before proceeding with the certification.

7. After certification, the certificate will once again be marked as VS-NfD Compliant, indicated by the green background.

You should not delete your old keys, but keep them. Even if a key has expired or been revoked, you can still use it to decrypt older data.

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

There are no strict rules on when you should renew or replace your key.

The BSI recommends limiting the validity of a key pair to a maximum of three years. As long as you have no reason to believe that your key has been compromised, you can simply extend its validity again and again. There's no need to create a new key in that case.

Setting an expiration date helps limit the risk if you lose your key and can no longer revoke it. After some time, it will automatically become unusable.

If you want to avoid encrypting too much data with the same (sub)key, you can generate a new subkey for encryption at regular intervals and just extend the signing key. This reduces the risk in case an attacker ever gains access to your key and password, because from that point on, they won't be able to decrypt any new communication.

This approach assumes that someone gains access to your private key and its passphrase. It raises additional technical and organizational questions that we won't cover here.

If you handle your key material carefully, you usually don't need to take this extra step.

No, cryptographic keys do not age.

As of today, modern algorithms are considered secure against brute-force attacks for many centuries to come.

As long as the security community does not raise concerns about a particular algorithm, you can continue using it without worry.

If that changes, we (and the BSI) will of course let you know, so you can generate new key pairs if necessary.

Yes, if you make changes to your key, you need to redistribute the public part (i.e., the certificate) to your communication partners. They will then need to import the updated key.

This also applies if you only changed the expiration date.

If you've added or modified a user ID, you also need to have it certified again (see What should I do if my name or email address changes?).

Manually certifying individual certificates takes time, especially if new or updated user IDs are added regularly. Fortunately, there are several ways to significantly reduce the effort required.

A good place to start is our pages on GnuPG Infrastructure Services and GnuPG actium. You'll also find our white paper Certificate Management with GnuPG VS-Desktop®. The document “Certification Management” is available in Kleopatra under Help / More Documentation. It focuses on practical implementation and complements the white paper with real-world examples.

Once you've reviewed the materials, we're happy to help you choose the approach that best fits your organization.

If you're managing even a few dozen certificates, using GnuPG actium is worth a look. The tool automates internal certifications, saves time, and keeps your workflows running smoothly.

One option is to copy the private key to a USB stick labeled as VS-NfD and hand it over in person. Alternatively, you can send it by postal mail with guaranteed personal delivery. In either case, make sure to transfer the associated passphrase separately using a different communication channel.

Alternatively, you can store or send the private key encrypted in compliance with VS-NfD requirements, for example, in a shared folder or via email, just as you would with other VS-NfD data. To do this, each person who needs access to the shared key must have their own OpenPGP key. The private key file is then encrypted to their individual keys.

This method also allows you to securely and easily distribute passphrases for symmetrically encrypted files. There is no need to send them by registered postal mail.

For project or work teams, Kleopatra's group feature is usually the best option. Group size doesn't matter much, any data sent to a Kleopatra group is automatically encrypted for each individual member.

Groups are managed directly in Kleopatra. Choose a group name that clearly reflects the team or project. If there's a central email address for the group, it's best to use that as the group name. This way, encrypted messages sent to that address will be accessible to all group members, provided their certificates are included in the group.

Make sure one responsible person maintains the group regularly. Only authorized individuals should be included, and any updates to the group should be promptly shared with all members.

A detailed guide to the group feature is available in Kleopatra under Help.