2. Comportement du serveur et du client

2.1. Syntaxe du champ d'en-tête de réponse

Le champ d'en-tête de réponse Expect-CT est un nouveau champ défini dans cette spécification. Il est utilisé par un serveur pour indiquer que les UA doivent évaluer les connexions à l'hôte émettant le champ d'en-tête pour la conformité CT (section 2.4).

Expect-CT           = 1#expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ]
directive-name      = token
directive-value     = token / quoted-string

Les directives définies dans cette spécification sont décrites ci-dessous. Les exigences globales pour les directives sont :

1. L'ordre d'apparition des directives n'est pas significatif.
2. Une directive donnée NE DOIT PAS apparaître plus d'une fois dans un champ d'en-tête donné.
3. Les noms de directive ne sont pas sensibles à la casse.
4. Les UA DOIVENT ignorer tout champ d'en-tête contenant des directives ou d'autres données de valeur de champ d'en-tête qui ne sont pas conformes à la syntaxe définie dans cette spécification.
5. Si un champ d'en-tête contient des directives que l'UA ne reconnaît pas, l'UA DOIT ignorer ces directives.
6. Si le champ d'en-tête Expect-CT satisfait par ailleurs aux exigences ci-dessus (1 à 5) et qu'Expect-CT n'est pas désactivé pour des raisons de politique locale (comme discuté dans la section 2.4.1), l'UA DOIT traiter les directives qu'il reconnaît.

2.1.1. La directive report-uri

La directive OPTIONNELLE report-uri indique l'URI vers lequel l'UA DEVRAIT signaler les échecs Expect-CT (section 2.4).

2.1.2. La directive enforce

La directive OPTIONNELLE enforce est une directive sans valeur qui, si présente (c'est-à-dire, elle est "affirmée"), signale à l'UA que la conformité à la politique CT doit être appliquée (plutôt que rapport uniquement) et que l'UA doit refuser les futures connexions qui violent sa politique CT.

2.1.3. La directive max-age

La directive max-age spécifie le nombre de secondes après la réception du champ d'en-tête Expect-CT pendant lesquelles l'UA DEVRAIT considérer l'hôte de qui le message a été reçu comme un hôte Expect-CT connu.

max-age-value = delta-seconds
delta-seconds = 1*DIGIT

2.1.4. Exemples

Expect-CT: max-age=86400, enforce

Expect-CT: max-age=86400,enforce
Expect-CT: report-uri="https://foo.example/report"

Expect-CT: max-age=86400,report-uri="https://foo.example/report"

2.2. Modèle de traitement de l'hôte

Cette section décrit le modèle de traitement que les hôtes Expect-CT implémentent.

2.2.1. Type de requête HTTP-over-Secure-Transport

Un hôte Expect-CT inclut un champ d'en-tête Expect-CT dans sa réponse. Le champ d'en-tête DOIT satisfaire la grammaire spécifiée dans la section 2.1.

2.2.2. Type de requête HTTP

Les hôtes Expect-CT NE DEVRAIENT PAS inclure le champ d'en-tête Expect-CT dans les réponses HTTP transmises sur un transport non sécurisé.

2.3. Modèle de traitement de l'agent utilisateur

Le modèle de traitement de l'UA repose sur l'analyse des noms de domaine. Notez que les noms de domaine internationalisés DEVRONT être canonicalisés par l'UA selon le schéma de la section 10 de [RFC6797].

L'UA stocke les hôtes Expect-CT connus et leurs directives Expect-CT associées. Ces données sont collectivement connues sous le nom de "métadonnées Expect-CT" d'un hôte.

2.3.1. Champs d'en-tête Expect-CT manquants ou malformés

Si une réponse HTTP n'inclut pas de champ d'en-tête Expect-CT conforme à la grammaire spécifiée dans la section 2.1, alors l'UA NE DOIT PAS mettre à jour les métadonnées Expect-CT.

2.3.2. Traitement du champ d'en-tête Expect-CT

Si l'UA reçoit une réponse HTTP sur un transport sécurisé qui inclut un champ d'en-tête Expect-CT conforme à la grammaire spécifiée dans la section 2.1, l'UA DOIT évaluer la connexion sur laquelle le champ d'en-tête a été reçu pour la conformité avec la politique CT de l'UA, puis traiter le champ d'en-tête Expect-CT comme suit.

Si la connexion ne se conforme pas à la politique CT de l'UA (c'est-à-dire, la connexion n'est pas CT qualifiée), alors l'UA NE DOIT PAS mettre à jour les métadonnées Expect-CT. Si le champ d'en-tête inclut une directive report-uri, l'UA DEVRAIT envoyer un rapport au report-uri spécifié (section 2.3.3).

Si la connexion se conforme à la politique CT de l'UA (c'est-à-dire, la connexion est CT qualifiée), alors l'UA DOIT soit :

• Noter l'hôte comme un hôte Expect-CT connu s'il n'est pas déjà ainsi noté (voir section 2.3.2.1) ou

• Mettre à jour les informations mises en cache de l'UA pour l'hôte Expect-CT connu si les directives de valeur de champ d'en-tête enforce, max-age ou report-uri transmettent des informations différentes de celles déjà maintenues par l'UA.

2.3.2.1. Noter Expect-CT

Lors de la réception du champ d'en-tête de réponse Expect-CT sur une connexion TLS sans erreur (avec validation de chaîne de certificat X.509 comme décrit dans [RFC5280], ainsi que la validation décrite dans la section 2.4 de ce document), l'UA DOIT noter l'hôte comme un hôte Expect-CT connu, stockant le nom de domaine de l'hôte et ses directives Expect-CT associées dans un stockage non volatile.

2.3.2.2. Modèle de stockage

Si la sous-chaîne correspondant à la production d'hôte du Request-URI (du message auquel l'hôte a répondu) ne correspond pas exactement au nom de domaine d'un hôte Expect-CT connu existant, selon la procédure de correspondance pour une correspondance congruente spécifiée dans la section 8.2 de [RFC6797], alors l'UA DOIT ajouter cet hôte au cache d'hôte Expect-CT connu. L'UA met en cache :

• le nom de domaine de l'hôte Expect-CT.
• si la directive enforce est présente.
• la date d'expiration effective (la date Expect-CT effective plus la valeur de la directive max-age).
• la valeur de la directive report-uri, si présente.

2.3.3. Rapport

Si l'UA reçoit, sur un transport sécurisé, une réponse HTTP qui inclut un champ d'en-tête Expect-CT avec une directive report-uri, et que la connexion ne se conforme pas à la politique CT de l'UA (c'est-à-dire, la connexion n'est pas CT qualifiée), et que l'UA n'a pas déjà envoyé un rapport Expect-CT pour cette connexion, alors l'UA DEVRAIT envoyer un rapport au report-uri spécifié comme spécifié dans la section 3.

2.4. Évaluation des connexions Expect-CT pour la conformité CT

Lorsqu'un UA établit une connexion TLS, l'UA détermine si l'hôte est un hôte Expect-CT connu selon son cache d'hôte Expect-CT connu. Un hôte Expect-CT est "expiré" si la date d'expiration effective fait référence à une date dans le passé. L'UA DOIT ignorer tout hôte Expect-CT expiré dans son cache et ne pas traiter de tels hôtes comme des hôtes Expect-CT connus.

Lorsqu'un UA se connecte à un hôte Expect-CT connu à l'aide d'une connexion TLS, si la connexion TLS n'a pas d'erreurs, alors l'UA appliquera une vérification de correction supplémentaire : conformité avec une politique CT.

Si une connexion à un hôte Expect-CT connu viole la politique CT de l'UA (c'est-à-dire, la connexion n'est pas CT qualifiée), et si les métadonnées Expect-CT de l'hôte Expect-CT connu indiquent une configuration enforce, l'UA DOIT traiter l'échec de conformité CT comme une erreur.

Si une connexion à un hôte Expect-CT connu viole la politique CT de l'UA, et si les métadonnées Expect-CT de l'hôte Expect-CT connu incluent un report-uri, l'UA DEVRAIT envoyer un rapport Expect-CT à ce report-uri (section 3).

2.4.1. Ignorer les vérifications de conformité CT

Il est acceptable pour un UA d'ignorer les vérifications de conformité CT pour certains hôtes selon la politique locale. Par exemple, un UA PEUT désactiver les vérifications de conformité CT pour les hôtes dont la chaîne de certificats validée se termine à une ancre de confiance définie par l'utilisateur plutôt qu'à une ancre de confiance intégrée à l'UA (ou à la plateforme sous-jacente).

Si l'UA n'évalue pas la conformité CT, par exemple, parce que l'utilisateur a choisi de la désactiver, ou parce qu'une chaîne de certificats présentée s'enchaîne jusqu'à une ancre de confiance définie par l'utilisateur, les UA NE DEVRAIENT PAS envoyer de rapport Expect-CT.