Zusammenfassung

  • RFC 1991 legte eine Reihenfolge fest: Literaldaten signieren, Signatur und Daten komprimieren, das Ergebnis mit einem Sitzungsschlüssel verschlüsseln, diesen Schlüssel für jeden Empfänger verpacken und optional ASCII Armor hinzufügen.
  • CTB und Längen belegten Struktur; CRC und Schlüsselprüfungen belegten begrenzte Konsistenz. Keiner dieser Befunde authentifizierte automatisch Absender, Auftrag oder Zustellung.
  • Die Dokumentsignatur erfasste definierte Datenbytes, nicht sämtliche sichtbaren Metadaten. Dateiname, vertrauenswürdige Zeit, Personenbindung und Befugnis brauchten eigene Nachweise.

Die Reihenfolge ist Teil der Aussage

PGP erzeugt zunächst eine Signatur und stellt ihr die Literaldaten zur Seite. Wird komprimiert, landen beide in einem komprimierten Paket. Ein einmaliger konventioneller Schlüssel verschlüsselt dieses Paket. Vor den Chiffretext setzt PGP für jeden Empfänger ein Public-Key-Paket mit dem verschlüsselten Sitzungsschlüssel. Erst um das fertige Binärobjekt kann eine druckbare ASCII-Hülle gelegt werden.

Diese Abfolge definiert den Geltungsbereich. Die Signatur entsteht vor Kompression und Verschlüsselung. Nach dem Öffnen prüft der Empfänger eine Beziehung zwischen einem Schlüssel und den wiedergewonnenen inneren Bytes. Die äußere Verschlüsselung erweitert den signierten Bereich nicht; eine korrekte ASCII-Hülle authentifiziert die innere Signatur nicht.

Besonders deutlich wird das beim Literal-Data-Paket. Es trägt Modus, vorgeschlagenen Dateinamen, Zeitangabe und eigentliche Daten. Für eine Dokumentsignatur gehen nur die Literaldaten in den Hash ein. Ein Programm kann alle Felder nebeneinander anzeigen. Es darf daraus nicht folgern, sie seien alle signiert.

Auch unabhängige und verschachtelte Signaturen sind nicht gleich. Eine abgetrennte Signatur wird über eine externe Datei berechnet, ohne die Literal-Headerfelder. Mehrere Signierende können parallel arbeiten. Bei Verschachtelung umfasst eine spätere Signatur auch die frühere. Ein belastbares Protokoll muss daher festhalten, welche Bytes und welche vorausgehenden Signaturen erfasst wurden.

Der CTB liefert eine Karte

Mit dem Cipher Type Byte beginnt die Paketstruktur. Seine Bits nennen den Typ und die Form des Längenfelds. Parser können dadurch Signatur-, Kompressions-, Verschlüsselungs- und Literaldatenpakete unterscheiden und zur nächsten Grenze springen. Eine besondere Längenform für komprimierte Daten reicht bis zum Ende der umgebenden Struktur.

Das ist ein Interoperabilitätsgewinn: Zusammengesetzte Dateien werden schrittweise lesbar. Doch ein gültiger Typ ist nur eine Syntaxaussage. Eine stimmige Länge sagt, dass der Parser die deklarierte Grenze erreicht hat. Beides beweist weder Herkunft noch Vollständigkeit, sichere Algorithmuswahl oder Anwendungsbefugnis.

Die unbestimmte Länge macht die Abhängigkeit sichtbar. Ihr Ende lässt sich nur kennen, wenn die äußere Struktur bekannt ist. Lokales Parserglück und eine falsche Annahme über das Gesamtobjekt können gleichzeitig bestehen.

ASCII Armor war eine Transportanpassung

Binärdaten überstanden nicht jeden damaligen Mailweg. ASCII Armor bildete jeweils drei Bytes auf vier druckbare Zeichen ab und ergänzte Kopf, optionale Felder, Nutzteil, 24-Bit-CRC und Abschluss. Der CRC wurde über die Binärdaten vor der Radix-64-Darstellung berechnet.

Die optische Geschlossenheit verführt zu viel Vertrauen. RFC 1991 trennt Armor-Header ausdrücklich von der Nachricht. Sie können unterwegs geändert werden und sollen keine wichtige Information tragen. Ein unbekannter, korrekt geformter Header wird gemeldet; die Verarbeitung geht weiter.

Ein passender CRC belegt deshalb nur, dass die Zeichenfolge ein zu dieser Fehlerprüfung konsistentes Binärobjekt rekonstruiert hat. Er benennt keinen Absender. Ein Angreifer kann den gesamten Block ersetzen und den CRC neu berechnen. Ob im Inneren eine gültige Signatur liegt, entscheidet eine andere Prüfung.

Schlüsselwahl, Person und Zeit

Am Anfang des konventionellen Chiffretexts stehen Zufallsdaten und wiederholte Prüfbits. Nach dem Entschlüsseln hilft ihr Vergleich, einen falschen Sitzungsschlüssel zu erkennen. Das Public-Key-Paket besitzt zusätzlich eine Prüfsumme über den Datenverschlüsselungsschlüssel. Das sind nützliche Konsistenzsignale, keine Autorisierungsnachweise.

Auch die 64-Bit-Key-ID ist nur ein Suchhinweis. RFC 1991 warnt vor zufälligen oder absichtlichen Kollisionen. Für eine Beweiskette zählen der tatsächlich aufgelöste Schlüssel, alle Kandidaten, die Auswahlregel, Zertifizierungsvertrauen, Widerruf, Kompromittierung und die lokale Berechtigung.

Der normale Signaturzeitpunkt ist gewöhnlich nahe der Erstellung, muss es laut RFC aber nicht sein; Nutzer können ihn wählen. Vertrauenswürdige Zeit erfordert eine gesonderte Notarsignatur über das Signaturpaket. Kryptografische Gültigkeit lässt sich daher nicht ohne Weiteres in Frische oder rechtsverbindlichen Zeitpunkt übersetzen.

Der bleibende historische Wert

Der RFC Editor führt RFC 1991 als Informational-Dokument vom August 1996, später durch RFC 4880 abgelöst. Text, HTML und der IETF-Eintrag belegen die Spezifikation, nicht die lückenlose Praxis jeder damaligen Implementierung.

Der verknüpfte IETF-Verzeichniseintrag dient nur der institutionellen Navigation; er belegt keine Zustimmung der Organisation zu dieser Auslegung.

Lu Hengs Essays über den Vorrang laufenden Codes, minimale Anfangsspezifikation und lokale Entscheidung sowie Realitätsebenen dienen hier als redaktionelle Linse, nicht als historische PGP-Quelle. Ihr Nutzen liegt in der Trennung: Ein technischer Befund soll nur die Realitätsebene vertreten, die er tatsächlich beobachtet.

RFC 1991 bleibt deshalb als Schule enger Zuständigkeit lesenswert. Mehrere präzise Belege ergeben eine Kette — aber erst dann, wenn ihre Grenzen erhalten bleiben.