1. Introduction (Introduction)
1. Introduction (Introduction)
Ce document spécifie un protocole utile pour déterminer le statut actuel d'un certificat numérique sans nécessiter de CRLs. Des mécanismes supplémentaires répondant aux exigences opérationnelles de PKIX sont spécifiés dans des documents séparés.
Cette spécification rend obsolètes [RFC2560] et [RFC6277]. La raison principale de la publication de ce document est de lever les ambiguïtés qui ont été trouvées depuis la publication du RFC 2560. Ce document ne diffère du RFC 2560 que dans quelques domaines :
-
La section 2.2 étend l'utilisation de la réponse "revoked (révoqué)" pour permettre ce statut de réponse pour les certificats qui n'ont jamais été émis.
-
La section 2.3 étend l'utilisation de la réponse d'erreur "unauthorized (non autorisé)", telle que spécifiée dans [RFC5019].
-
Les sections 4.2.1 et 4.2.2.3 indiquent qu'une réponse peut inclure des informations sur le statut de révocation pour des certificats qui n'étaient pas inclus dans la demande, comme permis dans [RFC5019].
-
La section 4.2.2.2 clarifie quand un répondeur est considéré comme un Authorized Responder (Répondeur autorisé).
-
La section 4.2.2.3 clarifie que le champ ResponderID correspond au certificat du signataire du répondeur OCSP.
-
La section 4.3 modifie l'ensemble des algorithmes cryptographiques que les clients doivent supporter et l'ensemble des algorithmes cryptographiques que les clients devraient supporter, tel que spécifié dans [RFC6277].
-
La section 4.4.1 spécifie, pour l'extension nonce, la syntaxe ASN.1 qui manquait dans le RFC 2560.
-
La section 4.4.7 spécifie une nouvelle extension qui peut être incluse dans un message de demande pour spécifier les algorithmes de signature que le client préférerait que le serveur utilise pour signer la réponse, tel que spécifié dans [RFC6277].
-
La section 4.4.8 spécifie une nouvelle extension qui indique que le répondeur supporte l'utilisation étendue de la réponse "revoked" pour les certificats non émis définis dans la section 2.2.
-
L'annexe B.2 fournit un module ASN.1 utilisant la syntaxe 2008 de l'ASN.1, qui met à jour [RFC5912].
Un aperçu du protocole est fourni dans la section 2. Les exigences fonctionnelles sont spécifiées dans la section 3. Les détails du protocole sont discutés dans la section 4. Nous couvrons les problèmes de sécurité avec le protocole dans la section 5. L'annexe A définit OCSP sur HTTP, l'annexe B fournit les éléments syntaxiques ASN.1, et l'annexe C spécifie les types MIME pour les messages.
1.1. Requirements Language (Langue des exigences)
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le RFC 2119 [RFC2119].