6.5. Révocation de certificat

Les considérations et recommandations suivantes représentent l'état de l'art actuel concernant la révocation de certificats, même si aucune solution complète et efficace n'existe pour le problème de vérification du statut de révocation des certificats à clé publique courants [RFC5280]:

Bien que les listes de révocation de certificats (CRL) soient le mécanisme le plus largement supporté pour distribuer les informations de révocation, elles présentent des défis d'échelle connus qui limitent leur utilité (malgré des solutions de contournement telles que les CRL partitionnées et les CRL delta).
Les mécanismes propriétaires qui intègrent des listes de révocation dans la base de données de configuration du navigateur Web ne peuvent pas être mis à l'échelle au-delà d'un petit nombre de serveurs Web les plus utilisés.
Le protocole OCSP (On-Line Certification Status Protocol) [RFC6960] présente à la fois des problèmes d'échelle et de confidentialité. De plus, les clients effectuent généralement un "soft-fail", ce qui signifie qu'ils n'interrompent pas la connexion TLS si le serveur OCSP ne répond pas. (Cependant, cela pourrait être une solution de contournement pour éviter les attaques par déni de service si un répondeur OCSP est mis hors ligne.)
L'extension TLS Certificate Status Request (Section 8 de [RFC6066]), communément appelée "OCSP stapling", résout les problèmes opérationnels avec OCSP. Cependant, elle est toujours inefficace en présence d'un attaquant MITM car l'attaquant peut simplement ignorer la demande du client pour une réponse OCSP agrafée.
L'agrafage OCSP tel que défini dans [RFC6066] ne s'étend pas aux certificats intermédiaires utilisés dans une chaîne de certificats. Bien que l'extension Multiple Certificate Status [RFC6961] traite cette lacune, il s'agit d'un ajout récent sans beaucoup de déploiement.
Les CRL et OCSP dépendent tous deux d'une connectivité relativement fiable à Internet, qui pourrait ne pas être disponible pour certains types de nœuds (tels que les dispositifs nouvellement provisionnés qui doivent établir une connexion sécurisée pour démarrer pour la première fois).

En ce qui concerne les certificats à clé publique courants, les serveurs DEVRAIENT supporter les éléments suivants comme meilleure pratique compte tenu de l'état actuel de l'art et comme base pour une solution future possible:

OCSP [RFC6960]
À la fois l'extension status_request définie dans [RFC6066] et l'extension status_request_v2 définie dans [RFC6961] (Cela pourrait permettre l'interopérabilité avec la plus large gamme de clients.)
L'extension d'agrafage OCSP définie dans [RFC6961]

Les considérations de cette section ne s'appliquent pas aux scénarios où l'enregistrement de ressource DANE-TLSA [RFC6698] est utilisé pour signaler à un client quel certificat un serveur considère comme valide et bon à utiliser pour les connexions TLS.