Summary

  • AS2-From и AS2-To — чувствительные к регистру строки, согласованные торговыми партнёрами, а не глобальные идентификаторы из сертификата.
  • draft-ietf-ediint-rfc4130bis-04 требует разделять TLS-сертификат и AS2-сертификат подписи или шифрования и защищать получение и активацию партнёрских ключей.
  • Подпись, отражённые имена, Message-ID и MIC доказывают отдельные звенья. Право ключа представлять имя, направление и отношение создаётся локальным решением.

Ошибка, которую не покажет красная лампа

В 02:00 начинается плановая смена. HTTPS отвечает. Ответ меняет AS2-From и AS2-To как положено. Новый ключ проверяет подпись MDN, а MIC совпадает с сохранённым дайджестом. Только журнал изменений показывает, что отпечаток был вставлен в соседнюю запись.

Текст редакции 04 позволяет разложить ситуацию по слоям. Datatracker показывает активный документ группы EDIINT, API — состояние I-D Exists, история — загрузку 24 сентября 2026 года. Предполагаемый статус — Proposed Standard. Это ещё не RFC; RFC 4130 будет заменён только в случае утверждения.

Имя существует по соглашению двоих

Раздел 6.3 разрешает DUNS или согласованную строку. В имени 1–128 печатных ASCII-символов, регистр значим, поле обязательно в сообщениях и MDN. AS2-To ответа совпадает с AS2-From запроса, а AS2-From ответа — с исходным AS2-To.

Отражение подтверждает текстовую корреляцию, но не превращает строку в юридическое лицо, DNS-имя или субъект сертификата. Неизвестные значения могут вызвать unknown-trading-relationship или unknown-trading-partner. Для такого решения уже нужна локальная таблица; универсального реестра имя—ключ проект не создаёт.

Канал и документ имеют разные удостоверения

TLS-сертификат защищает HTTPS-точку. RFC 8446 задаёт TLS 1.3, RFC 9110 — семантику HTTP. RFC 9525 даёт современный контекст идентичности сервиса, но не является включённым в AS2 правилом привязки.

AS2-сертификат подписывает или шифрует сообщение и MDN. RFC 8551 и RFC 5652 описывают S/MIME и CMS, RFC 5280 — основу PKIX. Проект запрещает применять один сертификат для TLS и AS2. Компрометация и ротация канала не должны автоматически менять защиту документа.

Путь доверия отвечает требованиям сертификатной политики. Администратор партнёров решает, разрешён ли этот ключ сейчас для имени X, направления Y и отношения Z.

Доставка ключа не назначает ему роль

Раздел 9.2 рекомендует Certificate Exchange Messaging и ссылается на проект CEM. При ручном обмене до активации требуются целостность и аутентификация ключа. Для первичного получения возможен Well-Known URI, но запрос должен быть аутентифицирован, а доступ — разрешён законным партнёрам.

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

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

MDN не выбирает полномочие своего проверочного ключа

Отправитель хранит сообщение, Message-ID и MIC, затем проверяет подпись MDN, Original-Message-ID и возвращённый MIC. RFC 8098 задаёт современную основу MDN.

Проект называет проверенный результат “non-repudiation of receipt”. Здесь это не превращается в универсальный юридический вывод. Различие доставки и делового принятия уже принадлежит прежней статье. Наш вопрос раньше: почему открытый ключ проверки имел полномочие данного партнёра?

Лестница доказательств: HTTP/TLS; имена; проверка сертификата; локальная авторизация; подпись; Message-ID/MIC; disposition MDN; принятие EDI; коммерческий исход. Успех позднего звена не восстанавливает пропущенное раннее решение.

Редакция 03 уже содержит основные сертификатные требования. Корректно говорить, что текущая редакция их кодифицирует, а не изобрела заново. Формы HTML и XML подтверждают структуру, но не внедрение.

Источники и пределы

Пакет включает текст, HTML и XML редакции 04; страницу, API и историю Datatracker; редакцию 03; RFC 4130, RFC 8098, RFC 8551, RFC 8615, RFC 5652, RFC 5280, проект CEM, RFC 9110, RFC 9525 и RFC 8446. Для управленческого анализа отдельно использованы эссе Lu Heng о приоритете работающего кода, слоях реальности и минимальной начальной спецификации. Источники не доказывают конкретный продукт, инцидент, атаку или судебное решение.