Zusammenfassung

  • draft-ietf-lamps-rfc6211-update-01 korrigiert die in RFC 6211 gedruckte OID 1.2.840.113549.1.9.52 zu 1.2.840.113549.1.9.16.2.52, dem seit jeher bei IANA registrierten Wert für id-aa-cmsAlgorithmProtect.
  • Eine belastbare Migration unterscheidet Erkennen, Beobachten, Vertrauen und Erzeugen. Ein Register für Bezeichnervorrang und Kompatibilitätsabbau hält fest, welche Altdaten lesbar bleiben, welche neuen Ausgaben verboten sind und wann Ausnahmen enden.

Ein Fehler zwischen zwei offiziellen Wahrheiten

Das IANA-Register für S/MIME-Attribute liegt unter 1.2.840.113549.1.9.16.2; Eintrag 52 heißt id-aa-cmsAlgorithmProtect. RFC 6211 ließ in der Definition und im ASN.1-Modul die Zweige 16.2 aus. So entstand die kürzere Folge 1.2.840.113549.1.9.52.

Die Zahlen sind keine zwei Schreibweisen desselben Namens. Sie kennzeichnen unterschiedliche Objekte. Die Autoren des neuen Entwurfs kennen nach eigener Aussage zwei RFC-6211-Implementierungen, die deshalb nicht interoperierten: Die eine folgte der RFC, die andere dem Register.

Mehr belegt der Entwurf nicht. Er nennt weder eine Zahl betroffener Produkte noch einen Angriff oder einen flächendeckenden Ausfall. Diese Begrenzung ist wichtig. Zugleich reicht der dokumentierte Fall aus, um eine Annahme zu widerlegen: Ein richtiges Zentralregister sorgt nicht automatisch dafür, dass alle ausgelieferten Systeme den richtigen Wert verwenden.

Ein Entwickler handelt plausibel, wenn er das ASN.1-Modul einer RFC kompiliert. Ein anderer handelt ebenso plausibel, wenn er die Zuteilung bei IANA prüft. Führen beide Wege zu verschiedenen Bytes, liegt die Verantwortung nicht nur beim letzten Programmierer, sondern auch in der Verbindung zwischen Register, Normtext und ausführbarem Artefakt.

Der Schutz muss zunächst erkannt werden

CMS transportiert signierte, authentifizierte und verschlüsselte Inhalte. RFC 6211 führte ein Attribut ein, das die beim Verarbeiten verwendeten Algorithmenbezeichner an die geschützte Nachricht bindet. Dadurch soll eine Algorithmussubstitution erschwert werden: Ein Angreifer darf nicht unbemerkt Algorithmus oder Parameter verändern und damit das Prüfergebnis beeinflussen.

Der Empfänger muss das Attribut jedoch finden, bevor er seinen Schutz bewerten kann. Kennzeichnet der Erzeuger es mit einer OID und sucht der Prüfer nach der anderen, können beide schon über die Anwesenheit des Schutzes uneins sein. Der Aktualisierungsentwurf hält deshalb fest, dass der Mechanismus ohne dieselbe ASN.1-OID bei allen Implementierungen nicht erfolgreich ist.

Daraus folgt nicht automatisch eine ausnutzbare Schwachstelle in einem bestimmten Produkt. Parser können ein Objekt ablehnen, ein unbekanntes Attribut ignorieren oder zusätzliche lokale Regeln anwenden. Die gesicherte Aussage ist enger: Der codierte Name eines Sicherheitsmechanismus gehört zum Mechanismus und verlangt überprüfbares, gemeinsames Verhalten.

Das Modul hatte operative Autorität

Standards werden auf verschiedenen Ebenen konsumiert. Ein Entscheider liest die Beschreibung. Ein Entwickler kopiert das Modul. Ein Generator übersetzt es in Datentypen und Konstanten. Tests fixieren die erzeugten Bytes, Bibliotheken tragen sie in langlebige Produkte.

IANA besaß die Zuteilungsautorität, die RFC die normative Autorität und das Modul eine besondere Verbreitungsmacht innerhalb automatisierter Werkzeugketten. Die Korrektheit des Registers konnte eine bereits kompilierte Definition nicht überschreiben.

Revision 01 behebt noch eine zweite Trennung zwischen Prosa und Maschine. RFC 6211 verlangte im Text, dass die Attributmenge nur eine Instanz des Schutzattributs enthält. Die neue Definition ergänzt COUNTS MAX 1. Damit steht die Begrenzung nun dort, wo geeignete Werkzeuge sie prüfen können.

Das macht Schemas nicht unfehlbar. Ein falsches Schema vervielfältigt Fehler besonders effizient. Registereintrag, normativer Text, ASN.1-Modul, Beispiele und Konformitätsvektoren müssen daher als zusammengehörige Veröffentlichung geprüft werden.

Berichtigung und installierte Basis laufen getrennt

Die Errata 9144 und 9145 wurden am 19. August 2026 für Anhang A und Abschnitt 2 gemeldet. Am 13. September standen beide noch auf Reported; gemeldet ist nicht dasselbe wie verifiziert. Auch der Entwurf ist laufende Arbeit. Revision 00 ging am 1. September in den Working Group Last Call der LAMPS-Gruppe, Revision 01 wurde am 9. September UTC eingestellt.

Diese Schritte klären den gemeinsamen Dokumentbestand. Sie ändern keine alte Bibliothek, kein schwer aktualisierbares Gerät und kein signiertes Archivobjekt. Der Abschluss einer dokumentarischen Korrektur und die Konvergenz einer installierten Basis brauchen getrennte Statusangaben.

Eine Organisation kann vorher handeln. Sie sollte eine solche Maßnahme als lokale, überprüfbare Politik auf Grundlage des aktuellen Sachstands ausweisen, nicht als vorweggenommenen IETF-Konsens. So bleibt die Entscheidung beweglich, falls sich der Entwurf ändert.

Lesen ist nicht Vertrauen, Vertrauen ist nicht Senden

„Wir unterstützen beide OIDs“ beschreibt keinen eindeutigen Zustand. Ein Archivleser kann den alten Wert erkennen, um ein historisches Objekt zu erläutern. Ein Gateway kann ihn erfassen und dem Erzeuger zuordnen. Ein Prüfer kann ihn decodieren, aber nicht als Erfüllung einer Schutzanforderung anerkennen. Ein neuer Erzeuger kann Altdaten lesen und zugleich am Senden des falschen Werts gehindert werden.

Erkennen, Messen, Akzeptieren und Erzeugen brauchen getrennte Schalter. Stille Doppelakzeptanz kann eine Übergangslösung in einen dauerhaften zweiten Namensraum verwandeln. Sofortige globale Ablehnung kann dagegen Beweismaterial unlesbar machen oder Systeme abschneiden, die nicht gleichzeitig aktualisiert werden können.

Ein vernünftiger Übergang ist asymmetrisch: Zuerst endet die neue Ausgabe des alten Werts. Die Erkennung bleibt befristet aktiv, um Restquellen zu messen. Verantwortliche sanieren die Erzeuger; Leseregeln werden nach Zweck und Risiko enger. Eine unsichtbare Umschreibung ist zu vermeiden, denn bei signierten Objekten kann sie Herkunft und Gültigkeit zerstören.

Das Vorrang- und Stilllegungsregister

Die Organisation braucht ein knappes Betriebsregister für diesen Konflikt. Am Anfang stehen beide vollständigen OIDs, ihre Quellen und eine lokale Vorrangentscheidung. Die registrierte S/MIME-OID ist das Ziel für neue Ausgaben; der kurze Wert erhält einen klaren Altstatus und einen Prüftermin.

Danach folgen die tatsächlichen Komponenten: Signaturdienst, Validator, S/MIME-Gateway, Hardwaremodul, Archivleser, Analysewerkzeug und Dienst zur erneuten Serialisierung. Für jede Version wird vermerkt, was sie erkennt, was sie als gültigen Schutz anerkennt, was sie erzeugt und ob sie beim Lesen und Schreiben die Originalbytes bewahrt.

Ein kleiner Prüfkorpus macht aus Behauptungen Belege. Er enthält ein Objekt mit jeder OID, eines ohne Schutzattribut, eines mit zwei Instanzen und Fälle, in denen die genannten Algorithmen nicht zur umgebenden CMS-Struktur passen. Ergebnis, Objekthash, Software- und Richtlinienversion gehören zusammen. Auch COUNTS MAX 1 wird zur Laufzeit geprüft, weil nicht jede Bibliothek jede Schemaeinschränkung automatisch durchsetzt.

Der Stilllegungsplan stoppt zuerst neue Altproduktion. Danach misst er den Rest je Erzeuger. Ausnahmen haben Eigentümer, Grund und Enddatum. Historische Objekte bleiben bytegenau erhalten; externe Metadaten können ihren Status erklären. Erst wenn Messungen zeigen, dass Altproduktion beendet oder verantwortlich isoliert ist, wird endgültige Ablehnung vertretbar.

Jede Reparatur braucht Herkunft

Ein Umsetzungsnachweis sollte fünf Fragen beantworten: Welche Quelle legt die Ziel-OID fest? Welches Modul oder welche Konstante wurde geändert? Welcher Test belegt die neuen Bytes? Wie werden bestehende Objekte behandelt? Wer hat das Ende des Kompatibilitätsfensters beschlossen?

Ohne diese Angaben kann „RFC 6211 korrigiert“ nur einen geänderten Sender und einen beschädigten Archivleser bedeuten. Es kann eine ewige Doppelakzeptanz bei fortgesetzter Fehlerproduktion bezeichnen. Oder es verdeckt eine Umschreibung gespeicherter Objekte, durch die alte Signaturen nicht mehr erklärbar sind.

Private Schlüssel und Nachrichteninhalte gehören nicht in den Nachweis. Hashes der Prüffälle, Versionen, Ergebnisse, Ausnahmeverweise und Entscheidungsdaten genügen. Dokumentiert wird der Weg der Autorität, nicht vertraulicher Inhalt.

Die gemeinsame Spezifikation darf klein bleiben

Der IETF-Entwurf muss nicht für jedes Archiv und jedes eingebettete Gerät dieselbe Übergangsfrist setzen. Die gemeinsame Ebene soll eine OID, eine Kardinalitätsregel und deren Sicherheitsbedeutung klären. Langzeitarchive und nicht aktualisierbare Systeme können dort entschieden werden, wo Kosten und Risiken anfallen.

Das entspricht Heng Lus Prinzip einer minimalen Anfangsspezifikation mit lokalisierten späteren Entscheidungen. Das gemeinsam Notwendige sichert Interoperabilität. Lokale Übergänge dürfen Kosten verteilen, aber weder die gemeinsame Bedeutung auf dem Draht ändern noch eine Ausnahme zur zweiten globalen Norm erklären.

Der Policy Mirror verlangt sprachliche Genauigkeit. „IANA führt den richtigen Wert“, „dieser Leser erkennt den alten“, „diese Richtlinie vertraut ihm“ und „dieser Erzeuger sendet den neuen“ sind vier Aussagen. Das grüne Feld „RFC-6211-Unterstützung“ ist kein Ersatz dafür.

Das richtige Register zeigt das Ziel. Repariert ist die Abweichung erst, wenn Module, Produkte, Tests und der Umgang mit historischen Bytes nachweisbar dorthin gelangt sind.

Quellen