S/MIME vs OpenPGP : signature et chiffrement des e-mails

S/MIME vs OpenPGP, c’est le choix entre les deux normes de sécurité de bout en bout des e-mails. S/MIME (RFC 8551) enveloppe les messages dans la Cryptographic Message Syntax et identifie les personnes par des certificats X.509 délivrés par des autorités de certification. OpenPGP (RFC 9580) utilise son propre format de paquets et des clés que leurs propriétaires génèrent et publient eux-mêmes, la confiance s’établissant par la vérification des empreintes, par les signatures d’autres utilisateurs ou par le domaine du destinataire.

Vue d’ensemble

À quoi ressemble une signature

Le script ci-dessous signe le même message court des deux façons avec GnuPG 2.5.21 et OpenSSL 3.6.5, puis vérifie chaque signature. Les clés et l’AC jetable sont créées dans un répertoire temporaire, puis supprimées.

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

La différence de taille est structurelle. Une signature CMS transporte normalement le certificat du signataire : n’importe quel destinataire peut ainsi la vérifier par rapport à une racine de confiance et conserver le certificat pour chiffrer ses réponses ; même sans lui, des attributs signés comme l’heure de signature et le type de contenu alourdissent la structure. Une signature détachée OpenPGP désigne la clé par son empreinte : le destinataire doit donc déjà posséder la clé ou aller la chercher. L’empreinte de 40 caractères montre que GnuPG a créé une clé de version 4 ; les clés de version 6 de la RFC 9580 utilisent des empreintes SHA-256 de 64 caractères.

Comment chacun décide à qui faire confiance

S/MIME délègue la décision aux autorités de certification. Depuis le 1er septembre 2023, les certificats S/MIME de confiance publique suivent les Baseline Requirements S/MIME du CA/Browser Forum : l’AC doit vérifier le contrôle de chaque adresse e-mail, les types de certificats vont de la validation de la seule boîte aux lettres à la validation de la personne, les profils « legacy », plus laxistes, ne peuvent plus être délivrés depuis le 15 juillet 2025, et les certificats d’abonnés durent au plus 825 jours. Les entreprises peuvent aussi exploiter leur propre AC et déployer les certificats par la gestion des appareils : c’est ainsi que fonctionnent la plupart des grands déploiements S/MIME.

OpenPGP laisse la décision aux utilisateurs. La toile de confiance d’origine, dans laquelle les utilisateurs signent mutuellement leurs clés, n’a jamais dépassé le cadre de petites communautés, et les serveurs de clés publics qui acceptaient n’importe quel envoi sont devenus inutilisables pour les identités non vérifiées. La pratique actuelle consiste à comparer les empreintes hors bande, à accepter une clé dès sa première utilisation ou à la rechercher dans un Web Key Directory, où le domaine du destinataire sert lui-même la clé en HTTPS. keys.openpgp.org ne publie les identités qu’après avoir vérifié l’adresse.

Clients, compatibilité et scission d’OpenPGP

La force de S/MIME, c’est l’intégration : Outlook, Apple Mail et iOS Mail signent et chiffrent nativement une fois un certificat installé, et Gmail propose S/MIME hébergé dans certaines éditions de Google Workspace. OpenPGP est natif dans Thunderbird et Proton Mail, et disponible ailleurs via des extensions.

OpenPGP connaît aussi une scission de ses normes. L’IETF a publié la RFC 9580 en juillet 2024, avec les clés de version 6, le chiffrement AEAD obligatoire et la protection des phrases de passe par Argon2, puis la RFC 9980 en juin 2026 pour les clés post-quantiques. GnuPG implémente à la place LibrePGP, dont les clés de version 5 et le format de paquet OCB diffèrent de la RFC 9580. Les clés de version 4 avec le paquet classique de données chiffrées fonctionnent dans toutes les implémentations ; GnuPG peut passer à son paquet OCB pour les destinataires dont les clés en annoncent la prise en charge, et les fonctionnalités de la RFC 9580, comme les clés de version 6, doivent être testées avec les logiciels de vos correspondants.

Les deux normes ont été touchées par EFAIL (2018), où un texte chiffré spécialement construit amenait les clients de messagerie à laisser fuiter le texte déchiffré via le HTML. Les correctifs durables sont le chiffrement authentifié (AES-GCM dans S/MIME 4.0, le code de détection de modification puis désormais AEAD dans OpenPGP) et des clients qui refusent d’afficher un texte clair dont l’authentification échoue.

Quand choisir l’un ou l’autre

• Messagerie d’entreprise sur des appareils gérés : S/MIME avec des certificats déployés par MDM ; placez sous séquestre les clés de chiffrement, jamais les clés de signature.
• Partenaires externes qui ont déjà des certificats S/MIME (secteur public, banques, santé) : S/MIME.
• Particuliers, journalistes, mainteneurs open source : OpenPGP, avec des clés publiées via WKD ou keys.openpgp.org.
• Chiffrer des fichiers, des sauvegardes ou des secrets plutôt que des e-mails : ni l’un ni l’autre ; utilisez age (voir age vs GPG).
• Signer des versions logicielles et des commits : OpenPGP fonctionne toujours, mais Sigstore et les signatures SSH sont souvent plus simples (voir Sigstore vs signature GPG).
• Protéger l’objet du message : quel que soit votre choix, utilisez un client qui implémente la protection des en-têtes (RFC 9788) ; sinon, l’objet circule en clair.

Notes de migration

1. Nouveaux déploiements S/MIME : demandez des certificats de profil strict ou polyvalent (multipurpose) avec l’adresse dans le Subject Alternative Name, et séparez les clés de signature des clés de chiffrement pour que seules ces dernières soient placées sous séquestre.
2. Utilisateurs S/MIME existants : les certificats délivrés selon le profil legacy sont remplacés au renouvellement ; vérifiez que les clients de vos partenaires acceptent les nouveaux profils avant l’expiration de vos anciens certificats.
3. Clés OpenPGP : générez des clés Ed25519 et X25519 (ou des clés de version 6 si les logiciels de tous vos correspondants les prennent en charge), fixez une expiration d’un à deux ans et prolongez-la, conservez un certificat de révocation hors ligne et publiez via WKD.
4. Archives : conservez les anciennes clés de déchiffrement ou les anciens certificats aussi longtemps que vous devez lire d’anciens e-mails ; rechiffrer les archives est le seul moyen de retirer ces clés.
5. Planification post-quantique : les e-mails chiffrés sont exposés aux attaques de type récolter maintenant, déchiffrer plus tard. ML-KEM est spécifié pour CMS (RFC 9936) et, combiné à X25519, pour OpenPGP (RFC 9980) ; traitez d’abord les clés de chiffrement, les signatures ensuite. L’inspecteur OpenPGP et le vérificateur S/MIME montrent quels algorithmes utilise une clé, un certificat ou un message.

Références

• RFC 8551, spécification des messages S/MIME 4.0
• RFC 5652, syntaxe des messages cryptographiques (CMS)
• RFC 9580, OpenPGP
• RFC 9980, cryptographie post-quantique dans OpenPGP
• RFC 9936, ML-KEM dans CMS
• RFC 9788, protection des en-têtes des e-mails protégés par la cryptographie
• Baseline Requirements S/MIME du CA/Browser Forum (§6.1.5, §6.3.2, §7.1.6.1)
• Web Key Directory d’OpenPGP (Internet-Draft)
• EFAIL