RFC 6960
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Part 1 of 7 🎀
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP 🎀
Okay bestie, the title block is giving "who made this and why does it matter" 🧚 This is RFC 6960, and it's an Internet Standards Track document, so it's an actual spec people build against 💅 It came from the Internet Engineering Task Force (IETF) in June 2013, with ISSN 2070-1721. The authors are S. Santesson (3xA Security), M. Myers and R. Ankney (both TraceRoute Security), A. Malpani (CA Technologies), S. Galperin (A9), and C. Adams (University of Ottawa) 🫶
It obsoletes RFCs 2560 and 6277, so those are out of date now 💀 It also updates RFC 5912 ✨
Abstract ✨
Okay so the whole point 🔐 is a protocol for figuring out if a digital certificate is still valid right now, without needing Certificate Revocation Lists (CRLs). There are extra mechanisms for PKIX operational stuff, but those live in separate documents 📄 This doc obsoletes RFCs 2560 and 6277, and it also updates RFC 5912 🦋
Status of This Memo 🌸
This is an Internet Standards Track document, bestie 💖
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 🔥
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6960 🧚
Copyright Notice 🎀
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 👑 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶
Table of Contents 📚
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Protocol Overview ...............................................5
2.1. Request ....................................................5
2.2. Response ...................................................6
2.3. Exception Cases ............................................8
2.4. Semantics of thisUpdate, nextUpdate, and producedAt ........9
2.5. Response Pre-Production ....................................9
2.6. OCSP Signature Authority Delegation .......................10
2.7. CA Key Compromise .........................................10
3. Functional Requirements ........................................10
3.1. Certificate Content .......................................10
3.2. Signed Response Acceptance Requirements ...................10
4. Details of the Protocol ........................................11
4.1. Request Syntax ............................................11
4.1.1. ASN.1 Specification of the OCSP Request ............11
4.1.2. Notes on OCSP Requests .............................13
4.2. Response Syntax ...........................................14
4.2.1. ASN.1 Specification of the OCSP Response ...........14
4.2.2. Notes on OCSP Responses ............................16
4.2.2.1. Time ......................................16
4.2.2.2. Authorized Responders .....................16
4.2.2.2.1. Revocation Checking of
an Authorized Responder ........17
4.2.2.3. Basic Response ............................18
4.3. Mandatory and Optional Cryptographic Algorithms ...........19
4.4. Extensions ................................................19
4.4.1. Nonce ..............................................20
4.4.2. CRL References .....................................20
4.4.3. Acceptable Response Types ..........................20
4.4.4. Archive Cutoff .....................................21
4.4.5. CRL Entry Extensions ...............................21
4.4.6. Service Locator ....................................22
4.4.7. Preferred Signature Algorithms .....................22
4.4.7.1. Extension Syntax ..........................23
4.4.7.2. Responder Signature Algorithm Selection ...24
4.4.7.2.1. Dynamic Response ...............24
4.4.7.2.2. Static Response ................25
4.4.8. Extended Revoked Definition ........................25
5. Security Considerations ........................................26
5.1. Preferred Signature Algorithms ............................27
5.1.1. Use of Insecure Algorithms .........................27
5.1.2. Man-in-the-Middle Downgrade Attack .................27
5.1.3. Denial-of-Service Attack ...........................28
6. IANA Considerations ............................................28
7. References .....................................................28
7.1. Normative References ......................................28
7.2. Informative References ....................................29
8. Acknowledgements ...............................................29
Appendix A. OCSP over HTTP ........................................30
A.1. Request ....................................................30
A.2. Response ...................................................30
Appendix B. ASN.1 Modules .........................................30
B.1. OCSP in ASN.1 - 1998 Syntax ................................31
B.2. OCSP in ASN.1 - 2008 Syntax ................................34
Appendix C. MIME Registrations ....................................39
C.1. application/ocsp-request ...................................39
C.2. application/ocsp-response ..................................401. Introduction ✨
Okay so this doc is about a protocol for checking the current status of a digital certificate without needing CRLs 🔐 Other PKIX operational mechanisms get their own separate documents 📄
This spec obsoletes [RFC2560] and [RFC6277] 💀 The main reason it exists is to clear up ambiguities people found after RFC 2560 came out. Here's how this one differs from RFC 2560, and honestly it's only a few areas 🦋
- Section 2.2 extends the use of the "revoked" response so it can also be used for certificates that have never been issued 🙈
- Section 2.3 extends the use of the "unauthorized" error response, as specified in [RFC5019] 🌸
- Sections 4.2.1 and 4.2.2.3 say that a response may include revocation status information for certificates that were not included in the request, as permitted in [RFC5019] ✨
- Section 4.2.2.2 clarifies when a responder counts as an Authorized Responder 👑
- Section 4.2.2.3 clarifies that the ResponderID field matches the OCSP responder signer certificate 🧚
- Section 4.3 changes the set of cryptographic algorithms that clients must support, and the set that clients should support, as specified in [RFC6277] 🔥
- Section 4.4.1 specifies ASN.1 syntax for the nonce extension, which was missing from RFC 2560 💅
- Section 4.4.7 specifies a new extension that a client may include in a request to tell the server which signature algorithms it would prefer for signing the response, as specified in [RFC6277] 🫶
- Section 4.4.8 specifies a new extension that indicates the responder supports the extended use of the "revoked" response for non-issued certificates, as defined in Section 2.2 💖
- Appendix B.2 provides an ASN.1 module using the 2008 syntax of ASN.1, which updates [RFC5912] 🌈
So the roadmap: the overview is in Section 2, the functional requirements are in Section 3, and the protocol details are in Section 4. Security issues are covered in Section 5 😭 Appendix A defines OCSP over HTTP, Appendix B has the ASN.1 syntactic elements, and Appendix C specifies the MIME types for the messages 🍓
1.1. Requirements Language 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Those are the ones with the real force, so pay attention to them 👑
2. Protocol Overview 🔐
Okay, so in lieu of checking a periodic CRL, or as a supplement to one, it may be necessary to get timely info about whether certificates are revoked (cf. [RFC5280], Section 3.3) ⭐ Examples are high-value funds transfers or big stock trades 💸
The Online Certificate Status Protocol (OCSP) lets applications find out the (revocation) state of identified certificates 🦋 OCSP can help meet some operational requirements for getting more timely revocation info than CRLs can give, and it can also be used to get extra status info 🧚 An OCSP client sends a status request to an OCSP responder and holds off on accepting the certificates in question until the responder replies 🫶
This protocol specifies the data that needs to be exchanged between an application checking the status of one or more certificates and the server giving the matching status 💜
2.1. Request 📨
Every OCSP request has these pieces of data 🌸
- protocol version 🎀
- service request 🎀
- target certificate identifier 🎀
- optional extensions, which MAY be processed by the OCSP responder 🎀
When the OCSP responder gets a request, it checks three things 👀
- whether the message is well formed,
- whether the responder is configured to provide the requested service, and
- whether the request contains the information the responder needs.
If any one of those conditions isn't met, the OCSP responder sends back an error message 💀 Otherwise, it returns a definitive response ✨
2.2. Response ✨
okay so OCSP responses come in different types 🎀 every response is a response type plus the bytes of the actual response. there's one basic type that MUST be supported by all OCSP servers and clients 💅 the rest of this section only talks about that basic one 🦋
All definitive response messages SHALL be digitally signed 🔥 and the key used to sign the response MUST belong to one of these:
- the CA who issued the certificate in question
- a Trusted Responder whose public key is trusted by the requestor
- a CA Designated Responder (Authorized Responder, defined in Section 4.2.2.2) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA
a definitive response message is made up of:
- version of the response syntax
- identifier of the responder
- time when the response was generated
- responses for each of the certificates in a request
- optional extensions
- signature algorithm OID
- signature computed across a hash of the response
the response for each certificate in a request has:
- target certificate identifier
- certificate status value
- response validity interval
- optional extensions
this spec defines these definitive response indicators for the certificate status value:
- good
- revoked
- unknown
the "good" state is a positive response to the status inquiry 💖 at a minimum it means that no certificate with the requested certificate serial number currently within its validity interval is revoked. it does NOT necessarily mean the certificate was ever issued, or that the time the response was produced is inside the certificate's validity interval 👀 response extensions may be used to convey extra info on the responder's assertions about the certificate's status, like a positive statement about issuance, validity, etc.
the "revoked" state means the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently 💀 this state MAY also be returned if the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key (referred to as a "non-issued" certificate in this document).
the "unknown" state means the responder doesn't know about the certificate being requested, usually because the request names an unrecognized issuer that this responder doesn't serve 🧚
NOTE: The "revoked" status indicates that a certificate with the requested serial number should be rejected, while the "unknown" status indicates that the status could not be determined by this responder, thereby allowing the client to decide whether it wants to try another source of status information (such as a CRL). This makes the "revoked" response suitable for non-issued certificates (as defined above) where the intention of the responder is to cause the client to reject the certificate rather than trying another source of status information. The "revoked" status is still optional for non-issued certificates in order to maintain backwards compatibility with deployments of RFC 2560. For example, the responder may not have any knowledge about whether a requested serial number has been assigned to any issued certificate, or the responder may provide pre-produced responses in accordance with RFC 5019 and, for that reason, is not capable of providing a signed response for all non-issued certificate serial numbers.
when a responder sends a "revoked" response to a status request for a non-issued certificate, the responder MUST include the extended revoked definition response extension (Section 4.4.8) in the response 🌈 that tells the client the responder supports the extended definition of "revoked" that also covers non-issued certificates. on top of that, the SingleResponse related to this non-issued certificate:
- MUST specify the revocation reason certificateHold (6),
- MUST specify the revocationTime January 1, 1970, and
- MUST NOT include a CRL references extension (Section 4.4.2) or any CRL entry extensions (Section 4.4.5).
2.3. Exception Cases 🙈
if something goes wrong, the OCSP responder may return an error message. these messages are NOT signed 😭 the error types are:
- malformedRequest
- internalError
- tryLater
- sigRequired
- unauthorized
a server sends "malformedRequest" if the request it got doesn't follow the OCSP syntax 🍓
"internalError" means the OCSP responder hit an inconsistent internal state. the query should be retried, potentially with another responder.
if the OCSP responder is up but can't return a status for the requested certificate, "tryLater" can be used to say the service exists but is temporarily unable to respond ⏳
"sigRequired" comes back when the server needs the client to sign the request before it can build a response ✍️
"unauthorized" comes back when the client isn't allowed to make this query to this server, or the server can't respond authoritatively (cf. [RFC5019], Section 2.2.3) 🔒
2.4. Semantics of thisUpdate, nextUpdate, and producedAt 🧠
responses in this doc can have four times: thisUpdate, nextUpdate, producedAt, and revocationTime. here's what each one means:
thisUpdate The most recent time at which the status being
indicated is known by the responder to have been
correct.
nextUpdate The time at or before which newer information will be
available about the status of the certificate.
producedAt The time at which the OCSP responder signed this
response.
revocationTime The time at which the certificate was revoked or
placed on hold.2.5. Response Pre-Production 🌸
OCSP responders MAY pre-produce signed responses that specify the status of certificates at a given time ✨ the time the status was known to be correct SHALL be reflected in the thisUpdate field of the response. the time at or before which newer info will be available goes in nextUpdate, and the time the response was produced shows up in producedAt 💅
2.6. OCSP Signature Authority Delegation 🎀
the key that signs a certificate's status info doesn't have to be the same key that signed the certificate 👑 a certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for the extended key usage extension (defined in [RFC5280], Section 4.2.1.12) in the OCSP signer's certificate. this certificate MUST be issued directly to the responder by the cognizant CA. see Section 4.2.2.2 for details.
2.7. CA Key Compromise 😱
if an OCSP responder knows a particular CA's private key has been compromised, it MAY return the "revoked" state for all certificates issued by that CA 🚨
3. Functional Requirements 📋
3.1. Certificate Content 🦋
so OCSP clients have a well-known spot to look for the info, CAs SHALL provide the capability to include the authority information access extension (defined in [RFC5280], Section 4.2.2.1) in certificates that can be checked using OCSP 💖 alternatively, the accessLocation for the OCSP provider can be configured locally at the OCSP client.
CAs that support an OCSP service, whether it's hosted locally or provided by an Authorized Responder, MUST provide for the inclusion of a value for a Uniform Resource Identifier (URI) [RFC3986] accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE 🫶
the accessLocation field in the subject certificate defines the transport (e.g., HTTP) used to access the OCSP responder, and it may contain other transport-dependent info (e.g., a URL) 🌐
3.2. Signed Response Acceptance Requirements 🔍
before accepting a signed response for a particular certificate as valid, OCSP clients SHALL confirm that:
- The certificate identified in a received response corresponds to the certificate that was identified in the corresponding request;
- The signature on the response is valid;
- The identity of the signer matches the intended recipient of the request;
- The signer is currently authorized to provide a response for the certificate in question;
- The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent;
- When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.
4. Details of the Protocol 🧚♀️
the ASN.1 syntax imports terms defined in [RFC5280]. for signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].
ASN.1 EXPLICIT tagging is used as a default unless specified otherwise 🍭
the terms imported from elsewhere are Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, and CRLReason 💜
4.1. Request Syntax 📨
this section gives the ASN.1 spec for a confirmation request 💅 the actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
4.1.1. ASN.1 Specification of the OCSP Request
Okay so this is the ASN.1 structure for the OCSPRequest, and it's giving full blueprint energy 🧚💖
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 }Let's break down the fields in OCSPRequest, because each one has a job 🎀
tbsRequestis the optionally signed OCSP request.optionalSignatureholds the algorithm identifier and any associated algorithm parameters insignatureAlgorithm, the signature value insignature, and, optionally, certificates the server needs to verify the signed response (normally up to but not including the client's root certificate). ✨
The contents of TBSRequest include these fields:
versionindicates the version of the protocol, which for this document isv1(0).requestorNameis OPTIONAL and indicates the name of the OCSP requestor. 🫶requestListcontains one or more single certificate status requests.requestExtensionsis OPTIONAL and includes extensions applicable to the requests found inreqCert. See Section 4.4.
The contents of Request include these fields:
reqCertcontains the identifier of a target certificate.singleRequestExtensionsis OPTIONAL and includes extensions applicable to this single certificate status request. See Section 4.4.
The contents of CertID include these fields, and this part is lowkey the most important bit 🥹
hashAlgorithmis the hash algorithm used to generate theissuerNameHashandissuerKeyHashvalues.issuerNameHashis the hash of the issuer's distinguished name (DN). The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked.issuerKeyHashis the hash of the issuer's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate.serialNumberis the serial number of the certificate for which status is being requested.
4.1.2. Notes on OCSP Requests
Here's the tea on why there's a hash of the CA's public key and a hash of the CA's name 🍵 The primary reason to use the hash of the CA's public key in addition to the hash of the CA's name to identify the issuer is that it is possible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). Two CAs will never, however, have the same public key unless the CAs either explicitly decided to share their private key or the key of one of the CAs was compromised. Bestie, names can collide, but keys basically can't 💅
Support for any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. Section 4.4 suggests several useful extensions. Additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood). 🌸
The requestor MAY choose to sign the OCSP request. In that case, the signature is computed over the tbsRequest structure. If the request is signed, the requestor SHALL specify its name in the requestorName field. Also, for signed requests, the requestor MAY include certificates that help the OCSP responder verify the requestor's signature in the certs field of Signature. 🦋
4.2. Response Syntax
This section specifies the ASN.1 specification for a confirmation response. The actual formatting of the message could vary, depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). So the ASN.1 is the core, and the wrapping can change depending on how it travels 🚀
4.2.1. ASN.1 Specification of the OCSP Response
An OCSP response at a minimum consists of a responseStatus field indicating the processing status of the prior request. If the value of responseStatus is one of the error conditions, the responseBytes field is not set. Ngl, that's a very clear "if this, then no bytes" moment 👑
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
}The value for responseBytes is an OBJECT IDENTIFIER plus a response syntax identified by that OID, encoded as an OCTET STRING. 🧚
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type. Both sides need to be able to handle this one, so it's a real two-way street 🫶
The value for response SHALL be the DER encoding of BasicOCSPResponse.
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }The value for signature SHALL be computed on the hash of the DER encoding of ResponseData. The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature. If no certificates are included, then certs SHOULD be 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 ::= NULL4.2.2. Notes on OCSP Responses
4.2.2.1. Time
Responses can contain four times -- thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics of these fields are defined in Section 2.4. The format for GeneralizedTime is as specified in Section 4.1.2.5.2 of [RFC5280]. Time is the main character here, honestly ⏰
The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable. So if the clock says "not yet" or "too late," it's sus 🙈
If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time. ✨
4.2.2.2. Authorized Responders
The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following:
- sign the OCSP responses itself, or
- explicitly designate this authority to another entity
OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request. Main character energy for the delegated signer, but only if the CA itself vouched for them 👑
The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. Systems relying on OCSP responses MUST recognize a delegation certificate as being issued by the CA that issued the certificate in question only if the delegation certificate and the certificate being checked for revocation were signed by the same key.
Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder. 🙈 Lowkey a big red flag, but still allowed for compat reasons.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing the use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities and specifying the set of CAs for which each signing authority is trusted. They MUST reject the response if the certificate required to validate the signature on the response does not meet at least one of the following criteria:
- Matches a local configuration of OCSP signing authority for the certificate in question, or
- Is the certificate of the CA that issued the certificate in question, or
- Includes a value of id-kp-OCSPSigning in an extended key usage extension and is issued by the CA that issued the certificate in question as stated above.
Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response. 🌈
4.2.2.2.1. Revocation Checking of an Authorized Responder ✨
okay so an Authorized OCSP responder hands out status info for one or more CAs, which means clients need a way to check that the responder's own certificate hasn't been revoked 👀. CAs have three options for handling this 💅:
- A CA can say an OCSP client can trust a responder for the whole lifetime of the responder's certificate 🫶. It does this by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing one of these should realize that a compromise of the responder's key is as serious as a compromise of a CA key used to sign CRLs, at least for the validity period of this certificate 😭. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently 🧚.
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }- A CA can spell out how the responder's certificate should be checked for revocation 🔍. If the check should use CRLs, it does this with CRL Distribution Points. If it should happen some other way, it uses Authority Information Access. The details for either of these two mechanisms are in [RFC5280] 📚.
- A CA can also choose not to specify any revocation checking method for the responder's certificate 🤷♀️. In that case, it's up to the OCSP client's local security policy to decide whether that certificate gets checked for revocation or not.
4.2.2.3. Basic Response 🎀
the basic response type contains:
- the version of the response syntax, which MUST be v1 (value is 0) for this version of the basic response syntax 🔢;
- either the name of the responder or a hash of the responder's public key as the ResponderID 🪪;
- the time at which the response was generated ⏰;
- responses for each of the certificates in a request 📬;
- optional extensions ✨;
- a signature computed across a hash of the response ✍️; and
- the signature algorithm OID 🧾.
the whole point of ResponderID is to help clients find the certificate that signed an OCSP response 🕵️♀️. So the information MUST correspond to the certificate that was used to sign the response. no mismatches, bestie 🙅♀️.
The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature 🌸.
the response for each certificate in a request consists of:
- an identifier of the certificate whose revocation status information is being provided (i.e., the target certificate) 🎯;
- the revocation status of the certificate (good, revoked, or unknown). If it's revoked, it also says when the certificate was revoked and, optionally, why 💀;
- the validity interval of the response ⏳; and
- optional extensions 💖.
The response MUST include a SingleResponse for each certificate in the request 💯. The response SHOULD NOT include any additional SingleResponse elements. That said, OCSP responders that pre-generate status responses might include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency (according to [RFC5019], Section 2.2.1) 🦋.
4.3. Mandatory and Optional Cryptographic Algorithms 🔐
Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-256 (identified by the sha256WithRSAEncryption OID specified in [RFC4055]) 👑. Clients SHOULD also be capable of processing responses signed using RSA with SHA-1 (identified by the sha1WithRSAEncryption OID specified in [RFC3279]) and the Digital Signature Algorithm (DSA) with SHA-1 (identified by the id-dsa-with-sha1 OID specified in [RFC3279]) 🌈. Clients MAY support other algorithms 🍓.
4.4. Extensions 🧩
this section defines some standard extensions, based on the extension model used in X.509 version 3 certificates (see [RFC5280]) 📖. Support for all extensions is optional for both clients and responders 🫠. For each extension, the definition covers its syntax, the processing the OCSP responder does, and any extensions included in the matching response 💅.
4.4.1. Nonce 🎲
the nonce cryptographically binds a request and a response so replay attacks don't work 🙅♀️. It shows up as one of the requestExtensions in requests, and in responses it shows up as one of the responseExtensions. In both, the nonce is identified by the object identifier id-pkix-ocsp-nonce, and the extnValue is the value of the nonce 🔑.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Nonce ::= OCTET STRING4.4.2. CRL References 📜
sometimes it's useful for the OCSP responder to point out which CRL a revoked or onHold certificate is on 🗂️. This is handy when OCSP is used between repositories, and it also works as an auditing tool 🕵️. The CRL can be identified by a URL (where the CRL is available), a number (the CRL number), or a time (when the relevant CRL was created) ⏱️. These extensions are specified as singleExtensions, the identifier is id-pkix-ocsp-crl, and the value is 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 }For the crlUrl choice, the IA5String is the URL where the CRL is available 🔗. For crlNum, the INTEGER is the value of the CRL number extension of the relevant CRL 🔢. For crlTime, the GeneralizedTime is the time the relevant CRL was issued 🕰️.
4.4.3. Acceptable Response Types 💌
an OCSP client MAY wish to say which kinds of response types it understands 🙋♀️. To do that, it SHOULD use an extension with the OID id-pkix-ocsp-response and the value AcceptableResponses ✨. This extension goes in as one of the requestExtensions in requests. The OIDs listed in AcceptableResponses are the OIDs of the response types this client can accept (for example, id-pkix-ocsp-basic) 🎀.
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIERAs noted in Section 4.2.1, OCSP responders SHALL be capable of responding with responses of the id-pkix-ocsp-basic response type 🧠. Matching that, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type 🤝.
4.4.4. Archive Cutoff 🗄️
an OCSP responder MAY choose to keep revocation information beyond a certificate's expiration 🕰️. Subtract this retention interval from the producedAt time in a response, and you get the certificate's "archive cutoff" date 📅.
OCSP-enabled applications can use an OCSP archive cutoff date to help prove that a digital signature was (or was not) reliable on the date it was produced 🧾. This works even if the certificate needed to validate the signature has long since expired 💀.
OCSP servers that support this kind of historical reference SHOULD include an archive cutoff date extension in responses 💅. If it's included, the value SHALL be provided as an OCSP singleExtensions extension identified by id-pkix-ocsp-archive-cutoff, with GeneralizedTime syntax 🎁.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}
ArchiveCutoff ::= GeneralizedTimefor example, say a server runs a 7-year retention interval policy and the status was produced at time t1. Then the ArchiveCutoff value in the response would be (t1 - 7 years) 🧁.
4.4.5. CRL Entry Extensions 🧾
every extension specified as a CRL entry extension (see Section 5.3 of [RFC5280]) is also supported as a singleExtensions 🙌.
4.4.6. Service Locator 🧭
an OCSP server can run in a mode where it receives a request and routes it to the OCSP server known to be authoritative for the identified certificate 🗺️. The serviceLocator request extension was made for exactly this 🎯. It goes in as one of the singleRequestExtensions in requests.
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }The values for these fields come from the matching fields in the subject certificate 🪄.
4.4.7. Preferred Signature Algorithms 🖋️
okay this one's a little messy 😅. Algorithms other than the mandatory-to-implement ones are allowed, and a client currently has no way to say which algorithms it prefers. So there's always a risk that a server picking a non-mandatory algorithm makes a response the client can't support 😬.
An OCSP responder can apply rules for picking an algorithm, like using the signature algorithm the CA uses for signing CRLs and certificates. But those rules can fail in common situations 🙃:
- The algorithm used to sign the CRLs and certificates may not match the key pair the OCSP responder uses to sign responses 🔑.
- A request for an unknown certificate gives the responder no basis for choosing between multiple algorithm options 🤷♀️.
The last one can't be fixed with the in-band signaling in the RFC 2560 [RFC2560] protocol without changing the protocol itself 🛠️.
There are also two reasons an OCSP responder might want to use a different signature algorithm than the one the CA uses to sign certificates and CRLs 💅:
- The responder may use an algorithm for certificate status responses that's less computationally demanding than the one for signing the certificate itself 🏋️♀️.
- An implementation may want to guard against the possibility of a compromise caused by a signature algorithm compromise, by using two separate signature algorithms 🛡️.
This section describes:
- an extension that lets a client indicate the set of preferred signature algorithms 💜; and
- rules for signature algorithm selection that maximize the probability of successful operation when no supported preferred algorithm(s) are specified 🌟.
4.4.7.1. Extension Syntax ✨
okay so a client MAY declare a preferred set of algorithms in a request by including a preferred signature algorithms extension in requestExtensions of the OCSPRequest. 💅
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}the syntax of AlgorithmIdentifier is defined in Section 4.1.1.2 of RFC 5280 [RFC5280]. the syntax of SMIMECapability is defined in RFC 5751 [RFC5751]. 🎀
sigIdentifier is where the client says which signature algorithm it likes best, like algorithm=ecdsa-with-sha256. parameters are absent for most common signature algorithms, so you usually don't have to worry about them. 🦋
pubKeyAlgIdentifier is the subject public key algorithm identifier the client prefers in the server's certificate that gets used to validate the OCSP response, like algorithm=id-ecPublicKey and parameters= secp256r1. 🌸
pubKeyAlgIdentifier is OPTIONAL, but it's a super handy way to tell apart different uses of the same algorithm. for example, a client can use it to say which curve it supports for a particular elliptic curve algorithm. so extra, I'm obsessed 🧚
The client MUST support each of the specified preferred signature algorithms, and the client MUST specify the algorithms in the order of preference, from the most preferred to the least preferred. no skipping the rules, bestie! 👑
Section 4.4.7.2 of this document describes how a server selects an algorithm for signing OCSP responses to the requesting client. 🫶
4.4.7.2. Responder Signature Algorithm Selection 🔥
RFC 2560 [RFC2560] didn't have a way to decide which signature algorithm goes in an OCSP response. ngl that's a problem, because without a clear method nobody could be sure which algorithm got picked, and that makes interoperability sketchy. 🙈
4.4.7.2.1. Dynamic Response 💖
A responder MAY maximize the potential for ensuring interoperability by selecting a supported signature algorithm using the following order of precedence, as long as the selected algorithm meets all security requirements of the OCSP responder. the first selection mechanism has the highest precedence:
- Select an algorithm specified as a preferred signature algorithm in the client request.
- Select the signature algorithm used to sign a certificate revocation list (CRL) issued by the certificate issuer providing status information for the certificate specified by CertID.
- Select the signature algorithm used to sign the OCSPRequest.
- Select a signature algorithm that has been advertised as being the default signature algorithm for the signing service using an out-of-band mechanism.
- Select a mandatory or recommended signature algorithm specified for the version of OCSP in use.
A responder SHOULD always apply the lowest-numbered selection mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength. ✨
4.4.7.2.2. Static Response 🌈
for efficiency, an OCSP responder is permitted to generate static responses in advance of a request. the case may not permit the responder to make use of the client request data during the response generation. even so, the responder SHOULD still use the client request data during the selection of the pre-generated response to be returned. 💅
Responders MAY use the historical client requests as part of the input to the decisions of what different algorithms should be used to sign the pre-generated responses. it's giving "learn from the past" 🧠🍓
4.4.8. Extended Revoked Definition 🦋
this extension tells you the responder supports the extended definition of the "revoked" status, which also covers non-issued certificates according to Section 2.2. one of its big jobs is letting audits figure out what kind of operation the responder runs. clients don't have to parse this extension to work out the status of certificates in responses, so it's not a must-read for them. 🙌
This extension MUST be included in the OCSP response when that response contains a "revoked" status for a non-issued certificate. This extension MAY be present in other responses to signal that the responder implements the extended revoked definition. When included, this extension MUST be placed in responseExtensions, and it MUST NOT appear in singleExtensions. the rules are strict, so no sneaky placements! 🚫
This extension is identified by the object identifier id-pkix-ocsp-extended-revoke.
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}The value of the extension SHALL be NULL. This extension MUST NOT be marked critical. 🫠
5. Security Considerations 💀
okay this part is seriously important, so let's get into it. For this service to be effective, certificate-using systems must connect to the certificate status service provider. If such a connection can't be obtained, certificate-using systems could implement CRL processing logic as a fall-back position. 😭
there's a denial-of-service vulnerability with respect to a flood of queries. producing a cryptographic signature really slows down response generation cycle time, which makes the situation worse. unsigned error responses open the protocol up to another denial-of-service attack, where the attacker sends false error responses. 🚨
the use of precomputed responses allows replay attacks. in these, an old (good) response gets replayed before its expiration date but after the certificate has been revoked. deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution. 🔍
requests don't contain the responder they're directed to. this means an attacker can replay a request to any number of OCSP responders. 👀
relying on HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectly configured or are known to have cache management faults. implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP. 🧊
responding with a "revoked" state to a certificate that has never been issued may enable someone to get a revocation response for a certificate that isn't issued yet but soon will be. this works if the certificate serial number of the future certificate can be predicted or guessed by the requestor. such a prediction is easy for a CA that issues certificates with sequential certificate serial number assignment. this risk is handled in the specification by requiring compliant implementations to use the certificateHold reason code, which avoids permanently revoking the serial number. for CAs that support "revoked" responses to status requests for non-issued certificates, one way to completely avoid this issue is to assign random certificate serial number values with high entropy. 🎲✨
5.1. Preferred Signature Algorithms 🎀
The mechanism used to choose the response signing algorithm MUST be considered to be sufficiently secure against cryptanalytic attack for the intended application. non-negotiable, bestie 🔐
in most applications, it's enough for the signing algorithm to be at least as secure as the signing algorithm used to sign the original certificate whose status is being queried. however, this criterion may not hold in long-term archival applications. there, the status of a certificate might be queried for a date in the distant past, long after the signing algorithm has stopped being considered trustworthy. 🏛️
5.1.1. Use of Insecure Algorithms 🙅♀️
it's not always possible for a responder to generate a response that the client is expected to understand and that also meets contemporary standards for cryptographic security. in those cases, an OCSP responder operator MUST balance the risk of employing a compromised security solution and the cost of mandating an upgrade. that includes the risk that the alternative chosen by end users will offer even less security or no security at all. 🫣
in archival applications, it's quite possible that an OCSP responder gets asked to report the validity of a certificate on a date in the distant past. such a certificate might use a signing method that's no longer considered acceptably secure. in those circumstances, the responder MUST NOT generate a signature using a signing mechanism that is not considered acceptably secure. absolutely not, no exceptions 🚫💅
A client MUST accept any signing algorithm in a response that it specified as a preferred signing algorithm in the request. it follows, therefore, that a client MUST NOT specify as a preferred signing algorithm any algorithm that is either not supported or not considered acceptably secure. 🧾
5.1.2. Man-in-the-Middle Downgrade Attack 😈
the mechanism that supports client indication of preferred signature algorithms is not protected against a man-in-the-middle downgrade attack. this isn't considered a significant security concern, since the OCSP responder MUST NOT sign OCSP responses using weak algorithms even if the client asks for them. also, the client can reject OCSP responses that don't meet its own criteria for acceptable cryptographic security, no matter what mechanism is used to determine the signing algorithm of the response. so the client still gets the final say 💖
5.1.3. Denial-of-Service Attack 🚧
the algorithm agility mechanisms defined in this document add a slightly bigger attack surface for denial-of-service attacks. in those attacks, the client request gets altered to require algorithms the server doesn't support. Denial-of-service considerations as discussed in RFC 4732 [RFC4732] are relevant for this document. 🛡️
6. IANA Considerations 📋
This document includes media type registrations (in Appendix C) for ocsp-request and ocsp-response. those were registered when RFC 2560 was published. because this document obsoletes RFC 2560, IANA has updated the references in the "Application Media Types" registry for ocsp-request and ocsp-response to point to this document. the paperwork is all sorted, periodt 🗂️✨
7. References 📚
7.1. Normative References ✨
okay bestie, these are the sources the spec needs you to have read 📚💅 without them the rules don't really make sense:
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
- [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
- [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
- [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
- [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011.
- [X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008.
7.2. Informative References 🦋
these ones are the extra reading that's good to know about, but the spec doesn't lean on them to work 🌸
- [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
- [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
- [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", RFC 5019, September 2007.
- [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
8. Acknowledgements 🫶
the people who made this happen deserve all the flowers 💐
Development of this document has been made possible thanks to extensive inputs from members of the PKIX working group.
Jim Schaad provided valuable support by compiling and checking the ASN.1 modules of this specification. 👑
Appendix A. OCSP over HTTP 🌈
okay so this part is all about how the OCSP messages get dressed up to travel over HTTP 🎀 the spec says it's describing the formatting that gets done to the request and response to support HTTP [RFC2616].
A.1. Request 💌
HTTP-based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes) MAY be submitted using GET. If HTTP caching is not important or if the request is greater than 255 bytes, the request SHOULD be submitted using POST. Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol. 🔐
an OCSP request using the GET method is constructed like this 🧚
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}where {url} may be derived from the value of the authority information access extension in the certificate being checked for revocation, or other local configuration of the OCSP client.
an OCSP request using the POST method is constructed as follows: the Content-Type header has the value application/ocsp-request, while the body of the message is the binary value of the DER encoding of the OCSPRequest. 🍓
A.2. Response 🌸
an HTTP-based OCSP response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the OCSPResponse. The Content-Type header has the value application/ocsp-response. The Content-Length header SHOULD specify the length of the response. Other HTTP headers MAY be present and MAY be ignored if not understood by the requestor. 💅
Appendix B. ASN.1 Modules 📚
this appendix has the ASN.1 modules for OCSP, so the data structures are spelled out exactly 🤓 Appendix B.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1 for all syntax elements of OCSP, including the preferred signature algorithms extension that was defined in [RFC6277]. This module replaces the modules in Appendix B of [RFC2560] and Appendix A.2 of [RFC6277]. Appendix B.2 includes an ASN.1 module, corresponding to the module present in B.1, that conforms to the 2008 version of ASN.1. This module replaces the modules in Section 12 of [RFC5912] and Appendix A.1 of [RFC6277]. Although a 2008 ASN.1 module is provided, the module in Appendix B.1 remains the normative module as per the policy of the PKIX working group. 👑
B.1. OCSP in ASN.1 - 1998 Syntax 🎀
OCSP-2013-88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-2013-88(81)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax, CRLReason, GeneralName
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }
Name, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
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 }
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
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
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
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
certIdentifier AlgorithmIdentifier OPTIONAL }
-- 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 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
ENDB.2. OCSP in ASN.1 - 2008 Syntax ✨
OCSP-2013-08
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-08(82)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
Extensions{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
Name, CertificateSerialNumber, id-kp, id-ad-ocsp, CertificateFROM PKIX1Explicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1
FROM PKIXAlgs-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56)};
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 {{re-ocsp-nonce |
re-ocsp-response, ...,
re-ocsp-preferred-signature-algorithms}} OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier
{ SIGNATURE-ALGORITHM, {...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions
{ {re-ocsp-service-locator,
...}} OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
{DIGEST-ALGORITHM, {...}},
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's 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
}
RESPONSE ::= TYPE-IDENTIFIER
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@responseType}))}
basicResponse RESPONSE ::=
{ BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{sa-dsaWithSHA1 | sa-rsaWithSHA1 |
sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
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
{{re-ocsp-nonce, ...,
re-ocsp-extended-revoke}} 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{{re-ocsp-crl |
re-ocsp-archive-cutoff |
CrlEntryExtensions, ...}
} 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
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet})
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL
}
-- Certificate Extensions
ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED
BY id-pkix-ocsp-nocheck }
-- Request Extensions
re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
BY id-pkix-ocsp-nonce }
re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED
BY id-pkix-ocsp-response }
re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator
IDENTIFIED BY
id-pkix-ocsp-service-locator }
re-ocsp-preferred-signature-algorithms EXTENSION ::= {
SYNTAX PreferredSignatureAlgorithms
IDENTIFIED BY id-pkix-ocsp-pref-sig-algs }
-- Response Extensions
re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY
id-pkix-ocsp-crl }
re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff
IDENTIFIED BY
id-pkix-ocsp-archive-cutoff }
re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-extended-revoke }
-- 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 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
ENDC.1. application/ocsp-request 📨
Okay bestie, this is the MIME registration form for the request type. 💅
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 document on the
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:
Stefan Santesson <sts@aaa-sec.com>
Intended usage: COMMON
Author/Change controller: IETFC.2. application/ocsp-response 📬
And this one is the matching form for the response type. 🫶
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 document on the
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:
Stefan Santesson <sts@aaa-sec.com>
Intended usage: COMMON
Author/Change controller: IETFAuthors' Addresses ✨
Here are the people who wrote this thing, the real MVPs. 👑
Stefan Santesson 3xA Security AB Scheelev. 17 223 70 Lund Sweden
EMail: sts@aaa-sec.com
Michael Myers TraceRoute Security
EMail: mmyers@fastq.com
Rich Ankney
Ambarish Malpani CA Technologies 455 West Maude Ave. Suite 210 Sunnyvale, CA 94085 United States
EMail: ambarish@gmail.com
Slava Galperin A9.com Inc. 130 Lytton Ave. Suite 300 Palo Alto, CA 94301 United States
EMail: slava.galperin@gmail.com
Carlisle Adams University of Ottawa 800 King Edward Avenue Ottawa ON K1N 6N5 Canada
EMail: cadams@eecs.uottawa.ca
📦 where this page comes from
- ietf: rfc6960 2013-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms