Кратко

  • 2 сентября IESG открыла финальное обсуждение редакции 29 проекта о передаче удалённой аттестации в запросах сертификатов. Замечания принимаются до 16 сентября.
  • Когда один идентификатор формата поддерживают несколько проверяющих, правило выбора должна определить спецификация этого формата. Совпадение способов чтения данных ещё не описывает весь путь их обработки.

Замена проверяющего сервиса начинается не только с перечня поддерживаемых форматов. Оператору сертификатов нужно выяснить, по какому правилу система отправляет конкретное доказательство конкретному проверяющему. Если это правило нигде не описано, совместимость интерфейса может скрывать дополнительную работу по интеграции.

Новый повод посмотреть на эту границу — объявленный 2 сентября Last Call по draft-ietf-lamps-csr-attestation-29. IESG рассматривает продвижение документа в статус Proposed Standard и ждёт замечаний до 16 сентября. Пока это рабочий проект, а не утверждённый RFC; объявление также не свидетельствует о внедрении.

Проект задаёт общую структуру для передачи удалённой аттестации в запросах PKCS#10 и CRMF. Поддерживаются как стандартизованные, так и проприетарные форматы. Удостоверяющий центр CA или регистрационный центр RA может выполнять проверку самостоятельно либо направлять сведения внешнему проверяющему.

Где должна появиться определённость

Раздел 4.3 редакции 29 разбирает неоднозначность при нескольких проверяющих, поддерживающих один OID — идентификатор объекта для формата аттестации. Рекомендуются разные OID для типов проверяющего или проверки, даже при одинаковой структуре, либо оболочка с явной подсказкой. Точный механизм направления данных и выбора nonce должен быть установлен спецификацией формата.

OID здесь не является адресом сервера. Он обозначает представление данных, понятное потенциально нескольким сервисам. Чтобы выбрать нужный контекст обработки, необходимо дополнительное соглашение. Общий проект не диктует единое решение всем форматам, а указывает, где это соглашение должно быть завершено.

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

Внешняя регистрация решает другую задачу

В проверенной таблице атрибутов S/MIME IANA значение 59 всё ещё записано как id-aa-evidence. Проект запрашивает переименование в id-aa-attestation с сохранением номера. Это внешний атрибут запроса сертификата, а не каталог проверяющих организаций.

Идентификаторы форматов внутри него относятся к другому уровню. Раздел 4.2 оставляет их выделение авторам соответствующих спецификаций из контролируемых ими ветвей идентификаторов. Поэтому по записи внешнего атрибута невозможно восстановить правило, которым конкретная система выбирает сервис.

Архитектура RFC 9334 показывает, почему выбор имеет значение. Владелец проверяющего задаёт политику оценки доказательств; владелец стороны, использующей результат, определяет политику его применения. Направление данных может тем самым выбирать условия оценки, а не просто программу, способную прочитать байты. Даже если роли выполняет одна организация, это разные обязанности.

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

Изученные источники не описывают инцидент ошибочного направления и не измеряют стоимость смены сервиса. Новость состоит в распределении проектной ответственности, которое теперь проходит финальное обсуждение. Общая оболочка облегчает передачу; предсказуемый выбор обработки всё равно нуждается в отдельном явном соглашении.

Источники

  1. Объявление Last Call от IESG
  2. Проект аттестации CSR, редакция 29
  3. Архитектура RATS, RFC 9334
  4. Регистрация номеров SMI в IANA