Кратко

  • RFC 10004 распределяет требования между сущностями, клиентами, серверами, конечными сущностями, регистрационными и сертификационными центрами. Один компонент может выполнять несколько ролей.
  • Проверяемое соответствие должно связывать версию, граф ролей, условные функции, алгоритмы, конфигурацию, маршрут транзакции и результат.

После спорной выдачи команда подняла отчет о соответствии. В нем были перечислены поддерживаемые сообщения и алгоритмы, но не было схемы: какая RA приняла запрос, какая проверяла личность, кто выполнял доказательство владения ключом и какой маршрут зависел от содержимого запроса.

Это условный пример, а не описание реального сертификата или происшествия. Он показывает, почему RFC 10004 нельзя свести к одному двоичному признаку.

В простой схеме конечная сущность выступает клиентом, а CA — сервером. После добавления RA она становится сервером для заявителя и клиентом для CA. RA может быть несколько; маршрут может зависеть от содержимого; не каждая RA обязана видеть каждый запрос.

Документ выделяет шесть пересекающихся областей требований: все сущности, клиенты, серверы, EE, RA и CA. Положение компонента определяется ребром и включенной функцией, а не названием коробки.

RFC 10002 задает структуры и управляющие элементы, RFC 10003 — транспорт. RFC 10004 распределяет обязанности реализации. Карточка RFC и поиск исправлений фиксируют точную нормативную эпоху.

Все сущности должны поддерживать Full PKI Requests, Simple и Full PKI Responses, CRMF и HTTP. Серверам рекомендуется Simple PKI Requests и PKCS 10. Но дальше следует таблица, где MUST, SHOULD и условные требования различаются для EE, RA и CA.

Если CA предназначен для работы с RA, часть RA-связанных функций становится обязательной. Если RA проверяет личность или генерирует ключи, для EE усиливается требование Response Body. Encrypted POP и Decrypted POP зависят от согласования ключей, аппаратных ключей без подписи и делегирования POP.

Поэтому добавление роли или функции меняет область соответствия даже при неизменном ПО. Старый успешный тест не переносится автоматически на новый маршрут.

Криптографический список тоже зависит от пути. Базу образуют RSA-SHA256, AES, AES-GCM с заданными длинами и транспорт ключа RSA. DH, PBKDF2, AES Key Wrap и HMAC-SHA256 становятся требованиями при соответствующих условиях. RFC 5652 определяет CMS, RFC 5754 — SHA-2, RFC 5084 — аутентифицированное шифрование.

Наличие алгоритма не доказывает его выбор и параметры в конкретной транзакции. Успешный обмен не доказывает, что проверку выполнил уполномоченный агент или что выдача была разрешена.

POP делает владельца решения видимым. CA обязан обеспечить доказательство владения до выдачи, но может делегировать проверку RA в ограниченных случаях. DH-механизм описан в RFC 6955. Журнал должен называть запрос, метод, проверяющего, правило делегирования и переданный результат.

Версия стандарта также меняет смысл отчета. RFC 10004 заменяет RFC 5274 и включает обновления RFC 6402, переводя обязательный минимум к SHA-256. Старые алгоритмы допускаются для совместимости, но должны помогать выявлять сертификаты для перехода. Совместимость без списка зависимых клиентов и срока становится постоянной блокировкой.

Выдача сертификата не завершает проверку. RFC 5280 регулирует сертификаты и построение пути. Соответствие CMC не доказывает право на имя, принятие пути, прикладную авторизацию или результат сервиса.

Слои реальности Heng Lu разделяют стандарт, возможность, настройку, исполнение, выдачу и использование. Приоритет работающего кода требует наблюдаемого поведения. Минимальная начальная спецификация удерживает общий контракт проверяемым и оставляет будущий выбор ответственному оператору.

Нужна не марка, а привязанная к роли квитанция: версия компонента, RFC и errata, направление client/server на каждом ребре, роли EE/RA/CA, активные условия, алгоритмы, версии политики и конфигурации, пройденные RA, обработанные элементы, решение POP, ответ и принятие сертификата. Неувиденный участок должен оставаться пробелом.

Источники