Zusammenfassung

  • RFC 5402 erlaubt, den inneren MIME-Inhalt vor der Signatur zu komprimieren oder die fertige multipart/signed-Struktur danach zu komprimieren; beides zugleich ist verboten.
  • Bei signierten Nachrichten wird der zurückgesandte MIC über dieselben Daten berechnet, die signiert wurden, und kann deshalb eine komprimierte oder unkomprimierte Darstellung bezeichnen.
  • Ein revisionsfähiges System muss Schichten, Bytebereiche und Transformationen exportieren; die spätere Geschäftsannahme bleibt ein eigener Nachweis.

Gleiche Bedeutung, anderer kryptografischer Gegenstand

Die Fachabteilung sah in beiden Fällen dieselbe Bestellnummer, Menge und Lieferadresse. Für sie waren die Dokumente identisch. Die Kryptografie beantwortete aber eine andere Frage: Welche konkrete Bytefolge war im Moment der Signatur vorhanden?

RFC 5402 fügt EDIINT-Nachrichten für AS1, AS2 und AS3 eine CMS-Kompressionsschicht hinzu. Solche Nachrichten können bereits Nutzinhalt, Signatur und Verschlüsselung enthalten. Eine zusätzliche reversible Transformation erzeugt mehrere zulässige Darstellungen und verändert die Reihenfolge der Prüfungen.

Das Dokument erschien im Februar 2010 im Independent Stream als Informational. Der IESG-Hinweis sagt ausdrücklich, dass es keine Internet-Standards-Track-Spezifikation und kein Kandidat für eine Standardstufe ist. Diese Einordnung verhindert, dass eine veröffentlichte Regel mit einer universellen Implementierungszusage verwechselt wird.

Zwei zulässige Bäume

Im ersten Baum wird der innerste MIME-Teil mit ZLIB komprimiert und als CMS CompressedData verpackt. Danach signiert der Sender diese komprimierte Entität. Im zweiten Baum signiert er den MIME-Inhalt zuerst und komprimiert anschließend das gesamte multipart/signed.

RFC 5402 untersagt, beide Varianten im selben Dokument anzuwenden. Der Empfänger muss jedoch beide empfangen und entpacken können. Die Einschränkung verhindert eine unklare doppelte Kompression, während die Empfängerpflicht Interoperabilität zwischen den beiden vorgesehenen Formen schafft.

Für signierte Nachrichten folgt der zurückgegebene MIC exakt den ursprünglich signierten Daten. Im ersten Baum bezeichnet er daher die komprimierte Entität, im zweiten den unkomprimierten MIME-Inhalt. Ein Feld payload_digest ohne Stufenname verliert diese Unterscheidung.

Forensisch braucht jeder Baum seine eigene Kette: Quell-MIME, Canonicalization, komprimierte CMS-Bytes, signierter Bereich, gegebenenfalls verschlüsselter Bereich und Transportdarstellung. Der lesbare Endinhalt ist wichtig, aber kein Ersatz für die Bytefolge, auf die sich Signatur und MIC beziehen.

Transfer-Encoding wandert nach außen

Komprimierte Binärdaten benötigen base64 Content-Transfer-Encoding, wenn sie in der äußeren Schicht über ein Sieben-Bit-Protokoll wie SMTP laufen. Liegt die Kompressionsschicht innerhalb einer Verschlüsselung, braucht nicht der innere komprimierte Teil, sondern der äußere verschlüsselte Teil die Transfercodierung.

Damit entstehen weitere Darstellungen. Eine Zeilenumwandlung in base64 kann die Transportform verändern, ohne den dekodierten Inhalt zu ändern. Ein Abbruch kann die äußere Darstellung beschädigen, bevor Dekompression überhaupt beginnt. Nur stufenbezogene Hashes lokalisieren den Fehler.

Bei komprimierten, nicht signierten Nachrichten verlangt RFC 5402 den MIC über den unkomprimierten Inhalt einschließlich MIME-Headern und angewandtem Content-Transfer-Encoding. RFC 4130 ergänzt Canonicalization-Regeln für AS2. Ein Hash über die im Browser angezeigte XML-Datei kann deshalb die falsche Frage beantworten.

Die Wiederholung muss dieselben Header, Grenzen, Zeilenenden und Transformationsschritte verwenden. Andernfalls wird eine Abweichung der Rekonstruktion als Abweichung der ursprünglichen Nachricht missverstanden.

Selbst der Algorithmus hat eine Darstellungsvariante

RFC 5402 schreibt ZLIB-Unterstützung vor; ZLIB verwendet DEFLATE. RFC 3274 definiert den CMS-Inhaltstyp und den Algorithmusbezeichner. Unterschiedliche Kompressionsstufen sind dekompressionskompatibel und müssen nicht als Parameter übertragen werden.

Historisch existieren dennoch zwei AlgorithmIdentifier-Formen. Das Parameterfeld kann fehlen oder als ASN.1 NULL kodiert sein. RFC 3274 empfiehlt das Weglassen, warnt aber, dass Implementierungen beide Formen antreffen können.

Ein strenger Decoder kann daher trotz eines gemeinsamen ZLIB-Häkchens scheitern. Dazu kommen MIME-Verschachtelung, Größenlimits, Canonicalization, Fehlerabbildung und Partnervereinbarung. RFC 5402 verlangt bei Nutzung der Kompression AS2- oder AS3-Version 1.1 oder höher. Das Versionsfeld ist ein Profilhinweis, kein Ausführungsbeleg.

Ein belastbares Inventar trennt angekündigte Fähigkeit, vertragliche Freigabe, aktive Konfiguration und beobachtete Verarbeitung. Diese Zustände dürfen sich nicht gegenseitig grün färben.

Ein signierter Fehler grenzt die Ursache ein

Scheitert die Dekompression und wurde ein Beleg angefordert, enthält der signierte MDN nach RFC 5402 Error: decompression-failed. Nach erfolgreicher Signaturprüfung ist dies eine zurechenbare Aussage des Empfängers: Er konnte die Kompressionsschicht nicht rückgängig machen.

Es ist keine fachliche Ablehnung der Bestellung. Der Empfänger könnte den Inhalt nie erreicht haben. Der Fehler beweist auch nicht allein, dass die Quelle des Senders falsch war; Beschädigung, lokale Grenzwerte oder Interpretationsunterschiede bleiben möglich.

RFC 4130 verlangt einen signierten Beleg selbst dann, wenn Inhaltsverarbeitung fehlschlägt, und sagt, dass die Transaktion selbst ungültig sein kann. Die Signatur authentifiziert den Bericht. Sie macht aus einem negativen Disposition-Wert keinen Erfolg.

Der richtige Folgeprozess hält die Eingangsbytes und Schichtdaten fest, reproduziert den Fehler und entscheidet dann über erneute Übertragung oder Profilkorrektur. Eine pauschale Übersetzung in „Partner hat abgelehnt“ vernichtet diese Präzision.

Mehrere Anhänge teilen Integrität, nicht Semantik

RFC 6362 erlaubt mehrere Anhänge in multipart/related. Bei komprimierten, nicht signierten Nachrichten deckt der MIC nach transportgerechter Canonicalization den gesamten unkomprimierten Multipart-Körper ab. Weicht er ab, gelten alle Anhänge als ungültig und müssen erneut übertragen werden.

Nach erfolgreicher Integritätsprüfung trennen sich die Wege. XML, PDF und Bild werden extrahiert, typgeprüft und an verschiedene Anwendungen übergeben. Speicherung und Transaktionsverarbeitung bleiben implementierungsabhängig.

Das Datenmodell braucht daher einen Elternbeleg für den gemeinsamen Umschlag und Kindbelege für jeden Content-ID. Der Elternbeleg hält Struktur, MIC und MDN. Jedes Kind hält extrahierten Hash, Parser, Schema, Berechtigung und Geschäftsentscheidung. Ein Gruppen-MIC darf nicht als semantische Freigabe jeder Datei dupliziert werden.

Replay-Fähigkeit ist die eigentliche Portabilität

Eine vollständige Kette beginnt mit Partnervertrag, erwarteter Version und erlaubter Schichtordnung. Sie speichert Quell-MIME, Canonicalization, Algorithmusbezeichner und Parameterform, signierte und verschlüsselte Bereiche. Empfangsseitig folgen Transferdecodierung, Entschlüsselung, Dekompression, Signaturprüfung und MIC-Rezept.

Der MDN fügt seine Signatur, Partnerzertifikat, Original-Message-ID und Disposition hinzu. Erst danach folgen Extraktion, Formatprüfung, Duplikatkontrolle, fachliche Autorität und Annahme.

Die Quellen belegen keine aktuelle Marktverbreitung und keinen konkreten Vorfall. Sie belegen, dass zwei legale Schichtbäume unterschiedliche Replay-Unterlagen benötigen. Wer nur das Enddokument aufbewahrt, besitzt Inhalt, aber keinen vollständigen Beleg.