Zusammenfassung

  • Die am 30. September vorgelegte Fassung 06 des TLS-Arbeitsgruppenentwurfs zu Trust Anchor Identifiers senkt die zulässige Länge einer binären Kennung von 255 auf 32 Byte. Auch der TLS-Datentyp TrustAnchorID reicht nun von einem bis 32 Byte. Das Dokument ist ein aktiver Internet-Draft mit IESG-Status I-D Exists, noch kein RFC.
  • Neu sind Anforderungen für beliebig große OID-Komponenten: keine falsche Auslegung und kein undefiniertes Verhalten bei Überlauf; gültige Kennungen müssen auch dann interoperabel behandelt werden, wenn eine lokale Text- oder Konfigurationskomponente sie nicht vollständig verarbeiten kann. Die Kennung erleichtert eine Pfadwahl, ersetzt aber keine Vertrauensprüfung.

Die Reihenfolge der Entscheidungen ist entscheidend. Zunächst legt die prüfende Seite fest, welchen Zertifizierungsstellen sie vertraut. Eine Gegenstelle, die sich ausweist, kann mehrere Zertifizierungspfade bereithalten und einen davon auswählen. Erst danach wird geprüft, ob der vorgelegte Pfad zur lokalen Vertrauenskonfiguration und zu den übrigen Zertifikatsregeln passt. Der vorgeschlagene TLS-Mechanismus trust_anchors soll die Auswahl mit kurzen Kennungen erleichtern, gerade wenn alte und neue Trust Stores nebeneinander existieren. Er verschiebt die Entscheidung über das Vertrauen nicht zu demjenigen, der eine Kette präsentiert.

Der konkrete Versionssprung lässt sich an den von der IETF bereitgestellten Texten ablesen. Fassung 05 vom 14. September erlaubte für die binäre Darstellung einer ID bis zu 255 Byte. Fassung 06 vom 30. September begrenzt sie auf 32 Byte und ändert den Vektor TrustAnchorID von <1..2^8-1> auf <1..32>. Damit sollen binäre sowie punktierte dezimale Darstellungen einer relativen oder vollständigen OID bequem unter 255 Byte bleiben. Es geht um die Größe einer einzelnen Kennung, nicht um eine Obergrenze von 32 vertrauenswürdigen CAs oder Zertifizierungspfaden.

Die zweite Änderung betrifft eine andere Größe. Eine OID kann in einem ihrer Bestandteile einen mathematisch sehr großen Wert tragen; auch Muster für Ankergruppen können solche Werte enthalten. Wer diese Bestandteile blind in einen Ganzzahltyp mit fester Breite überführt, riskiert Überlauf oder eine falsche Übereinstimmung. Die neue Implementierungssektion untersagt Fehlinterpretation und undefiniertes Verhalten. Sie empfiehlt, Kennungen als Bytefolgen zu behalten, denn Gleichheit und Musterabgleich lassen sich auf dieser Ebene durchführen, ohne jeden Bestandteil erst in eine lokale Dezimalzahl zu verwandeln.

Für Diagnoseausgaben und textbasierte Konfiguration kann eine Dezimalschreibweise trotzdem sinnvoll sein. Der Entwurf gestattet dort implementierungsspezifische Grenzen. Eine solche Grenze darf jedoch nicht die Bedeutung gültiger Protokolleingaben stillschweigend umschreiben. TLS-Implementierungen müssen Kennungen mit beliebig großen OID-Komponenten in den genannten Handshake-Nachrichten annehmen; vor der Weitergabe an andere Komponenten dürfen sie nicht unterstützte Kennungen verwerfen. Werden sämtliche Kennungen in EncryptedExtensions verworfen, entspricht dies einem fehlenden Erweiterungsfeld. Wer Grenzen für OID-Bestandteile setzt, sollte wenigstens Werte bis 2^32-1 unterstützen, damit der Bereich der Private Enterprise Numbers abgedeckt ist; IDs sollten passend vergeben werden. Das ist eine Empfehlung mit SHOULD, keine Behauptung über bereits getestete Produkte.

Auch das Beispiel einer versionierten Ankergruppe wurde geändert: Ein bisher als 2^64-1 formulierter offener Höchstwert wird zu unendlich. Daraus folgt kein beobachteter Eingriff in ein produktives CA-Verzeichnis. Die Datatracker-Seite zeigt weiterhin einen WG-Entwurf im IESG-Zustand I-D Exists. Weder eine Standardverabschiedung noch reale Verbreitung oder ein konkreter Sicherheitsvorfall lässt sich aus dieser Revision ableiten.

Quellen