Appendix A. Design Decision Notes (Notes sur les Décisions de Conception)

Cette annexe enregistre diverses décisions de conception.

1. Les cookies ne conviennent pas pour l'expression de la politique HSTS, car ils peuvent être mutables lorsqu'ils sont stockés dans le UA; par conséquent, un champ d'en-tête HTTP a été adopté.

2. Nous avons choisi de ne pas tenter de spécifier comment traiter les "chargements de contexte de sécurité mixte" (également appelés "chargements de contenu mixte"), en raison des considérations d'implémentation de UA et des difficultés de catégorisation.

3. Un hôte HSTS peut mettre à jour la notion de politique HSTS du UA via de nouvelles valeurs de paramètre de champ d'en-tête HSTS. Nous avons choisi de faire en sorte que le UA se conforme aux informations "les plus récentes" reçues du serveur, car il est possible qu'un site Web émette une politique HSTS erronée, par exemple une valeur max-age de plusieurs années, et/ou une directive includeSubDomains erronée. Si l'hôte HSTS ne peut pas corriger de telles erreurs via le protocole, cela nécessiterait une certaine forme d'annonce aux utilisateurs et une intervention manuelle de l'utilisateur, ce qui pourrait être un problème non trivial pour les fournisseurs d'applications Web et leurs utilisateurs.

4. Les hôtes HSTS ne sont identifiés que par nom de domaine -- excluant toutes les formes d'identification d'adresse IP explicite. C'est pour la simplicité, ainsi que pour reconnaître les divers problèmes lors de l'utilisation de l'identification d'adresse IP directe en conjonction avec la sécurité basée sur PKI.

5. L'approche max-age a été choisie, permettant aux hôtes HSTS de fournir un nombre entier simple de secondes comme valeur de durée de vie de la politique HSTS mise en cache, plutôt qu'une approche d'énonciation d'un temps d'expiration dans le futur, pour diverses raisons. Les raisons incluent : pas besoin de synchronisation d'horloge, pas besoin de définir une syntaxe de valeur de date et d'heure (simplicité de spécification), et simplicité d'implémentation.

6. En déterminant s'il faut adopter le mappage de port, l'option de rejeter simplement la déréférence de tout URL avec un port explicite a été envisagée. Cependant, on a pensé que la possibilité que l'URI à déréférencer soit incorrect (et qu'il y ait en fait un serveur HTTPS valide sur ce port) valait le petit coût d'une récupération HTTPS potentiellement gaspillée vers le serveur HTTP.