Кратко

  • Certificate Policy задаёт требования, а Certification Practice Statement описывает заявленный способ их выполнения; общий OID не превращает разные организации в одну операционную систему.
  • В распределённой цепочке каждый критичный пункт должен иметь владельца, идентификатор события, неизменяемое свидетельство, независимое наблюдение, опубликованный статус и итоговое решение приложения.

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

RFC 3647 различает политику и практику. CP устанавливает, что участники должны делать. CPS раскрывает, как одна CA или организация заявляет о выполнении процедур и контролей. Одна CPS может поддерживать несколько CP; несколько CA с разными CPS могут поддерживать одну CP. Политический идентификатор не является идентификатором конкретной реализации.

Текстовая редакция прямо говорит: документ объясняет понятия и помогает составлять материалы, но не определяет конкретную политику и не предписывает конкретные практики. Это гибкая рамка. Девять разделов создают общий язык, а не сертификат соответствия.

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

Расширение Certificate Policies — заявление выдающей CA. Ограничения и mappings участвуют в обработке пути. RFC 5280 и обновление RFC 6818 описывают профили и проверку. Успешный путь не содержит журнал проверки личности, состояние HSM, разделение полномочий или подписи свидетелей церемонии.

Сквозное свидетельство должно связать запрос RA, полномочие заявителя, решение CA, устройство, состояние, входы и выходы, отпечаток ключа, участников, исключения и выданный сертификат. При делегировании обязанность сохранять этот join нельзя оставлять «между договорами».

Отзыв распадается на отдельные часы: обнаружение, аутентифицированный запрос, утверждение, генерация статуса, доставка в репозиторий, внешнее получение и отказ приложения. RFC 6960 задаёт OCSP, а RFC 5019 — профиль для массового применения. Ответ статуса доказывает одну точку наблюдения, не всю цепочку.

Публикация требует внешней проверки. RFC 6481 описывает точки публикации RPKI, RFC 6486 позволяет манифестом обнаруживать определённые отсутствующие или устаревшие объекты. Это сильнее обещания в CPS, но не свидетельствует обо всех кадровых и физических мерах.

Разделение документов хорошо видно в RFC 6484 как CP, RFC 7382 как шаблоне CPS по RFC 3647 и RFC 6487 как техническом профиле сертификатов и CRL. Требование, описание реализации и формат проверки дополняют друг друга.

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

Юридическая связь тоже не автоматична. CPS может быть информационным документом. Договор с подписчиком или полагающейся стороной может включить его по ссылке. Сам сертификат и URL не доказывают согласие, ответственность и применимое право. Техническая проверка не выдаёт юридический вывод.

RFC 3647 заменил RFC 2527. Его Informational-статус и происхождение подтверждают Datatracker, страница RFC Editor и история. Замороженные errata редакционные и не являются аудитом реализации.

Реестр IANA SMI Numbers координирует OID. Общий идентификатор не удостоверяет исполнение.

Идеи Heng Lu о первичности работающего кода, минимальной начальной спецификации и слоях реальности задают предел институциональной декларации. Общая схема помогает сравнивать. Реальность появляется только после исполнения, сохранения, публикации, независимого наблюдения и локального использования.

Рабочая цепочка должна включать версии CP/CPS, владельца и подрядчика, событие, людей и устройство, область аудита, опубликованный объект, внешнее получение, свежесть, результат пути и политики, решение приложения. Отсутствующее звено нельзя заменять авторитетом документа.