Кратко

  • draft-ietf-lamps-csr-attestation-29 позволяет CA или RA проверить дополнительные заявления в соответствии с политикой выпуска либо отбросить их без обработки.
  • Поскольку чувствительные сведения об устройстве не рекомендуется переносить в публичный сертификат, сам сертификат не доказывает, какая закрытая оценка ему предшествовала. Защищённая квитанция о свидетельствах выпуска могла бы связать точный CSR, результат оценки и выданный сертификат.

Публичный документ показывает только финал

2 сентября IETF объявила Last Call по проекту рабочей группы LAMPS и установила срок подачи комментариев до 16 сентября. Это следует из официального сообщения. Страница Datatracker показывает редакцию 29 на рассмотрении: 6 сентября назначен обзор ARTART, а для IANA указано состояние Review Needed. В истории документа нет решения о публикации в качестве RFC.

Проект добавляет аттестационные данные к запросам сертификатов в форматах PKCS #10 и CRMF. Контейнер AttestationBundle содержит одно или несколько заявлений и при необходимости вспомогательные сертификаты. По меньшей мере одно заявление должно содержать аттестацию, криптографически связанную с открытым ключом в CSR.

Однако доставка контейнера ещё не означает его использование. В редакции 29 CA или RA может проверить аттестации для применения своей политики выпуска, а может отбросить их без обработки. CA, принимающему или требующему такие данные, рекомендуется описать практику в CPS. Поэтому одинаковый запрос способен пройти у двух эмитентов через разные по смыслу процедуры.

Несколько верных заявлений могут описывать разные объекты

Даже валидные по отдельности заявления не обязательно относятся к одному ключу, одной платформе и одному моменту времени. Итоговая ответственность за связь с ключом и объединение сведений о платформе и устройстве остаётся у CA или RA. Проект также допускает игнорирование устаревших либо неопределённых свидетельств.

Такое разделение соответствует архитектуре RATS в RFC 9334, где различаются Evidence, Appraisal Policy и Attestation Result. Отдельный проект о свежести аттестации рассматривает nonce и временные привязки. Подпись под заявлением сама по себе не отвечает на вопрос, оставалось ли описанное состояние актуальным в момент выпуска сертификата.

Сравнение редакций 28 и 29 помогает увидеть изменения перед Last Call. Но оно не даёт оснований считать, что редакция 29 впервые ввела выбор между проверкой и отбрасыванием: эта операционная граница уже присутствует в редакции 28.

Конфиденциальность не требует забыть решение

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

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

Такая квитанция — аналитическое предложение Daniel Kade, а не требование IETF, CA/Browser Forum или конкретного CA/RA. Требования CA/Browser Forum к сертификатам подписи кода дают контекст управления сертификатами, но не подтверждают внедрение механизма из проекта LAMPS.

Источники