2. Protocol Overview (Aperçu du protocole)

Au lieu de, ou en complément de la vérification par rapport à une CRL périodique, il peut être nécessaire d'obtenir des informations opportunes concernant le statut de révocation des certificats (cf. [RFC5280], Section 3.3). Les exemples incluent les transferts de fonds de grande valeur ou les transactions boursières importantes.

Le Online Certificate Status Protocol (Protocole de statut de certificat en ligne, OCSP) permet aux applications de déterminer l'état (de révocation) des certificats identifiés. OCSP peut être utilisé pour satisfaire certaines des exigences opérationnelles de fourniture d'informations de révocation plus opportunes qu'il n'est possible avec les CRL et peut également être utilisé pour obtenir des informations de statut supplémentaires. Un client OCSP émet une demande de statut à un répondeur OCSP et suspend l'acceptation des certificats en question jusqu'à ce que le répondeur fournisse une réponse.

Ce protocole spécifie les données qui doivent être échangées entre une application vérifiant le statut d'un ou plusieurs certificats et le serveur fournissant le statut correspondant.

2.1. Request (Demande)

Une demande OCSP contient les données suivantes :

version du protocole
demande de service
identifiant du certificat cible
extensions optionnelles, qui PEUVENT (MAY) être traitées par le répondeur OCSP

Dès réception d'une demande, un répondeur OCSP détermine si :

le message est bien formé,
le répondeur est configuré pour fournir le service demandé, et
la demande contient les informations nécessaires au répondeur.

Si l'une de ces conditions n'est pas remplie, le répondeur OCSP produit un message d'erreur ; sinon, il renvoie une réponse définitive.

2.2. Response (Réponse)

Les réponses OCSP peuvent être de différents types. Une réponse OCSP se compose d'un type de réponse et des octets de la réponse réelle. Il existe un type de base de réponse OCSP qui DOIT (MUST) être pris en charge par tous les serveurs et clients OCSP. Le reste de cette section ne concerne que ce type de réponse de base.

Tous les messages de réponse définitifs DOIVENT (SHALL) être signés numériquement. La clé utilisée pour signer la réponse DOIT (MUST) appartenir à l'un des suivants :

l'AC (Autorité de Certification) qui a émis le certificat en question
un Trusted Responder (Répondeur de confiance) dont la clé publique est approuvée par le demandeur
un CA Designated Responder (Répondeur désigné par l'AC/Authorized Responder (Répondeur autorisé), défini dans la section 4.2.2.2) qui détient un certificat spécialement marqué émis directement par l'AC, indiquant que le répondeur peut émettre des réponses OCSP pour cette AC

Un message de réponse définitif est composé de :

version de la syntaxe de réponse
identifiant du répondeur
heure à laquelle la réponse a été générée
réponses pour chacun des certificats dans une demande
extensions optionnelles
OID de l'algorithme de signature
signature calculée sur un hachage de la réponse

La réponse pour chacun des certificats dans une demande se compose de :

identifiant du certificat cible
valeur du statut du certificat
intervalle de validité de la réponse
extensions optionnelles

Cette spécification définit les indicateurs de réponse définitifs suivants pour une utilisation dans la valeur du statut du certificat :

good (bon)
revoked (révoqué)
unknown (inconnu)

L'état "good" indique une réponse positive à la demande de statut. Au minimum, cette réponse positive indique qu'aucun certificat avec le numéro de série de certificat demandé actuellement dans son intervalle de validité n'est révoqué. Cet état ne signifie pas nécessairement que le certificat a déjà été émis ou que le moment où la réponse a été produite se situe dans l'intervalle de validité du certificat. Les extensions de réponse peuvent être utilisées pour transmettre des informations supplémentaires sur les affirmations faites par le répondeur concernant le statut du certificat, telles qu'une déclaration positive sur l'émission, la validité, etc.

L'état "revoked" indique que le certificat a été révoqué, soit temporairement (le motif de révocation est certificateHold) ou définitivement. Cet état PEUT (MAY) également être renvoyé si l'AC associée n'a aucune trace d'avoir déjà émis un certificat avec le numéro de série de certificat dans la demande, en utilisant une clé d'émission actuelle ou précédente (appelé certificat "non-issued (non émis)" dans ce document).

L'état "unknown" indique que le répondeur ne connaît pas le certificat demandé, généralement parce que la demande indique un émetteur non reconnu qui n'est pas desservi par ce répondeur.

NOTE : Le statut "revoked" indique qu'un certificat avec le numéro de série demandé doit être rejeté, tandis que le statut "unknown" indique que le statut n'a pas pu être déterminé par ce répondeur, permettant ainsi au client de décider s'il souhaite essayer une autre source d'informations de statut (telle qu'une CRL). Cela rend la réponse "revoked" adaptée aux certificats non émis (tels que définis ci-dessus) où l'intention du répondeur est d'amener le client à rejeter le certificat plutôt que d'essayer une autre source d'informations de statut. Le statut "revoked" est toujours facultatif pour les certificats non émis afin de maintenir la rétrocompatibilité avec les déploiements du RFC 2560. Par exemple, le répondeur peut ne pas avoir connaissance de l'attribution d'un numéro de série demandé à un certificat émis, ou le répondeur peut fournir des réponses pré-produites conformément au RFC 5019 et, pour cette raison, n'est pas en mesure de fournir une réponse signée pour tous les numéros de série de certificats non émis.

Lorsqu'un répondeur envoie une réponse "revoked" à une demande de statut pour un certificat non émis, le répondeur DOIT (MUST) inclure l'extension de réponse extended revoked definition (définition révoquée étendue) (Section 4.4.8) dans la réponse, indiquant que le répondeur OCSP prend en charge la définition étendue de l'état "revoked" pour couvrir également les certificats non émis. De plus, la SingleResponse liée à ce certificat non émis :

DOIT (MUST) spécifier le motif de révocation certificateHold (6),
DOIT (MUST) spécifier l'heure de révocation revocationTime au 1er janvier 1970, et
NE DOIT PAS (MUST NOT) inclure d'extension CRL references (références CRL) (Section 4.4.2) ou d'extensions CRL entry (entrée CRL) (Section 4.4.5).

2.3. Exception Cases (Cas d'exception)

En cas d'erreurs, le répondeur OCSP peut renvoyer un message d'erreur. Ces messages ne sont pas signés. Les erreurs peuvent être des types suivants :

malformedRequest (demande mal formée)
internalError (erreur interne)
tryLater (réessayer plus tard)
sigRequired (signature requise)
unauthorized (non autorisé)

Un serveur produit la réponse "malformedRequest" si la demande reçue n'est pas conforme à la syntaxe OCSP.

La réponse "internalError" indique que le répondeur OCSP a atteint un état interne incohérent. La requête doit être réessayée, potentiellement avec un autre répondeur.

Dans le cas où le répondeur OCSP est opérationnel mais incapable de renvoyer un statut pour le certificat demandé, la réponse "tryLater" peut être utilisée pour indiquer que le service existe mais est temporairement incapable de répondre.

La réponse "sigRequired" est renvoyée dans les cas où le serveur exige que le client signe la demande afin de construire une réponse.

La réponse "unauthorized" est renvoyée dans les cas où le client n'est pas autorisé à effectuer cette requête à ce serveur ou le serveur n'est pas capable de répondre de manière faisant autorité (cf. [RFC5019], Section 2.2.3).

2.4. Semantics of thisUpdate, nextUpdate, and producedAt (Sémantique de thisUpdate, nextUpdate et producedAt)

Les réponses définies dans ce document peuvent contenir quatre heures -- thisUpdate, nextUpdate, producedAt et revocationTime. La sémantique de ces champs est :

thisUpdate : L'heure la plus récente à laquelle le statut indiqué est connu par le répondeur comme étant correct.

nextUpdate : L'heure à laquelle ou avant laquelle des informations plus récentes seront disponibles sur le statut du certificat.

producedAt : L'heure à laquelle le répondeur OCSP a signé cette réponse.

revocationTime : L'heure à laquelle le certificat a été révoqué ou mis en attente.

2.5. Response Pre-Production (Pré-production de réponse)

Les répondeurs OCSP PEUVENT (MAY) pré-produire des réponses signées spécifiant le statut des certificats à une heure spécifiée. L'heure à laquelle le statut était connu comme étant correct DOIT (SHALL) être reflétée dans le champ thisUpdate de la réponse. L'heure à laquelle ou avant laquelle des informations plus récentes seront disponibles est reflétée dans le champ nextUpdate, tandis que l'heure à laquelle la réponse a été produite apparaîtra dans le champ producedAt de la réponse.

2.6. OCSP Signature Authority Delegation (Délégation d'autorité de signature OCSP)

La clé qui signe les informations de statut d'un certificat n'a pas besoin d'être la même clé qui a signé le certificat. L'émetteur d'un certificat délègue explicitement l'autorité de signature OCSP en émettant un certificat contenant une valeur unique pour l'extension extended key usage (utilisation étendue de la clé) (définie dans [RFC5280], Section 4.2.1.12) dans le certificat du signataire OCSP. Ce certificat DOIT (MUST) être émis directement au répondeur par l'AC compétente. Voir la section 4.2.2.2 pour plus de détails.

2.7. CA Key Compromise (Compromission de la clé de l'AC)

Si un répondeur OCSP sait que la clé privée d'une AC particulière a été compromise, il PEUT (MAY) renvoyer l'état "revoked" pour tous les certificats émis par cette AC.