When to Use This

This option is well suited when multiple people need access to the same email inbox—such as a functional address like support@example.com.

Setup Instructions

1. Create a standard secret key for the functional address.
2. Distribute this key to all team members—for example, using Kleopatra via File / Backup Secret Keys.

How It Works

• Anyone with access to the functional mailbox can read encrypted emails.
• Outgoing messages from the functional address can be both encrypted and signed using the shared key.

→ This allows the entire team to read incoming messages and send encrypted replies.

When the Team Changes

• New team members receive the shared secret key.
• If someone leaves the team, the existing key is revoked and replaced with a new one. The corresponding revocation certificate and the new key must be distributed to all remaining team members.

Note: Since the new key has a different fingerprint, it must be revalidated—either by your internal certificate authority or by the users themselves.

Benefits

• Very easy to set up
• Quick to implement—no additional tools required

Things to Keep in Mind

1. Anyone with access to the secret key can make changes to the certificate.
2. Emails are always signed using the functional address—individual attribution is not possible. (Depending on your use case, this may actually be desired.)

Extended Option

If you need more control and stronger security, you can extend this setup as follows:

1. Central Key Management

One or two designated individuals are responsible for managing the full key for the functional address.Only they have access to the part of the key that allows changes—the subkey with the Certify capability.

2. Limit Access for the Team

For all other team members, provide a reduced version of the secret key that includes only the subkeys for Sign and Encrypt/—but not the /Certify subkey.

This allows the team to encrypt, decrypt, and sign emails, while preventing any changes to the key itself (such as adding user IDs).

Note: This approach prevents unintended modifications to the functional address key by team members. Day-to-day use remains simple—only the administrative overhead increases slightly.

Guide: Creating a Team Key for a Functional Mailbox

gpg --quick-gen-key FUNKTIONS_MAIL rsa3072 cert

> gpg --quick-add-key FINGERPRINT rsa3072 sign
> gpg --quick-add-key FINGERPRINT rsa3072 encrypt

> gpg --export-secret-subkeys -a FINGERPRINT > TEAMKEY_SECRET_no-certify.asc

When to Use This

This option is suitable for closed email distribution lists or centrally encrypted documents that should be accessible to a defined group of people.

Setup Instructions

In this context, a "group" refers to a Kleopatra group—a collection of public keys bundled together for easier handling.

1. Each team member has their own certificate.
2. A designated person creates a Kleopatra group using the public keys of all team members.
3. The group file is shared with all participants and imported into their environment.
4. [Optional] The group can also be shared with third parties (see the “Things to Keep in Mind” section).

How It Works

• All team members receive messages directly in their personal inboxes.
• The group can be used as the recipient to send a single message encrypted for all members at once.
• The message is encrypted individually for each recipient using their personal public key.
• When replying to external contacts, the response is always sent from the user's personal address—not the functional address. The message is also signed with the user's own key.

When the Team Changes

• New members are added to the group; departing members are removed.
• The updated group file must be redistributed to all team members and re-imported.

Benefits

• No shared secret key is required.
• Each team member uses their own existing certificate.
• Key management remains decentralized—no central key administration is necessary.

Things to Keep in Mind

1. The functional address itself does not have its own certificate—so it cannot be used as an independent, encrypted identity.
2. The group file must be distributed and imported in advance. This only works if all team members are using GnuPG VS-Desktop^®.
3. Replies to external contacts are always sent from personal addresses—not the functional address.
4. Responses are signed using the sender's personal key.
5. Messages sent by one team member to external recipients cannot be read by the rest of the team.
6. Replies to messages within the team are also only readable by the original sender—not the entire group.

Note: Issues 3 and 4 can lead to confusion for external recipients who may expect a single, unified team address but receive replies from individual users instead.

Extended Option

To reduce the impact of the limitations mentioned above, consider the following measures:

• When replying to external messages, set the Reply-To field to the shared functional address. This ensures a consistent reply address, even though the email is technically sent from a personal account.
• Include the group in CC when replying to external contacts. This keeps the conversation visible to the entire team, even if only one person responds.

When to Use This

This option is suitable for functional email addresses where incoming messages are automatically forwarded to the personal inboxes of individual team members.

Setup Instructions

1. Each team member has their own certificate.
2. A private key is generated for the functional address.
3. From this key, a certificate is created that contains only the secret decryption subkey.
4. This certificate is distributed to all team members.
5. Each team member imports the certificate containing the secret decryption key.

How It Works

• Emails sent to the functional address are automatically forwarded to the individual inboxes of team members.
• Because each person has imported the shared decryption key, they can all read these messages.
• Replies are signed using each person's individual certificate.

When the Team Changes

• New team members receive the secret decryption key.
• When someone leaves the team, the decryption subkey is replaced and redistributed. The primary key remains unchanged, so the certificate's fingerprint does not change—no revalidation is required.

Benefit

The functional address key remains under central control—only the decryption part is shared with the team.

Things to Keep in Mind

1. If the functional address is not included in the CC field when replying, the rest of the team won't be able to decrypt the message.
2. For external recipients, it's not obvious that the message came from a team—they only see the individual sender's address.

Extended Option

• Include the functional address in the CC field when sending a reply. This ensures the entire team can decrypt the message.
• Use the Reply-To field to set the functional address. This makes it clear to external recipients that they're communicating with a team.

Central Key Authority

For larger organizations, setting up a Central Key Authority is recommended. This allows all issued certificates to be managed centrally and ensures that keys can be revoked when individuals leave the organization.

This approach gives your organization full control over key validation and trust relationships—ensuring that communication partners can always verify which keys are valid and in use.

Certificate Distribution

Depending on your use case, there are several ways to distribute certificates within your team or externally:

• Internal: via a central directory service such as LDAP—also suitable for external certificates
• External: using a Web Key Directory (WKD)
• Alternatively, via email or embedded in the signature of a message

Smartcards

Using smartcards adds an extra layer of security: If secret keys are stored exclusively on the card, they can be returned and removed from circulation when someone leaves the organization.

This approach is particularly useful in Options 1 and 2, where either shared or individual keys are in use.

Re-encrypting Data During Key Rotation

When a secret key is replaced—for example, because a team member has left the organization or a new key is introduced for security reasons—existing encrypted data must be reprocessed. This is known as re-encryption.

In this process, the affected files or messages are first decrypted using the old key and then re-encrypted with the new one. This ensures that only authorized individuals retain access to the data.

Depending on the setup, this may involve:

• centrally stored encrypted documents,
• archived emails in functional mailboxes,
• or shared datasets protected by a team key.

Re-encryption can be performed manually or automated via scripts, especially for larger data sets.

Note: It is essential that the data is available in decrypted form during the transition. This means that the person carrying out the re-encryption must be authorized and technically able to decrypt the data. For this reason, the process must take place in a secure and trusted environment.