Кратко

  • RFC 3125 требовала policy OID и hash окончательной спецификации в процессе подписи, чтобы verifier применял именно указанные байты и правила.
  • Правильные подпись и hash не завершали решение: период, commitment, сертификаты, отзыв, время, атрибуты, алгоритмы, институциональное признание и результат оставались раздельными.

Транзакция была больше криптографического равенства

Подпись показывает, что bytes проверяются под ключом и алгоритмом. Договор спрашивает больше: подходил ли сертификат для цели, попало ли создание в разрешённый период, означало ли действие одобрение или получение, какие сведения об отзыве, времени и роли требовались?

RFC 3125 вышла Experimental в сентябре 2001 года. Она назвала набор правил создания и проверки signature policy. Правовой или договорный контекст мог признать такую политику. Сам RFC не создавал признание.

Policy Issuer, Signer, Verifier, Arbitrator и поставщики доверия имели разные роли. Издатель задавал требования, подписант ссылался на политику, проверяющий применял её, арбитр мог повторить проверку. Общий объект не объединял полномочия.

OID указывал на правила, но не заменял их

Политике требовались Object Identifier, существующая спецификация и одна окончательная форма с уникальной бинарной кодировкой. Подписант передавал её hash, проверяющий сверял его.

OID выбирал идентичность, hash фиксировал bytes. Опциональная ASN.1-структура с DER делала машинную форму детерминированной, не позволяя общему названию скрывать разные редакции.

Но OID не был знаком одобрения. Совпадение hash доказывало использование одного rulebook, а не компетенцию издателя, выполнение внешней процедуры или признание судом. Поэтому требовалась и человекочитаемая форма для оценки в конкретном контексте.

Валидность получила явные параметры

Структура включала signing period, common rules и commitment rules. Вне периода математически правильная подпись могла нарушить правило создания.

Общие правила охватывали обязанности, доверие сертификатам, времени и атрибутам, алгоритмы и расширения. Commitment rules подбирали условия для одобрения, получения или обязательства в семантике сообщения. Сначала следовало выбрать редакцию и commitment, затем строить trust path.

Одна цепочка могла подходить в одном поле и не подходить в другом. Ключ мог соответствовать до алгоритмического предела и перестать после. Одно слово «валидна» удаляло параметры решения.

Сервисы доверия давали части доказательства

CA, RA, repositories, timestamp authorities, status responders и attribute authorities могли поддерживать политику. Она выбирала trust points, пути, отзыв, время и роли.

Сертификат связывал ключ с утверждением. Status описывал сертификат во времени. Timestamp подтверждал существование данных ранее. Атрибут поддерживал роль. Ни один документ не решал коммерческое обязательство целиком.

Воспроизводимая проверка сохраняла ответы, времена, программу и правило, использовавшее каждую часть. Зелёного результата было недостаточно для позднего арбитража.

Hash не наблюдал все процедуры

CMS attributes, ссылки и сертификаты можно было проверить машиной. Custody ключа, внутренняя санкция и человеческие шаги могли находиться вне подписи. Hash определял книгу правил, но не доказывал каждый описанный процесс.

Поэтому «валидна под OID X» не означало автоматически полномочие, принятие контрагентом, оплату или исполнение. У каждого вывода свой владелец и источник.

Алгоритмы делали решение историческим

RFC подчёркивала защиту private key и ослабление алгоритмов, рекомендуя modular implementations. Политика могла ограничивать алгоритм и длину ключа.

Поздняя проверка требовала прежнюю редакцию, период, timestamps и migration rule. Последующий запрет алгоритма не определял судьбу старого evidence сам по себе.

RFC 3126 описала долгосрочные форматы, RFC 3161 — время. RFC 2630, 2634, 2459 и 2560 дали контекст CMS, S/MIME, PKIX и status; RFC 5280 и 5652 продолжили линию. Они не доказывают deployment RFC 3125.

Experimental не означало внедрение

Conformance требовала обработки по идентифицированной политике. Это условие для conforming participant, не статистика участников.

Подтверждённый вклад — цепочка OID, окончательной формы, уникальной кодировки, hash, commitment и trust conditions. Adoption, interoperability и юридический эффект требуют иных источников.

Полный receipt сохранял бы объект, подпись, сертификат, OID, политику, hash, период, commitment, пути, отзыв, время, атрибуты, алгоритмы и вывод verifier, а затем договор, признавший политику. Криптография закрывала расчёт; политика говорила, какой расчёт имеет значение.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3125.txt
  2. https://www.rfc-editor.org/info/rfc3125
  3. https://datatracker.ietf.org/doc/rfc3125/
  4. https://www.rfc-editor.org/rfc/rfc3126.txt
  5. https://www.rfc-editor.org/rfc/rfc2630.txt
  6. https://www.rfc-editor.org/rfc/rfc2634.txt
  7. https://www.rfc-editor.org/rfc/rfc2459.txt
  8. https://www.rfc-editor.org/rfc/rfc2560.txt
  9. https://www.rfc-editor.org/rfc/rfc3161.txt
  10. https://www.rfc-editor.org/rfc/rfc2119.txt
  11. https://www.rfc-editor.org/rfc/rfc5280.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt