Aller au contenu principal

4. Details of the Protocol (Détails du protocole)

4. Details of the Protocol (Détails du protocole)​

La syntaxe ASN.1 importe les termes définis dans [RFC5280]. Pour le calcul de la signature, les données à signer sont encodées à l'aide des règles d'encodage distinctes (DER - Distinguished Encoding Rules) ASN.1 [X.690].

L'étiquetage ASN.1 EXPLICIT est utilisé par défaut, sauf indication contraire.

Les termes importés d'ailleurs sont Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier et CRLReason.

4.1. Request Syntax (Syntaxe de la demande)​

Cette section spécifie la spécification ASN.1 pour une demande de confirmation. Le formatage réel du message pourrait varier en fonction du mécanisme de transport utilisé (HTTP, SMTP, LDAP, etc.).

4.1.1. ASN.1 Specification of the OCSP Request (Spécification ASN.1 de la demande OCSP)​

La structure ASN.1 correspondant à OCSPRequest est :

OCSPRequest     ::=     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
    version             [0]     EXPLICIT Version DEFAULT v1,
    requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
    requestList                 SEQUENCE OF Request,
    requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

Signature       ::=     SEQUENCE {
    signatureAlgorithm      AlgorithmIdentifier,
    signature               BIT STRING,
    certs               [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}

Version         ::=             INTEGER  {  v1(0) }

Request         ::=     SEQUENCE {
    reqCert                     CertID,
    singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

CertID          ::=     SEQUENCE {
    hashAlgorithm       AlgorithmIdentifier,
    issuerNameHash      OCTET STRING, -- Hash of issuer's DN
    issuerKeyHash       OCTET STRING, -- Hash of issuer's public key
    serialNumber        CertificateSerialNumber }

Les champs dans OCSPRequest ont les significations suivantes :

  • tbsRequest est la demande OCSP signée facultativement.

  • optionalSignature contient l'identifiant de l'algorithme et tous les paramètres d'algorithme associés in signatureAlgorithm ; la valeur de signature in signature ; et, facultativement, les certificats dont le serveur a besoin pour vérifier la réponse signée (normalement jusqu'à, mais sans inclure, le certificat racine du client).

Le contenu de TBSRequest comprend les champs suivants :

  • version indique la version du protocole, qui pour ce document est v1(0).

  • requestorName est FACULTATIF (OPTIONAL) et indique le nom du demandeur OCSP.

  • requestList contient une ou plusieurs demandes de statut de certificat unique.

  • requestExtensions est FACULTATIF (OPTIONAL) et inclut les extensions applicables aux demandes trouvées dans reqCert. Voir la section 4.4.

Le contenu de Request comprend les champs suivants :

  • reqCert contient l'identifiant d'un certificat cible.

  • singleRequestExtensions est FACULTATIF (OPTIONAL) et inclut les extensions applicables à cette demande de statut de certificat unique. Voir la section 4.4.

Le contenu de CertID inclut les champs suivants :

  • hashAlgorithm est l'algorithme de hachage utilisé pour générer les valeurs issuerNameHash et issuerKeyHash.

  • issuerNameHash est le hachage du nom distinctif (DN) de l'émetteur. Le hachage doit être calculé sur l'encodage DER du champ de nom de l'émetteur dans le certificat en cours de vérification.

  • issuerKeyHash est le hachage de la clé publique de l'émetteur. Le hachage doit être calculé sur la valeur (à l'exclusion de la balise et de la longueur) du champ de clé publique du sujet dans le certificat de l'émetteur.

  • serialNumber est le numéro de série du certificat pour lequel le statut est demandé.

4.1.2. Notes on OCSP Requests (Notes sur les demandes OCSP)​

La principale raison d'utiliser le hachage de la clé publique de l'AC en plus du hachage du nom de l'AC pour identifier l'émetteur est qu'il est possible que deux AC choisissent d'utiliser le même Nom (l'unicité du Nom est une recommandation qui ne peut pas être appliquée). Cependant, deux AC n'auront jamais la même clé publique à moins que les AC n'aient explicitement décidé de partager leur clé privée ou que la clé de l'une des AC n'ait été compromise.

La prise en charge de toute extension spécifique est FACULTATIVE (OPTIONAL). Le drapeau critique NE DEVRAIT PAS (SHOULD NOT) être défini pour l'une d'entre elles. La section 4.4 suggère plusieurs extensions utiles. Des extensions supplémentaires PEUVENT (MAY) être définies dans des RFC supplémentaires. Les extensions non reconnues DOIVENT (MUST) être ignorées (à moins qu'elles n'aient le drapeau critique défini et ne soient pas comprises).

Le demandeur PEUT (MAY) choisir de signer la demande OCSP. Dans ce cas, la signature est calculée sur la structure tbsRequest. Si la demande est signée, le demandeur DOIT (SHALL) spécifier son nom dans le champ requestorName. De plus, pour les demandes signées, le demandeur PEUT (MAY) inclure des certificats qui aident le répondeur OCSP à vérifier la signature du demandeur dans le champ certs de Signature.

4.2. Response Syntax (Syntaxe de la réponse)​

Cette section spécifie la spécification ASN.1 pour une réponse de confirmation. Le formatage réel du message pourrait varier en fonction du mécanisme de transport utilisé (HTTP, SMTP, LDAP, etc.).

4.2.1. ASN.1 Specification of the OCSP Response (Spécification ASN.1 de la réponse OCSP)​

Une réponse OCSP consiste au minimum en un champ responseStatus indiquant le statut de traitement de la demande précédente. Si la valeur de responseStatus est l'une des conditions d'erreur, le champ responseBytes n'est pas défini.

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),  -- Response has valid confirmations
    malformedRequest      (1),  -- Illegal confirmation request
    internalError         (2),  -- Internal error in issuer
    tryLater              (3),  -- Try again later
                                -- (4) is not used
    sigRequired           (5),  -- Must sign the request
    unauthorized          (6)   -- Request unauthorized
}

La valeur de responseBytes consiste en un OBJECT IDENTIFIER et une syntaxe de réponse identifiée par cet OID encodé sous forme de OCTET STRING.

ResponseBytes ::=       SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

Pour un répondeur OCSP de base, responseType sera id-pkix-ocsp-basic.

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

Les répondeurs OCSP DOIVENT (SHALL) être capables de produire des réponses du type de réponse id-pkix-ocsp-basic. De même, les clients OCSP DOIVENT (SHALL) être capables de recevoir et de traiter les réponses du type de réponse id-pkix-ocsp-basic.

La valeur de response DOIT (SHALL) être l'encodage DER de BasicOCSPResponse.

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

La valeur de signature DOIT (SHALL) être calculée sur le hachage de l'encodage DER de ResponseData. Le répondeur PEUT (MAY) inclure des certificats dans le champ certs de BasicOCSPResponse qui aident le client OCSP à vérifier la signature du répondeur. Si aucun certificat n'est inclus, alors certs DEVRAIT (SHOULD) être absent.

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good        [0]     IMPLICIT NULL,
    revoked     [1]     IMPLICIT RevokedInfo,
    unknown     [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL

4.2.2. Notes on OCSP Responses (Notes sur les réponses OCSP)​

4.2.2.1. Time (Heure)​

Les réponses peuvent contenir quatre heures -- thisUpdate, nextUpdate, producedAt et revocationTime. La sémantique de ces champs est définie dans la section 2.4. Le format de GeneralizedTime est tel que spécifié dans la section 4.1.2.5.2 de [RFC5280].

Les champs thisUpdate et nextUpdate définissent un intervalle de validité recommandé. Cet intervalle correspond à l'intervalle {thisUpdate, nextUpdate} dans les CRL. Les réponses dont la valeur nextUpdate est antérieure à la valeur de l'heure système locale DEVRAIENT (SHOULD) être considérées comme non fiables. Les réponses dont l'heure thisUpdate est postérieure à l'heure système locale DEVRAIENT (SHOULD) être considérées comme non fiables.

Si nextUpdate n'est pas défini, le répondeur indique que des informations de révocation plus récentes sont disponibles tout le temps.

4.2.2.2. Authorized Responders (Répondeurs autorisés)​

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. Il est nécessaire, cependant, de s'assurer que l'entité signant cette information est autorisée à le faire. Par conséquent, un émetteur de certificat DOIT (MUST) faire l'une des choses suivantes :

  • signer les réponses OCSP lui-même, ou

  • désigner explicitement cette autorité à une autre entité

La délégation de signature OCSP DOIT (SHALL) être désignée par l'inclusion de id-kp-OCSPSigning dans une extension de certificat d'utilisation étendue de clé incluse dans le certificat du signataire de la réponse OCSP. Ce certificat DOIT (MUST) être émis directement par l'AC identifiée dans la demande.

L'AC DEVRAIT (SHOULD) utiliser la même clé d'émission pour émettre un certificat de délégation que celle utilisée pour signer le certificat faisant l'objet de la vérification de révocation. Les systèmes s'appuyant sur les réponses OCSP DOIVENT (MUST) reconnaître un certificat de délégation comme étant émis par l'AC qui a émis le certificat en question uniquement si le certificat de délégation et le certificat faisant l'objet de la vérification de révocation ont été signés par la même clé.

Note : Pour la rétrocompatibilité avec le RFC 2560 [RFC2560], il n'est pas interdit d'émettre un certificat pour un Authorized Responder en utilisant une clé d'émission différente de la clé utilisée pour émettre le certificat faisant l'objet de la vérification de révocation. Cependant, une telle pratique est fortement déconseillée, car les clients ne sont pas tenus de reconnaître un répondeur avec un tel certificat comme un Authorized Responder.

id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

Les systèmes ou applications qui s'appuient sur les réponses OCSP DOIVENT (MUST) être capables de détecter et d'appliquer l'utilisation de la valeur id-kp-OCSPSigning comme décrit ci-dessus. Ils PEUVENT (MAY) fournir un moyen de configurer localement une ou plusieurs autorités de signature OCSP et de spécifier l'ensemble des AC pour lesquelles chaque autorité de signature est approuvée. Ils DOIVENT (MUST) rejeter la réponse si le certificat requis pour valider la signature sur la réponse ne répond pas à au moins l'un des critères suivants :

  1. Correspond à une configuration locale de l'autorité de signature OCSP pour le certificat en question, ou

  2. Est le certificat de l'AC qui a émis le certificat en question, ou

  3. Inclut une valeur de id-kp-OCSPSigning dans une extension d'utilisation étendue de clé et est émis par l'AC qui a émis le certificat en question comme indiqué ci-dessus.

Des critères supplémentaires d'acceptation ou de rejet peuvent s'appliquer soit à la réponse elle-même, soit au certificat utilisé pour valider la signature sur la réponse.

4.2.2.2.1. Revocation Checking of an Authorized Responder (Vérification de la révocation d'un répondeur autorisé)​

Puisqu'un répondeur OCSP autorisé fournit des informations de statut pour une ou plusieurs AC, les clients OCSP doivent savoir comment vérifier que le certificat d'un Authorized Responder n'a pas été révoqué. Les AC peuvent choisir de traiter ce problème de l'une des trois manières suivantes :

  • Une AC peut spécifier qu'un client OCSP peut faire confiance à un répondeur pour la durée de vie du certificat du répondeur. L'AC le fait en incluant l'extension id-pkix-ocsp-nocheck. Cela DEVRAIT (SHOULD) être une extension non critique. La valeur de l'extension DOIT (SHALL) être NULL. Les AC émettant un tel certificat devraient réaliser qu'une compromission de la clé du répondeur est aussi grave que la compromission d'une clé d'AC utilisée pour signer des CRL, au moins pour la période de validité de ce certificat. Les AC peuvent choisir d'émettre ce type de certificat avec une durée de vie très courte et de le renouveler fréquemment.
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

  • Une AC peut spécifier comment le certificat du répondeur doit être vérifié pour révocation. Cela peut être fait en utilisant des points de distribution CRL si la vérification doit être effectuée à l'aide de CRL, ou en utilisant l'Accès aux Informations de l'Autorité si la vérification doit être effectuée d'une autre manière. Les détails pour spécifier l'un de ces deux mécanismes sont disponibles dans [RFC5280].

  • Une AC peut choisir de ne spécifier aucune méthode de vérification de révocation pour le certificat du répondeur, auquel cas ce serait à la politique de sécurité locale du client OCSP de décider si ce certificat doit être vérifié pour révocation ou non.

4.2.2.3. Basic Response (Réponse de base)​

Le type de réponse de base contient :

  • la version de la syntaxe de réponse, qui DOIT (MUST) être v1 (la valeur est 0) pour cette version de la syntaxe de réponse de base ;

  • soit le nom du répondeur, soit un hachage de la clé publique du répondeur comme ResponderID ;

  • l'heure à laquelle la réponse a été générée ;

  • les réponses pour chacun des certificats dans une demande ;

  • les extensions facultatives ;

  • une signature calculée sur un hachage de la réponse ; et

  • l'OID de l'algorithme de signature.

Le but des informations ResponderID est de permettre aux clients de trouver le certificat utilisé pour signer une réponse OCSP signée. Par conséquent, les informations DOIVENT (MUST) correspondre au certificat qui a été utilisé pour signer la réponse.

Le répondeur PEUT (MAY) inclure des certificats dans le champ certs de BasicOCSPResponse qui aident le client OCSP à vérifier la signature du répondeur.

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

  • un identifiant du certificat pour lequel les informations de statut de révocation sont fournies (c'est-à-dire le certificat cible) ;

  • le statut de révocation du certificat (good, revoked ou unknown) ; s'il est révoqué, il indique l'heure à laquelle le certificat a été révoqué et, facultativement, la raison pour laquelle il a été révoqué ;

  • l'intervalle de validité de la réponse ; et

  • les extensions facultatives.

La réponse DOIT (MUST) inclure une SingleResponse pour chaque certificat dans la demande. La réponse NE DEVRAIT PAS (SHOULD NOT) inclure d'éléments SingleResponse supplémentaires, mais, par exemple, les répondeurs OCSP qui pré-génèrent des réponses de statut pourraient inclure des éléments SingleResponse supplémentaires si nécessaire pour améliorer les performances de pré-génération de réponse ou l'efficacité du cache (selon [RFC5019], Section 2.2.1).

4.3. Mandatory and Optional Cryptographic Algorithms (Algorithmes cryptographiques obligatoires et facultatifs)​

Les clients qui demandent des services OCSP DOIVENT (SHALL) être capables de traiter des réponses signées à l'aide de RSA avec SHA-256 (identifié par l'OID sha256WithRSAEncryption spécifié dans [RFC4055]). Les clients DEVRAIENT (SHOULD) également être capables de traiter des réponses signées à l'aide de RSA avec SHA-1 (identifié par l'OID sha1WithRSAEncryption spécifié dans [RFC3279]) et l'algorithme de signature numérique (DSA) avec SHA-1 (identifié par l'OID id-dsa-with-sha1 spécifié dans [RFC3279]). Les clients PEUVENT (MAY) prendre en charge d'autres algorithmes.

Dernière mise à jour le