5. Security Considerations (Considérations de sécurité)

Pour que ce service soit efficace, les systèmes utilisant des certificats doivent se connecter au fournisseur de services de statut de certificat. Dans le cas où une telle connexion ne peut être obtenue, les systèmes utilisant des certificats pourraient mettre en œuvre une logique de traitement de CRL comme position de repli.

Une vulnérabilité au déni de service (denial of service) est évidente en ce qui concerne un afflux de requêtes. La production d'une signature cryptographique affecte considérablement le temps de cycle de génération de réponse, exacerbant ainsi la situation. Les réponses d'erreur non signées ouvrent le protocole à une autre attaque par déni de service, où l'attaquant envoie de fausses réponses d'erreur.

L'utilisation de réponses précalculées permet des attaques par rejeu (replay attacks) dans lesquelles une ancienne (bonne) réponse est rejouée avant sa date d'expiration mais après que le certificat a été révoqué. Les déploiements d'OCSP devraient évaluer soigneusement le bénéfice des réponses précalculées par rapport à la probabilité d'une attaque par rejeu et aux coûts associés à son exécution réussie.

Les demandes ne contiennent pas le répondeur auquel elles sont adressées. Cela permet à un attaquant de rejouer une demande à n'importe quel nombre de répondeurs OCSP.

La dépendance à la mise en cache HTTP dans certains scénarios de déploiement peut entraîner des résultats inattendus si les serveurs intermédiaires sont mal configurés ou sont connus pour posséder des défauts de gestion de cache. Il est conseillé aux implémenteurs de prendre en compte la fiabilité des mécanismes de cache HTTP lors du déploiement d'OCSP sur HTTP.

Répondre avec un état "revoked" (révoqué) à un certificat qui n'a jamais été émis peut permettre à quelqu'un d'obtenir une réponse de révocation pour un certificat qui n'est pas encore émis, mais qui le sera bientôt, si le numéro de série du certificat qui sera émis peut être prédit ou deviné par le demandeur. Une telle prédiction est facile pour une AC qui émet des certificats en utilisant une attribution séquentielle de numéros de série de certificats. Ce risque est traité dans la spécification en exigeant que les implémentations conformes utilisent le code de raison certificateHold, ce qui évite de révoquer définitivement le numéro de série. Pour les AC qui prennent en charge les réponses "revoked" aux demandes de statut pour des certificats non émis, une façon d'éviter complètement ce problème est d'attribuer des valeurs aléatoires de numéro de série de certificat avec une entropie élevée.

5.1. Preferred Signature Algorithms (Algorithmes de signature préférés)

Le mécanisme utilisé pour choisir l'algorithme de signature de réponse DOIT (MUST) être considéré comme suffisamment sécurisé contre une attaque cryptanalytique pour l'application prévue.

Dans la plupart des applications, il suffit que l'algorithme de signature soit au moins aussi sécurisé que l'algorithme de signature utilisé pour signer le certificat original dont le statut est demandé. Cependant, ce critère peut ne pas tenir dans les applications d'archivage à long terme, dans lesquelles le statut d'un certificat est demandé pour une date dans le passé lointain, longtemps après que l'algorithme de signature a cessé d'être considéré comme digne de confiance.

5.1.1. Use of Insecure Algorithms (Utilisation d'algorithmes non sécurisés)

Il n'est pas toujours possible pour un répondeur de générer une réponse que le client est censé comprendre et qui répond aux normes contemporaines de sécurité cryptographique. Dans de tels cas, un opérateur de répondeur OCSP DOIT (MUST) équilibrer le risque d'employer une solution de sécurité compromise et le coût d'imposer une mise à niveau, y compris le risque que l'alternative choisie par les utilisateurs finaux offre encore moins de sécurité ou aucune sécurité.

Dans les applications d'archivage, il est tout à fait possible qu'un répondeur OCSP puisse être invité à signaler la validité d'un certificat à une date dans le passé lointain. Un tel certificat pourrait employer une méthode de signature qui n'est plus considérée comme acceptablement sécurisée. Dans de telles circonstances, le répondeur NE DOIT PAS (MUST NOT) générer une signature utilisant un mécanisme de signature qui n'est pas considéré comme acceptablement sécurisé.

Un client DOIT (MUST) accepter tout algorithme de signature dans une réponse qu'il a spécifié comme algorithme de signature préféré dans la demande. Il s'ensuit donc qu'un client NE DOIT PAS (MUST NOT) spécifier comme algorithme de signature préféré tout algorithme qui n'est pas pris en charge ou qui n'est pas considéré comme acceptablement sécurisé.

5.1.2. Man-in-the-Middle Downgrade Attack (Attaque par dégradation de type Man-in-the-Middle)

Le mécanisme pour soutenir l'indication par le client des algorithmes de signature préférés n'est pas protégé contre une attaque par dégradation de type man-in-the-middle (homme du milieu). Cette contrainte n'est pas considérée comme une préoccupation de sécurité significative, puisque le répondeur OCSP NE DOIT PAS (MUST NOT) signer les réponses OCSP en utilisant des algorithmes faibles même si le client le demande. De plus, le client peut rejeter les réponses OCSP qui ne répondent pas à ses propres critères de sécurité cryptographique acceptable, quel que soit le mécanisme utilisé pour déterminer l'algorithme de signature de la réponse.

5.1.3. Denial-of-Service Attack (Attaque par déni de service)

Les mécanismes d'agilité d'algorithme définis dans ce document introduisent une surface d'attaque légèrement accrue pour les attaques par déni de service où la demande du client est modifiée pour exiger des algorithmes qui ne sont pas pris en charge par le serveur. Les considérations de déni de service telles que discutées dans la RFC 4732 [RFC4732] sont pertinentes pour ce document.