Zusammenfassung

  • Revision 03 eines am 14. September veröffentlichten LAMPS-Arbeitsgruppenentwurfs würde RFC 5652 aktualisieren und id-data bei neuen Nutzungen von CMS SignedData verbieten.
  • Ob eine Nutzung neu ist, richtet sich danach, wann eine Spezifikation erstmals die Erzeugung oder Verarbeitung für eine Anwendung festlegt: ab Veröffentlichung des künftigen Dokuments, nicht ab Implementierung oder Inbetriebnahme.
  • Für bestehende Nutzungen sieht der Entwurf Migrations- und Prüfregeln statt desselben absoluten Verbots vor, weil ein pauschaler Bruch die Interoperabilität mit eingesetzten Sendern gefährden kann.
  • Es handelt sich um einen aktiven Entwurf mit dem angestrebten Status Best Current Practice, nicht um einen RFC, eine beschlossene Regel, einen Exploit-Nachweis oder den Beleg für ein verwundbares Produkt.

Eine Grenze, deren Datum noch aussteht

Revision 03 ergänzt Kopf und Zusammenfassung um eine klare Aussage. Im Fall ihrer Annahme würde sie RFC 5652, den geltenden Standard für Cryptographic Message Syntax, aktualisieren: Neue Nutzungen von CMS SignedData dürften den Inhaltstyp id-data nicht verwenden.

Entscheidend ist die neue Definition. Als neu gilt eine Nutzung, wenn eine Spezifikation am oder nach dem Veröffentlichungsdatum des künftigen Dokuments erstmals beschreibt, wie SignedData für eine Anwendung erzeugt oder verarbeitet wird. Ob diese spätere Spezifikation selbst ein RFC ist oder einen Inhaltstyp bei IANA registriert, spielt für die Einordnung keine Rolle. Was vor dem Stichtag liegt, gilt als bestehende Nutzung.

Das ist eine scharfe formale Linie, allerdings eine prospektive. Der Datatracker-Eintrag führt das Dokument als aktiven Internet-Draft einer Arbeitsgruppe mit angestrebtem BCP-Status. RFC 2026 beschreibt Internet-Drafts ausdrücklich als Arbeitsdokumente. Revision 03 kann die Prüfung heute lenken, ändert STD 70 durch ihre Veröffentlichung als Entwurf aber noch nicht.

Spezifikationszeit ist nicht Einsatzzeit

Der offizielle Versionsvergleich bringt zwei Uhren ins Spiel, die nicht zusammengelegt werden sollten.

Die Definition ordnet eine Nutzung nach ihrer ersten Spezifikation ein. Ein anderer Satz erklärt, dass das Verbot für neue Nutzungen die Konformität bereits eingesetzter Implementierungen nicht rückwirkend verändert. Beides lässt sich miteinander vereinbaren, bezeichnet aber unterschiedliche Belege. Ein Protokoll kann spezifiziert sein, ohne weit verbreitet zu sein. Software kann lange nach ihrem maßgeblichen Text ausgeliefert werden. Und ein alter Sender kann weiterlaufen, nachdem eine Nachfolgespezifikation erschienen ist.

Der Entwurf veröffentlicht keine Bestandsaufnahme, die diese Zustände miteinander verbindet, und behauptet das auch nicht. Seine Anhänge nennen RFCs mit id-data und untersuchen die Anwendbarkeit. Eine RFC-Referenz misst jedoch keine installierte Basis. Ebenso belegt ein IANA-Eintrag einen Bezeichner und seine Referenz, nicht aber den ausgeführten Codepfad, die Durchsetzung von signedAttrs beim Empfänger oder die Verwendung desselben Signaturschlüssels in mehreren Protokollen.

Für die Sicherheitsfrage zählt das Verhalten. RFC 5652 erlaubt, signedAttrs wegzulassen, wenn der gekapselte Inhaltstyp id-data ist. Der Entwurf erläutert, wie dadurch eine Signatur über eine Struktur erfolgreich geprüft werden kann, die der Unterzeichner nicht ausdrücklich signieren wollte. Er benennt zugleich Grenzen: Manche Protokolle schreiben signierte Attribute vor; korrekte Empfängerprüfungen können den Angriff verhindern; die Nachrichtenform kann die Anwendbarkeit einschränken; weitere Gegenmaßnahmen sind möglich. „Bestehend“ bedeutet daher nicht „verwundbar“, und „neu“ beweist keine sichere Implementierung.

Kompatibilität gehört zur Regel

Für neue Nutzungen lautet die Vorgabe in Revision 03: id-data MUST NOT verwendet werden. Bei MIME-Inhalten soll SHOULD der vorgeschlagene Typ mimeData zum Einsatz kommen, sofern kein zweckgebundener Inhaltstyp besser begründet ist. Der Entwurf ersucht IANA um Modul- und Inhaltstypkennungen, doch deren Werte stehen noch auf TBD. Die derzeitigen Register für SMI Numbers und CMS Inner Content Types machen aus einem Platzhalter noch keine Zuweisung.

Für bestehende Nutzungen gilt ein anderer Weg. Wird ein solches Protokoll aktualisiert, sollte es id-data außer Gebrauch setzen. Behält die neue Fassung den Typ, verlangt der Entwurf eine Begründung, damit Prüfer die Sicherheitsabwägung nachvollziehen können. Eine rückwärtskompatible Erweiterung kann der falsche Moment für einen erzwungenen Bruch sein; eine Hauptversion oder eine ohnehin inkompatible Änderung kann ein geeigneteres Migrationsfenster öffnen.

Das ist keine versteckte Ausnahme, sondern eine offen formulierte Interoperabilitätsentscheidung. Bereits eingesetzte Sender erzeugen signedAttrs womöglich nicht so, wie es eine verschärfte Regel erwartet. Ein universelles MUST könnte dazu führen, dass neue Empfänger legitimen alten Verkehr zurückweisen, bevor es einen Übergangspfad gibt. Das Governance-Problem besteht nicht darin, dass Ermessen bleibt. Es besteht darin, nachvollziehbar zu machen, wo es ausgeübt wurde, mit welchen Belegen und bis zu welcher nächsten Entscheidung.

Schlüssel und Anwendungen erweitern die Kontrollfläche

Revision 03 fügt einen Abschnitt zur Schlüsseltrennung hinzu. Signierte Attribute in einem Protokoll zu verlangen reicht nicht aus, wenn derselbe Signaturschlüssel auch in einem anderen Protokoll oder einer älteren Version ohne diese Pflicht genutzt wird. Der Entwurf verweist auf getrennte Schlüssel oder auf eine Gegenmaßnahme, die einheitlich für alle Signiervorgänge mit diesem Schlüssel gilt.

Auch für allgemeine CMS-Bibliotheken zieht er eine Zuständigkeitsgrenze. Bei neuen Nutzungen müssen der erwartete Inhaltstyp und das Vorhandensein der vorgeschriebenen signierten Attribute geprüft werden. Kann die Bibliothek keine protokollspezifische Regel durchsetzen, muss sie den empfangenen Inhaltstyp an die Anwendung weitergeben, damit dort entschieden wird.

Spezifikationsautoren wählen Typ und Übergang. Bibliotheksentwickler erhalten Informationen und Prüfpunkte. Anwendungsverantwortliche setzen die Protokollerwartung durch. Schlüsselverwalter bestimmen, ob ein Schlüssel alte und neue Kontexte verbindet. IANA registriert Kennungen. Kein einzelner Akteur kann belegen, dass die gesamte Kette sicher migriert ist.

Übergangsinventar statt Pauschalurteil

Ein knappes öffentliches Inventar könnte den Stichtag prüfbar machen. Für jede bekannte Nutzung von CMS SignedData würde es festhalten: erste Spezifikation samt Datum; Inhaltstyp und vorgeschriebenen Zustand von signedAttrs; Art der Einsatzbelege, ohne unbekannte Mengen vorzutäuschen; mögliche Schlüsselwiederverwendung zwischen Protokollen oder Versionen; nächste realistische Gelegenheit für einen inkompatiblen Wechsel; Begründung für Beibehaltung oder Ersatz von id-data; sowie Spezifikationsverantwortliche, nächsten Prüftermin und Korrekturhistorie.

Dieses Register ist ein Vorschlag von Daniel Kade, keine Anforderung des Entwurfs. Es würde alte Nutzungen nicht pauschal als unsicher bezeichnen. Stattdessen ließe sich eine ältere Spezifikation mit verpflichtender Prüfung von einem Altbestand mit unbekanntem Verhalten und von einer neuen, der künftigen Regel unterliegenden Spezifikation unterscheiden.

Das Publikationsdatum kann die formale Grenze bleiben. Das Inventar liefert die operative Karte dazu.

Quellen