Appendix A. Design Decision Notes (Designentscheidungs-Notizen)

Dieser Anhang dokumentiert verschiedene Designentscheidungen.

1. Cookies sind nicht für die HSTS-Richtlinienausdrucksform geeignet, da sie beim Speichern im UA veränderlich sein könnten; daher wurde ein HTTP-Header-Feld übernommen.

2. Wir haben uns entschieden, nicht zu versuchen, festzulegen, wie "gemischte Sicherheitskontextladungen" (auch "gemischte Inhaltsladungen" genannt) zu behandeln sind, aufgrund von UA-Implementierungsüberlegungen und Kategorisierungsschwierigkeiten.

3. Ein HSTS-Host kann die HSTS-Richtlinienvorstellung des UA über neue HSTS-Header-Feld-Parameterwerte aktualisieren. Wir haben uns entschieden, den UA den "aktuellsten" vom Server empfangenen Informationen folgen zu lassen, da es möglich ist, dass eine Website eine fehlerhafte HSTS-Richtlinie ausgibt, z. B. einen max-age-Wert von mehreren Jahren und/oder eine fehlerhafte includeSubDomains-Direktive. Wenn der HSTS-Host solche Fehler nicht über das Protokoll korrigieren kann, würde dies eine Form der Ankündigung an Benutzer und manuelle Benutzereingriffe erfordern, was für Webanwendungsanbieter und ihre Benutzer ein nicht triviales Problem sein könnte.

4. HSTS-Hosts werden nur durch Domainnamen identifiziert -- unter Ausschluss aller Formen expliziter IP-Adressidentifikation. Dies ist aus Gründen der Einfachheit sowie zur Anerkennung verschiedener Probleme bei der Verwendung direkter IP-Adressidentifikation in Verbindung mit PKI-basierter Sicherheit.

5. Der max-age-Ansatz wurde gewählt, der es HSTS-Hosts ermöglicht, eine einfache ganze Zahl von Sekunden als Lebensdauerwert der zwischengespeicherten HSTS-Richtlinie bereitzustellen, anstatt eines Ansatzes der Angabe einer Ablaufzeit in der Zukunft, aus verschiedenen Gründen. Gründe umfassen: keine Notwendigkeit einer Uhrsynchronisation, keine Notwendigkeit, eine Datums- und Zeitwertesyntax zu definieren (Spezifikationseinfachheit) und Implementierungseinfachheit.

6. Bei der Bestimmung, ob Port-Zuordnung übernommen werden soll, wurde die Option erwogen, einfach das Dereferenzieren jeder URL mit einem expliziten Port abzulehnen. Es wurde jedoch angenommen, dass die Möglichkeit, dass der zu dereferenzierende URI falsch ist (und es tatsächlich einen gültigen HTTPS-Server auf diesem Port gibt), die kleinen Kosten eines möglicherweise verschwendeten HTTPS-Abrufs zum HTTP-Server wert ist.