PGP Key Retrieval

S/Notify offers four different ways to retrieve public PGP keys for users:

• Key store file: a PGP keyring as used by GnuPG or OpenPGP

• HKP key servers: any PGP key server supporting the HKP protocol, including key server pools and verifying key servers (VKS)

• LDAP key servers: any PGP server supporting the LDAP based Global Key Server protocol

• User upload: users can upload their public PGP keys to their user profiles

S/Notify can be configured to use one of these options or any combination of them.

The priority in which keys from these sources are used:

1. User upload (skipped when user is inactive)

2. Incoming email

3. Key store file

4. Key server

Key Store File

A file containing public or private PGP keys, usually referred to as a keyring. The file can be in one of the following formats:

• ASCII-armored (usual file suffixes: asc, txt)

• PGP binary (usual file suffixes: pgp, gpg, pkr, skr)

Note that the new keybox format (kbx) is not currently supported. If your GnuPG installation uses the keybox format, you must export it in one of the above formats in order to use it as a key store for S/Notify.

HKP Protocol

Most PGP key servers use the HKP protocol which defines HTTP GET requests to obtain the key of a specific ID (HKP = HTTP Key server Protocol). If this protocol is used over HTTPS, it is usually referred to as HKPS.

S/Notify understands the HKP and HKPS protocol. If you specify the key server url using one of these, default port 11731 can be omitted. If you use HTTP or HTTPS in the key server url, you must include the correct port.

LDAP Protocol

From release 3.4, S/Notify also supports PGP key servers based on the LDAP protocol if they follow the structure as implemented in Broadcom’s (former Symantec’s) PGP Universal Server which is also supported by GnuPG. Use the LDAP or LDAPS protocol in the key server url if you want to use such a server.

A publicly available LDAP based PGP key server

• https://keyserver.pgp.com/

SKS Key Server Pool

The SKS Key Server Pool is no longer available due to takedown requests based on GDPR relevant problems.

Alternate PGP key servers that are publicly available:

• https://keys.openpgp.org/ (based on https://gitlab.com/hagrid-keyserver/hagrid )

• https://keyserver.ubuntu.com/ (based on Hockeypuck )

• https://keys.mailvelope.com/ (based on https://github.com/mailvelope )

VKS Verifying Key Servers

There is a problem with the way PGP key servers used to work: anyone can create and upload a key for any email address, or even change or delete keys.

Verifying key servers try to rectify this problem. VKS is not another protocol, but rather the approach to publish keys only after they have been verified by their owner. To do so, verifying key server send a confirmation email to each email address that is connected to the key. Only after a confirmation of the email, the key is published.

VKS Protocol

To further complicate things, VKS is not only the acronym for a Verifying Key Server, but also for a protocol that can be used to access a PGP key server (that happens to be a Verifying Key Server), for example Hagrid. Hagrid also supports HKP, but HKP has significant weaknesses, so the VKS protocol was created as a REST like protocol to rectify the problems HKP has.

The VKS protocol is not yet supported by S/Notify. Please let us know if you are interested to see this feature.

WKD/WKS Web Key Directory/Service

A different approach is not a key server that holds and replicates any key, but it’s a key directory that is maintained under the domain of the email address. This means that the PGP key is requested using a defined protocol from a given path at the domain of the email address which is derived from the user part of the email address. Because the domain owner should be controlling the email accounts under their domain, keys retrieved from A WKD are expected to be safe (enough).

WKD/WKS is not yet supported by S/Notify. Please let us know if you are interested to see this feature.

PGP/inline vs. PGP/MIME

S/Notify defaults to the only standard there is for sending OpenPGP Mails, which is PGP/MIME according to RFC 3156. PGP/Inline is an undocumented non-standard format, which leads to several problems. For example, PGP/Inline requires to protect each part of the email message separately which is why it cannot proof authenticity and integrity for the complete message (also see Inline PGP signatures considered harmful). Besides that, PGP/Inline does not properly support non-ASCII texts, so HTML messages as well as messages containing umlauts or other special characters can create severe problems.

From the GnuPG-FAQ:

Should I use PGP/MIME for my emails?

Almost certainly. In the past this was a controversial question, but recently there’s come to be a consensus: use PGP/MIME whenever possible. The reason for this is that it’s possible to armor email headers and metadata with PGP/MIME, but sending messages inline leaves this data exposed. As recent years have taught us, the metadata is often as sensitive as the contents of the message. PGP/MIME can protect metadata; inline can’t.

Even worse in our eyes is the fact that PGP/Inline does not encrypt the complete message body like PGP/MIME does. Instead, message parts are encrypted independently, and thus an email may contain encrypted as well as unencrypted parts. Therefore, the recipient might get the impression that the message came encrypted while in fact only a part of it was indeed encrypted. This can lead to dangerous confusion.

PGP/MIME, on the other hand, offers additional features such as attachments encryption together with the message body, and full support for encryption of messages that use HTML format and special character sets. Today, PGP/MIME is supported by most mail clients.

Therefore, we have decided to create PGP/MIME messages only.

With regard to incoming email, by default, S/Notify supports PGP/MIME only, but it is possible to enable PGP/inline support if necessary. Please refer to Advanced Settings | Support Incoming PGP/Inline for instructions.

Encryption Cipher

Content Encryption

Algorithms

The following symmetric ciphers are supported:

• IDEA

• DES/3DES (will be rejected, should not be used)

• CAST5 (deprecated)

• BLOWFISH

• AES128/192/256

• TWOFISH

• CAMELLIA128/192/256

Selection

S/Notify selects the symmetric encryption cipher used to encrypt the message contents as defined in the OpenPGP standard. This means the key of the recipient is inspected with regard to the encryption preferences, and the first applicable cipher in the list is used. However, DES and 3DES will always be rejected because their known weakness is considered too harmful. According to NIST Special Publication 800-131A Revision 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths, 3DES is deprecated in 2023, and disallowed after 2023, and the upcoming OpenPGP RFC requires that implementations MUST NOT encrypt with 3DES any more.

Note that if you have set up S/Notify to encrypt outgoing messages for the sender email, too, then the first applicable cipher supported by both keys is selected.

Default Cipher

If key preferences are not available or cannot be determined, S/Notify defaults to AES-128 encryption rather than 3DES which is considered weak.

Key Encryption

Algorithms

The following asymmetric ciphers are supported:

• RSA

• DSA

• ElGamal

• ECDSA

• EdDSA

Digest Algorithm

The digest algorithm used when signing outgoing emails is SHA-256.

The digest algorithm is also referred to as hash algorithm.