Ce document spécifie un protocole servant à déterminer l'état de révocation actuel d'un certificat numérique sans avoir recourt aux CRL (Listes de certificats révoqués). Les mécanismes opérationnels nécessaires concernant PKIX sont spécifiés dans des documents séparés.
La section 2 fournie un aperçu du protocole. Les exigences fonctionnelles sont précisées en section 3. le protocole est détaillé en section 4. La section 5 traite des aspects sécurité du protocole. L'annexe A définie OCSP over HTTP, l'annexe B présente des éléments de syntaxe ASN1. L'annexe C précise les types mime pour les messages.
A la place ou en complément d'une vérification périodique dans une CRL, il peut s'avérer nécessaire d'obtenir ponctuellement le statut de révocation d'un certificat (cf. [RFC2459], Section 3.3), par exemple pour des transferts de fonds importants ou de volumineux échanges de marchés.
l'OCSP permet aux applications de déterminer l'état (de révocation) d'un certificat donné. OCSP peut être utilisé pour satisfaire à des exigences opérationnelles de fourniture d'information de révocation plus ponctuelles qu'il n'est possible de le faire avec les CRL. Il peut également être utilisé pour obtenir des informations complémentaires. Un client OCSP émet une requête d'état de certificat à un serveur OCSP et suspend l'acceptation du certificat en attendant une réponse du serveur.
Ce protocole décrit les données qui nécessitent d'être échangées entre une application qui vérifie l'état d'un certificat et le serveur fournissant l'information.
Les réponses OCSP peuvent être de différents types. Une réponse OCSP se compose d'un type de réponse et des données de ladite réponse. Il y a un type de réponse basique qui doit être supporté par tous les clients et serveurs OCSP.
Toutes les réponses complètes devraient être numériquement signées. La clé utilisée pour la signature doit appartenir à l'une des entités parmi:
La valeur "good" signifie une réponse positive quant au statut recherché. Cette réponse signifie au minimum que le certificat n'est pas révoqué, mais ne signifie pas nécessairement que le certificat a été émis ni que la date à laquelle la réponse à été produite est incluse dans la période de validité du certificat. Les extensions des réponses peuvent servir à fournir des informations complémentaires correspondant à des assertions faites par le répondeur concernant l'état du certificat telles que relatives à la publication, validité, etc.
Le statut "revoked" indique que le certificat a été révoqué (soit de façon permanente soit temporaire (suspendu)).
Le statut "unknown" indique que le répondeur ne dispose pas d'information concernant le certificat faisant l'objet de la requête.
Dans le cas d'erreur, le répondeur OCSP peut retourner un message d'erreur. Ces messages ne sont pas signés. Les erreurs sont parmi les types suivants:
Un message produit une réponse "malformedRequest" si la requête reçue n'est pas conforme à la syntaxe OCSP.
La réponse "malformedRequest" est produite lorsque le serveur ne peut fournir de réponse du fait d'une erreur interne. La requête devrait alors être re-émise vers un autre serveur OCSP.
Dans le cas ou le serveur OCSP est opérationnel mais dans l'incapacité à fournir une réponse pour le certificat questionné, la réponse "tryLater" peut être utilisée pour indiquer que le service existe mais qu'il n'est pas en mesure de répondre temporairement.
La réponse "sigRequired" est retournée lorsque le serveur requiert que le client signe la requête afin de produire la réponse.
La réponse "unauthorized" est émise lorsque le client n'est pas autorisé à formuler cette requête sur ce serveur.
Les réponses peuvent indiquer trois dates: thisUpdate, nextUpdate and producedAt. La sémantique de ces champs est:
Les répondeurs OCSP peuvent pré-produire des réponses signées spécifiant le statut des certificats à un instant donné. La date à laquelle le statut du certificat est connu comme fiable devrait correspondre au champ "thisUpdate" de la réponse. La date à ou avant laquelle sera disponible une nouvelle information correspond au champ nextUpdate, le champ correspondant à la date de production de la réponse correspond au champ "producedAt".
La clé servant à la signature des réponses OCSP ne correspond pas nécessairement à la clé ayant signé le certificat. Un émetteur de certificat peut explicitement déléguer la signature des réponses OCSP en produisant un certificat contenant qu'une seule valeur pour le "extendedKeyUsage" du certificat signataire OCSP. Ce certificat doit être directement émis par cette CA.
Si un serveur OCSP à connaissance de la compromission de la clé privée d'une CA, il peut retourner le statut "revoked" pour tous les certificats émis par cette CA.
Afin de fournir aux clients OCSP un point d'information reconnu, la CA devrait être capable d'inclure l'extension AuthorityInfoAccess (définie dans [RFC2459], section 4.2.2.1) dans les certificats pouvant être vérifiés par OCSP. Accessoirement "accesLocation" désignant le serveur OCSP peut être configuré localement chez les clients OCSP.
Les CA qui supportent le service OCSP, hébergé localement ou fourni par un "Authorized Responder", doivent fournir les valeurs "uniformResourceIndicator" (URI), "accessLocation" et la valeur de l'OID "id-ad-ocsp" pour "accessMethod" dans la séquence "AccessDescription".
La valeur du champ accessLocation dans le certificat concerné définie le mode de transport utilisé pour accéder au serveur OCSP (ex: HTTP) et peut contenir des informations afférentes au transport (ex: URL)
Avant de considérer une réponse signée comme valide, les clients OCSP sont tenus de vérifier que:
La syntaxe ASN.1 emploie des termes définis dans [RFC2459]. Pour la production de signatures, les données à signer sont encodées en ASN.1 Distinguished Encoding Rules (DER) [X.690].
ASN.1 est employé par défaut à moins d'une spécification différente
Les termes employés, provenant ou définis dans d'autres documents sont: "Extensions", "CertificateSerialNumber", "SubjectPublicKeyInfo", "Name", "AlgorithmIdentifier", "CRLReason"
Cette section définit les spécifications ASN.1 pour une requête de confirmation. La mise en forme du message peut varier en fonction du mécanisme de transport utilisé (HTTP, SMTP, LDAP, etc.).
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 Issuers public key
serialNumber CertificateSerialNumber }
issuerNameHash est le hash du "distinguished name" de l'émetteur du certificat. Le hash devrait être calculé à partir de l'encodage DER du champ nom de l'émetteur du certificat vérifié. issuerKeyHash est le hash de la clé publique du issuer. Ce hash devrait être calculé à partir de la valeur du champ de la clé publique (tag et longueur exclue) du certificat de l'issuer. L'algorithme de hachage utilisé est précisé dans hashAlgorithm. serialNumber et le numéro de série du certificat faisant l'objet de la requête.
La principale raison d'utiliser le hash de la clé publique d'une CA en complément à son nom pour identifier l'émetteur du certificat est qu'il est possible que deux CA choisissent d'utiliser le même nom (l'unicité du nom est une recommandation mais ne peut être exigée). Deux CA ne peuvent disposer de la même clé publique à moins que les CA aient explicitement décidé de partager la même clé privée ou que la clé de l'un d'entre elle ait été compromise.
Le support des extensions spécifiques est optionnelle. le drapeau obligatoire ne devrait être utilisé pour aucun d'entre eux. la section 4.4 suggère quelques extensions utiles. Des extensions complémentaires peuvent être définies dans d'autres RFC. Les extensions non reconnues DOIVENT être ignorées (à moins que le drapeau obligatoire soit mis et que les extensions ne soient pas comprises).
L'émetteur d'une requête peut choisir de signer la requête OCSP. Dans ce cas la signature est calculée à partir de la structure "tbsRequest". Si la requête est signée l'émetteur de la requête devrait spécifier son nom dans le champ requestorName. Dans le cas d'une requête signée, il se peut que l'émetteur de la requête inclue des certificats dans le champ certs de "Signature" afin d'aider le serveur OCSP à vérifier la signature
Cette section décrit les spécifications ASN.1 pour une réponse de confirmation. La forme du message peut varier en fonction des mécanismes de transport utilisés (HTTP, SMTP, LDAP, etc.).
Une réponse OCSP est au moins constituée d'un champ "responseStatus" indiquant le stade de traitement de la requête. Si la valeur du champ "responseStatus" correspond à une des conditions d'erreur, les valeurs "responseBytes" ne sont pas précisées.
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 pour les "responseBytes" correspondent à un "OBJECT IDENTIFIER" et à une syntaxe de réponse correspondant à cet OID encodée en OCTET STRING.
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
Pour un serveur émettant des réponses basiques, le champ "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 émetteurs des réponses OCSP devraient être capables de produire des réponses du type "id-pkix-ocsp-basic". De façon analogue les clients OCSP devraient être capables de recevoir et de traiter des réponses du type "id-pkix-ocsp-basic".
La valeur "response" devrait être l'encodage DER de "BasicOCSPResponse"
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
La valeur pour "signature" devrait être calculée à partir du hash de l'encodage DER de "ResponseData"
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 -- this can be replaced with an enumeration
Les champs "thisUpdate" et "nextUpdate" définissent un intervalle recommandé de temps. Cet intervalle correspond à l'intervalle "{thisUpdate, nextUpdate}" dans les CRL. Les réponses dont la valeur de "nextUpdate" est antérieure à la valeur locale de la date doivent être considérées comme inutilisables. Les réponses dans la valeur du champ "thisUpdate" est postérieure à la valeur de la date locale doivent être considérées comme inutilisables. Les réponses dont le champ "nextUpdate" n'est pas valorisé sont équivalentes à des CRL dont le champ "nextUdpdate" n'est pas valorisé (cf. section 2.4).
Le champ "produceAt" indique la date à laquelle cette réponse a été signée.
La clé signant les informations du statut d'un certificat ne doit pas être nécessairement la même clé que celle ayant signé le certificat à vérifier. Il reste néanmoins nécessaire de s'assurer que l'entité signant la réponse est autorisée à le faire. Ainsi, l'émetteur du certificat DOIT soit signer la réponse OCSP, soit explicitement désigner une entité ayant cette autorité. La délégation de l'autorité de signature DEVRAIT être spécifiée par l'inclusion de "id-kp-OCSPSigning" dans une extension extendedKeyUsage du certificat du serveur OCSP. Ce certificat doit être issu directement de la CA ayant émis le certificat concerné.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
Les systèmes ou applications qui s'appuient sur les réponses OCSP DOIVENT être capables de comprendre et traiter la valeur "id-ad-ocspSigning". Ils peuvent fournir un moyen de préciser localement la configuration des autorités signataire OCSP et spécifier une liste de CA pour laquelle chaque autorité signataire de réponses OCSP est reconnue de confiance. Ils DOIVENT rejeter la réponse si le certificat requis pour valider la signature ne répond pas à au moins l'un des critères suivants:
Puisque qu'un serveur OCSP mandaté fourni de l'information pour une ou plusieurs CA, les clients OCSP ont besoin de savoir comment vérifier que le certificat d'un répondeur mandaté n'a pas été révoqué. Les CA peuvent choisir de traiter cette problématique d'une des trois façons suivantes:
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
Les clients faisant appel aux services OCSP DEVRAIENT être capables de traiter les réponses signées par des clés DSA identifiées par l'identifiant sig-alg-oid décrit dans la section 7.2.2 of [RFC2459]. Les clients DEVRAIENT également être capables de traiter les signatures RSA telles que décrites dans la section 7.2.1 of [RFC2459]. Les répondeurs OCSP DEVRAIENT supporter l'algorithme de hachage SHA1.
Cette section décrit quelques extensions standards basées sur le modèle employé dans les certificats X509 v3 (cf.[RFC2459]). Le support des extensions est optionnel aussi bien pour les clients que les serveurs OCSP. Pour chacune des extensions la définition précise la syntaxe, le traitement effectué par le serveur OCSP ainsi que toutes les extensions incluses dans la réponse correspondante.
Le nonce lie de façon cryptographique une requête à une réponse afin de se prémunir des attaques de type re-jeu. Le nonce est inclus en tant que des "requestExtensions" dans les requêtes, et des "responseExtensions" dans les réponses. Aussi bien dans la réponse que dans la requête, le nonce est identifié par l'identifiant d'objet "id-pkix-ocsp-nonce"; le nonce ayant pour valeur "extnValue".
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Il peut être souhaitable pour un répondeur OCSP d'indiquer la CRL dans laquelle le certificat révoqué ou suspendu à été trouvé. Cela peut être utile lorsque l'OCSP "is used between repositories", et également comme un mécanisme d'audit. La CRL peut être désignée par une URL (l'URL ou la CRL est disponible), un numéro (numéro de CRL), une date (la date de création de la CRL concernée). Ces extensions seront indiquées dans "singleExtensions". L'identifiant pour cette extension est "id-pkix-ocsp-crl" et 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 }
Concernant le choix de crlUrl, IA5String désigne l'URL où la CRL est disponible. pour CrlNum, l'INTEGER désigne la valeur de l'extension CRL number de la CRL concernée. Pour crlTime, CeneralizedTime indiquera la date de production de la CRL.
Un client OCSP peut souhaiter spécifier le type de réponse qu'il comprend. A cette fin il DEVRAIT utiliser une extension avec l'OID "id-pkix-ocsp-response" avec la valeur "AcceptableResponse". Cette extension fait partie des "resquestExtensions" dans les requêtes. Les OID inclus dans "AcceptableResponse" sont les OID des différents types de réponse que le client accepte (ex: id-pkix-ocsp 4).
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
Conformément à ce qui a été indiqué dans la section section 4.2.1., les répondeurs OCSP doivent être capables de fournir des réponses du type "id-pkix-ocsp-basic". De façon analogue les clients OCSP DEVRAIENT pouvoir comprendre et traiter les réponses du type "id-pkix-ocsp-basic".
Un répondeur OCSP peut décider de fournir des informations relatives à la révocation d'un certificat antérieurement à la date d'expiration du de ce dernier. La durée obtenue par la différence entre cette date et la valeur de "produceAt" dans une réponse, définit la durée de remontée des archives pour le certificat.
Une application disposant de l'OCSP pourrait utiliser la remontée dans les archives pour contribuer à fournir la preuve qu'une signature numérique était (ou n'était pas) de confiance à la date à laquelle elle a été produite, même si le certificat nécessaire à la validation de la signature a expiré depuis longtemps.
Les serveurs OCSP fournissant ce genre de services DEVRAIENT inclure une extension pour la remonté d'archive dans les réponses. Si incluse, cette valeur DEVRAIT être fournie comme une singleExtensions identifiée par l'OID "id-pkix-ocsp-archive-cutoff".
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
ArchiveCutoff ::= GeneralizedTime
A titre d'exemple, si un serveur opère avec un intervalle de remonté des archives de 7 ans, et que le statut du certificat ait été produit à t1, alors la durée de remonté dans les archives serait de (7-t1).
Toutes les extensions spécifiées en tant qu'"Entry Extensions" de la section 5.3 de la [RFC2459] sont également supportées en tant que "singleExtensions".
Un serveur OCSP peut être mis en place de façon à ce que lorsqu'il reçoit une requête, celle-ci soit alors transmise à un serveur disposant de l'autorité pour statuer sur le certificat concerné. L'extension "serviceLocator" de la requête est définie à cette fin. Cette extension est incluse dans des "singleRequestExtensions" de la requête.
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }
Afin d'être efficace, les systèmes utilisant des certificats doivent se connecter au fournisseur du service d'information du statut. Dans l'éventualité où cette connexion ne pourrait être établie, ces systèmes pourraient implémenter un traitement des CRL comme service de secours.
Une vulnérabilité au déni de service est évidente en cas d'afflux massif de requêtes. La génération d'une signature cryptographique affecte de plus le cycle de temps d'une réponse, accentuant la vulnérabilité. Les erreurs non signées exposent le protocole à une autre attaque par DoS dans laquelle l'attaquant enverrait des messages d'erreurs falsifiés.
L'utilisation de réponses pré-générées ouvre la voie aux attaques de type re-jeu dans lesquelles, une ancienne réponse ("good") est réutilisée avant son expiration mais après que le certificat ait été révoqué. Le déploiement d'un service OCSP devrait évaluer le bénéfice que peuvent apporter des réponses pré-générées au regard de l'exposition à une attaque de ce type qu'elle apporte mais aussi au coût engendré si une telle attaque devait aboutir.
Les requêtes n'indiquent pas à quel serveur elles sont destinées. Cela permet à un attaquant de rejouer une requête vers n'importe quel serveur OCSP
L'intégration de cache HTTP dans certains déploiements peut résulter en des résultats inattendus si certains serveurs intermédiaires sont mal configurés ou connus pour avoir des problèmes de gestion de cache. Il est conseillé aux personnes assurant le déploiement d'OCSP over HTTP de tenir compte des mécanismes de cache HTTP.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,
Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
Michael Myers
VeriSign, Inc.
1350 Charleston Road
Mountain View, CA 94043
EMail: mmyers@verisign.com
Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA 20151
EMail: rankney@erols.com
Ambarish Malpani
ValiCert, Inc.
1215 Terra Bella Ave.
Mountain View, CA 94043
Phone: 650.567.5457
EMail: ambarish@valicert.com
Slava Galperin
My CFO, Inc.
1945 Charleston Road
Mountain View, CA
EMail: galperin@mycfo.com
Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario
K1V 1A7
Canada
EMail: cadams@entrust.com
Cette section décrit le formatage appliqué aux requêtes et réponses pour supporter HTTP.
Les requêtes OCSP basées sur le protocole OCSP peuvent soit utiliser la méthode GET ou POST pour soumettre leurs requêtes. Afin de permettre le cache HTTP, les petites requêtes (moins de 255 octets après encodage) DEVRAIENT être soumises avec la méthode GET. Si le cache HTTP n'est pas important ou que les requêtes sont plus grandes que 255 octets, la requête devrait alors être soumise à l'aide de la méthode POST. Lorsque la confidentialité est requise, les requêtes OCSP transitant par HTTP PEUVENT être protégées en utilisant TLS/SSL ou d'autres protocoles de plus bas niveaux.
Une requête OCSP utilisant la méthode GET est construite de la façon suivante:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
Une requête OCSP utilisant la méthode POST est construite de la façon suivante: le "Content-Type" de l'entête possède la valeur "application/ocsp-request", le corps du message est la valeur binaire de l'encodage "DER de OCSPRequest"
Une réponse OCSP basée sur HTTP est composée des entêtes adéquates, suivies de la valeur binaire de l'encodage DER "OCSPResponse". le "Content-Type" de l'entête à la valeur "application/ocsp-response". Le "Content-Length" de l'en-tête DEVRAIT indiquer la longueur de la réponse. D'autres entêtes HTTP PEUVENT être présentes et PEUVENT être ignorées si elles ne sont comprises par le requêteur.
OCSP DEFINITIONS EXPLICIT TAGS::=
BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier, CRLReason
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
Name, GeneralName, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)};
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 Issuers public key
serialNumber CertificateSerialNumber }
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
}
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
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 -- this can be replaced with an enumeration
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
-- Object Identifiers
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
END
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-request
MIME media type name: application
MIME subtype name: ocsp-request
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a request for information. This
request may optionally be cryptographically signed.
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Online
Certificate Status Protocol - OCSP
Applications which use this media type: OCSP clients
Additional information:
Magic number(s): None
File extension(s): .ORQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani
C.2. application/ocsp-response
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-response
MIME media type name: application
MIME subtype name: ocsp-response
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographically signed response
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Online
Certificate Status Protocol - OCSP
Applications which use this media type: OCSP servers
Additional information:
Magic number(s): None
File extension(s): .ORS
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani
Intended usage: COMMON
Author/Change controller: