Summary

  • Редакция 04 индивидуального Internet-Draft добавляет проприетарный драйвер УЦ CygnetSSL, работавший в одном контуре под управлением одного администратора; независимого теста совместимости не проводилось.
  • Наблюдения охватывают 22 сертификата ECDSA, CRL в DER и один переход статуса OCSP. Они не подтверждают экспорт по TLS-сессиям, зонам DNSSEC и QUIC, распределение алгоритмов сертификатов или агрегацию с совместимостью CBOM.
  • Daniel Kade предлагает матрицу доказательств, где каждый пробел закрывается отдельно. Это редакционное предложение, а не требование IETF и не отрицательная оценка самой реализации.

Новая запись — ориентир для проверки, а не вердикт

Опубликованная 13 сентября редакция 04 получила раздел Implementation Status. В редакции 03 его не было, а официальное сравнение показывает границы добавления. Раскрытие статуса реализации, описанное в RFC 7942, помогает отличить идею на бумаге от испытанного кода. Но оно не превращает отдельный опыт в свидетельство повсеместной готовности.

У документа ограничен и процедурный статус. Datatracker называет его активным индивидуальным Internet-Draft. API метаданных фиксирует редакцию 04, состояние IESG I-D Exists и отсутствие IETF stream; заголовок запрашивает статус Informational. Это не консенсус рабочей группы, не одобрение IESG и не RFC.

У наблюдения есть точная граница

Запись относится к драйверу удостоверяющего центра CygnetSSL. Это проприетарное ПО в единственной среде, которой распоряжается один администратор; независимая проверка совместимости отсутствует. В двух профилях обнаружены 22 сертификата конечных субъектов, все на ECDSA P-384 / ECDSA-SHA384. Также зафиксированы CRL в DER и ответ OCSP, изменившийся с good на revoked.

Для работы УЦ эти данные полезны: они показывают выпуск и отзыв. Однако они не являются внедрением постквантовой криптографии. Стандарт FIPS 204 определяет ML-DSA, а FIPS 205 — SLH-DSA; это не меняет алгоритмы в выборке и не доказывает способность оператора увидеть криптографический состав всей инфраструктуры.

Пять требований требуют пяти независимых цепочек

REQ-RG-1 — REQ-RG-5 относятся к разным поверхностям наблюдения: алгоритм, согласованный в каждой TLS-сессии; алгоритм каждой зоны DNSSEC; распределение алгоритмов сертификатов с данными OCSP и CRL; соответствующий сигнал QUIC; затем сводка между протоколами, совместимая с перечнем криптографических материалов CBOM. Технический контекст этих объектов задают RFC 8446, RFC 4034, RFC 5280, RFC 6960 и RFC 9000.

Выборка сертификатов не заменяет журналы сессий, подписанных зон или соединений QUIC. Для управленческого вывода важен знаменатель: 22 из скольких, в какой совокупности и с какими исключениями? Без него корректный локальный факт легко превращается в необоснованное утверждение обо всей среде.

Практический выход — матрица закрытия пробелов, по одной строке на требование. В строке нужны механизм наблюдения и версия, артефакт и устойчивое место хранения, среда и оператор, метод тестирования, совокупность и знаменатель, результат, ограничение, дата, ответственный, следующая проверка и независимый воспроизводитель. Тогда статусы «эксперимент есть», «частичное покрытие» и «ожидает независимой проверки» сохранят информацию, не создавая общей зелёной отметки.

В качестве артефакта проект приводит URL CygnetLib на GitHub. На момент этой проверки точный адрес с производственного хоста отвечал HTTP 404. Это лишь ограниченное по времени и адресу наблюдение доступности: оно не доказывает, что репозитория никогда не было, ничего не говорит о намерениях автора и не оценивает работоспособность ПО. Оно означает только, что графу независимого воспроизведения нельзя закрыть, пока указанный материал недоступен.

Такой подход продолжает принцип проверяемого отражения политики из The Policy Mirror, движение от минимальной исходной спецификации из Minimum Initial Specification и разделение наблюдаемой реальности и пропаганды позиции из Why BTW Media Exists. Реализация заслуживает места в записи. Но пять выводов должны опираться на пять заполненных строк.

Sources

  1. Пробелы готовности к PQC, редакция 04
  2. Пробелы готовности к PQC, редакция 03
  3. Официальное сравнение 03–04
  4. Карточка Datatracker
  5. API метаданных Datatracker
  6. RFC 7942
  7. RFC 8446
  8. RFC 4034
  9. RFC 5280
  10. RFC 6960
  11. RFC 9000
  12. NIST FIPS 204
  13. NIST FIPS 205
  14. Ссылка CygnetLib, приведённая в проекте
  15. The Policy Mirror
  16. Minimum Initial Specification
  17. Why BTW Media Exists