Кратко

  • Рабочая группа ACME 21 сентября 2026 года направила draft-ietf-acme-profiles-02 в IESG. Статус Publication Requested не означает одобрения IESG или публикации RFC.
  • Поле newOrder.profile улучшает управление заказом, но объявление, право аккаунта, принятие заказа, финализация и внедрение остаются разными доказательствами.

В системе управления сертификатами легко принять знакомое имя за неизменный продукт. Новый проект ACME Profiles помогает раньше увидеть выбор, но одновременно показывает предел такой уверенности. Один и тот же идентификатор может фигурировать в Directory, применяться как закрытый профиль вне Directory или перестать быть доступным после создания заказа.

Это не предположение об аварии. Все три пути прямо укладываются в предлагаемую модель. Поэтому хороший журнал должен фиксировать не только имя, но и каждое решение вокруг него.

Что произошло в IETF

21 сентября Datatracker сменил состояние документа с Working Group Last Call на «Submitted to IESG for Publication». Состояние IESG — «Publication Requested», ответственным Area Director указан Deb Cooley, дата telechat отсутствует. Mike Ounsworth запросил публикацию от имени рабочей группы.

Ревизия 02 нацелена на Proposed Standard, однако остается Internet-Draft. Shepherd write-up называет консенсус слабым: расширение считали простым, а явно положительных ответов было немного; споров и апелляций не зафиксировано. Список реализаций и опыт Let’s Encrypt показывают реальную разработку, но не общую рыночную поддержку.

Выбор перемещается в начало заказа

RFC 8555 разделяет создание заказа и последующую отправку CSR на finalize. Проект добавляет необязательный объект profiles в метаданные Directory. Ключ — короткий уникальный для сервера идентификатор, значение — URL понятного человеку описания; допускается data URL.

Клиент может передать имя в newOrder.profile. Если сервер его принимает, объект Order возвращает выбранное имя. Политика характеристик срабатывает до CSR, а CSR продолжает нести открытый ключ и subjectAltName. Авторы отмечают возможность сократить разбор и копирование ASN.1 в политике CA.

Управление аккаунтами и проверка идентификаторов не меняются. Глобального словаря имен не возникает. Реальный смысл ограничен конкретным Directory, временем получения и опубликованным описанием.

Пять отдельных решений

Сначала сервер объявляет имя. Это предложение, а не право любого аккаунта. При несовместимом заказе сервер обязан вернуть invalidProfile; среди примеров — профиль TLS-сервера с почтовым идентификатором и аккаунт вне allowlist.

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

Если клиент вообще не указывает поле, серверу рекомендуется самостоятельно выбрать и связать профиль с заказом. Поэтому запрос не является полным доказательством; нужен ответ Order.

Принятый Order еще не означает выдачу. Если к finalize CA больше не готов выдавать сертификат по этому профилю, он должен вернуть invalidProfile. Рекомендуется сначала дождаться истечения открытых заказов, однако протокол сохраняет явный путь отказа.

Локальная семантика меняется со временем

Let’s Encrypt называет текущий Directory каноническим списком и предупреждает о различиях между средами и allowlist-ограничениях. classic, tlsserver и shortlived имеют разные сроки повторного использования авторизаций, жизни заказа и сертификата, виды идентификаторов и поля сертификата.

tlsclient недоступен с 8 июля 2026 года. tlsserver перешел на 45-дневные сертификаты 13 мая, а для classic опубликован план дальнейшего сокращения сроков. Это доказательства изменений у одного оператора, а не определения для всех CA.

Как сохранить проверяемую историю

Нужно зафиксировать исходный ответ Directory, URL и время. Отдельно — URL описания и хеш прочитанного текста. Следующий слой связывает endpoint CA, аккаунт, идентификаторы, запрошенное имя, решение о допуске и Order с возвращенным профилем.

Для finalize сохраняются отпечаток CSR, статус ответа и ACME problem type. После выдачи отпечаток сертификата и разобранные свойства показывают подписанный результат. Для доказательства установки требуется отдельное наблюдение рабочего сервиса с временем и точкой измерения.

Directory не дает права, Order не является сертификатом, а сертификат не подтверждает установку. Разделение сохраняет пользу имени как ключа транзакции и не превращает его в несуществующую гарантию.

Источники

  1. Текущее состояние в Datatracker
  2. История документа
  3. draft-ietf-acme-profiles-02
  4. Запрос на публикацию
  5. Shepherd write-up
  6. RFC 8555
  7. Документация профилей Let’s Encrypt
  8. Объявление ACME Profiles
  9. План сроков сертификатов
  10. Объявление последнего рассмотрения рабочей группой
  11. Завершение последнего рассмотрения
  12. Трекер реализации Boulder
  13. Протокол ACME на IETF 126