Summary

  • draft-ietf-ediint-rfc4130bis-04 treats AS2-From and AS2-To as case-sensitive textual names agreed by trading partners, while TLS certificates protect the transport endpoint and separate AS2 certificates sign or encrypt the business message.
  • The current draft requires those two certificate roles to remain separate, requires authenticated and authorized certificate retrieval, and requires out-of-band fingerprint verification before a self-signed AS2 certificate enters production.
  • A valid signature, reflected AS2 names and matching Message-ID/MIC form a strong receipt chain. They still depend on a local authority having bound the exact partner name, current signer, direction and trading relationship before activation.

The rollover window with no red light

Imagine a scheduled AS2 certificate rollover at 02:00. The HTTPS endpoint presents a valid TLS certificate. The incoming message carries the expected AS2-From and AS2-To strings. The returned MDN reverses those strings as required. Its signature verifies under a newly installed public key. The Original-Message-ID points to the outbound document, and the returned MIC matches the digest retained by the sender.

Every individual check can pass. The remaining question is not mathematical: who decided that the new AS2 certificate was authorized for that exact name and relationship? If the key arrived through the wrong administrative channel, was attached to the wrong partner row, or was activated for inbound traffic when approval covered only outbound encryption, the cryptography can faithfully verify the wrong local proposition.

That gap is the most consequential operational reading of revision 04 of AS2 Specification Modernization. The Datatracker lists an active EDIINT Working Group document, and its document API records I-D Exists. The history shows revision 04 uploaded on 24 September 2026. The intended status is Proposed Standard. It is not an RFC or an approved IETF standard, and it would obsolete RFC 4130 only if the process eventually approves it.

Three identity surfaces, not one

Section 6.3 defines AS2 system identifiers as text. AS2-From and AS2-To may be company-specific values such as DUNS numbers, or simply identification strings agreed by trading partners. They are case-sensitive, limited to 1–128 printable ASCII characters and mandatory in both messages and MDNs. A response reverses the request's names: response AS2-To matches request AS2-From, and response AS2-From matches request AS2-To.

This reflection is important routing and correlation evidence. It does not make the string a certificate subject, DNS name, legal identity or globally registered principal. The receiving system may reject an unknown name with an unsigned MDN carrying unknown-trading-relationship or unknown-trading-partner, but the document does not create a universal registry that tells every operator which public key owns each AS2 name.

The transport identity is separate. HTTPS establishes a protected connection to an endpoint using TLS. TLS 1.3 supplies the channel protocol; RFC 9525 supplies modern contextual guidance for service identity, although the AS2 draft does not incorporate that RFC as its own binding rule. HTTP semantics, now specified by RFC 9110, carry the request and response.

The message identity is separate again. S/MIME and CMS—the current references include RFC 8551 and RFC 5652—provide the signature and encryption structures around the business content and MDN. Certificate-path concepts come from the PKIX lineage represented here by RFC 5280. A certificate can be well formed, in date and anchored to an accepted issuer without answering whether the local AS2 administrator approved it for partner X, flow Y, at time Z.

Revision 04 makes the domain separation explicit: an AS2 certificate must not be the TLS certificate. Compromise at the channel layer should not automatically compromise message-level security, and operational renewal can proceed on different schedules. That rule prevents one credential from silently accumulating two jobs. It also removes a tempting shortcut: a healthy HTTPS endpoint cannot, by itself, authorize the signer of the business document.

Distribution is not authorization

Section 9.2 recommends Certificate Exchange Messaging and cites draft-meadors-certificate-exchange-14, itself an Internet-Draft. If CEM is unavailable, manual exchange must preserve integrity and authenticate keys before activation. A Well-Known URI may expose a partner certificate, but retrieval must authenticate the requester and authorize access to legitimate trading partners.

That wording matters. The certificate issuer's signature makes substitution detectable. It does not decide who should be allowed to retrieve the certificate, which bilateral relationship it serves, or whether the operator copied it into the correct partner profile. For a self-signed AS2 certificate, the draft requires an additional out-of-band check—such as confirming the fingerprint over a secure channel—before production use.

The activation record therefore needs more than a PEM file. It should identify the case-sensitive AS2 name, relationship, inbound or outbound role, signing or encryption use, fingerprint, validity window, trust method, approvers, activation time, overlap interval and rollback credential. Without that record, the organization knows that a key exists. It cannot show why the key acquired authority.

What the signed MDN actually joins

AS2's receipt chain is substantial. The sender retains the message, Message-ID and MIC. The receiver processes the message and may return a signed MDN. The sender can verify the MDN signature using the receiving trading partner's public key, correlate the Original-Message-ID and compare the returned MIC with the digest of the original content.

The current draft uses “non-repudiation of receipt” for the event produced after signature verification and MIC comparison. RFC 8098 supplies the current Message Disposition Notification framework. This article does not extend the draft's term into a universal legal conclusion. Jurisdiction, contract, key custody, compromise and evidentiary procedure remain outside a hash comparison.

Nor does this commission repeat the separate proposition that transport receipt is not business acceptance. The existing RFC 1865 analysis owns that boundary. Here the narrower problem precedes it: before relying on the signed receipt, the verifier must know that the public key used for verification was authorized for the reflected AS2 name and current relationship.

The evidence ladder is therefore: HTTP/TLS connection; AS2-name parsing and reflection; certificate path, lifetime and key checks; local partner authorization; message or MDN signature; Message-ID and MIC correlation; MDN disposition; downstream EDI acceptance; commercial outcome. Each rung can support the next. None should impersonate it.

The draft reinforces the certificate rung by requiring immediate, noticeable reporting for expired, revoked or untrusted certificates. That is necessary, not sufficient. A certificate can be unexpired and trusted yet mapped to the wrong local partner. Conversely, a partner may be legitimate while its replacement certificate is not yet approved. Trust-path state and relationship state must remain two fields.

The comparison with revision 03

The frozen revision 03 shows that the certificate provisions were already present before the current upload. Revision 04 includes editorial and MIME-structure work; it should not be advertised as having newly invented every certificate control. The responsible claim is that the current revision codifies the separation and exchange requirements.

The frozen HTML and XML forms help verify structure against the text. They do not supply deployment evidence. No product, operator, interoperability event, attack or certificate incident is established by this source set.

Sources and limits

The analysis uses the current draft's text, HTML and XML forms, its Datatracker page, API and history, revision 03, RFC 4130, RFC 8098, RFC 8551, RFC 8615, RFC 5652, RFC 5280, the CEM draft, RFC 9110, RFC 9525 and RFC 8446. The leadership reading draws separately on Lu Heng's essays on running-code primacy, reality layers and minimum initial specification. The source packet supports protocol and governance analysis, not a claim about any named deployment.