Summary

  • RFC 2440 definierte viele OpenPGP-Paket-Tags, aber kein reguläres Verfahren für dauerhaft neue Werte: Wechselwirkungen zwischen Funktionen konnten die Sicherheit des Gesamtprotokolls senken.
  • Freie Nummern im Paketkopf waren keine Erlaubnis. Die Werte 60 bis 63 blieben privater oder experimenteller Nutzung vorbehalten; neue Anträge sollten an die Security Area Directors des IESG oder eine zuständige IETF-Arbeitsgruppe gehen.
  • Unbekannte Signatur-Unterpakete wurden gewöhnlich ignoriert. Mit dem Critical-Bit konnte der Unterzeichner einen Fehler einem stillen Bedeutungsverlust vorziehen. Erkennen war nicht Implementieren; ungehashte Metadaten waren kein endgültiger Beleg.
  • Spätere Fassungen machten Register und Prüfwege explizit. Eine zugeteilte Nummer, erfolgreiche Analyse oder gültige Signatur beweist weiterhin weder sichere Zusammensetzung noch Einsatz in der Praxis.

Die freie Stelle entschied nichts

Eine Entwicklerin findet ein ungenutztes Tag in einem OpenPGP-Paket. Zwei neue Clients schreiben den Wert und lesen ihn wieder; der Test besteht. Die Bytes passen hinein. Aber was tut ein älterer Prüfer? Kann eine Aushandlung die Funktion herabstufen? Verändert ein anderes Paket ihre Bedeutung? Bleibt die Signatur mathematisch gültig, wenn die neue Semantik ignoriert wird? Ein lokaler Round-Trip beantwortet keine dieser Fragen.

Genau diese Sorge hielt der IESG-Hinweis in RFC 2440 im November 1998 fest. Das Dokument definierte viele Tags, beschrieb aber keinen normalen Weg, weitere hinzuzufügen. Zwar konnte ein Paketkopf im neuen Format Tags bis 63 darstellen; die Spezifikation warnte dennoch, dass subtile Wechselwirkungen zwischen neuen und bestehenden Funktionen die Gesamtsicherheit deutlich senken könnten. Anträge für neue Werte – etwa für Verschlüsselungsalgorithmen – sollten an die Security Area Directors des IESG oder eine passende Arbeitsgruppe weitergeleitet werden. Die Werte 60 bis 63 blieben privat oder experimentell.

Nummernraum war vorhanden; ein sicheres Erweiterungsverfahren folgte daraus nicht.

OpenPGP war kein Beutel unabhängiger Algorithmen. Pakete werden zu Schlüsseln, Signaturen und verschlüsselten Nachrichten zusammengesetzt. Eine neue Funktion kann verändern, wie alte Software eine Sequenz liest, wie neue Software ein überliefertes Feld deutet oder was ein Empfänger als von einer Signatur abgedeckt versteht. Ein Tag kann syntaktisch verfügbar sein, während seine Wechselwirkungen ungeprüft bleiben. RFC 2440 trennte Kodierfähigkeit von protokollarischer Erlaubnis.

Signaturen machten die Grenze sichtbar

Bei Signatur-Unterpaketen zeigte sich dieselbe Spannung im Kleinen. Ein unbekanntes Unterpaket zu ignorieren, förderte Vorwärtskompatibilität: Ältere Software konnte eine Signatur mit neuen Metadaten weiterverarbeiten. Deshalb empfahl RFC 2440, nicht erkannte Typen zu ignorieren. Doch dieses Schweigen konnte eine Funktion auslöschen, auf die der Unterzeichner angewiesen war.

Bit 7 des Unterpakettyps bot eine Wahl. War ein unbekanntes Unterpaket als kritisch markiert, sollte der Prüfer die Signatur als fehlerhaft behandeln. Der Unterzeichner konnte sichtbares Scheitern einem Akzeptieren unter Bedeutungsverlust vorziehen. Das war keine absolute Garantie: Der Prüfer musste die Regel kennen; und selbst ein erkannter Typ musste nicht implementiert sein. Die Spezifikation unterschied diese Zustände ausdrücklich.

Auch erkannte Daten neben einer gültigen Signatur erhielten nicht automatisch deren Autorität. Unterpakete konnten im gehashten oder ungehashten Abschnitt stehen. RFC 2440 warnte, ungehashte Informationen seien nicht maßgeblich, weil sie nicht Teil der Signatur selbst waren. Ein Leser konnte sie sehen, ein Prüfer sie analysieren – beides machte sie nicht kryptografisch abgedeckt. Vorhandensein, Analyse, Erkennung, Implementierung und Abdeckung blieben getrennte Zustände.

Von der Vorsicht zum Register

RFC 4880, das RFC 2440 2007 ersetzte, schuf ausdrückliche IANA-Register und verlangte IETF-Konsens für neue Pakettypen, die als wesentliche Funktionen galten. Außerdem benannte es Downgrade- und Cross-Grade-Risiken bei Erweiterungen der Änderungsprüfung. Das Verfahren wurde nachvollziehbarer, doch Interoperabilität, Umsetzung und Sicherheitsanalyse wurden keine einzige Checkbox.

RFC 9580 ersetzte 2024 RFC 4880 und behielt unterschiedliche Zuteilungsverfahren bei. Manche OpenPGP-Register nutzen „Specification Required“; für Pakettypen und ausgewählte Versions- oder Identitätsräume gilt das strengere „RFC Required“. Experten sollen erwartete Sicherheitseigenschaften und die Interoperabilität mit bestehenden Implementierungen prüfen. Das ist eine institutionelle Antwort auf die frühere Lücke, kein Beweis, dass jede angenommene Erweiterung überall sicher ist.

Diese Dokumente behaupten weder, jede Erweiterung sei schädlich, noch, alle Implementierer hätten einheitlich gehandelt. Sie zeigen eine präzisere historische Einsicht: In einem Kryptoprotokoll kann neue Bedeutung das Verhalten bestehender Pfade ändern. Eine verfügbare Ganzzahl ist nur eine Adresse im Format. Sie belegt weder Kompatibilität noch kryptografische Abdeckung, Nutzerverständnis oder Betriebssicherheit.

Quellen