Summary

  • AS2-From und AS2-To sind zwischen Handelspartnern vereinbarte, groß-/kleinschreibungssensitive Texte und keine automatisch aus Zertifikaten abgeleiteten Identitäten.
  • draft-ietf-ediint-rfc4130bis-04 verlangt getrennte Zertifikate für TLS und AS2-Nachrichten und schützt auch Abruf und Aktivierung der Partnerzertifikate.
  • Signatur, reflektierte Namen, Message-ID und MIC ergeben eine starke Beweiskette. Die Autorisierung von Name, Schlüssel, Richtung und Beziehung bleibt ein lokaler Verwaltungsakt.

Das grüne Ergebnis mit einer offenen Frage

Ein neues AS2-Zertifikat wird nachts aktiviert. Der TLS-Endpunkt ist erreichbar. Die Antwort vertauscht AS2-From und AS2-To korrekt. Die MDN-Signatur lässt sich prüfen und der MIC entspricht der gespeicherten Nachricht. Offen bleibt: Wer genehmigte den neuen Fingerabdruck für genau diese Partnerzeile?

Die Revision 04 hilft, diese Ebenen zu trennen. Der Datatracker führt einen aktiven EDIINT-Arbeitsgruppenentwurf, die API den Status I-D Exists, die Historie den 24. September 2026. Ziel ist Proposed Standard. Der Text ist noch kein RFC und würde RFC 4130 nur nach Genehmigung ablösen.

Vereinbarter Name, nicht globale Identität

Abschnitt 6.3 erlaubt DUNS-Nummern oder andere vereinbarte Zeichenfolgen. Der AS2-Name hat 1 bis 128 druckbare ASCII-Zeichen, unterscheidet Groß-/Kleinschreibung und ist in Nachrichten sowie MDNs Pflicht. In der Antwort entspricht AS2-To dem AS2-From der Anfrage und umgekehrt.

Das belegt syntaktische Zuordnung. Es macht den Namen nicht zum Rechtsträger, DNS-Namen oder Zertifikatssubjekt. Für unbekannte Werte kann ein unsigniertes MDN unknown-trading-relationship oder unknown-trading-partner melden. Schon diese Entscheidung beruht auf einer lokalen Tabelle; ein globales AS2-Namen-Schlüsselregister entsteht nicht.

Zwei Zertifikate, zwei Zuständigkeiten

Das TLS-Zertifikat schützt den HTTPS-Endpunkt. RFC 8446 beschreibt TLS 1.3, RFC 9110 HTTP-Semantik. RFC 9525 bietet modernen Kontext zur Dienstidentität, ist aber keine im AS2-Entwurf übernommene Bindungsregel.

Das AS2-Zertifikat signiert oder verschlüsselt Nachricht und MDN. RFC 8551 und RFC 5652 liefern S/MIME und CMS, RFC 5280 den PKIX-Rahmen. Der Entwurf verbietet dasselbe Zertifikat für TLS und AS2. Kanal und Dokument erhalten getrennte Kompromittierungs- und Erneuerungsgrenzen.

Ein gültiger Pfad beantwortet die Vertrauenspolitik. Die Partnerverwaltung beantwortet, ob der Schlüssel heute für Namen X, Richtung Y und Beziehung Z zugelassen ist.

Schlüsseltransport ist noch keine Rollenzuweisung

Abschnitt 9.2 empfiehlt Certificate Exchange Messaging und verweist auf den CEM-Entwurf. Ohne CEM muss der manuelle Austausch Integrität und Authentisierung vor Aktivierung sichern. Ein Well-Known URI darf dem Erstabruf dienen, sofern der Anfragende authentisiert und sein Zugriff autorisiert ist.

Für selbstsignierte Zertifikate ist zusätzlich eine Bestätigung des Fingerabdrucks über einen sicheren Nebenkanal erforderlich. Die Ausstellersignatur schützt vor unbemerkter Veränderung; sie wählt nicht den richtigen Partnerdatensatz.

Der Aktivierungsbeleg sollte genaue Schreibweise, Beziehung, Richtung, Zweck, Fingerabdruck, Seriennummer, Algorithmus, Laufzeit, Vertrauensmethode, Herkunft, Genehmiger, Zeitpunkt, Überlappung und Rückfall enthalten. Abgelaufene, widerrufene oder nicht vertrauenswürdige Zertifikate müssen sofort sichtbar scheitern. Ein gültiges Zertifikat kann dennoch lokal falsch zugeordnet sein.

Der Empfangsnachweis wählt seinen Prüfschlüssel nicht selbst

Der Sender behält Nachricht, Message-ID und MIC. Er prüft Signatur, Original-Message-ID und zurückgegebenen MIC des MDN. RFC 8098 ist der aktuelle MDN-Rahmen.

Der Entwurf nennt das verifizierte Ergebnis „non-repudiation of receipt“. Daraus folgt hier kein allgemeines Rechtsurteil. Ebenso bleibt die bereits veröffentlichte Trennung von Zustellung und geschäftlicher Annahme außerhalb dieser These. Hier geht es vorher um die Autorität des Prüfschlüssels.

Die Beweiskette lautet: HTTP/TLS; AS2-Namen; Zertifikatsprüfung; lokale Partnerautorisierung; Signatur; Message-ID/MIC; MDN-Disposition; EDI-Annahme; Geschäftsergebnis. Keine Stufe darf die nächste darstellen.

Die Revision 03 enthält bereits wesentliche Zertifikatsregeln. Revision 04 kodifiziert sie aktuell, hat sie aber nicht sämtlich neu erfunden. HTML und XML belegen Struktur, keine Implementierung.

Quellen und Grenzen

Verwendet werden Text, HTML und XML der Revision 04; Datatracker-Seite, API und Historie; Revision 03; RFC 4130, RFC 8098, RFC 8551, RFC 8615, RFC 5652, RFC 5280, CEM-Entwurf, RFC 9110, RFC 9525 und RFC 8446. Die Führungsanalyse greift gesondert auf Lu Hengs Texte über Vorrang laufenden Codes, Realitätsebenen und minimale Anfangsspezifikation zurück. Die Quellen belegen kein Produkt, Ereignis, keinen Angriff und kein Urteil.