Кратко

  • Необязательный token-authority — подсказка клиенту для поиска, а не якорь доверия сервера. Доверие определяется локальной конфигурацией экосистемы и сертификатом издателя, указанным через x5u или x5c.
  • Сервер ACME считает JWTClaimConstraints непрозрачной строкой и напрямую сравнивает значение исходного заказа с tkvalue октет за октетом, ничего не декодируя, не кодируя заново и не нормализуя.
  • Успех требует отдельных подтверждений издателя, подписи, типа, точной идентичности, exp, jti, ключа учётной записи ACME и роли CA в CSR. Выпуск сертификата ещё не доказывает последующую проверку JWS или исход звонка.

Найти адрес — не значит установить доверие

В испытании tkauth-01 может присутствовать URL token-authority. Клиент ACME вправе пойти по нему к службе, которая выдаст JWTClaimConstraints Authority Token. Если поля нет, местоположение должно быть известно из внешней конфигурации.

Редакция 05 прямо запрещает переносить эту подсказку в решение сервера: при проверке ответа сервер ACME не использует token-authority. Маршрут, предложенный клиенту, не включает подписанта на его конце в доверенный набор сервера.

Доверие приходит другим путём. Authority Token обязан быть подписан сертификатом, который сервер настроен принимать как издателя таких токенов в данной экосистеме. Сертификат можно указать по HTTPS x5u либо передать через x5c. Если нет ни одного варианта или сертификат не обладает настроенной ролью, проверка должна завершиться неудачей. Необязательный iss называет издателя, но заявление внутри токена не может само выдать себе доверие.

Разделение позволяет перемещать адрес выдачи ради доступности, не расширяя полномочия. И наоборот, отзыв роли издателя не обязан менять сетевой маршрут клиента. Если связать оба решения одним параметром, обычная правка URL незаметно станет правкой границы авторизации.

Смысл проверяет один участник, идентичность — другой

Идентификатор JWTClaimConstraints в новом заказе несёт DER-кодированный объект ASN.1 JWTClaimConstraints или EnhancedJWTClaimConstraints в base64url без дополнения. Authority Token повторяет значение в atc.tkvalue.

Внутри находятся ограничения claims экосистемы STIR. Token Authority по RFC 8226 и RFC 9118 решает, соответствуют ли они ресурсам и утверждениям, которые заявитель вправе представлять. Сервер ACME не разбирает ASN.1 повторно; для него значение непрозрачно.

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

Никакой самодельной эквивалентности

DER и base64url без дополнения задают единственную каноническую последовательность октетов. Сервер сравнивает две полученные строки напрямую. Он не должен декодировать и кодировать их заново, канонизировать, нормализовать или иначе преобразовывать до сравнения.

Символ =, знак вне алфавита base64url, пробел, другой алфавит, BER не в форме DER или отличие одного октета означают отказ. Проект также рекомендует сравнение с постоянным временем, хотя значения не являются секретными.

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

Восемь проверок вместо одной лампы

Сначала atc должен быть корректным объектом с tktype, tkvalue и fingerprint. Затем сертификат подписанта должен оказаться настроенным издателем, а подпись — пройти проверку. Тип должен быть равен JWTClaimConstraints. Значение должно побайтно совпасть с сохранённым идентификатором исходного заказа.

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

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

Сбой любого этапа делает испытание недействительным и может вызвать ошибку авторизации ACME. Общий счётчик «токен неверен» скрывает причину: доверие, загрузка сертификата, подпись, байты, часы, идентификатор операции, аккаунт или роль CA.

Ссылка, обязательство по которой начинается позже

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

Этот последующий x5u — не ссылка на сертификат издателя Authority Token. Они относятся к разным стадиям, ключам и срокам хранения. Запись о выпуске не доказывает, что позднее сертификат удалось скачать, принять или применить к телефонному утверждению.

Граница известных фактов

Редакция 05 опубликована 5 сентября 2026 года как Internet-Draft рабочей группы IETF и истекает 9 марта 2027 года без обновления. Она может измениться и не является RFC. Здесь не тестировались клиенты, серверы, CA, Token Authority, среды, репозитории, операторы и тракты звонков.

Источники не доказывают внедрение, соответствие, совместимость, выпуск, право на телефонные номера, аутентификацию звонков или снижение мошенничества. Они задают проект договора, а не подтверждают его исполнение.

Источники