Résumé

  • RFC 9919 impose SHA-256 aux nouveaux clients du profil OCSP léger pour les hachages du nom et de la clé de l’émetteur dans CertID. Les anciens clients compatibles RFC 5019 doivent quitter SHA-1 dès que possible.
  • Pour assurer une transition, un répondeur peut placer dans une même réponse un SingleResponse en SHA-1 et un autre en SHA-256. L’algorithme observé dans les requêtes peut éclairer le retrait de la variante SHA-1.
  • Ce relevé ne couvre que les requêtes arrivées au point mesuré. Cache local, proxy, réponse préproduite, agrafage, autre répondeur ou accord hors bande peuvent masquer une dépendance toujours active.
  • Le hachage de CertID identifie le contexte de l’émetteur du certificat ; il ne désigne pas l’algorithme qui signe la réponse OCSP.
  • La clôture exige un reçu indiquant périmètre d’observation, dénominateur, politique de double réponse, critère d’arrêt, responsable, essai canari, repli, échéance de l’exception et résultat après bascule.

Le silence n’est pas encore une population

Une courbe à zéro raconte d’abord ce qui n’est pas arrivé à une entrée donnée. Elle ne raconte pas automatiquement ce que tous les clients ont fait. Cette réserve est décisive dans un profil conçu pour réduire le nombre de contacts directs avec le répondeur.

RFC 9919 permet de produire les réponses à l’avance et organise leur réutilisation. Un client conserve localement une réponse autoritative ; un intermédiaire HTTP peut la servir ; le serveur peut la distribuer depuis son propre cache. Une réponse peut aussi accompagner une autre négociation, notamment par agrafage, sans nouvelle session HTTP entre le client et le service OCSP. Le compteur d’origine baisse alors même que la réponse continue d’être consommée.

La topologie ajoute une seconde lacune. Une vue régionale ne voit pas forcément les instances de secours ou les chemins d’un autre fournisseur. Le protocole ne signale pas lui-même les capacités du répondeur ; les opérateurs peuvent donc s’appuyer sur des conventions hors bande pour décider quel profil employer. Ni ces conventions ni les parcs isolés ne se déduisent d’une seule série de requêtes.

Ainsi, une baisse peut signifier mise à niveau, mais aussi allongement de durée, meilleur cache, extension de l’agrafage ou déplacement du trafic. Sans dénominateur déclaré, ces causes se confondent.

La migration porte sur deux hachages précis

RFC 5019 exigeait SHA-1 pour CertID.issuerNameHash et CertID.issuerKeyHash. RFC 9919 remplace cette règle : un client conforme au nouveau profil doit utiliser SHA-256. Il maintient toutefois une transition praticable pour les clients anciens, qui peuvent encore émettre du SHA-1 mais doivent migrer dès que possible.

Le répondeur peut répondre aux deux générations. Le format devrait normalement contenir un seul SingleResponse, mais des éléments supplémentaires sont admis pour la préproduction, l’efficacité du cache ou la rétrocompatibilité. L’exemple normatif décrit précisément une entrée SHA-1 et une entrée SHA-256. Si aucun client n’a plus besoin de SHA-1, le répondeur ne devrait plus distribuer cette forme. Le journal des algorithmes demandés peut contribuer à cette appréciation.

Il n’existe pourtant ni délai silencieux universel ni seuil fourni par l’IETF. Le verbe d’action demeure chez l’opérateur : mesurer, interpréter, accepter un risque résiduel, décider et pouvoir revenir en arrière.

Il faut aussi préserver la bonne couche technique. Dans RFC 6960, CertID.hashAlgorithm sert à calculer les hachages du nom et de la clé publique de l’émetteur, puis le numéro de série complète l’identifiant de la cible. BasicOCSPResponse.signatureAlgorithm est un champ distinct. RFC 9919 précise que SHA-1 dans ce calcul de CertID n’est pas, en soi, une inquiétude cryptographique ; le coût vient du support logiciel maintenu, de la complexité et de la surface d’attaque potentielle.

Un dénominateur auditable

L’inventaire doit commencer par les instances de répondeur, noms de service, régions, chemins réseau, familles de certificats et groupes de clients. Pour chaque ligne, il faut dire si l’on voit la requête directe, la révalidation de cache, l’agrafage, l’usage hors ligne et le repli vers une autre route.

La fenêtre doit couvrir les rythmes réels. Un ancien client muni d’une réponse longue durée ne reviendra pas avant expiration. Un appareil d’entreprise mis à jour une fois par trimestre peut rester absent d’une observation de deux semaines. Un canari sur des certificats publics très sollicités ne représente pas nécessairement une PKI fermée.

Les angles morts ne sont pas des échecs si le reçu les nomme. Ils deviennent dangereux lorsqu’ils sont classés sans preuve dans la colonne SHA-256. Une exclusion doit avoir un propriétaire, une justification et une date d’expiration.

Fermer l’exception par un reçu

Le reçu de retrait réunit la portée et le décideur, les points d’observation et le dénominateur, l’inventaire d’exceptions SHA-1, la politique de réponse simple ou double, la couverture des caches et de l’agrafage, la durée de mesure et le critère d’arrêt. Il ajoute le groupe canari, sa durée, le chemin de repli et l’échéance au-delà de laquelle l’exception doit être réautorisée.

Après bascule, le même document reçoit les résultats : retour de requêtes SHA-1, erreurs de réponse, échecs de validation, activation du repli, familles de certificats touchées et effet sur le service. Une décision sans ce retour n’est qu’une autorisation de changement.

La norme organise l’interopérabilité ; elle ne porte pas la responsabilité opérationnelle d’une entreprise. Le responsable du logiciel et du service doit donc signer la clôture. La compatibilité ne doit pas survivre indéfiniment par inertie, ni mourir parce qu’un seul écran s’est tu.

Sources