3. Rapport d'échec Expect-CT

Lorsque l'UA tente de se connecter à un hôte Expect-CT connu et que la connexion n'est pas CT qualifiée, l'UA DEVRAIT signaler les échecs Expect-CT au report-uri, le cas échéant, dans les métadonnées Expect-CT de l'hôte Expect-CT connu.

3.1. Génération d'un rapport de violation

Pour générer un objet de rapport de violation, l'UA construit un objet JSON [RFC8259] avec les clés et valeurs suivantes :

"date-time" - La valeur de cette clé indique l'heure UTC à laquelle l'UA a observé l'échec de conformité CT. La valeur est une chaîne formatée selon la section 5.6 de [RFC3339].

"hostname" - La valeur est le nom d'hôte vers lequel l'UA a fait la requête d'origine qui a échoué à la vérification de conformité CT. La valeur est fournie sous forme de chaîne.

"port" - La valeur est le port vers lequel l'UA a fait la requête d'origine qui a échoué à la vérification de conformité CT. La valeur est fournie sous forme d'entier.

"scheme" - (facultatif) La valeur est le schéma avec lequel l'UA a fait la requête d'origine qui a échoué à la vérification de conformité CT. La valeur est fournie sous forme de chaîne. Cette clé est facultative et est supposée être "https" si elle n'est pas présente.

"effective-expiration-date" - La valeur indique la date d'expiration effective (voir section 2.3.2.2) pour l'hôte Expect-CT qui a échoué à la vérification de conformité CT, en UTC. La valeur est fournie sous forme de chaîne formatée selon la section 5.6 de [RFC3339].

"served-certificate-chain" - La valeur est la chaîne de certificats telle qu'elle a été servie par l'hôte Expect-CT pendant la configuration de la session TLS. La valeur est fournie sous forme de tableau de chaînes, qui DOIT apparaître dans l'ordre dans lequel les certificats ont été servis ; chaque chaîne du tableau est la représentation PEM (Privacy-Enhanced Mail) de chaque certificat X.509 comme décrit dans [RFC7468].

"validated-certificate-chain" - La valeur est la chaîne de certificats telle qu'elle a été construite par l'UA pendant la vérification de la chaîne de certificats. La valeur est fournie sous forme de tableau de chaînes.

"scts" - La valeur représente les SCT (s'il y en a) que l'UA a reçus pour l'hôte Expect-CT et leurs statuts de validation. La valeur est fournie sous forme de tableau d'objets JSON. Chaque objet JSON du tableau a les clés suivantes :

• Une clé "version", avec une valeur entière. L'UA DOIT définir cette valeur à 1 si le SCT est dans le format défini dans la section 3.2 de [RFC6962] ou 2 s'il est dans le format défini dans la section 4.5 de [RFC9162].

• La clé "status", avec une valeur de chaîne que l'UA DOIT définir à l'une des valeurs suivantes : "unknown" (indiquant que l'UA n'a pas ou ne fait pas confiance à la clé publique du journal dont le SCT a été émis) ; "valid" (indiquant que l'UA a validé avec succès le SCT comme décrit dans la section 5.2 de [RFC6962] ou la section 8.1.3 de [RFC9162]) ; ou "invalid" (indiquant que la validation du SCT a échoué en raison d'une mauvaise signature ou d'un horodatage invalide).

• La clé "source", avec une valeur de chaîne qui indique d'où l'UA a obtenu le SCT. L'UA DOIT définir la valeur à l'une des suivantes : "tls-extension", "ocsp", ou "embedded".

• La clé "serialized_sct", avec une valeur de chaîne. Si la valeur de la clé "version" est 1, l'UA DOIT définir cette valeur à la structure SignedCertificateTimestamp sérialisée encodée en base64 [RFC4648] de la section 3.2 de [RFC6962].

"failure-mode" - La valeur indique si le rapport Expect-CT a été déclenché par une politique Expect-CT en mode enforce ou report-only. L'UA DOIT définir cette valeur à "enforce" si les métadonnées Expect-CT indiquent une configuration enforce, et "report-only" sinon.

"test-report" - (facultatif) La valeur est définie à true si le rapport est envoyé par un client de test pour vérifier que le serveur de rapport se comporte correctement. La valeur est fournie sous forme de booléen et DOIT être définie à true si le rapport sert à tester le comportement du serveur et peut être jeté.

3.2. Envoi d'un rapport de violation

L'UA DEVRAIT signaler les échecs Expect-CT pour les hôtes Expect-CT connus : c'est-à-dire, lorsqu'une connexion à un hôte Expect-CT connu ne se conforme pas à la politique CT de l'UA et que les métadonnées Expect-CT de l'hôte contiennent un report-uri.

Les étapes pour signaler un échec Expect-CT sont les suivantes :

1. Préparer un objet JSON rapport avec la clé unique "expect-ct-report", dont la valeur est le résultat de la génération d'un objet de rapport de violation comme décrit dans la section 3.1.

2. Soit corps de rapport la stringification JSON de l'objet rapport.

3. Soit report-uri la valeur de la directive report-uri dans le champ d'en-tête Expect-CT.

4. Envoyer une requête HTTP POST à report-uri avec un champ d'en-tête Content-Type de application/expect-ct-report+json et un corps d'entité constitué du corps de rapport.

L'UA PEUT effectuer d'autres opérations dans le cadre de l'envoi de la requête HTTP POST, comme l'envoi d'un preflight CORS (Cross-Origin Resource Sharing) dans le cadre de [FETCH].

3.3. Réception d'un rapport de violation

Lors de la réception d'un rapport de violation Expect-CT, le serveur de rapport DOIT répondre avec un code de statut 2xx (Réussi) s'il peut analyser le corps de la requête comme JSON valide, le rapport est conforme au format décrit dans la section 3.1, et il reconnaît le schéma, le nom d'hôte et le port dans les champs "scheme", "hostname" et "port" du rapport.

Si le serveur de rapport ne reconnaît pas le format du rapport, le serveur de rapport DOIT répondre avec un code de statut 501 Not Implemented.

Si la clé "test-report" du rapport est définie à true, le serveur PEUT jeter le rapport sans traitement supplémentaire mais DOIT toujours retourner un code de statut 2xx (Réussi). Si la clé "test-report" est absente ou définie à false, le serveur DEVRAIT stocker le rapport pour traitement et analyse par le propriétaire de l'hôte Expect-CT.