S/MIME или OpenPGP — это выбор между двумя стандартами сквозной защиты электронной почты. S/MIME (RFC 8551) упаковывает сообщения в формат Cryptographic Message Syntax и идентифицирует людей по сертификатам X.509, выпущенным центрами сертификации (certificate authority, CA). OpenPGP (RFC 9580) использует собственный формат пакетов и ключи, сгенерированные и опубликованные самими владельцами, а доверие к ключу устанавливается сверкой отпечатков, подписями других пользователей или через домен получателя.
Коротко о главном
| S/MIME | OpenPGP | |
|---|---|---|
| Спецификация | RFC 8551 (S/MIME 4.0), CMS (RFC 5652) | RFC 9580 (2024); для постквантовых алгоритмов — RFC 9980 (июнь 2026 года); GnuPG следует LibrePGP |
| Контейнер ключа | Сертификат X.509, выпущенный CA | Ключ OpenPGP с самоподписью; при желании его сертифицируют другие пользователи |
| Решение о доверии | Иерархия CA в хранилищах корневых сертификатов операционной системы и почтового клиента | Сверка отпечатка, сеть доверия, доверие при первом использовании или Web Key Directory домена |
| Проверка идентификационных данных | CA проверяет владение почтовым ящиком (а в зависимости от типа сертификата — также организацию или личность) | По умолчанию нет; некоторые каталоги проверяют адрес электронной почты |
| Поиск ключей | Внутри подписанных сообщений, в корпоративных каталогах (GAL, LDAP) | Web Key Directory, серверы ключей, заголовки Autocrypt, обмен вручную |
| Размер отделённой подписи (замер ниже) | 907 байт с сертификатом подписанта, 446 байт без него | 147 байт (Ed25519) |
| Срок действия | Публичные сертификаты — не более 825 дней | Выбирает владелец, срок можно продлить |
| Отзыв | CRL или OCSP, публикуемые CA | Подпись отзыва, публикуемая владельцем ключа |
| Встроенная поддержка в клиентах | Outlook, Apple Mail, iOS Mail; Gmail в некоторых редакциях Workspace | Thunderbird (начиная с версии 78), Proton Mail; в остальных — через дополнения |
| Алгоритмы, допустимые в 2026 году | RSA 2048+, ECDSA P-256/384/521, EdDSA, ML-DSA и ML-KEM по базовым требованиям к S/MIME (S/MIME Baseline Requirements) | Ed25519, X25519, Ed448, X448, RSA; составные ML-DSA+Ed25519 и ML-KEM+X25519 (RFC 9980) |
| Шифрование содержимого | Обязателен AES-GCM (RFC 8551), AES-CBC — для совместимости | AEAD (обязателен OCB) в SEIPD v2 по RFC 9580 |
Как выглядит подпись
Скрипт ниже подписывает одно и то же короткое сообщение обоими способами с помощью GnuPG 2.5.21 и OpenSSL 3.6.5, а затем проверяет каждую подпись. Ключи и одноразовый CA создаются во временном каталоге и после работы удаляются.
#!/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
Разница в размере заложена в самой структуре. Подпись CMS обычно содержит сертификат подписанта, поэтому любой получатель может проверить её по доверенному корневому сертификату и сохранить сертификат, чтобы шифровать ответы; даже без сертификата структуру увеличивают подписанные атрибуты, такие как время подписания и тип содержимого. Отделённая подпись OpenPGP указывает ключ по отпечатку, поэтому получатель должен уже иметь этот ключ или загрузить его. Отпечаток из 40 символов показывает, что GnuPG создал ключ версии 4; у ключей версии 6 из RFC 9580 отпечатки SHA-256 длиной 64 символа.
Как каждый стандарт решает, кому доверять
S/MIME передаёт решение центрам сертификации. С 1 сентября 2023 года публично доверенные сертификаты S/MIME подчиняются базовым требованиям CA/Browser Forum к S/MIME: CA обязан проверить, что заявитель контролирует каждый адрес электронной почты; типы сертификатов варьируются от проверенных по почтовому ящику (mailbox-validated) до проверенных по личности владельца (individual-validated); нестрогие профили «legacy» с 15 июля 2025 года выпускать больше нельзя, а сертификаты абонентов действуют не более 825 дней. Предприятия также могут развернуть собственный CA и распространять сертификаты через системы управления устройствами — именно так устроено большинство крупных внедрений S/MIME.
OpenPGP оставляет решение пользователям. Изначальная сеть доверия (web of trust), в которой пользователи подписывают ключи друг друга, так и не вышла за пределы небольших сообществ, а публичные серверы ключей, принимавшие любые загрузки, стали непригодны для работы с непроверенными идентификаторами пользователей. Сейчас принято сверять отпечатки по независимому каналу, принимать ключ при первом использовании или искать его через Web Key Directory, где сам домен получателя отдаёт ключ по HTTPS. keys.openpgp.org публикует идентификаторы пользователей только после проверки адреса.
Клиенты, совместимость и раскол OpenPGP
Сильная сторона S/MIME — интеграция: Outlook, Apple Mail и iOS Mail подписывают и шифруют письма штатными средствами, как только установлен сертификат, а Gmail в некоторых редакциях Google Workspace предлагает S/MIME на стороне сервера. OpenPGP встроен в Thunderbird и Proton Mail, а в других клиентах доступен через дополнения.
Кроме того, у OpenPGP раскололись стандарты. IETF опубликовал RFC 9580 в июле 2024 года — с ключами версии 6, обязательным шифрованием AEAD и защитой парольной фразы с помощью Argon2 — и RFC 9980 в июне 2026 года для постквантовых ключей. GnuPG же реализует LibrePGP, у которого ключи версии 5 и формат пакета OCB отличаются от RFC 9580. Ключи версии 4 с классическим пакетом зашифрованных данных работают во всех реализациях; GnuPG может перейти на свой пакет OCB для получателей, чьи ключи объявляют о его поддержке, а возможности RFC 9580, такие как ключи версии 6, нужно проверять с программами ваших корреспондентов.
Оба стандарта были уязвимы для EFAIL (2018): специально сформированный шифртекст заставлял почтовые клиенты раскрывать расшифрованный текст через HTML. Надёжно проблему решают аутентифицированное шифрование (AES-GCM в S/MIME 4.0, код обнаружения изменений, а теперь и AEAD в OpenPGP) и клиенты, которые отказываются показывать открытый текст, не прошедший аутентификацию.
Что когда выбирать
- Корпоративная почта на управляемых устройствах: S/MIME с сертификатами, развёрнутыми через MDM; ключи шифрования депонируйте, ключи подписи — никогда.
- Внешние партнёры, у которых уже есть сертификаты S/MIME (госсектор, банки, здравоохранение): S/MIME.
- Частные лица, журналисты, мейнтейнеры проектов с открытым исходным кодом: OpenPGP с ключами, опубликованными через WKD или keys.openpgp.org.
- Шифрование файлов, резервных копий или секретов, а не почты: ни то ни другое; используйте age (см. age или GPG).
- Подпись релизов ПО и коммитов: OpenPGP по-прежнему подходит, но подписи Sigstore и SSH часто проще (см. Sigstore или GPG для подписи).
- Защита темы письма: что бы вы ни выбрали, используйте клиент с поддержкой защиты заголовков (RFC 9788); иначе тема передаётся в открытом виде.
Заметки о миграции
- Новые внедрения S/MIME: запрашивайте сертификаты профиля strict или multipurpose с адресом в альтернативном имени субъекта (Subject Alternative Name) и разделяйте ключи подписи и шифрования, чтобы депонировать только ключи шифрования.
- Текущие пользователи S/MIME: сертификаты, выпущенные по профилю legacy, при продлении заменяются; до того как истечёт срок действия ваших старых сертификатов, убедитесь, что клиенты партнёров принимают новые профили.
- Ключи OpenPGP: генерируйте ключи Ed25519 и X25519 (или ключи версии 6, если их поддерживают программы всех ваших корреспондентов), задайте срок действия от одного года до двух лет и продлевайте его, храните сертификат отзыва офлайн и публикуйте ключи через WKD.
- Архивы: храните старые ключи расшифрования или сертификаты, пока вам нужно читать старую почту; единственный способ вывести их из употребления — перешифровать архивы.
- План перехода на постквантовые алгоритмы: зашифрованная почта уязвима для стратегии «собери сейчас, расшифруй потом». ML-KEM определён для CMS (RFC 9936) и в сочетании с X25519 — для OpenPGP (RFC 9980); сначала переводите ключи шифрования, подписи — позже. Инспектор OpenPGP и инструмент проверки подписей S/MIME показывают, какие алгоритмы используются в ключе, сертификате или сообщении.
Источники
- RFC 8551, спецификация сообщений S/MIME 4.0
- RFC 5652, синтаксис криптографических сообщений (CMS)
- RFC 9580, OpenPGP
- RFC 9980, постквантовая криптография в OpenPGP
- RFC 9936, ML-KEM в CMS
- RFC 9788, защита заголовков в криптографически защищённой электронной почте
- Базовые требования CA/Browser Forum к S/MIME (§ 6.1.5, § 6.3.2, § 7.1.6.1)
- Web Key Directory для OpenPGP (Internet-Draft)
- EFAIL