Does the gateway support the web of trust?

This CipherMail gateway only accepts OpenPGP data that can be verified using self-signatures. In practice, this means:

A User ID on a key is accepted only if it is signed by the same key that owns the User ID (a self-signature), and that signature is not revoked and has not expired. Third‑party certifications and the broader “web of trust” are not used for acceptance decisions.

A subkey is accepted only if it has a valid subkey binding signature made by the primary key that owns the subkey. If the subkey can create signatures (a signing subkey), it must also include a valid “primary key binding” back‑signature made by the subkey over the primary key. This prevents an attacker from moving a signing subkey to a different primary key and claiming signatures as their own.

Note about older keys: some historical keys do not include the back‑signature on signing subkeys. Such keys may be rejected. If you encounter this, update the key with a modern OpenPGP tool to add the required back‑signature or recreate the key pair.

What this means for you:

If a User ID or subkey is rejected, check that:

  1. the User ID or subkey was signed by the correct key (the same primary key that owns it),

  2. the relevant signatures are not expired or revoked, and

  3. for signing subkeys, the back‑signature is present and valid.

If you rely on third‑party certifications to establish trust, be aware that they are intentionally ignored by this product. Trust is derived solely from self-signatures and required binding signatures.

Is a key trusted by default?

By default, the gateway does not trust any PGP key. Untrusted keys are not used for signing or encryption. To trust a key, open its details page and select Key trust. By default, all subkeys are also trusted.

Which keys are used for encryption?

A key is considered suitable for encrypting a message when all of the following are true:

  • The key is valid and trusted.

  • The key is not revoked or expired.

  • The key is permitted for encryption (for example, it includes an encryption-capable key or subkey).

  • The recipient’s email address matches one of the email addresses or domains associated with the key.

If more than one suitable key is found for a recipient, the message is encrypted to all of those keys. This allows the recipient to decrypt the message with any of their applicable keys (for example, a personal key and a departmental or backup key).

Why is Incoming PGP/INLINE not enabled by default?

With PGP/INLINE, each part of an email—both the message body and every attachment—is protected separately by signing and/or encryption. Unlike PGP/MIME, PGP/INLINE does not add a distinctive header that indicates protection. As a result, the only reliable way to determine whether a message uses PGP/INLINE is to scan the entire message from start to finish.

Full-message scanning can be resource intensive, especially when emails contain very large attachments. It may increase CPU usage and introduce processing delays on busy systems. For that reason, it is recommended to keep Incoming PGP/INLINE enabled turned off unless you specifically need to support partners or workflows that rely on PGP/INLINE for incoming mail.

Enable Incoming PGP/INLINE only if:

  • You have confirmed that one or more correspondents send encrypted or signed emails exclusively using PGP/INLINE.

  • Your system has sufficient capacity to handle the additional scanning overhead without impacting overall mail throughput.

  • You have operational requirements or policies that mandate handling of PGP/INLINE messages.

If you are unsure whether incoming PGP/INLINE support is required, leave it disabled and enable it later if a concrete need arises.

What is “Auto update email addresses”?

When Auto update email addresses is enabled, the system automatically associates a PGP key with all email addresses found in the key’s User IDs, but only if those User IDs have a valid self-signed signature.

If Auto update email addresses is disabled, you must manually associate email addresses with the key. This is a global setting.

Consider disabling this option because User IDs themselves are not verified. In principle, a key owner could add an email address they do not control. With the option disabled, an administrator should validate each email address and then manually associate it with the key.

What happens if I click “refresh public keys”?

When you click Refresh public keys and select keys, the application retrieves those keys from the registered key servers and imports any updates. The downloaded information is merged into your existing local key. Only new information is added, such as new user IDs or signatures; nothing already on your key is removed or changed. For example, if your local key is revoked, it will remain revoked even if the copy on the key server is not.