Кратко

  • draft-birkholz-did-x509-03 валидирует переданную цепочку от конечного сертификата к последнему, используя последний как якорь этого запуска, а затем сверяет отпечаток не конечного сертификата и предикаты конечного.
  • Алгоритмический якорь не становится автоматически доверенным якорем приложения. Локальное хранилище, allowlist или иная политика должны независимо принять УЦ, DID и контекст.
  • Разрешение, доверие, проверка подписи сообщения, целевая авторизация, надёжная фиксация и внешний эффект требуют разных квитанций. Редакция 03 — информационный Internet-Draft независимой подачи, а не RFC или стандарт IETF.

Проверяющий сервис получает DID и полную цепочку. Подписи сходятся до последнего сертификата. Отпечаток из идентификатора найден на промежуточном УЦ. Поля конечного сертификата удовлетворяют всем условиям. Из его ключа построен DID Document, и сервис возвращает успех.

В этом аккуратном отчёте нет ответа на вопрос, принимала ли организация последний сертификат в собственный круг доверия.

Именно эту границу подчёркивает третья редакция did:x509. Метод позволяет обойтись без постоянного реестра DID-документов: идентификатор задаёт класс сертификатов, цепочка приходит при разрешении, ключ извлекается детерминированно. Полезность механизма сохраняется только пока внутреннюю согласованность доказательств не называют внешним доверием.

Идентификатор задаёт множество сертификатов

Строка начинается с did:x509:0, затем содержит алгоритм отпечатка, отпечаток и хотя бы один предикат. Разрешены SHA-256, SHA-384 и SHA-512. Отпечаток вычисляется для не конечного сертификата — промежуточного или якорного, — а предикаты проверяются на конечном.

subject требует, чтобы выбранные пары атрибутов имени входили в subject. san сопоставляет один email, DNS или URI. eku ищет OID Extended Key Usage. fulcio-issuer восстанавливает префикс https:// и сравнивает расширение издателя Fulcio; расширение должно присутствовать и не быть critical.

Благодаря этому один DID способен пережить смену конечного сертификата. Ему могут соответствовать несколько цепочек. Но широкое множество означает широкую власть издателя. Слишком слабый subject-предикат может охватить незапланированные сертификаты. EKU не является бизнес-разрешением, а правильный SAN не даёт права утверждать релиз или распоряжаться ресурсом. Предикат выбирает кандидата, но не санкционирует действие.

Последний сертификат замыкает вычисление, а не политику

Параметр x509chain переносит полные DER-сертификаты в base64url, разделённые запятыми. Сначала идёт конечный сертификат, последним — корневой или якорный. Цепочка короче двух элементов должна быть отвергнута.

Разрешатель выполняет проверку пути по RFC 5280: подписи, базовые и именные ограничения, политики, назначения ключей, критические расширения, алгоритмы и время. Затем он сопоставляет отпечаток DID с не конечным сертификатом, проверяет все предикаты и выводит JWK и DID Document из открытого ключа конечного сертификата.

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

RFC 9360 формулирует близкое правило для цепочек в COSE: полученный сертификатный материал не должен молча менять настроенные доверенные якоря приложения. Переданная цепочка способна доказать собственную структуру, но не согласие получателя.

Квитанция Допустимый вывод Что ещё неизвестно
Разбор DID Версия, алгоритм, отпечаток и предикаты корректно закодированы Существует ли легитимная подходящая цепочка
Проверка пути Конечный сертификат ведёт к последнему при заявленных параметрах Доверяет ли ему локальная сторона
Отпечаток и предикаты Цепочка входит в класс, заданный DID Достаточно ли узок класс для операции
Локальное доверие УЦ или DID приняты в данном контексте Проверена ли подпись конкретного сообщения
Подпись Охваченные байты проверяются разрешённым ключом Имеет ли подписант право на действие
Авторизация и commit Разрешены актор, ресурс и операция; запись закреплена Возник ли заявленный внешний результат

Видимая строка не удостоверяет атрибут

Предикаты читаются в DID, поэтому разработчик может попытаться извлечь имя организации или домен до разрешения. Редакция 03 прямо запрещает использовать компоненты для авторизации до проверки цепочки.

Любой способен составить синтаксически верную строку с престижным именем. Пока она не сопоставлена с проверенным конечным сертификатом, её никто не подписывал. После сопоставления всё ещё требуется локальное признание УЦ. Пропуск любого перехода создаёт канал самообъявленной идентичности.

Время и отзыв меняют ответ

Путь можно проверять на текущее время или на релевантный момент, например время подписи. Сертификат, истёкший сегодня, мог быть действителен при создании артефакта. Поле iat в JWT или CWT не становится надёжными часами только от наличия. RFC 7519 и RFC 8392 задают claim, а целостность и допустимость определяет приложение.

Отзыв проверяется, если этого требует политика, через CRL, OCSP или иной механизм. Могут добавляться Certificate Transparency, endorsements и запрет слабых алгоритмов. Поэтому результат обязан сохранять время, режим отзыва, использованные ответы и версию алгоритмической политики.

Модели прозрачности и квитанций в RFC 9597 и RFC 9943 проводят ту же линию: формат переносит доказательство, но не определяет институт, который придаёт ему силу.

Отсутствие реестра не означает отсутствия управляющего

В методе нет операции обновления DID Document и авторизации обновления. Нет также операции деактивации. Создание локально, а разрешение объединяет DID с предъявленной цепочкой.

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

Несколько подходящих цепочек могут выводить разные конечные ключи. Аудит должен хранить фактическую цепочку и verification method для сообщения, а не только постоянную строку DID.

Ценность реализации видна в расхождениях

Редакция 03 сообщает о реализации Microsoft, Nuts Foundation и сценариях подписи, SCITT, CCF и confidential containers. README Microsoft, репозиторная спецификация и тестовые векторы позволяют проверять работающее поведение.

Документ также отмечает видимые отличия Nuts в поддержке eku и расширения SAN otherName. Это не помеха для маркетингового списка, а точная граница совместимости: разные разрешатели могут признать разные множества сертификатов. Сведения предоставлены участниками и не означают одобрение IETF.

Редакция 02 предполагала Standards Track. В 03 статус изменён на Informational и значительно расширены доверие, операции, разрешение, приватность и реализации. Datatracker, история и объявление I-D подтверждают: это независимая рабочая подача, не RFC и не продукт IETF.

W3C DID Core и DID Specification Registries задают общий аппарат DID-документов и verification relationships, но не повышают нормативный статус этой конкретной схемы.

Полный журнал решения

Следует хранить точный DID и декодированные байты предикатов; все DER-сертификаты в исходном порядке; хеш пакета; построение и проверку пути; выбранное время; решения по именам, политикам, ограничениям, key usage, critical extensions и алгоритмам; отзыв и прозрачность; сертификат с совпавшим отпечатком; результат каждого предиката; локальную trust/allowlist-политику и её версию; полученные DID Document и JWK; подписанный объект и охваченные байты; результат подписи; целевую авторизацию актора, ресурса, операции и срока; идентификатор commit; наблюдаемый внешний эффект.

Не выполненная проверка должна остаться неизвестной. not_required_by_policy не означает good, а not_evaluated не означает trusted.

Minimum Initial Specification Лу Хэна ограничивает общий слой минимальной проверяемой механикой. Running-Code Primacy требует следов реализации и эффекта. The Policy Mirror показывает владельца trust store, а Reality Layers не позволяет строке, сертификату, суждению, подписи и действию слиться в один символ.

Источники