Кратко

  • draft-ietf-acme-pop-00 предлагает необязательный путь: ключ сертификата объявляется как popKey, а владение подтверждается в отдельной авторизации pop без CSR при финализации.
  • Для ML-KEM сервер проверяет ключ и выполняет Encaps до атомарного создания заказа, авторизации, challenge и состояния доказательства.
  • Клиент возвращает HMAC от хеша точных байтов newOrder; контроль DNS или другого идентификатора проверяется отдельно.
  • KEM-транскрипт убеждает сервер, но не даёт проверяемого третьей стороной неотречения, поскольку сервер способен вычислить тот же MAC.
  • Редакция 00 остаётся Internet-Draft, а не RFC, реализацией, тестом совместимости или фактом эксплуатации.

Стоимость возникает до готового challenge

Клиент передаёт DER SubjectPublicKeyInfo в popKey и пустой идентификатор pop. Для ML-KEM сервер сначала обязан проверить тип, параметры, длину и математические условия ключа. Только после этого он вызывает ML-KEM.Encaps.

Результат содержит общий секрет и ciphertext. Сервер выводит из секрета mac_key через HKDF-SHA-256, помещает свежий ciphertext в challenge и атомарно фиксирует весь набор состояний. Если вычисление не завершилось, частичного заказа остаться не должно.

Такой порядок защищает целостность, но открывает поверхность ресурсов. Поток новых заказов может заставлять сервер выполнять дорогие операции ещё до того, как клиент ответил на challenge. Проект прямо требует учитывать rate limiting для KEM encapsulation.

Ограничение должно опираться не только на число HTTP-запросов. Нужны стоимость алгоритма, учётная запись, источник, параллелизм, доля неоконченных заказов и время удержания памяти.

Временный секрет имеет собственный жизненный цикл

Ciphertext должен быть новым для каждого challenge и не может кэшироваться или переноситься между заказами. Сырой shared secret не сохраняется. После HKDF сервер удерживает только mac_key, необходимый для проверки ответа.

Клиент выполняет Decaps своим приватным ключом, получает тот же материал и отправляет HMAC-SHA-256 от newOrder_hash. И клиент, и сервер должны удалить промежуточные секреты. Сервер уничтожает mac_key, когда challenge, авторизация, заказ или учётная запись переходят в соответствующее конечное состояние.

Повторная отправка после завершения не должна возвращать материал к жизни. Ошибка доказательства инвалидирует challenge, авторизацию и заказ. Это граница, где криптография и машина состояний должны завершаться вместе.

Хеш принадлежит исходным байтам

newOrder_hash вычисляется от payload JWS после base64url-декодирования и до разбора JSON. Нельзя разобрать объект, упорядочить поля по-своему и хешировать новую сериализацию. Неоднозначный JSON с повторяющимися ключами отклоняется.

Поэтому HMAC подтверждает способность decapsulate именно в контексте этого заказа: заявленного popKey, набора идентификаторов и других полей. Изменение хотя бы одного байта даёт другой контекст.

Для подписывающих ключей вместо ciphertext используется свежий 32-байтовый popNonce, а клиент подписывает доменный префикс, nonce и тот же хеш. В обоих режимах авторизация специфична для заказа и не переносится из прошлой проверки.

У владения ключом узкий смысл

Пустой pop не является именем в сертификате и не содержит ключа. Он создаёт отдельный вопрос: владел ли участник приватным ключом к принятому popKey в момент выполнения challenge?

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

Ключ учётной записи тоже отделён. Он подписывает ACME-сообщения и по проекту не может совпадать с popKey. Это разные полномочия и разные планы восстановления.

Сервер может воспроизвести KEM-доказательство

Клиент без приватного KEM-ключа не сможет получить правильный MAC. Для текущего решения сервера этого достаточно. Но сервер сам создал encapsulation и знает ожидаемый MAC, поэтому внешний аудитор не может считать ответ уникальной подписью клиента.

Журнал ciphertext, ответа, хеша и времени полезен как внутреннее свидетельство. Он не даёт неотречения. Организация должна заранее решить, достаточно ли этого для её регулируемого аудита, а не повышать статус записи постфактум.

Потеря account key влияет на остановку

KEM-приватный ключ не подписывает запрос на отзыв. В RFC 8555 остаётся путь через ACME account key. Если тот потерян, протокольного способа отозвать обычный KEM-сертификат может не быть.

В STAR исходный popKey используется для автоматических продлений без нового challenge. STAR не отзывает отдельные сертификаты; account key отменяет заказ и прекращает будущую выдачу. Потеря этого ключа может оставить обновление включённым до end-date.

Короткие сроки, восстановление аккаунта и отдельные CRL/OCSP-каналы способны ограничить ущерб. Их необходимо проверять как реальные средства управления.

После всех авторизаций finalize содержит {}. CA всё равно решает остальные поля сертификата, а затем оператор должен установить и наблюдать результат. Успешный PoP не доказывает продолжение владения, развёртывание или принятие клиентом.

Редакция 00 опубликована 1 сентября 2026 года и может измениться или истечь. Поддержка конкретной CA или программы, выпуск, совместимость, инцидент и распространённость не утверждаются.