S/MIME vs. OpenPGP: E-Mails signieren und verschlüsseln

Bei S/MIME vs. OpenPGP geht es um die Wahl zwischen den beiden Standards für Ende-zu-Ende-Sicherheit von E-Mails. S/MIME (RFC 8551) verpackt Nachrichten in die Cryptographic Message Syntax und identifiziert Personen über X.509-Zertifikate, die Zertifizierungsstellen ausstellen. OpenPGP (RFC 9580) nutzt ein eigenes Paketformat und Schlüssel, die ihre Besitzer selbst erzeugen und veröffentlichen; Vertrauen entsteht durch den Abgleich von Fingerabdrücken, durch Signaturen Dritter oder über die Domain des Empfängers.

Auf einen Blick

Wie eine Signatur aussieht

Das folgende Skript signiert dieselbe kurze Nachricht auf beide Arten, mit GnuPG 2.5.21 und OpenSSL 3.6.5, und prüft anschließend jede Signatur. Die Schlüssel und die Wegwerf-CA entstehen in einem temporären Verzeichnis und werden danach gelöscht.

#!/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

Der Größenunterschied ist strukturell bedingt. Eine CMS-Signatur enthält normalerweise das Zertifikat des Unterzeichners, sodass jeder Empfänger sie gegen ein vertrauenswürdiges Root-Zertifikat prüfen und das Zertifikat aufbewahren kann, um Antworten zu verschlüsseln; auch ohne Zertifikat machen signierte Attribute wie der Signaturzeitpunkt und der Inhaltstyp die Struktur größer. Eine abgetrennte Signatur von OpenPGP nennt den Schlüssel über seinen Fingerabdruck, daher muss der Empfänger den Schlüssel bereits haben oder ihn abrufen. Der Fingerabdruck mit 40 Zeichen zeigt, dass GnuPG einen Schlüssel der Version 4 erzeugt hat; Schlüssel der Version 6 nach RFC 9580 verwenden SHA-256-Fingerabdrücke mit 64 Zeichen.

Wie beide entscheiden, wem sie vertrauen

S/MIME überlässt die Entscheidung den Zertifizierungsstellen. Seit dem 1. September 2023 folgen öffentlich vertrauenswürdige S/MIME-Zertifikate den S/MIME Baseline Requirements des CA/Browser Forum: Die CA muss für jede E-Mail-Adresse prüfen, dass der Antragsteller über sie verfügt, die Zertifikatstypen reichen von der Validierung nur des Postfachs (Mailbox-validated) bis zur Validierung der Person (Individual-validated), die laxen „Legacy“-Profile dürfen seit dem 15. Juli 2025 nicht mehr ausgestellt werden, und Teilnehmerzertifikate gelten höchstens 825 Tage. Unternehmen können auch eine eigene CA betreiben und Zertifikate über ihr Gerätemanagement verteilen; so laufen die meisten großen S/MIME-Rollouts ab.

OpenPGP überlässt die Entscheidung den Nutzern. Das ursprüngliche Web of Trust, in dem Nutzer gegenseitig ihre Schlüssel signieren, ist nie über kleine Communitys hinausgewachsen, und öffentliche Schlüsselserver, die jeden Upload annahmen, wurden für nicht geprüfte Identitäten unbrauchbar. Heute üblich ist es, Fingerabdrücke über einen zweiten Kanal abzugleichen, einen Schlüssel bei der ersten Nutzung zu akzeptieren oder ihn über ein Web Key Directory abzurufen, bei dem die Domain des Empfängers selbst den Schlüssel über HTTPS ausliefert. Der Schlüsselserver keys.openpgp.org veröffentlicht Identitäten erst, nachdem er die Adresse geprüft hat.

Clients, Kompatibilität und die Spaltung bei OpenPGP

Die Stärke von S/MIME ist die Integration: Outlook, Apple Mail und iOS Mail signieren und verschlüsseln nativ, sobald ein Zertifikat installiert ist, und Gmail bietet in einigen Editionen von Google Workspace gehostetes S/MIME an. OpenPGP ist in Thunderbird und Proton Mail nativ eingebaut und anderswo über Add-ons verfügbar.

Bei OpenPGP sind außerdem die Standards gespalten. Die IETF veröffentlichte im Juli 2024 RFC 9580 mit Schlüsseln der Version 6, verpflichtender AEAD-Verschlüsselung und Passphrase-Schutz mit Argon2; im Juni 2026 folgte RFC 9980 für Post-Quanten-Schlüssel. GnuPG implementiert stattdessen LibrePGP, dessen Schlüssel der Version 5 und dessen OCB-Paketformat von RFC 9580 abweichen. Schlüssel der Version 4 mit dem klassischen Paket für verschlüsselte Daten funktionieren in allen Implementierungen; GnuPG kann für Empfänger, deren Schlüssel Unterstützung dafür ankündigen, auf sein OCB-Paket umsteigen, und Funktionen von RFC 9580 wie Schlüssel der Version 6 musst du mit der Software deiner Kommunikationspartner testen.

Beide Standards waren von EFAIL (2018) betroffen: Präpariertes Chiffrat brachte Mailclients dazu, entschlüsselten Text über HTML preiszugeben. Dauerhaft behoben wird das durch authentifizierte Verschlüsselung (AES-GCM in S/MIME 4.0, den Modification Detection Code und inzwischen AEAD in OpenPGP) und durch Clients, die Klartext nicht anzeigen, wenn seine Authentifizierung fehlschlägt.

Wann welcher Standard passt

• Firmen-E-Mail auf verwalteten Geräten: S/MIME mit Zertifikaten, die per MDM verteilt werden; hinterlege Verschlüsselungsschlüssel, niemals Signaturschlüssel.
• Externe Partner, die bereits S/MIME-Zertifikate haben (öffentlicher Sektor, Banken, Gesundheitswesen): S/MIME.
• Einzelpersonen, Journalisten, Maintainer von Open-Source-Projekten: OpenPGP, mit Schlüsseln, die über WKD oder keys.openpgp.org veröffentlicht werden.
• Dateien, Backups oder Secrets statt E-Mails verschlüsseln: keines von beiden; nimm age (siehe age vs. GPG).
• Software-Releases und Commits signieren: OpenPGP funktioniert weiterhin, aber Sigstore und SSH-Signaturen sind oft einfacher (siehe Signieren mit Sigstore vs. GPG).
• Betreffzeile schützen: Egal wofür du dich entscheidest, nutze einen Client, der Header-Schutz (RFC 9788) implementiert; sonst wird der Betreff im Klartext übertragen.

Hinweise zur Migration

1. Neue S/MIME-Einführungen: Beantrage Zertifikate mit dem Profil „strict“ oder „multipurpose“, bei denen die Adresse im Subject Alternative Name steht, und trenne Signatur- von Verschlüsselungsschlüsseln, damit nur Letztere hinterlegt werden.
2. Wer S/MIME bereits nutzt: Zertifikate nach dem Legacy-Profil werden bei der Erneuerung ersetzt; prüfe, ob die Clients deiner Partner die neuen Profile akzeptieren, bevor deine alten Zertifikate ablaufen.
3. OpenPGP-Schlüssel: Erzeuge Ed25519- und X25519-Schlüssel (oder Schlüssel der Version 6, wenn die Software aller deiner Kommunikationspartner sie unterstützt), setze ein Ablaufdatum in ein bis zwei Jahren und verlängere es, bewahre ein Widerrufszertifikat offline auf und veröffentliche deinen öffentlichen Schlüssel über WKD.
4. Archive: Bewahre alte Schlüssel zum Entschlüsseln oder Zertifikate so lange auf, wie du alte E-Mails lesen musst; nur wenn du die Archive neu verschlüsselst, kannst du die alten Schlüssel ausmustern.
5. Post-Quanten-Planung: Verschlüsselte E-Mails sind durch harvest now, decrypt later (jetzt speichern, später entschlüsseln) gefährdet. ML-KEM ist für CMS spezifiziert (RFC 9936) und, kombiniert mit X25519, für OpenPGP (RFC 9980); kümmere dich zuerst um die Verschlüsselungsschlüssel, später um die Signaturen. Der OpenPGP-Inspektor und der S/MIME-Signatur-Verifizierer zeigen, welche Algorithmen ein Schlüssel, ein Zertifikat oder eine Nachricht verwendet.

Quellen

• RFC 8551, Nachrichtenspezifikation von S/MIME 4.0
• RFC 5652, Spezifikation der Cryptographic Message Syntax
• RFC 9580, OpenPGP
• RFC 9980, Post-Quanten-Kryptografie in OpenPGP
• RFC 9936, ML-KEM in CMS
• RFC 9788, Header-Schutz für kryptografisch geschützte E-Mails
• S/MIME Baseline Requirements des CA/Browser Forum (§6.1.5, §6.3.2, §7.1.6.1)
• Web Key Directory für OpenPGP (Internet-Draft)
• EFAIL