Кратко

  • В редакции 05 профиля Authority Token для JWTClaimConstraints DER-ограничение является для клиента и сервера ACME непрозрачной последовательностью октетов: они переносят и точно сравнивают её, но не толкуют.
  • Смысл по отраслевым правилам проверяет Token Authority. Отдельно внедряющая экосистема решает, каким сертификатам таких издателей доверяет сервер.
  • Необязательный token-authority лишь подсказывает клиенту место получения токена. Сервер игнорирует подсказку при проверке и требует сертификат через x5u или x5c, уже включённый в его настройку доверия.
  • Документ остаётся Internet-Draft рабочей группы. Успех протокольной проверки не подтверждает юридическую личность, правдивость звонящего или всеобщее право издателя.

В новой редакции у каждого слоя своя задача

Авторы объявили редакцию 05 5 сентября 2026 года. Ей предшествовала проверка председателя ACME, поставившая вопросы об адресатах нормативных требований и трактовке нескольких полей. Ответ Chris Wendt и перечень изменений фиксируют уточнения по аудитории, доверию к издателю и роли token-authority.

Профиль предназначен для удостоверяющих центров Secure Telephone Identity. Он применяет ACME для доказательства полномочия над расширением JWTClaimConstraints, ограничивающим утверждения, которые разрешено нести учётным данным. Само расширение задаёт RFC 9448, а RFC 8226 и RFC 9118 дают контекст сертификатов и ограничений.

По тексту редакции 05 клиент ACME отправляет идентификатор и получает токен. Сервер ACME проверяет ответ на испытание. До этого Token Authority решает, допустимо ли запрошенное ограничение по правилам предметной области, и подписывает разрешение.

Клиент и сервер не разбирают значение ради смысла. DER-представление в base64url остаётся непрозрачной последовательностью октетов. Оно переносится без изменения и сравнивается между идентификатором и токеном с полной точностью. Уместность mustInclude, permittedValues и mustExclude оценивает Token Authority, а не ACME.

Такое самоограничение полезно. RFC 8555 автоматизирует управление сертификатами, но не делает универсальный сервер испытаний органом, устанавливающим права на телефонные ограничения.

Адрес для клиента не назначает доверенного издателя

Параметр token-authority может подсказать клиенту, где получить токен. Это необязательная информация для обнаружения. Редакция 05 прямо говорит, что сервер не использует её при проверке ответа.

Сертификат издателя передаётся в токене через x5u или x5c; оба не могут отсутствовать. Сервер получает или читает сертификат, проверяет подпись и выясняет, настроен ли он доверять этому сертификату как издателю Authority Token в данной экосистеме. Ссылка помогает найти ключ, но не наделяет ключ полномочием.

Якоря доверия и специальные требования к сертификатам Token Authority устанавливает внедряющая экосистема. Проект приводит управление STIR как пример, не определяя всемирного органа или процедуры допуска, ограничения, приостановки, отзыва и обжалования.

Та же предпосылка заложена в уже опубликованном Standards Track RFC 9447. Он рассчитывает на заранее существующие отношения между CA и Token Authority, а также между клиентом и Token Authority. Там, где их нельзя предположить, испытание неприменимо. Новый профиль меняет предмет разрешения, но не создаёт институциональную основу доверия.

Сервер доказывает согласованность, а не законность мандата

Получив конфигурацию доверия, сервер проверяет структуру, тип и подпись токена. Он требует наличия действующего exp и jti, связывает ответ с ключом учётной записи ACME, открывшей заказ, и сопоставляет флаг ca с видом запрошенного сертификата.

Значение ограничения в токене должно полностью совпасть с идентификатором. Сбой переводит испытание в invalid; обычно серверу рекомендуется вернуть документ проблемы ACME типа unauthorized. Токен становится труднее перенести на другой аккаунт, форму заказа или последовательность байтов.

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

Текущая карточка Datatracker показывает документ активным и In WG Last Call, а его состояние IESG — только I-D Exists. Не назначены document shepherd и ответственный Area Director, нет даты telechat. В прежнем объявлении окончанием называлось 25 июля, поэтому текущая метка не доказывает, что комментарии ещё принимаются. Редакция 05 не является одобренным RFC, реализацией или отчётом о внедрении.

Проект допускает в одном заказе не более одного идентификатора JWTClaimConstraints и одного TNAuthList. Для выпущенного сертификата адрес x5u рекомендуется сохранять доступным, пока он нужен полагающимся сторонам, обычно хотя бы до истечения срока. Это сохраняет материал проверки, но не обоснование доверия.

Нужна квитанция о полномочии над ограничением

Экосистема могла бы формировать связанную с решением ACME квитанцию без публикации телефонных номеров и сырого частного ограничения. Она соединяла бы идентификатор и версию политики, личность Token Authority, отпечаток доверенного сертификата, допустимое семейство ограничений, класс делегированного объёма и хеш заказа с закодированным значением.

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

Это редакционное предложение Daniel Kade, а не требование IETF. Квитанцию должен автоматически выдавать реальный механизм политики доверия, а не вторичный журнал ручного ввода. Так можно увидеть источник полномочия, не раскрывая данные, которые протокол намеренно считал непрозрачными.