Zusammenfassung

  • Revision 21 definiert einen reversibel zu DER wandelbaren C509-Typ und einen nativ über CBOR signierten Typ.
  • Erfolgreiches Dekodieren und Prüfen der Signatur schafft noch kein Vertrauen: RFC-5280-Pfadprüfung bleibt Pflicht, COSE-Zertifikatsmaterial bleibt nicht vertrauenswürdige Eingabe.
  • Ein IANA-Codepunkt benennt Syntax; er empfiehlt keinen Algorithmus und erteilt keine lokale Freigabe.

Der Prüfbeleg muss das signierte Objekt nennen

Typ 3 ist eine invertierbare CBOR-Neucodierung eines DER-X.509-Zertifikats. Der Empfänger rekonstruiert das originale DER und prüft dessen Signatur. Typ 2 signiert TBSCertificate direkt in CBOR. Beide können dieselbe X.509-Semantik tragen, doch ihre Belege unterscheiden sich: rekonstruiertes DER hier, kanonische CBOR-Bytes dort. „C509 gelesen“ verschweigt diese Identität.

Kompaktheit entsteht durch entfernte statische und redundante Felder, kurze Integer statt vieler OIDs sowie kleinere Zeit- und Kurvendarstellungen. Das ist eine Aussage über Darstellung und Transport. Sie beweist weder aktuelle Schlüsselgewalt noch Ausstellerbefugnis, Gültigkeit, Zweck oder Anwendungsfreigabe.

Der Entwurf verlangt weiterhin die Pfadvalidierung aus Abschnitt 6 von RFC 5280. Vertrauensanker, CA-Beschränkungen, Zeit, Namen, Richtlinien, kritische Erweiterungen und Zweck müssen geprüft werden. Eine gültige Signatur ist ein Integritätsbeleg, nicht das ganze Vertrauensurteil.

COSE darf seinen eigenen Root nicht ernennen

c5b, c5c, c5t und c5u transportieren Zertifikate oder Verweise, bleiben aber nicht vertrauenswürdige Eingabe. Ein dort empfangenes selbstsigniertes Zertifikat darf den Ankersatz nicht ohne eigene Autorisierung erweitern. Ein geschützter COSE-Header authentisiert den Behälter; er verleiht dem Inhalt keine Root-Befugnis.

Medientypen, CoAP-Formate, TLS-Zertifikatstyp und TLSA-Selektor schaffen interoperable Bezeichnungen. Sie ersetzen weder DNSSEC und DANE-Regeln noch Dienstidentität oder Anwendungspolitik.

Der Entwurf betont, dass IANA-Registrierung keine Empfehlung ist. Veraltete Algorithmen können Codes erhalten, damit bestehende Zertifikate darstellbar bleiben. Im TLS-Register steht C509 Certificate unter Wert 4 mit Recommended = N. N ist kein Mangelurteil, aber auch keine allgemeine Aktivierung. Bedeutung, Reife, Empfehlung und lokale Erlaubnis sind getrennt.

Eine Größentabelle ist kein Betriebsnachweis

Bei manchen profilierten IoT-Zertifikaten spart C509 deutlich. Brotli kann zusätzlich Wiederholungen einer ganzen Kette nutzen. Bei FN-DSA und ML-DSA dominieren nahezu zufällige Schlüssel und Signaturen; beide Verfahren sparen wenig. Daraus folgt weder Energie-, Latenz- noch Interoperabilitätsgewinn in einem benannten Netz.

Ein Gateway kann C509 für einen alten Server in X.509 zurückwandeln. Der Entwurf warnt, dass dieser Aufbau unverschlüsselte Zertifikate erfordert und Identitätsschutz verletzen kann. Ende-zu-Ende verschlüsselte Zertifikate brauchen Endpunktunterstützung. Konversionstreue, Parsersicherheit und Vertrauen bleiben eigene Kontrollen.

Revision 21 erschien am 24. September 2026. Sie ist IESG-genehmigt, in der RFC-Editor-Warteschlange und wartet derzeit blockiert auf Autorenrückmeldung. Das ist Publikationsstatus, keine RFC-Nummer, technische Ablehnung oder Einführungsmessung.

Quellen