Zusammenfassung

  • Die COSE-Arbeitsgruppe reichte am 24. September 2026 Fassung 21 ihres C509-Entwurfs ein. Fassung 20 war im Juli von der IESG gebilligt worden; das Dokument steht weiterhin in der Warteschlange des RFC Editors und ist noch kein veröffentlichter RFC.
  • Die neue Fassung grenzt die zu signierende CBOR-Sequenz deutlicher ab, verlangt für Seriennummern eine Bytefolge und erlaubt die gekürzte Ausstellerangabe nur bei oktettgenauer Übereinstimmung mit dem Subjekt.
  • Typ 3 übernimmt die Signatur eines reversibel umkodierten DER-Zertifikats; Typ 2 signiert CBOR selbst. Das sind unterschiedliche Prüfpfade, die beide eine X.509-Pfadvalidierung benötigen.

Ein Betreiber kann einen kleineren Zertifikatsdatensatz erfolgreich übertragen und dennoch an der entscheidenden Frage vorbeigehen: Was hat der Aussteller unterschrieben? Beim Wechsel zwischen DER und CBOR genügt es nicht, nachher denselben lesbaren Namen und denselben öffentlichen Schlüssel zu sehen. Die Signatur bindet eine definierte Bytefolge; erst ein passender Prüfpfad und die lokalen Vertrauensregeln machen aus einem dekodierten Objekt ein akzeptiertes Zertifikat.

Hier setzt die Änderung vom 24. September an. Der Entwurf bezeichnet C509Certificate nun ausdrücklich als CBOR-Array und seine Elemente als Sequenz. Die Gruppe TBSCertificate ohne den abschließenden Signaturwert bildet die zu signierende Teilsequenz. Die Präzisierung grenzt eine Schnittstelle für Implementierungen ab. Sie ist kein Bericht über einen gefundenen Fehler, keine neue Angriffsmeldung und kein Beleg dafür, dass vorhandene Produkte die Regeln bereits einhalten.

Gerade die unscheinbaren Kodierungsdetails zeigen, weshalb Reversibilität eine überprüfbare Eigenschaft sein muss. Eine Seriennummer wird in C509 auch dann als CBOR-Bytefolge kodiert, wenn ihr Wert als kleine vorzeichenlose Zahl darstellbar wäre. Bei der Rückwandlung eines Typ-3-Zertifikats in DER muss gegebenenfalls eine führende Null ergänzt werden, damit das höchste Bit nicht die Ganzzahlinterpretation verändert. Die kurze null-Darstellung des Ausstellers ist nur zulässig, wenn Aussteller und Subjekt Oktett für Oktett identisch sind. Ähnlich aussehende Namensanzeigen erfüllen diese Bedingung nicht.

Aus diesen Regeln folgen keine austauschbaren Zertifikatstypen. Typ 3 nimmt ein bereits in DER signiertes X.509-Zertifikat, kodiert es umkehrbar um und transportiert dessen ursprüngliche Signatur. Eine Vertrauensfunktion kann diese Umkodierung nach der Ausstellung ausführen; zur Prüfung lässt sich DER rekonstruieren. Typ 2 wird dagegen über die CBOR-Darstellung signiert. Das kann in einer kontrollierten Umgebung ASN.1-Verarbeitung vermeiden, setzt jedoch Prüfer voraus, die diesen nativen Signaturpfad beherrschen. Eine reine DER-Implementierung versteht Typ 2 nicht allein deshalb, weil beide Typen X.509-Semantik beanspruchen.

Auch der Verfahrensstand ist eng zu lesen. Am 20. Juli billigte die IESG Fassung 20. Die jetzt vorliegende Fassung 21 befindet sich im RFC-Editor-Prozess; laut Datatracker sind Autorenangaben und IANA-Schritte weiterhin offen. Daraus wird weder ein neuer RFC noch eine abgeschlossene Registrierung oder ein Nachweis breiter Einführung. Die Größenbeispiele im Entwurf illustrieren mögliche Einsparungen, nicht den Zustand der installierten Infrastruktur.

Die Sicherheitsgrenze verläuft zudem nicht am Ende des Komprimierers. Der Entwurf hält an der Pfadvalidierung nach RFC 5280 fest; COSE-Zertifikats-Header sind zunächst nicht vertrauenswürdig. Eine IANA-Kennung empfiehlt auch keinen Algorithmus. Für einen Betreiber wäre deshalb ein Prüfprotokoll sinnvoll, das Zertifikatstyp, Umkodierungsstand, konkrete signierte Testbytes, DER-Rückbau und unterstützte Prüfer zusammenführt. Das ist eine redaktionelle Handlungsempfehlung, keine neue Vorgabe der Arbeitsgruppe.

Quellen