8. User Agent Processing Model (Modèle de Traitement de l'Agent Utilisateur)

Cette section décrit le modèle de traitement HTTP Strict Transport Security des UA. Le modèle comporte plusieurs aspects, énumérés par les sous-sections suivantes.

Ce modèle de traitement suppose que le UA implémente IDNA2008 [RFC5890], ou éventuellement IDNA2003 [RFC3490], comme discuté dans la section 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration"). Il suppose également que tous les noms de domaine opérant dans le contexte de cette spécification ont été normalisés IDNA avant le traitement spécifié dans cette section, comme décrit dans la section 10 ("Domain Name IDNA-Canonicalization").

NOTE : La référence à [RFC3490] est due à sa pertinence continue pour le déploiement réel dans un avenir prévisible.

Les hypothèses ci-dessus impliquent également que ce modèle de traitement suppose spécifiquement qu'une validation IDNA et Unicode appropriée et des tests de liste de caractères ont été effectués sur les noms de domaine avant le traitement spécifié dans cette section, dans le cadre du processus de normalisation IDNA des noms de domaine. Voir les considérations de sécurité spécifiques à IDNA dans la section 14.10 ("Internationalized Domain Names") pour la justification et des détails supplémentaires.

8.1. Strict-Transport-Security Response Header Field Processing (Traitement du Champ d'En-tête de Réponse Strict-Transport-Security)

Si une réponse HTTP reçue via un transport sécurisé contient un champ d'en-tête STS conforme à la syntaxe spécifiée dans la section 6.1 ("Strict-Transport-Security HTTP Response Header Field"), et qu'il n'y a aucune erreur ou avertissement du transport sécurisé sous-jacent (voir section 8.4), le UA doit (MUST) :

• Noter l'hôte comme hôte HSTS connu s'il n'est pas déjà noté (voir section 8.1.1 ("Noting an HSTS Host - Storage Model")),

ou

• Mettre à jour les informations mises en cache du UA pour l'hôte HSTS connu si l'une ou les deux informations transmises dans les jetons de valeur de champ d'en-tête max-age et includeSubDomains diffèrent des informations que le UA maintient déjà.

  La valeur max-age est essentiellement une valeur de "durée de vie (time to live)" relative au moment de réception du champ d'en-tête STS.

  Si la valeur du jeton de valeur de champ d'en-tête max-age est nulle, le UA doit (MUST) supprimer ses informations de politique HSTS mises en cache (y compris la directive includeSubDomains, si affirmée) si l'hôte HSTS est connu, ou le UA ne doit pas (MUST NOT) noter cet hôte HSTS s'il n'est pas encore connu.

  Si le UA reçoit plusieurs champs d'en-tête STS dans un message de réponse HTTP via un transport sécurisé, le UA doit (MUST) traiter uniquement le premier tel champ d'en-tête.

Sinon :

• Si une réponse HTTP est reçue via un transport non sécurisé, le UA doit (MUST) ignorer tout champ d'en-tête STS présent.

• Le UA doit (MUST) ignorer tout champ d'en-tête STS qui ne se conforme pas à la syntaxe spécifiée dans la section 6.1 ("Strict-Transport-Security HTTP Response Header Field").

8.1.1. Noting an HSTS Host - Storage Model (Noter un Hôte HSTS - Modèle de Stockage)

Si la sous-chaîne correspondant à la production host dans le Request-URI (le message auquel l'hôte répond) correspond syntaxiquement à la production IP-literal ou IPv4address dans la section 3.2.2 de [RFC3986], alors le UA ne doit pas (MUST NOT) noter cet hôte comme hôte HSTS connu.

Sinon, si la sous-chaîne ne correspond pas de manière congruente au nom de domaine d'un hôte HSTS connu selon le processus de correspondance spécifié dans la section 8.2 ("Known HSTS Host Domain Name Matching"), alors le UA doit (MUST) noter cet hôte comme hôte HSTS connu, mettre en cache le nom de domaine de l'hôte HSTS, et noter avec lui le temps d'expiration de cette information, comme effectivement stipulé par la valeur max-age donnée, et si la directive includeSubDomains est affirmée. Voir également la section 11.2 ("HSTS Policy Expiration Time Considerations").

Le UA ne doit pas (MUST NOT) modifier le temps d'expiration ou la directive includeSubDomains de tout hôte HSTS connu correspondant au domaine parent.

Si l'entrée en cache d'un hôte HSTS connu a une date d'expiration dans le passé, cet hôte HSTS connu est "expiré (expired)". Si à tout moment il existe des hôtes HSTS connus expirés dans le cache, le UA doit (MUST) expulser tous les hôtes HSTS connus expirés de son cache.

8.2. Known HSTS Host Domain Name Matching (Correspondance de Nom de Domaine d'Hôte HSTS Connu)

Un nom de domaine donné peut correspondre au nom de domaine d'un hôte HSTS connu de l'une ou des deux manières suivantes : correspondance congruente (congruent match) ou correspondance de domaine parent (superdomain match). Ou bien, il peut ne pas y avoir de correspondance.

Les étapes suivantes déterminent s'il y a une correspondance et, le cas échéant, de quelle manière :

En utilisant une comparaison ASCII insensible à la casse, en commençant par l'étiquette la plus à droite et en continuant de droite à gauche, comparez étiquette par étiquette (en comparant uniquement les étiquettes) le nom de domaine donné avec le nom de domaine de chaque hôte HSTS connu non expiré du UA. Voir également la section 2.3.2.4 de [RFC5890].

• Correspondance de Domaine Parent (Superdomain Match)

  Si une correspondance étiquette par étiquette est trouvée entre l'intégralité du nom de domaine de l'hôte HSTS connu et la partie droite du nom de domaine donné, alors le nom de domaine de cet hôte HSTS connu est une correspondance de domaine parent du nom de domaine donné. Il peut y avoir plusieurs correspondances de domaine parent pour un nom de domaine donné.

• Correspondance Congruente (Congruent Match)

  Si une correspondance étiquette par étiquette est trouvée entre le nom de domaine de l'hôte HSTS connu et le nom de domaine donné -- c'est-à-dire, il n'y a plus d'étiquettes à comparer -- alors le nom de domaine donné correspond de manière congruente à cet hôte HSTS connu.

8.3. URI Loading and Port Mapping (Chargement d'URI et Mappage de Port)

Lors du chargement d'un URI, si la politique HSTS s'applique comme décrit dans la section 5.4, le UA doit (MUST) se comporter comme suit :

• Si l'URI n'a pas de composant de port, ou si le composant de port est égal au port par défaut non sécurisé 80, attribuez au URI le port de transport sécurisé par défaut 443 comme composant de port de l'URI de requête valide.

• Changez le composant de schéma de l'URI en "https".

• Ne doit pas (MUST NOT) établir de connexion non sécurisée.

• Peut (MAY) tenter d'établir une connexion sécurisée vers l'URI de requête valide construit.

8.4. Errors in Secure Transport Establishment (Erreurs dans l'Établissement du Transport Sécurisé)

Si une erreur se produit lors de la tentative d'établissement d'une connexion sécurisée vers un hôte HSTS connu, le UA ne doit pas (MUST NOT) poursuivre la connexion et ne doit pas (MUST NOT) afficher un message avertissant l'utilisateur de l'erreur. Le UA ne doit pas (MUST NOT) permettre à l'utilisateur de continuer malgré l'erreur.

Ces erreurs incluent (mais ne sont pas limitées à) :

• Certificat expiré
• Certificat auto-signé
• Chaîne de certificats non fiable
• Incompatibilité de nom d'hôte
• Erreurs de protocole TLS/SSL