RFC 2632

RFC 2632 — это спецификация протокола, озаглавленная «S/MIME Version 3 Certificate Handling», опубликованная в июне 1999 года в составе серии документов Internet Engineering Task Force (IETF). Документ определяет правила обработки сертификатов X.509 версии 3 в рамках стандарта S/MIME (Secure/Multipurpose Internet Mail Extensions) версии 3, предназначенного для шифрования и цифровой подписи электронной почты. RFC 2632 уточняет, как клиенты электронной почты должны проверять сертификаты, устанавливать цепочки доверия и обрабатывать расширения сертификатов, включая поддержку атрибутов ключей и политик сертификации.

История и контекст создания

Разработка S/MIME началась в середине 1990-х годов как инициатива компаний RSA Data Security, Microsoft, Netscape и других для обеспечения безопасности электронной почты в коммерческом и корпоративном сегменте. Первая версия S/MIME (RFC 2311) была опубликована в марте 1998 года, но она не охватывала все аспекты управления сертификатами. Вторая версия (RFC 2312) уточнила некоторые аспекты, но потребовала дальнейшей доработки.

К июню 1999 года IETF опубликовала три взаимосвязанных документа, образующих основу S/MIME версии 3:

• RFC 2632 — «S/MIME Version 3 Certificate Handling» (обработка сертификатов);
• RFC 2633 — «S/MIME Version 3 Message Specification» (формат сообщений);
• RFC 2634 — «Enhanced Security Services for S/MIME» (расширенные услуги безопасности, включая метки времени и подтверждения получения).

RFC 2632 стал ответом на необходимость стандартизации процедур проверки подлинности сертификатов в условиях, когда в Интернете начали активно использоваться центры сертификации (CA) с различными политиками. Документ был написан группой авторов: Б. Калиски (B. Kaliski), С. Даквортом (S. Duckworth) и другими участниками рабочей группы S/MIME IETF.

Основные положения RFC 2632

Цель и область применения

RFC 2632 определяет, как S/MIME-клиенты должны обрабатывать сертификаты X.509v3, полученные вместе с зашифрованными или подписанными сообщениями. Основная цель — обеспечить единообразную проверку доверия к сертификатам, независимо от используемого программного обеспечения. Спецификация не описывает создание сертификатов или работу центров сертификации, а фокусируется на стороне получателя сообщения.

Ключевые требования

1. Проверка цепочки сертификатов

Клиент должен построить цепочку от сертификата отправителя до доверенного корневого сертификата, используя сертификаты, включённые в сообщение, и локальное хранилище доверенных сертификатов. RFC 2632 требует, чтобы цепочка была полной и не содержала разрывов.

1. Проверка подписей

Для каждого сертификата в цепочке проверяется цифровая подпись, созданная вышестоящим центром сертификации. Если подпись недействительна (например, из-за истечения срока действия или нарушения алгоритма), сертификат считается недействительным.

1. Обработка расширений X.509v3

Документ описывает, как интерпретировать расширения сертификатов, такие как:

• Key Usage (использование ключа) — определяет, для каких целей может применяться ключ (подпись, шифрование и т.д.);
• Extended Key Usage (расширенное использование ключа) — уточняет допустимые сценарии (например, только для электронной почты);
• Basic Constraints (базовые ограничения) — указывает, может ли сертификат использоваться для подписи других сертификатов (то есть является ли он сертификатом CA);
• Certificate Policies (политики сертификации) — ссылки на документы, описывающие правила выдачи и использования сертификата.

1. Игнорирование неподдерживаемых расширений

Если клиент не распознаёт какое-либо расширение, он должен игнорировать его, но не отвергать сертификат целиком. Это обеспечивает обратную совместимость с будущими версиями стандарта.

1. Списки отзыва сертификатов (CRL)

RFC 2632 рекомендует, но не требует проверки статуса сертификата по CRL (Certificate Revocation List). Однако если CRL доступен, клиент должен проверить, не отозван ли сертификат.

Поддержка атрибутов ключей

Документ вводит понятие «атрибутов ключей» (key attributes), которые связывают открытый ключ с конкретным пользователем или устройством. В S/MIME версии 3 атрибуты ключей могут быть включены в сертификат или передаваться отдельно. RFC 2632 определяет, как клиент должен обрабатывать такие атрибуты, в частности, проверять их соответствие содержимому сертификата.

Взаимосвязь с другими RFC

RFC 2632 является частью триады документов S/MIME v3 и тесно связан с:

• RFC 2633 — описывает формат сообщений (зашифрованных и подписанных), включая структуру конвертов и алгоритмы шифрования;
• RFC 2634 — добавляет расширенные услуги, такие как метки времени (signed receipts) и подтверждения получения (security labels).

Позднее S/MIME версии 3 был обновлён в RFC 3850 (2004 год) и RFC 5750 (2010 год), которые заменили RFC 2632, но сохранили его основные принципы. RFC 2632 остаётся важным историческим документом, заложившим основу для современных реализаций S/MIME.

Примеры реализации

Проверка сертификата в почтовом клиенте

При получении подписанного письма клиент (например, Microsoft Outlook или Mozilla Thunderbird) выполняет следующие шаги:

1. Извлекает сертификат отправителя из сообщения.
2. Строит цепочку сертификатов, используя промежуточные сертификаты, если они приложены.
3. Проверяет подписи в цепочке, начиная с корневого сертификата.
4. Проверяет расширения Key Usage и Basic Constraints.
5. Если сертификат отозван (по CRL или OCSP), выводит предупреждение.

Обработка ошибок

RFC 2632 определяет три уровня ошибок:

• Warning (предупреждение) — сертификат недействителен, но сообщение может быть прочитано (например, истёк срок действия);
• Error (ошибка) — сертификат не может быть проверен, сообщение считается небезопасным;
• Fatal (фатальная ошибка) — цепочка сертификатов не построена, сообщение отвергается.

Критика и ограничения

Хотя RFC 2632 стал важным шагом в стандартизации S/MIME, он имел несколько недостатков:

1. Отсутствие обязательной проверки CRL

Документ не требовал обязательного использования списков отзыва, что снижало безопасность в реальных сценариях. Злоумышленник мог использовать отозванный сертификат, если клиент не проверял его статус.

1. Сложность обработки расширений

Разные центры сертификации использовали расширения X.509v3 по-разному, что приводило к несовместимости между клиентами. RFC 2632 не давал исчерпывающих инструкций по интерпретации всех возможных расширений.

1. Отсутствие поддержки OCSP

Протокол OCSP (Online Certificate Status Protocol) был опубликован только в 1999 году (RFC 2560) и не был включён в RFC 2632. Это ограничивало возможности оперативной проверки статуса сертификата.

1. Зависимость от закрытых корневых сертификатов

В ранних реализациях S/MIME доверенные корневые сертификаты часто поставлялись вместе с программным обеспечением (например, от Microsoft или Netscape), что создавало риск компрометации при взломе поставщика.

Значение и наследие

RFC 2632 сыграл ключевую роль в популяризации S/MIME как стандарта для защищённой электронной почты. Он заложил основы для обработки сертификатов, которые используются до сих пор, включая проверку цепочек, интерпретацию расширений и обработку ошибок. Документ также повлиял на развитие других протоколов безопасности, таких как TLS и IPsec, где применяются аналогичные методы проверки сертификатов.

Несмотря на замену более новыми RFC (3850, 5750), RFC 2632 остаётся важным историческим документом, иллюстрирующим эволюцию инфраструктуры открытых ключей (PKI) в Интернете. Многие современные почтовые клиенты до сих пор реализуют логику, заложенную в этом стандарте, с учётом последующих улучшений.

Источники

• RFC 2632 — «S/MIME Version 3 Certificate Handling», IETF, июнь 1999.
• RFC 2633 — «S/MIME Version 3 Message Specification», IETF, июнь 1999.
• RFC 2634 — «Enhanced Security Services for S/MIME», IETF, июнь 1999.
• RFC 3850 — «S/MIME Version 3.1 Certificate Handling», IETF, июль 2004.
• RFC 5750 — «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling», IETF, январь 2010.
• «S/MIME: Secure/Multipurpose Internet Mail Extensions» — статья в Internet Engineering Task Force (IETF) Journal, 2000.