5. TLSA und DANE Anwendungsfälle und Anforderungen (TLSA and DANE Use Cases and Requirements)

Die verschiedenen Arten von Zertifikatszuordnungen, die in TLSA definiert sind, werden mit verschiedenen Abschnitten von [RFC6394] abgeglichen. Die Anwendungsfälle aus Abschnitt 3 von [RFC6394] werden in diesem Dokument wie folgt abgedeckt:

• 3.1 CA-Einschränkungen -- Implementiert unter Verwendung von Zertifikatsverwendung 0.

• 3.2 Zertifikatseinschränkungen -- Implementiert unter Verwendung von Zertifikatsverwendung 1.

• 3.3 Vertrauensanker-Assertion und Domain-ausgestellte Zertifikate -- Implementiert unter Verwendung der Zertifikatsverwendungen 2 bzw. 3.

Die Anforderungen aus Abschnitt 4 von [RFC6394] werden in diesem Dokument wie folgt abgedeckt:

Mehrere Ports (Multiple Ports) -- Die TLSA-Einträge für verschiedene Anwendungsdienste, die auf einem einzelnen Host ausgeführt werden, können durch den Dienstnamen und die Portnummer unterschieden werden, die dem Hostnamen vorangestellt sind (siehe Abschnitt 3).

Kein Downgrade (No Downgrade) -- Abschnitt 4 legt die Bedingungen fest, unter denen ein Client TLSA-Einträge verarbeiten und darauf reagieren kann. Insbesondere wenn der DNSSEC-Status für das TLSA-Ressourceneintragsset als gefälscht bestimmt wird, wird die TLS-Verbindung (falls gestartet) fehlschlagen.

Verkapselung (Encapsulation) -- Verkapselung wird in der TLSA-Antwortsemantik abgedeckt.

Vorhersagbarkeit (Predictability) -- Die Anhänge dieser Spezifikation bieten betriebliche Überlegungen und Implementierungsrichtlinien, um Anwendungsentwicklern eine konsistente Interpretation des empfohlenen Clientverhaltens zu ermöglichen.

Opportunistische Sicherheit (Opportunistic Security) -- Wenn ein Client, der dieser Spezifikation entspricht, zuverlässig das Vorhandensein eines TLSA-Eintrags bestimmen kann, wird er versuchen, diese Informationen zu verwenden. Umgekehrt, wenn ein Client zuverlässig das Fehlen eines TLSA-Eintrags bestimmen kann, wird er auf die normale Verarbeitung von TLS zurückgreifen. Dies wird in Abschnitt 4 diskutiert.

Kombination -- Mehrere TLSA-Einträge können für einen bestimmten Hostnamen veröffentlicht werden, wodurch der Client mehrere TLSA-Zertifikatszuordnungen erstellen kann, die verschiedene Aussagen widerspiegeln. Es wird keine Unterstützung bereitgestellt, um zwei TLSA-Zertifikatszuordnungen in einer einzigen Operation zu kombinieren.

Rollover -- TLSA-Einträge werden im normalen Rahmen des DNS-Protokolls verarbeitet, einschließlich des TTL-Ablaufs der Einträge. Dies stellt sicher, dass Clients sich nicht an Aussagen klammern, die durch abgelaufene TLSA-Einträge gemacht wurden, und in der Lage sein werden, von der Verwendung eines öffentlichen Schlüssels oder einer Zertifikatsverwendung zu einer anderen zu wechseln.

Einfache Schlüsselverwaltung (Simple Key Management) -- Der SubjectPublicKeyInfo-Selektor im TLSA-Eintrag bietet einen Modus, der es einem Domaininhaber ermöglicht, nur ein einziges langlebiges öffentliches/privates Schlüsselpaar pflegen zu müssen, ohne Zertifikate verwalten zu müssen. Anhang A skizziert die Nützlichkeit und die potenziellen Nachteile der Verwendung dieses Modus.

Minimale Abhängigkeiten (Minimal Dependencies) -- Diese Spezifikation verlässt sich auf DNSSEC, um die Ursprungsauthentizität und Integrität des TLSA-Ressourceneintragssets zu schützen. Wenn die DNSSEC-Validierung nicht auf dem System durchgeführt wird, das TLSA-Zertifikatsbindungen verwenden möchte, erfordert diese Spezifikation zusätzlich, dass die "letzte Meile" über einen sicheren Transport erfolgt. Es gibt keine anderen Bereitstellungsabhängigkeiten für diesen Ansatz.

Minimale Optionen (Minimal Options) -- Die Betriebsmodi stimmen genau mit den DANE-Anwendungsfällen und -Anforderungen überein. Die DNSSEC-Verwendung ist insofern obligatorisch, als diese Spezifikation Anwendungen ermutigt, nur diejenigen TLSA-Einträge zu verwenden, die validiert wurden.

Wildcards -- Wildcards werden in begrenzter Weise in der TLSA-Anforderungssyntax abgedeckt; siehe Anhang A.

Umleitung (Redirection) -- Umleitung wird in der TLSA-Anforderungssyntax abgedeckt; siehe Anhang A.