Zusammenfassung

  • Revision 07 vom 2. November ergänzt eine Regel, die in Revision 06 fehlte: Wird ein Zertifizierungspfad trotz vertrauter Wurzel aus einem anderen Grund abgewiesen, sollte der Client dessen Anker-ID beim erneuten Verbindungsversuch nicht auswählen (im Entwurf: SHOULD NOT).
  • Der Text nennt Ablauf, Widerruf, Namensfehler und eine Einschränkung des Clients für diese Wurzel.
  • Eine andere geeignete ID kann weiterhin gewählt werden. Pro Verbindungsversuch soll es höchstens eine Wiederholung geben.

Der zweite Versuch darf kein Freispruch sein

Nehmen wir ein Behördenportal: Der Browser kennt die Zertifizierungsstelle, aber das vorgelegte Zertifikat gehört zu einem anderen Hostnamen. Er weist die Verbindung ab. Nun meldet der Server mögliche Vertrauensanker für einen zweiten Anlauf. Soll die Kennung der eben abgewiesenen Kette wieder auf dem Zettel stehen? Die neue Fassung sagt Nein. Ein bekannter Aussteller kann den falschen Namen nicht berichtigen.

Ein Server kann mehrere Zertifizierungspfade bereithalten und ihre Vertrauensanker-IDs in EncryptedExtensions auflisten. Scheitert seine erste Wahl, darf ein Client, der zusätzliche Anker angefragt oder vertraute ausgelassen hatte, denselben Endpunkt mit nur einer ausgewählten ID erneut kontaktieren. So beschreibt es die Fassung vom 2. November. Die Fassung vom 30. September kannte diese Wiederholung bereits, nicht aber die neue Ausnahme bei der ID-Auswahl.

Ein vertrauter Aussteller genügt eben nicht. Das Zertifikat kann abgelaufen oder widerrufen sein. Der Name kann nicht passen. Oder der Client lässt diese Wurzel nur unter bestimmten Bedingungen zu. In diesem Fall soll er die ID des abgewiesenen Pfads nicht für den nächsten Versuch wählen. Das normative SHOULD NOT bezieht sich auf diese eine ID. Steht eine andere passende ID in der Serverantwort, richtet sich die Wahl nach der Reihenfolge des Servers und lokalen Präferenzen. Fehlt die Erweiterung oder jeder Treffer, geht der Fehler an die Anwendung.

Der IETF-Eintrag führt das Papier weiterhin als Arbeitsgruppen-Internet-Draft mit Status I-D Exists. Die geprüften Originaltexte belegen keinen realen Missbrauch und keine fertige Einführung. Die Änderung ist trotzdem ein handfester Prüfpunkt für Browser und TLS-Bibliotheken: Beim Wiederverbinden muss die Software wissen, weshalb sie die erste Kette abgewiesen hat. Wer diese Information wegwirft, macht aus „diesem Aussteller vertraue ich“ eine Antwort auf eine ganz andere Frage.