Appendix A. OCSP over HTTP (OCSP sur HTTP)

Cette section décrit le formatage qui sera effectué sur la demande et la réponse pour prendre en charge HTTP [RFC2616].

A.1. Request (Demande)

Les demandes OCSP basées sur HTTP peuvent utiliser la méthode GET ou POST pour soumettre leurs demandes. Pour activer la mise en cache HTTP, les petites demandes (qui après encodage sont inférieures à 255 octets) PEUVENT (MAY) être soumises en utilisant GET. Si la mise en cache HTTP n'est pas importante ou si la demande est supérieure à 255 octets, la demande DEVRAIT (SHOULD) être soumise en utilisant POST. Lorsque la confidentialité est une exigence, les transactions OCSP échangées utilisant HTTP PEUVENT (MAY) être protégées en utilisant soit Transport Layer Security/Secure Socket Layer (TLS/SSL) ou un autre protocole de couche inférieure.

Une demande OCSP utilisant la méthode GET est construite comme suit :

GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}

où {url} peut être dérivée de la valeur de l'extension d'accès aux informations de l'autorité (authority information access) dans le certificat vérifié pour révocation, ou d'une autre configuration locale du client OCSP.

Une demande OCSP utilisant la méthode POST est construite comme suit : L'en-tête Content-Type a la valeur "application/ocsp-request", tandis que le corps du message est la valeur binaire de l'encodage DER de l'OCSPRequest.

A.2. Response (Réponse)

Une réponse OCSP basée sur HTTP est composée des en-têtes HTTP appropriés, suivis de la valeur binaire de l'encodage DER de l'OCSPResponse. L'en-tête Content-Type a la valeur "application/ocsp-response". L'en-tête Content-Length DEVRAIT (SHOULD) spécifier la longueur de la réponse. D'autres en-têtes HTTP PEUVENT (MAY) être présents et PEUVENT (MAY) être ignorés s'ils ne sont pas compris par le demandeur.