4.4. Extensions (Extensions)

Cette section définit certaines extensions standard, basées sur le modèle d'extension employé dans les certificats X.509 version 3 (voir [RFC5280]). La prise en charge de toutes les extensions est facultative pour les clients et les répondeurs. Pour chaque extension, la définition indique sa syntaxe, le traitement effectué par le répondeur OCSP, et toutes les extensions qui sont incluses dans la réponse correspondante.

4.4.1. Nonce (Nonce)

Le nonce lie cryptographiquement une demande et une réponse pour empêcher les attaques par rejeu. Le nonce est inclus comme l'une des requestExtensions dans les demandes, tandis que dans les réponses, il serait inclus comme l'une des responseExtensions. Dans la demande et la réponse, le nonce sera identifié par l'identifiant d'objet id-pkix-ocsp-nonce, tandis que l'extnValue est la valeur du nonce.

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

Nonce ::= OCTET STRING

4.4.2. CRL References (Références CRL)

Il peut être souhaitable pour le répondeur OCSP d'indiquer la CRL sur laquelle un certificat révoqué ou onHold (en attente) est trouvé. Cela peut être utile lorsque OCSP est utilisé entre des référentiels, et aussi comme mécanisme d'audit. La CRL peut être spécifiée par une URL (l'URL à laquelle la CRL est disponible), un numéro (numéro de CRL), ou une heure (l'heure à laquelle la CRL pertinente a été créée). Ces extensions seront spécifiées comme singleExtensions. L'identifiant pour cette extension sera id-pkix-ocsp-crl, tandis que la valeur sera CrlID.

id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

CrlID ::= SEQUENCE {
    crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
    crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
    crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

Pour le choix crlUrl, l'IA5String spécifiera l'URL à laquelle la CRL est disponible. Pour crlNum, l'INTEGER spécifiera la valeur de l'extension de numéro de CRL de la CRL pertinente. Pour crlTime, le GeneralizedTime indiquera l'heure à laquelle la CRL pertinente a été émise.

4.4.3. Acceptable Response Types (Types de réponse acceptables)

Un client OCSP PEUT (MAY) souhaiter spécifier les types de réponse qu'il comprend. Pour ce faire, il DEVRAIT (SHOULD) utiliser une extension avec l'OID id-pkix-ocsp-response et la valeur AcceptableResponses. Cette extension est incluse comme l'une des requestExtensions dans les demandes. Les OID inclus dans AcceptableResponses sont les OID des différents types de réponse que ce client peut accepter (par exemple, id-pkix-ocsp-basic).

id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

Comme indiqué dans la section 4.2.1, les répondeurs OCSP DOIVENT (SHALL) être capables de répondre avec 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.

4.4.4. Archive Cutoff (Date limite d'archivage)

Un répondeur OCSP PEUT (MAY) choisir de conserver les informations de révocation au-delà de l'expiration d'un certificat. La date obtenue en soustrayant cette valeur d'intervalle de conservation de l'heure producedAt dans une réponse est définie comme la date de "archive cutoff" (date limite d'archivage) du certificat.

Les applications compatibles OCSP utiliseraient une date limite d'archivage OCSP pour contribuer à la preuve qu'une signature numérique était (ou n'était pas) fiable à la date à laquelle elle a été produite, même si le certificat nécessaire pour valider la signature a expiré depuis longtemps.

Les serveurs OCSP qui fournissent une prise en charge pour une telle référence historique DEVRAIENT (SHOULD) inclure une extension de date limite d'archivage dans les réponses. Si elle est incluse, cette valeur DOIT (SHALL) être fournie comme une extension OCSP singleExtensions identifiée par id-pkix-ocsp-archive-cutoff et de syntaxe GeneralizedTime.

id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}

ArchiveCutoff ::= GeneralizedTime

Pour illustrer, si un serveur est exploité avec une politique d'intervalle de conservation de 7 ans et que le statut a été produit à l'heure t1, alors la valeur pour ArchiveCutoff dans la réponse serait (t1 - 7 ans).

4.4.5. CRL Entry Extensions (Extensions d'entrée CRL)

Toutes les extensions spécifiées comme extensions d'entrée CRL -- dans la section 5.3 de [RFC5280] -- sont également prises en charge comme singleExtensions.

4.4.6. Service Locator (Localisateur de service)

Un serveur OCSP peut être exploité dans un mode où le serveur reçoit une demande et l'achemine vers le serveur OCSP qui est connu pour faire autorité pour le certificat identifié. L'extension de demande serviceLocator est définie à cet effet. Cette extension est incluse comme l'une des singleRequestExtensions dans les demandes.

id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}

ServiceLocator ::= SEQUENCE {
    issuer    Name,
    locator   AuthorityInfoAccessSyntax OPTIONAL }

Les valeurs pour ces champs sont obtenues à partir des champs correspondants dans le certificat du sujet.

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

Puisque les algorithmes autres que les algorithmes obligatoires à mettre en œuvre sont autorisés, et puisqu'un client n'a actuellement aucun mécanisme pour indiquer ses préférences d'algorithme, il y a toujours un risque qu'un serveur choisissant un algorithme non obligatoire génère une réponse que le client peut ne pas prendre en charge.

Bien qu'un répondeur OCSP puisse appliquer des règles pour la sélection d'algorithmes, par exemple, en utilisant l'algorithme de signature employé par l'AC pour signer les CRL et les certificats, de telles règles peuvent échouer dans des situations courantes :

L'algorithme utilisé pour signer les CRL et les certificats peut ne pas être cohérent avec la paire de clés utilisée par le répondeur OCSP pour signer les réponses.
Une demande pour un certificat inconnu ne fournit aucune base pour qu'un répondeur choisisse parmi plusieurs options d'algorithme.

Le dernier critère ne peut pas être résolu par les informations disponibles à partir de la signalisation intrabande utilisant le protocole RFC 2560 [RFC2560] sans modifier le protocole.

De plus, un répondeur OCSP peut souhaiter employer des algorithmes de signature différents de celui utilisé par l'AC pour signer les certificats et les CRL pour deux raisons :

Le répondeur peut employer un algorithme pour la réponse de statut de certificat qui est moins exigeant en calcul que pour signer le certificat lui-même.
Une implémentation peut souhaiter se prémunir contre la possibilité d'une compromission résultant d'une compromission d'algorithme de signature en employant deux algorithmes de signature distincts.

Cette section décrit :

Une extension qui permet à un client d'indiquer l'ensemble des algorithmes de signature préférés.
Des règles pour la sélection de l'algorithme de signature qui maximisent la probabilité d'un fonctionnement réussi dans le cas où aucun algorithme préféré pris en charge n'est spécifié.

4.4.7.1. Extension Syntax (Syntaxe de l'extension)

Un client PEUT (MAY) déclarer un ensemble préféré d'algorithmes dans une demande en incluant une extension d'algorithmes de signature préférés dans requestExtensions de l'OCSPRequest.

id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }

PreferredSignatureAlgorithms ::= SEQUENCE OF
                                 PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
   sigIdentifier        AlgorithmIdentifier,
   pubKeyAlgIdentifier  SMIMECapability OPTIONAL
   }

La syntaxe d'AlgorithmIdentifier est définie dans la section 4.1.1.2 de la RFC 5280 [RFC5280]. La syntaxe de SMIMECapability est définie dans la RFC 5751 [RFC5751].

sigIdentifier spécifie l'algorithme de signature que le client préfère, par exemple, algorithm=ecdsa-with-sha256. Les paramètres sont absents pour la plupart des algorithmes de signature courants.

pubKeyAlgIdentifier spécifie l'identifiant d'algorithme de clé publique du sujet que le client préfère dans le certificat du serveur utilisé pour valider la réponse OCSP, par exemple, algorithm=id-ecPublicKey et parameters= secp256r1.

pubKeyAlgIdentifier est FACULTATIF (OPTIONAL) et fournit un moyen de spécifier les paramètres nécessaires pour distinguer entre différentes utilisations d'un algorithme particulier, par exemple, il peut être utilisé par le client pour spécifier quelle courbe il prend en charge pour un algorithme de courbe elliptique donné.

Le client DOIT (MUST) prendre en charge chacun des algorithmes de signature préférés spécifiés, et le client DOIT (MUST) spécifier les algorithmes dans l'ordre de préférence, du plus préféré au moins préféré.

La section 4.4.7.2 de ce document décrit comment un serveur sélectionne un algorithme pour signer les réponses OCSP au client demandeur.

4.4.7.2. Responder Signature Algorithm Selection (Sélection de l'algorithme de signature du répondeur)

La RFC 2560 [RFC2560] n'a pas spécifié de mécanisme pour décider de l'algorithme de signature à utiliser dans une réponse OCSP. Cela ne fournit pas un degré suffisant de certitude quant à l'algorithme sélectionné pour faciliter l'interopérabilité.

4.4.7.2.1. Dynamic Response (Réponse dynamique)

Un répondeur PEUT (MAY) maximiser le potentiel de garantir l'interopérabilité en sélectionnant un algorithme de signature pris en charge en utilisant l'ordre de priorité suivant, tant que l'algorithme sélectionné répond à toutes les exigences de sécurité du répondeur OCSP, où le premier mécanisme de sélection a la plus haute priorité :

Sélectionner un algorithme spécifié comme algorithme de signature préféré dans la demande du client.
Sélectionner l'algorithme de signature utilisé pour signer une liste de révocation de certificats (CRL) émise par l'émetteur de certificat fournissant des informations de statut pour le certificat spécifié par CertID.
Sélectionner l'algorithme de signature utilisé pour signer l'OCSPRequest.
Sélectionner un algorithme de signature qui a été annoncé comme étant l'algorithme de signature par défaut pour le service de signature à l'aide d'un mécanisme hors bande.
Sélectionner un algorithme de signature obligatoire ou recommandé spécifié pour la version d'OCSP utilisée.

Un répondeur DEVRAIT (SHOULD) toujours appliquer le mécanisme de sélection au numéro le plus bas qui aboutit à la sélection d'un algorithme connu et pris en charge qui répond aux critères du répondeur pour la force de l'algorithme cryptographique.

4.4.7.2.2. Static Response (Réponse statique)

À des fins d'efficacité, un répondeur OCSP est autorisé à générer des réponses statiques avant une demande. Le cas peut ne pas permettre au répondeur d'utiliser les données de demande du client pendant la génération de la réponse ; cependant, le répondeur DEVRAIT (SHOULD) toujours utiliser les données de demande du client pendant la sélection de la réponse pré-générée à renvoyer. Les répondeurs PEUVENT (MAY) utiliser les demandes historiques des clients comme partie de l'entrée pour les décisions concernant les différents algorithmes qui devraient être utilisés pour signer les réponses pré-générées.

4.4.8. Extended Revoked Definition (Définition de révoqué étendue)

Cette extension indique que le répondeur prend en charge la définition étendue du statut "revoked" (révoqué) pour inclure également les certificats non émis conformément à la section 2.2. L'un de ses principaux objectifs est de permettre aux audits de déterminer le type d'opération du répondeur. Les clients n'ont pas besoin d'analyser cette extension pour déterminer le statut des certificats dans les réponses.

Cette extension DOIT (MUST) être incluse dans la réponse OCSP lorsque cette réponse contient un statut "revoked" pour un certificat non émis. Cette extension PEUT (MAY) être présente dans d'autres réponses pour signaler que le répondeur implémente la définition de révoqué étendue. Lorsqu'elle est incluse, cette extension DOIT (MUST) être placée dans responseExtensions, et elle NE DOIT PAS (MUST NOT) apparaître dans singleExtensions.

Cette extension est identifiée par l'identifiant d'objet id-pkix-ocsp-extended-revoke.

id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}

La valeur de l'extension DOIT (SHALL) être NULL. Cette extension NE DOIT PAS (MUST NOT) être marquée critique.