Résumé

  • La version 07 du projet du groupe TLS ajoute une consigne absente de la version 06 : le client SHOULD NOT choisir, pour sa reprise, l’identifiant de l’ancre associée à un chemin refusé pour une autre raison.
  • Les motifs cités sont l’expiration, la révocation, un nom qui ne correspond pas et une contrainte imposée par le client à cette ancre.
  • Le texte conserve la possibilité de choisir un autre identifiant admissible. Il limite aussi la reprise à un nouvel essai par tentative de connexion.

La deuxième porte exige une nouvelle raison

Imaginez une connexion au portail de votre banque. Le navigateur connaît l’autorité qui a signé la chaîne, mais le certificat présenté porte le nom d’un autre site. La première connexion est refusée. La reprise sert à trouver un autre chemin de certification; elle ne doit pas demander de nouveau le badge du chemin qui vient de perdre au contrôle d’identité.

Un serveur peut posséder plusieurs chaînes de certificats. Le projet Trust Anchor Identifiers, version 07, daté du 2 novembre, lui permet d’indiquer dans EncryptedExtensions les identifiants des ancres correspondant à ses chemins candidats. Si la première sélection échoue, un client qui avait demandé des ancres supplémentaires ou omis certaines ancres fiables peut revenir au même point de terminaison avec un seul identifiant. La version 06 décrivait déjà cette reprise, sans la nouvelle exclusion.

Le piège est simple : une chaîne peut aboutir à une racine connue tout en échouant au contrôle qui compte. Un certificat expiré n’est pas rajeuni par sa racine. Une révocation ne disparaît pas, pas plus qu’une erreur de nom. La nouvelle phrase de la section 5.6 demande donc au client de ne pas sélectionner l’identifiant lié au chemin ainsi refusé. La formule SHOULD NOT vise cet identifiant précis. Un autre chemin reste possible. Le client n’a donc pas à choisir entre deux mauvaises réponses — répéter le même échec ou couper toute reprise.

Si plusieurs identifiants restent disponibles, le client tient compte de l’ordre proposé par le serveur et de ses préférences locales. Si l’extension manque ou qu’aucun identifiant ne convient, l’erreur remonte à l’application. La page de suivi de l’IETF classe encore le texte comme Internet-Draft du groupe de travail, I-D Exists. Les fichiers consultés n’établissent ni déploiement ni contournement réel. La modification est une règle de conception au point où la confiance dans une racine risquait d’effacer un refus plus précis.