Zusammenfassung

  • draft-ietf-tls-trust-anchor-ids-06 schlägt kompakte Kennungen vor, mit denen ein TLS-Partner einen Zertifikatspfad auswählen kann. Die Anfrage ist weder vollständig noch für die lokale Vertrauenspolitik bindend.
  • Fehlerhafte Pfadmetadaten oder bewusst ungenaue Clientlisten können eine abgelehnte Kette auswählen. Das führt zu einem fehlgeschlagenen Handshake und erweitert nicht den Vertrauensspeicher.
  • Signalpolitik, Pfadinventar, Auswahl, Validierung, Wiederherstellung, Datenschutz und Dienstergebnis brauchen getrennte Zuständigkeiten und Belege.

Metadatenfehler wirken harmlos, solange sie nur in einem Katalog stehen. In einer Auswahlmaschine werden sie ausführbar. Ordnet ein Betreiber einen Zertifikatspfad der falschen Trust Anchor ID oder einer unzutreffenden Gruppe zu, folgt der Server der falschen Beschreibung. Der Client erhält eine sauber ausgewählte, aber unzulässige Kette.

Gerade dieses Scheitern zeigt, dass die Sicherheitsgrenze intakt ist. Die Kennung soll die Wahrscheinlichkeit einer brauchbaren Auswahl erhöhen. Sie darf nicht festlegen, was der Client akzeptiert.

Revision 06 des Internet-Drafts wurde am 30. September 2026 aktualisiert. Im Kopf steht Standards Track als beabsichtigter Status; im eingefrorenen Datatracker-Datensatz sind intended_std_level und std_level null. Der Text ist kein RFC. Die Quellen belegen weder produktive Einführung noch Verbreitung oder Interoperabilität.

Eine absichtlich unvollständige Anfrage

Ein Server kann für dieselbe Anwendungsidentität mehrere Zertifikatsketten besitzen. Das bestehende certificate_authorities-Feld kann akzeptable Stellen nennen, doch lange Distinguished Names machen eine vollständige Liste groß. Der Entwurf führt kurze individuelle Trust Anchor IDs und Gruppenkennungen ein.

Der Client sendet in ClientHello oder CertificateRequest eine ungeordnete RequestedTrustAnchorList; sie darf leer sein. Er darf vertrauenswürdige Anker auslassen, nicht vertrauenswürdige nennen oder eine Gruppe senden, in der beides vorkommt. Begrenzte Nachrichtengröße und der Schutz vor einem exakten Trust-Store-Fingerabdruck können diese Unschärfe rechtfertigen.

Der Server hält für jeden Kandidatenpfad die individuelle ID des ausstellenden Ankers und passende Gruppenmuster vor. Er bildet die Schnittmenge mit der Anfrage. Ist zusätzlich certificate_authorities vorhanden, darf ein Kandidat aufgrund einer der beiden Angaben gewählt werden. Ohne Treffer kann der Server den Handshake abbrechen oder eine Fallback-Kette senden.

Erst danach entscheidet die Validierung. Der Client prüft den tatsächlichen Anker, die Anwendungsidentität, Gültigkeitszeiten, Algorithmen und Einschränkungen. Ein Treffer in den Metadaten ist keine Ausnahme von RFC 5280. Ist die Zuordnung falsch, fällt die Verbindung aus. Ist die Clientliste aus Datenschutzgründen breit, kann dasselbe geschehen. In beiden Fällen bleibt eine nicht akzeptierte Kette nicht akzeptiert.

Strenge Reihenfolge, unabhängiges Urteil

Wenn das ausgewählte Zertifikat einer angefragten ID entspricht, kann der Server eine leere trust_anchors-Erweiterung in Certificate setzen. Das leere Feld verpflichtet ihn zu einer vollständigen, korrekt geordneten Liste ohne fremde Zertifikate.

Der Client darf diese Liste als vorgebauten Pfad behandeln und die Suche nach weiteren Konstruktionen abschalten. RFC 4158 beschreibt die Komplexität des Pfadbaus. RFC 5280 beschreibt die anschließende Validierung. Der Entwurf kann die Suche verkürzen, nicht das Urteil. Auch eine perfekte Reihenfolge kann an einem unzulässigen Root, einer Namensbeschränkung oder einem Algorithmus scheitern.

Im Betriebsnachweis müssen daher zwei Aussagen getrennt bleiben: „Pfad P wurde wegen Kennung X gewählt“ und „Politik Y hat Pfad P aus Grund Z angenommen oder verworfen“. Ein einziges Feld trusted verliert sowohl die Ursache als auch die Zuständigkeit.

Eine kontrollierte zweite Auswahl

Der Server kann in EncryptedExtensions eine nicht leere, nach seiner Präferenz geordnete Liste verfügbarer individueller Anker senden. Lehnt der Client das Zertifikat später ab, sucht er darin einen tatsächlich vertrauenswürdigen Anker, stimmt Server- und Clientpräferenz ab und eröffnet eine neue Verbindung, die nur diese eine ID anfordert.

Der Entwurf begrenzt die Wiederholung auf einen Versuch. Fehlt die Liste, gibt es keine vertrauenswürdige Schnittmenge oder scheitert auch der zweite Versuch, erhält die Anwendung einen Fehler. Die zusätzliche Verbindung kostet eine Runde Latenz. Sie korrigiert die Pfadauswahl und nicht die Politik.

Bei einem Root-Wechsel kann der neue Pfad zuerst angeboten und der alte als Rückfalloption gehalten werden. Das beschleunigt den Test der neuen Kette. Gleichzeitig entsteht eine messbare Schuld: Wiederholungsquote, zusätzliche Perzentillatenz, Dauer der Doppelhaltung und ein klares Ausstiegskriterium.

Gruppen machen Metadaten zur Infrastruktur

Eine Gruppe spart Platz, weil sie mehrere Anker repräsentiert. Sie macht die Mitglieder nicht gleichwertig. Der Client kann eine Gruppe senden, obwohl er einzelne Mitglieder ablehnt. Ein veralteter Gruppenstand kann deshalb einen konsistenten Ausfall produzieren, aber keine lokale Freigabe erzwingen.

Die Kennung braucht Zuteilung, Mitgliedschaft, Versionierung, Verteilung und Rücknahme. Diese Arbeit liegt außerhalb des Handshakes. Wer nur die Byteersparnis kalkuliert, unterschätzt den dauerhaften Koordinationsaufwand.

Auch die Wahl einer CA durch den Server ist keine institutionelle Empfehlung. Sie zeigt, welche Kette Inventar, Metadaten und Prioritäten für diesen Verbindungsversuch ergaben. Technische Auswahl darf nicht als Mandat gelesen werden.

Drei Sichtbarkeitsklassen

Der Entwurf unterscheidet Clients, die nie, bedingt oder unbedingt Trust Anchor IDs senden. Bedingte Signale verlangen typischerweise eine aktive Sonde. Unbedingte Listen lassen sich passiv beobachten. Eine nutzereindeutige, stabile Liste wird zum Fingerabdruck.

Darum soll kein einzigartiges unbedingtes Muster gesendet werden; ein von einer Anonymitätsmenge geteiltes Muster ist vorzuziehen. Doch eine aus früheren Verbindungen abgeleitete Liste kann Sitzungen weiterhin verbinden. Eine Gruppe bietet nur dann Schutz, wenn ausreichend viele unabhängige Clients dasselbe Muster verwenden.

Die Verfügbarkeitsliste des Servers muss auf den angeforderten Dienst und den SNI-Kontext begrenzt werden. Das gesamte Inventar einer gemeinsamen Plattform offenzulegen, verrät unnötige Beziehungen. Sensible Anker sollten nicht über diesen Mechanismus erscheinen.

Sieben Felder für belastbare Ursachen

Ein minimaler Nachweis hält Signalpolitik, Pfadinventar und Auswahl/Fallback getrennt. Er nennt gesendete IDs und Bedingungen, tatsächlich verfügbare Ketten samt Metadatenquelle sowie den Treffer und das Verhalten ohne Treffer.

Daneben stehen lokale Validierung, Wiederherstellung und Datenschutzmodus: Vertrauensspeicher und Ablehnungsgrund, verfügbare Anker und einziger Neuversuch, Emissionsbedingung und Dienstfilter. Das siebte Feld ist das Ergebnis mit gelieferter Kette, Handshake-Status und sichtbarer Dienstwirkung.

So liefert laufender Code überprüfbare Tatsachen, ohne eine zentrale Instanz zur Vertrauensherrin zu machen. Die Beteiligten können koordinieren und trotzdem die spätere Entscheidung behalten.

Quellen