S/MIME vs OpenPGP: end-to-end email signing and encryption compared

S/MIME vs OpenPGP is the choice between the two standards for end-to-end email security. S/MIME (RFC 8551) wraps messages in the Cryptographic Message Syntax and identifies people with X.509 certificates issued by certificate authorities. OpenPGP (RFC 9580) uses its own packet format and keys that owners generate and publish themselves, with trust established by fingerprint checks, signatures from other users, or the recipient's domain.

At a glance

What a signature looks like

The script below signs the same short message both ways with GnuPG 2.5.21 and OpenSSL 3.6.5, then verifies each signature. Keys and the throwaway CA are created in a temporary directory and deleted afterwards.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
export GNUPGHOME="$dir/gnupg"
mkdir -m 700 "$GNUPGHOME"
printf 'Quarterly report attached.\n' > msg.txt

echo "== OpenPGP (GnuPG)"
gpg --batch --quiet --passphrase '' --quick-gen-key "Alice <alice@example.org>" ed25519 sign 1d
gpg --batch --quiet --detach-sign msg.txt
gpg --batch --verify msg.txt.sig msg.txt 2>&1 | grep -E "using|Good"
echo "signature bytes: $(wc -c < msg.txt.sig)"
gpgconf --kill gpg-agent

echo "== S/MIME (OpenSSL CMS)"
EC="-newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc"
openssl req -x509 $EC -keyout ca.key -out ca.pem -days 30 -subj "/CN=Example Mail CA" \
  -addext "keyUsage=critical,keyCertSign" 2>/dev/null
openssl req -x509 $EC -CA ca.pem -CAkey ca.key -keyout alice.key -out alice.pem -days 30 \
  -subj "/CN=Alice" -addext "subjectAltName=email:alice@example.org" \
  -addext "keyUsage=critical,digitalSignature" \
  -addext "extendedKeyUsage=emailProtection" 2>/dev/null
openssl cms -sign -binary -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out msg.p7s
openssl cms -verify -binary -in msg.p7s -inform DER -content msg.txt -CAfile ca.pem -out /dev/null
echo "signature bytes: $(wc -c < msg.p7s)"
openssl cms -sign -binary -nocerts -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out bare.p7s
echo "without the embedded certificate: $(wc -c < bare.p7s)"
cd / && rm -rf "$dir"

== OpenPGP (GnuPG)
gpg:                using EDDSA key 57AE27428681EABC417A15B7DDA5B1FF5FAE8694
gpg: Good signature from "Alice <alice@example.org>" [ultimate]
signature bytes:      147
== S/MIME (OpenSSL CMS)
CMS Verification successful
signature bytes:      907
without the embedded certificate:      446

The size difference is structural. A CMS signature normally carries the signer's certificate, so any recipient can verify it against a trusted root and keep the certificate to encrypt replies; even without it, signed attributes such as the signing time and content type make the structure larger. An OpenPGP detached signature names the key by fingerprint, so the recipient must already have the key or fetch it. The 40-character fingerprint shows that GnuPG created a version 4 key; RFC 9580 version 6 keys use 64-character SHA-256 fingerprints.

How each decides whom to trust

S/MIME delegates the decision to certificate authorities. Since 1 September 2023 publicly trusted S/MIME certificates follow the CA/Browser Forum S/MIME Baseline Requirements: the CA must verify control of each e-mail address, certificate types range from mailbox-validated to individual-validated, the lax "legacy" profiles may no longer be issued since 15 July 2025, and subscriber certificates last at most 825 days. Enterprises can also run their own CA and deploy certificates through device management, which is how most large S/MIME rollouts work.

OpenPGP leaves the decision to users. The original web of trust, in which users sign each other's keys, never scaled beyond small communities, and public keyservers that accepted any upload became unusable for unverified identities. Current practice is to compare fingerprints out of band, to accept a key on first use, or to look it up through a Web Key Directory, where the recipient's own domain serves the key over HTTPS. keys.openpgp.org publishes identities only after verifying the address.

Clients, compatibility and the OpenPGP split

S/MIME's strength is integration: Outlook, Apple Mail and iOS Mail sign and encrypt natively once a certificate is installed, and Gmail offers hosted S/MIME in some Google Workspace editions. OpenPGP is native in Thunderbird and Proton Mail and available elsewhere through add-ons.

OpenPGP also has a standards split. The IETF published RFC 9580 in July 2024 with version 6 keys, mandatory AEAD encryption and Argon2 passphrase protection, and RFC 9980 in June 2026 for post-quantum keys. GnuPG instead implements LibrePGP, whose version 5 keys and OCB packet format differ from RFC 9580. Version 4 keys with the classic encrypted-data packet work across all implementations; GnuPG may switch to its OCB packet for recipients whose keys advertise support for it, and RFC 9580 features such as version 6 keys need testing with your correspondents' software.

Both standards were affected by EFAIL (2018), in which crafted ciphertext made mail clients leak decrypted text through HTML. The lasting fixes are authenticated encryption (AES-GCM in S/MIME 4.0, the modification detection code and now AEAD in OpenPGP) and clients that refuse to display plaintext that fails authentication.

When to choose which

• Company mail on managed devices: S/MIME with certificates deployed by MDM; escrow encryption keys, never signing keys.
• External partners who already have S/MIME certificates (public sector, banks, healthcare): S/MIME.
• Individuals, journalists, open-source maintainers: OpenPGP, with keys published through WKD or keys.openpgp.org.
• Encrypting files, backups or secrets rather than mail: neither; use age (see age vs GPG).
• Signing software releases and commits: OpenPGP still works, but Sigstore and SSH signatures are often simpler (see Sigstore vs GPG signing).
• Protecting the subject line: whichever you choose, use a client that implements header protection (RFC 9788); otherwise the subject travels in clear.

Migration notes

1. New S/MIME deployments: request strict or multipurpose certificates with the address in the Subject Alternative Name, and separate signing from encryption keys so only the latter are escrowed.
2. Existing S/MIME users: certificates issued under the legacy profile are being replaced at renewal; check that partners' clients accept the new profiles before your old certificates expire.
3. OpenPGP keys: generate Ed25519 and X25519 keys (or version 6 keys where all your correspondents' software supports them), set an expiry of one to two years and extend it, store a revocation certificate offline, and publish through WKD.
4. Archives: keep old decryption keys or certificates as long as you need to read old mail; re-encrypting archives is the only way to retire them.
5. Post-quantum planning: encrypted mail is exposed to harvest now, decrypt later. ML-KEM is specified for CMS (RFC 9936) and, combined with X25519, for OpenPGP (RFC 9980); plan encryption keys first, signatures later. The OpenPGP inspector and S/MIME verifier show which algorithms a key, certificate or message uses.

References

• RFC 8551, S/MIME 4.0 message specification
• RFC 5652, Cryptographic Message Syntax
• RFC 9580, OpenPGP
• RFC 9980, post-quantum cryptography in OpenPGP
• RFC 9936, ML-KEM in CMS
• RFC 9788, header protection for cryptographically protected email
• CA/Browser Forum S/MIME Baseline Requirements (§6.1.5, §6.3.2, §7.1.6.1)
• OpenPGP Web Key Directory (Internet-Draft)
• EFAIL