1. Introduction
Le cadre d'extensions Transport Layer Security (TLS) Extension (Extension de sécurité de la couche de transport) [RFC6066] définit, entre autres extensions, l'extension Certificate Status (également appelée "OCSP stapling") que les clients peuvent utiliser pour demander la copie du serveur du statut actuel de son certificat. Les avantages de cette extension incluent un nombre réduit d'allers-retours et de délais réseau pour que le client vérifie le statut du certificat du serveur, ainsi qu'une charge réduite sur les serveurs de réponse de statut de l'émetteur du certificat, résolvant ainsi un problème qui peut devenir significatif lorsque le certificat émis est présenté par un serveur fréquemment visité.
Il existe deux problèmes avec l'extension Certificate Status existante. Premièrement, elle ne fournit pas de fonctionnalité pour demander les informations de statut concernant les certificats d'autorité de certification intermédiaire (Certification Authority, CA), ce qui signifie que le client doit demander les informations de statut par d'autres méthodes, telles que les listes de révocation de certificats (Certificate Revocation Lists, CRL), introduisant des délais supplémentaires. Deuxièmement, le format actuel de l'extension et les exigences du protocole TLS empêchent un client d'offrir au serveur plusieurs méthodes de statut.
De nombreuses CA émettent maintenant des certificats CA intermédiaires qui spécifient non seulement le point de publication de leurs CRL dans un point de distribution CRL (CRL Distribution Point) [RFC5280], mais spécifient également une URL pour leur serveur OCSP [RFC6960] dans l'accès aux informations d'autorité (Authority Information Access) [RFC5280]. Étant donné que les CRL mises en cache par les clients sont fréquemment obsolètes, les clients bénéficieraient de l'utilisation d'OCSP pour accéder aux informations de statut à jour concernant les certificats CA intermédiaires. L'avantage pour la CA émettrice est moins clair, car fournir la bande passante pour le répondeur OCSP peut être coûteux, en particulier pour les CA avec de nombreux sites d'abonnés à fort trafic, et ce coût est une préoccupation pour de nombreuses CA. Il existe des cas où des requêtes OCSP pour un seul site à fort trafic ont causé des problèmes réseau significatifs pour la CA émettrice.
Les clients bénéficieront du serveur TLS fournissant des informations de statut de certificat quel que soit le type, non seulement pour le certificat du serveur mais aussi pour les certificats CA intermédiaires. La combinaison des vérifications de statut en une seule extension réduira les allers-retours nécessaires pour compléter la poignée de main par le client à ceux strictement nécessaires pour négocier la connexion TLS. De plus, pour les autorités de certification, la charge sur leurs serveurs dépendra du nombre de certificats qu'elles ont émis, et non du nombre de visiteurs de ces sites. En outre, l'utilisation de cette extension réduit considérablement les préoccupations en matière de confidentialité concernant les clients informant l'émetteur du certificat des sites qu'ils visitent.
Pour qu'un tel nouveau système soit introduit de manière transparente, les clients doivent être en mesure d'indiquer la prise en charge de la méthode OCSP Certificate Status existante et d'un nouveau mode OCSP multiple.
Malheureusement, la définition de l'extension Certificate Status ne permet qu'une seule extension Certificate Status d'être définie dans un seul enregistrement d'extension dans la poignée de main, et le protocole TLS [RFC5246] ne permet qu'un seul enregistrement dans la liste d'extensions pour toute extension donnée. Cela signifie qu'il n'est pas possible pour les clients d'indiquer la prise en charge de nouvelles méthodes tout en prenant en charge les anciennes méthodes, ce qui causerait des problèmes d'interopérabilité entre les clients plus récents et les serveurs plus anciens. Cela ne sera pas seulement un problème pour le mode de demande de statut multiple proposé ci-dessus, mais aussi pour toutes autres futures méthodes de statut qui pourraient être introduites. Cela sera vrai non seulement pour l'infrastructure PKIX actuelle [RFC5280], mais aussi pour les structures PKI alternatives.
La solution à ce problème est de définir une nouvelle extension, "status_request_v2", avec un format étendu qui permet au client d'indiquer la prise en charge de plusieurs méthodes de demande de statut. Ceci est implémenté en utilisant une liste d'enregistrements CertificateStatusRequestItemV2 dans l'enregistrement d'extension. Comme le serveur sélectionnera la méthode de statut unique basée sur la suite de chiffrement sélectionnée et le certificat présenté, aucun changement significatif n'est nécessaire dans le format d'extension du serveur.