Кратко

  • Проект LAMPS One Signature Certificates связывает сертификат с одним входом подписи через signedDocumentBinding, но прямо допускает успешную криптографическую проверку без проверки этой связи. «Подпись верна» и «dataTbsHash совпал» — два разных свидетельства.
  • Сертификат также утверждает, что закрытый ключ создан только для этого документа, использован один раз и немедленно уничтожен. Это заявление о процедуре удостоверяющего центра, а не наблюдение расширения. Отказ от срока и отзыва сокращает одну операционную нагрузку, но переносит долгосрочное доверие в политику УЦ, сохранённые доказательства и будущую настройку доверия.

Поле notAfter указывает на последнюю секунду 9999 года. noRevAvail сообщает, что сведения об отзыве отсутствуют. signedDocumentBinding содержит хеш, предназначенный для одного документа. Обычная подпись успешно проверяется.

Что из этого доказывает, что приложение проверило привязку? Ничто.

Revision 02 проекта One Signature Certificates проводит это различие явно. Сертификат создаётся во время подписания для нового ключа, который применяется к одной цифровой подписи и сразу уничтожается. Сертификат связан с подписанным содержимым, практически не имеет окончания срока и не предполагает сервиса отзыва. Цель — упростить долгосрочную проверку, убрав постоянный ключ конечного субъекта и накапливаемое состояние отзыва.

Это активный Internet-Draft рабочей группы LAMPS в потоке IETF, нацеленный на Proposed Standard. Revision 02 датирован 1 июля 2026 года и истекает 2 января 2027-го. Datatracker показывает его как документ группы со статусом IESG I-D Exists. Это не RFC и не доказательство реальной выдачи сертификатов, уничтожения ключей, проверки привязки программой или вечной пригодности архивной подписи.

Один сертификат содержит утверждения разной природы

Новое расширение называется signedDocumentBinding. Его ASN.1-значение включает dataTbsHash, hashAlg и необязательный bindingType. Хеш обозначает данные для подписи, а тип объясняет, как последовательность байтов получена из формата документа.

Одну часть можно воспроизвести: проверяющий собирает вход, считает хеш и сравнивает. Из dataTbsHash невозможно увидеть, действительно ли удалённая служба создала новый ключ, запретила второе использование, стёрла все копии и соблюла свою политику. Расширение аутентифицирует заявление УЦ об этой процедуре. Revision 02 относит описание процесса и уровень гарантии уничтожения к Certificate Policy.

Долговечная квитанция должна раздельно хранить значение расширения, точный вход, результат сравнения, версию CP/CPS, транзакцию выдачи, событие генерации, единственное разрешение на подпись и доказательство уничтожения. Формула «одноразовый сертификат действителен» стирает границы, необходимые будущему аудиту.

Подпись может пройти, хотя привязку не проверяли

В Security Considerations сказано, что проверка signedDocumentBinding не обязательна для успешной криптографической валидации подписи. Библиотека может корректно обработать формат и открытый ключ, а приложение превратить результат в одобрение, не вызвав дополнительное сравнение. Полагающейся стороне следует сравнить подписанное содержимое с dataTbsHash: именно это ограничивает сертификат задуманным документом и снижает риск подмены или непредусмотренного повторного применения.

Интерфейс решения должен показывать как минимум два статуса. signature_valid относится к криптографической операции и формату. document_binding_match фиксирует тип связи, восстановленные байты, алгоритм хеша, ожидаемое значение и результат. Если второй тест не запускали, его состояние — not_checked, а не passed и не неявный успех вслед за первым.

Сделать ли SHOULD обязательным локальным правилом — выбор профиля. Организация, которая полагается на ограничение одним документом, должна доказать соблюдение правила при повторной проверке архива, пакетной обработке, в мобильных клиентах и внешних службах.

Тип привязки определяет, какие байты считать документом

Если bindingType отсутствует, стандартный вариант хеширует точный вход алгоритма подписи: XML SignedInfo, DER-кодированные CMS SignedAttributes или эквивалент. Сложность возникает, когда вход содержит сам сертификат или его хеш. dataTbsHash находится внутри сертификата, и вычисление объектов начинает зависеть друг от друга. Revision 02 запрещает стандартный вариант при такой цикличности и задаёт исключения для форматов.

В CAdES используется DER SignerInfo после удаления атрибутов SigningCertificate и SigningCertificateV2. В XAdES берётся canonicalized SignedInfo после удаления ссылок типа SignedProperties, а остальные символы, пробелы и переводы строк сохраняются. JWS и COSE связывают только payload и исключают protected и unprotected headers.

Поэтому один видимый документ может иметь разные dataTbsHash. Совпадение payload в JWS не доказывает тождество protected header, идентификатора ключа, алгоритма или ссылки на сертификат. Они остаются частью обычной проверки JWS и политики приложения. В квитанции нужны формат, идентификатор, правило канонизации или исключения, версия реализации и хеш восстановленных байтов.

Отсутствие отзыва не доказывает уничтожение

Проект рекомендует notAfter со значением 99991231235959Z и расширение RFC 9608 id-ce-noRevAvail. Первое показывает отсутствие определённого практического окончания, второе — отсутствие информации об отзыве для сертификата. Ни одно не доказывает, почему отзыв не нужен.

Аргумент опирается на эксплуатацию: если ключ существовал недолго, подписал один раз и был действительно уничтожен, позднее событие отзыва не должно менять уже созданную подпись. У одноразового уничтоженного ключа меньше будущая поверхность риска, чем у повторно используемого. Но риск перемещается в достоверность записи о создании. Был ли ключ новым? Существовал ли только один авторизованный запрос? Не осталась ли копия в backup, log, crash dump, репликации HSM или retry? Завершилось ли уничтожение до компрометации?

noRevAvail лишь говорит не ждать CRL или OCSP. Он не отвечает на эти вопросы. «Нет отзыва по проекту», «служба отзыва недоступна» и «профиль не распознан» должны быть разными состояниями.

Время выдачи расширяет временные полномочия УЦ

Долгосрочной проверке обычно нужен best-signature-time — самое раннее доверенное свидетельство существования подписи. RFC 3161 предлагает независимый Time-Stamp Authority. Revision 02 рассуждает иначе: сертификат одной подписи создаётся во время подписания, поэтому его выдача устанавливает время подписи, а УЦ играет роль, похожую на службу времени.

Связка эффективна, но расширяет поверхность доказательств УЦ. Центр утверждает не только личность и открытый ключ, но и время единственного события, область содержимого, свежесть ключа и его немедленное уничтожение. Оператор должен указать, получено ли лучшее время из выдачи, отметки RFC 3161, validation token, архивной записи или нескольких источников, и сохранить источник часов, транзакцию, политику и аудит. Синтаксически верный notBefore не становится независимым доказательством времени автоматически.

9999 год не делает удостоверяющий центр бессмертным

Проект ограничивает обещание неистекающего конечного сертификата. Проверка по-прежнему зависит от доверия к выдавшему УЦ. Первичная валидация предполагается в срок действия сертификата центра. Позднее может потребоваться сохранить ключ УЦ как локальный trust anchor, использовать cross-certification, получить обновлённые сертификаты или иной механизм. Построение доверия после срока УЦ находится вне области проекта.

Следовательно, дата 9999 убирает одну проверку срока, но не сохраняет всю цепь. Алгоритмы устаревают, trust stores меняются, политики заменяются, центры закрываются и меняют ключи, архивы мигрируют, программы исчезают. Исходные байты, цепь сертификатов, политики, временные доказательства, результаты валидации и история trust anchors должны оставаться доступными.

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