RFC 9919
The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
RFC 9919 ๐ The Lightweight OCSP Profile for High-Volume Environments
okay bestie, the title block tea โ: this is RFC 9919 ๐, called "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments" ๐ฆ. It's an Internet Standards Track doc, dated July 2026 ๐ , and the ISSN is 2070-1721.
The authors are T. Ito (SECOM CO., LTD.), C. Wilson (Apple, Inc.), C. Bonnell (DigiCert, Inc.), and S. Turner (sn3rd) ๐. It obsoletes RFC 5019 ๐. The title block doesn't list anything it updates ๐ธ.
Abstract โจ
okay so this spec defines a profile of the Online Certificate Status Protocol (OCSP) ๐ง that deals with the scalability problems you hit when OCSP runs in big, high-volume Public Key Infrastructure (PKI) environments, and/or in PKI environments that need something lightweight to keep bandwidth low and client-side processing minimal ๐ .
This spec obsoletes RFC 5019 ๐. The profile in RFC 5019 has been updated to allow and recommend SHA-256 over SHA-1 ๐ฅ.
Status of This Memo ๐
This is an Internet Standards Track document.
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). Further information on Internet Standards is available in Section 2 of RFC 7841 โญ.
Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc9919 ๐.
Copyright Notice ๐ซถ
Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License ๐.
Table of Contents ๐
1. Introduction
2. Conventions
3. OCSP Message Profile
3.1. OCSP Request Profile
3.1.1. OCSPRequest Structure
3.1.2. Signed OCSPRequests
3.2. OCSP Response Profile
3.2.1. OCSPResponse Structure
3.2.2. Signed OCSPResponses
3.2.3. OCSPResponseStatus Values
3.2.4. thisUpdate, nextUpdate, and producedAt
4. Client Behavior
4.1. OCSP Responder Discovery
4.2. Sending an OCSP Request
5. Ensuring an OCSPResponse Is Fresh
6. Transport Profile
7. Caching Recommendations
7.1. Caching at the Client
7.2. HTTP Proxies
7.3. Caching at Servers
8. Security Considerations
8.1. Replay Attacks
8.2. On-Path Attacks
8.3. Impersonation Attacks
8.4. Denial-of-Service Attacks
8.5. Modification of HTTP Header Fields
8.6. Request Authentication and Authorization
8.7. Use of SHA-1 for the Calculation of CertID Field Values
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Differences from RFC 5019
Appendix B. Examples
B.1. Root CA Certificate
B.2. End-Entity Certificate
B.3. OCSP Responder Certificate
B.4. OCSP Request
B.5. OCSP Response
Acknowledgments
Authors' Addresses1. Introduction โจ
okay so the Online Certificate Status Protocol [RFC6960] is a mechanism for checking whether digital certificates are still good, and it's used instead of Certificate Revocation Lists (CRLs) ๐ง. Since it was defined in 1999, it's been deployed in all sorts of environments and it has proven to be a super useful way to check certificate status ๐ . (Quick note: "OCSP" is used in this doc as shorthand for checking certificate status, but this protocol is used only to figure out whether a certificate has been revoked ๐.)
So many OCSP deployments have popped up to give timely, secure certificate status info ๐ฅ. That's clutch for high-value electronic transactions and for handling super sensitive info, like in banking and finance ๐ฐ. That's why it's been so important for an OCSP responder to answer in "real time" (i.e., generating a new OCSP response for each OCSP request) โฑ๏ธ. These deployments also ran in places where bandwidth wasn't a problem, on client and server systems where processing power wasn't limited ๐ป.
PKI keeps growing into all kinds of new environments, and so does the need for a scalable, cost-effective way to check certificate status ๐ธ. OCSP as it's defined and deployed right now works great for small to medium PKIs running on powerful systems on wired networks, but there's a limit to how these deployments scale on both efficiency and cost ๐. Mobile environments are a whole different vibe: bandwidth can be precious and client devices have limited processing power, so OCSP has to be used carefully to keep bandwidth usage and client-side processing complexity down [OCSPMP] ๐ฑ.
PKI is being deployed where millions, if not hundreds of millions, of certificates have been issued ๐. In a lot of these places, an even bigger crowd of users (also called relying parties) needs to make sure the certificate they're relying on hasn't been revoked ๐. So it really matters that OCSP is used in a way that keeps the load on OCSP responders, and on the network infrastructure hosting those responders, as low as possible ๐ฆ.
This doc tackles the scalability problems of using OCSP in highly scaled PKI environments ๐. It does that by defining a message profile and clarifying OCSP client and responder behavior, so that the following are possible โจ:
- OCSP response pre-production and distribution.
- Reduced OCSP message size to lower bandwidth usage.
- Response message caching both in the network and on the client.
The normative requirements in this profile are meant to be adopted by OCSP clients and OCSP responders that operate in very large-scale (high-volume) PKI environments, or in PKI environments that need a lightweight solution to minimize bandwidth and client-side processing power (or both), as described above ๐.
OCSP doesn't have a way to signal responder capabilities within the protocol ๐. So clients may need out-of-band mechanisms (e.g., agreed-upon arrangements between OCSP responder operators and OCSP clients) to figure out whether a responder conforms to the profile in this document ๐ง. Even without those mechanisms, this profile makes sure interoperability still happens between an OCSP client that fully conforms with [RFC6960] and a responder operating in a mode described in this spec ๐ซถ.
2. Conventions ๐
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here ๐ฅ.
3. OCSP Message Profile ๐ฆ
This section defines a subset of OCSPRequest and OCSPResponse functionality, as defined in [RFC6960] ๐ง.
3.1. OCSP Request Profile ๐
3.1.1. OCSPRequest Structure โจ
Here's a partial extract of the ASN.1 structure for the OCSPRequest, with the relevant CertID as defined in [RFC6960], just for convenience ๐:
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 }
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 }okay this is a big one ๐จ: OCSPRequests that conform to the profile in this document MUST include only one Request in the OCSPRequest.requestList structure ๐.
The CertID.issuerNameHash and CertID.issuerKeyHash fields hold hashes of the issuer's distinguished name (DN) and public key, respectively ๐ธ. OCSP clients that conform with this profile MUST use SHA-256, as defined in Section 2.2 of [RFC5754], as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values ๐.
Older OCSP clients that give backward compatibility with [RFC5019] use SHA-1, as defined in [RFC3174], as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values ๐ฐ๏ธ. However, these OCSP clients MUST transition from SHA-1 to SHA-256 as soon as practical ๐โโ๏ธ๐จ.
Clients MUST NOT include the singleRequestExtensions structure ๐ซ.
Clients SHOULD NOT include the requestExtensions structure ๐. If a requestExtensions structure is included, it is RECOMMENDED by this profile that the structure contain only the nonce extension (id-pkix-ocsp-nonce) ๐. See Section 5 for issues concerning the use of a nonce in high-volume OCSP environments ๐ง.
3.1.2. Signed OCSPRequests ๐
Clients SHOULD NOT send signed OCSPRequests ๐ . Responders MAY ignore the signature on OCSPRequests ๐ซถ.
If the OCSPRequest is signed, the client SHALL specify its name in the OCSPRequest.requestorName field ๐ท๏ธ. Otherwise, clients SHOULD NOT include the requestorName field in the OCSPRequest โจ. OCSP responders MUST handle unsigned OCSP requests that contain the requestorName field as if the requestorName field were absent ๐.
3.2. OCSP Response Profile ๐
3.2.1. OCSPResponse Structure โจ
okay so here's a partial peek at the ASN.1 structure for the OCSPResponse with the relevant CertID, as defined in [RFC6960]. it's just for convenience ๐
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }bestie, the value for response SHALL be the DER encoding of BasicOCSPResponse. no skipping this one ๐ซถ
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 }
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }Responders MUST generate a BasicOCSPResponse as identified by the id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a BasicOCSPResponse. OCSPResponses that conform to this profile SHOULD include only one SingleResponse in the ResponseData.responses structure, but they MAY include additional SingleResponse elements if that's necessary to improve response pre-generation performance or cache efficiency and to ensure backward compatibility. ๐ธ
For instance, to provide support to OCSP clients that do not yet support the use of SHA-256 for CertID hash calculation, the OCSP responder MAY include two SingleResponse elements in a BasicOCSPResponse. In that BasicOCSPResponse, the CertID of one of the SingleResponse structures uses SHA-1 for the hash calculation, and the CertID in the other SingleResponse uses SHA-256. ๐ฆ
OCSP responders SHOULD NOT distribute OCSP responses that contain CertIDs that use SHA-1 if the OCSP responder has no clients that require the use of SHA-1. Operators of OCSP responders may consider logging the hash algorithm used by OCSP clients to inform their determination of when it is appropriate to obsolete the distribution of OCSP responses that employ SHA-1 for CertID field hashes. See Section 8.7 for more information on the security considerations for the continued use of SHA-1. ๐ฅ
The responder SHOULD NOT include responseExtensions. As specified in [RFC6960], clients MUST ignore unrecognized non-critical responseExtensions in the response. ๐
In the case where a responder does not have the ability to respond to an OCSP request containing an option not supported by the responder, it SHOULD return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it SHOULD return a response that does not include a nonce. ๐ง
Clients SHOULD attempt to process a response even if the response does not include a nonce. See Section 5 for details on validating responses that do not contain a nonce. See also Section 8 for relevant security considerations. ๐
Responders that do not have the ability to respond to OCSP requests that contain an unsupported option, such as a nonce, MAY forward the request to an OCSP responder capable of doing so. ๐
The responder MAY include the SingleResponse.singleExtensions extensions structure. โจ
3.2.2. Signed OCSPResponses ๐
Clients MUST validate the signature on the OCSPResponse. no cap, this one is non-negotiable ๐ญ
If the response is signed by a delegate of the issuing certification authority (CA), a valid responder certificate MUST be referenced in the BasicOCSPResponse.certs structure.
It is RECOMMENDED that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension, as defined in [RFC6960], to indicate to the client that it need not check the certificate's status. In addition, it is RECOMMENDED that neither an OCSP Authority Information Access (AIA) extension nor a CRL Distribution Points (CRLDP) extension be included in the OCSP responder's certificate. Accordingly, the responder's signing certificate SHOULD be relatively short-lived and renewed regularly. ๐
Clients MUST be able to identify OCSP responder certificates using the byKey field, and SHOULD be able to identify OCSP responder certificates using the byName field of the ResponseData.ResponderID [RFC6960] choices. ๐
Older responders that provide backward compatibility with the protocol defined in [RFC5019] MAY use the byName field to represent the ResponderID, but should transition to using the byKey field as soon as practical. โญ
Newer responders that conform to this profile MUST use the byKey field to represent the ResponderID to reduce the size of the response. ๐
3.2.3. OCSPResponseStatus Values ๐ฆ
As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned. When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of "unauthorized". ๐ฅ
For example, OCSP responders that do not have access to authoritative records for a requested certificate, such as those that generate and distribute OCSP responses in advance and thus do not have the ability to properly respond with a signed "successful" yet "unknown" response, will respond with an OCSPResponseStatus of "unauthorized". Also, in order to ensure the database of revocation information does not grow unbounded over time, the responder MAY remove the status records of expired certificates. Requests from clients for certificates whose record has been removed will result in an OCSPResponseStatus of "unauthorized". ๐ธ
Security considerations regarding the use of unsigned responses are discussed in [RFC6960]. ๐
3.2.4. thisUpdate, nextUpdate, and producedAt โฐ
When pre-producing OCSPResponse messages, the responder MUST set the thisUpdate, nextUpdate, and producedAt times as follows:
- thisUpdate: The time at which the status being indicated is known to be correct.
- nextUpdate: The time at or before which newer information will be available about the status of the certificate. As described in Section 2.4 of [RFC6960], this field is optional. However, this field MUST be included in the profile specified in this document to help clients cache responses. See Section 7 for additional information on caching.
- producedAt: The time at which the OCSP response was signed.
Note: The values of thisUpdate, nextUpdate, and producedAt are set as described in Section 2.5 of [RFC6960], and in many cases, the value of thisUpdate and producedAt are the same. ๐ซถ
For the purposes of this profile, ASN.1-encoded GeneralizedTime values, such as thisUpdate, nextUpdate, and producedAt, MUST be expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. ๐ฐ๏ธ
4. Client Behavior ๐
4.1. OCSP Responder Discovery ๐
Clients MUST support the AIA extension as defined in [RFC5280] and MUST recognize the id-ad-ocsp access method. This enables CAs to inform clients how they can contact the OCSP service. ๐
In the case where a client is checking the status of a certificate that contains both an AIA extension pointing to an OCSP responder and a CRLDP extension pointing to a CRL, the client SHOULD attempt to contact the OCSP responder first. Clients MAY attempt to retrieve the CRL if no OCSPResponse is received from the responder after a locally configured timeout and number of retries. โณ
4.2. Sending an OCSP Request ๐ค
To avoid needless network traffic, applications MUST verify the signature of signed data before asking an OCSP client to check the status of certificates used to verify the data. If the signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested. ๐ซ
Similarly, an application MUST validate the signature on certificates in a chain before asking an OCSP client to check the status of the certificate. If the certificate signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested. Clients SHOULD NOT make a request to check the status of expired certificates. ๐ฅ
5. Ensuring an OCSPResponse Is Fresh ๐ง
In order to ensure that a client does not accept an out-of-date response that indicates a "good" status when in fact there is a more up-to-date response that specifies the status of "revoked", a client must ensure the responses they receive are fresh. this is the whole main character arc of this section ๐ค
In general, two mechanisms are available to clients to ensure a response is fresh. The first uses nonces, and the second is based on time. In order for time-based mechanisms to work, both clients and responders MUST have access to an accurate source of time. โฐ
Because this profile specifies that clients SHOULD NOT include a requestExtensions structure in OCSPRequests (see Section 3.1), clients MUST be able to determine OCSPResponse freshness based on an accurate source of time. Clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time. ๐ง
Clients that do not include a nonce in the request MUST ignore any nonce that may be present in the response. ๐ โโ๏ธ
Clients MUST check for the existence of the nextUpdate field and MUST ensure the current time, expressed in GMT time as described in Section 3.2.4, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client MUST reject the response. ๐จ
If the nextUpdate field is present, the client MUST ensure that it is not earlier than the current time. If the current time on the client is later than the time specified in the nextUpdate field, the client MUST reject the response as stale. Clients MAY allow configuration of a small tolerance period for acceptance of responses after nextUpdate to handle minor clock differences relative to responders and caches. This tolerance period should be chosen based on the accuracy and precision of time synchronization technology available to the calling application environment. For example, Internet peers with low latency connections typically expect NTP time synchronization to keep them accurate within parts of a second; higher latency environments, or where an NTP analogue is not available, may have to be more liberal in their tolerance (e.g., allow one day difference). ๐
See the security considerations in Section 8 for additional details on replay and on-path attacks. ๐
6. Transport Profile ๐
okay so OCSP clients can send HTTP-based requests using either the GET or POST method ๐ The OCSP responder MUST support requests and responses over HTTP, no exceptions bestie ๐ซถ When a request is 255 bytes or less in total (after encoding), counting the scheme and delimiters (http://), the server name, and the base64-encoded OCSPRequest structure, clients MUST use GET so the response can be cached ๐
Requests bigger than 255 bytes SHOULD go with POST instead. In every case, clients MUST follow the descriptions in Appendix A.1 of [RFC6960] when they build these messages ๐
When a client builds a GET message, it MUST base64-encode the OCSPRequest structure according to Section 4 of [RFC4648] ๐ง Clients MUST NOT include whitespace or any other characters outside the base64 character set in that string, ngl that's a strict vibe ๐ โโ๏ธ They also MUST properly URL-encode the base64-encoded OCSPRequest according to [RFC3986]. Then OCSP clients MUST append that base64-encoded OCSPRequest to the URI given in the AIA extension [RFC5280] โจ Here's what it looks like:
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dA
deGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3DWhen the responder gets a properly formatted OCSPRequest that is cachable (meaning the response has a nextUpdate value), it sends back the binary DER encoding of the OCSPResponse, along with these HTTP [RFC9110] [RFC9111] header fields ๐
Content-type: application/ocsp-response
Content-length: < OCSP response length >
Last-modified: < producedAt HTTP-date >
ETag: "< strong validator >"
Expires: < nextUpdate HTTP-date >
Cache-control: max-age=< n >, public, no-transform, must-revalidate
Date: < current HTTP-date >Check out Section 7.2 for the full scoop on how these header fields get used ๐ฆ
7. Caching Recommendations ๐ธ
Caching OCSP responses across the network is a huge deal for high-volume OCSP deployments, lowkey the whole point ๐ This section covers the caching behavior that's recommended for OCSP clients and HTTP proxies, plus the steps you should take to cut down on how often clients "hit the wire" ๐ธ๏ธ It also talks about including OCSP responses inside protocol exchanges (aka stapling or piggybacking), like what's been defined in TLS ๐
7.1. Caching at the Client
To keep bandwidth usage low, clients MUST locally cache authoritative OCSP responses (that's a response whose signature has been successfully validated and that shows an OCSPResponseStatus of "successful") ๐ง
Most OCSP clients send OCSPRequests at or near the nextUpdate time, which is when a cached response expires ๐ญ If tons of clients refresh their cached copies for one popular certificate all at once, the responder can get slammed with a massive spike in load ๐ To prevent that, responders MAY use the cache-control:max-age directive to say when the client should go grab an updated OCSP response ๐ Clients SHOULD fetch the updated OCSP response on or after the max-age time. And so clients actually get a fresh response, OCSP responders MUST refresh the OCSP response before the max-age time โจ
7.2. HTTP Proxies
The responder SHOULD set the HTTP header fields of the OCSP response in a way that lets intermediate HTTP proxy servers be used intelligently ๐ง For the full definitions of these HTTP header fields and the correct format for any date and time values, see [RFC9110] and [RFC9111] ๐
+===============+===================================================+
| HTTP Header | Description |
| Field | |
+===============+===================================================+
| Date | The date and time at which the OCSP responder |
| | generated the HTTP response. |
+---------------+---------------------------------------------------+
| Last-Modified | This value specifies the date and time at which |
| | the OCSP responder last modified the response. |
| | This date and time will be the same as the |
| | thisUpdate timestamp in the request itself. |
+---------------+---------------------------------------------------+
| Expires | Specifies how long the response is considered |
| | fresh. This date and time will be the same as |
| | the nextUpdate timestamp in the OCSP response |
| | itself. |
+---------------+---------------------------------------------------+
| ETag | A string that identifies a particular version of |
| | the associated data. It is RECOMMENDED by this |
| | profile that the ETag value be the ASCII HEX |
| | representation of the SHA-256 hash of the |
| | OCSPResponse structure. |
+---------------+---------------------------------------------------+
| Cache-Control | Contains a number of caching directives. |
| | |
| | * max-age = < n > - where n is a time value |
| | later than thisUpdate but earlier than |
| | nextUpdate. |
| | |
| | * public - makes normally uncachable response |
| | cachable by both shared and nonshared caches. |
| | |
| | * no-transform - specifies that a proxy cache |
| | cannot change the type, length, or encoding |
| | of the object content. |
| | |
| | * must-revalidate - prevents caches from |
| | intentionally returning stale responses. |
+---------------+---------------------------------------------------+Table 1: HTTP Header Fields ๐
OCSP responders MUST NOT include the "Pragma: no-cache", "Cache-Control: no-cache", or "Cache-Control: no-store" HTTP header fields in authoritative OCSP responses ๐ โโ๏ธ For non-authoritative OCSP responses, OCSP responders SHOULD include one or more of these HTTP header fields ๐
Here's an example. Say an OCSP response has these timestamp values:
thisUpdate = March 19, 2023 01:00:00 GMT
nextUpdate = March 21, 2023 01:00:00 GMT
producedAt = March 19, 2023 01:00:00 GMTand an OCSP client asks for the response on March 20, 2023 01:00:00 GMT. In that case, the HTTP response might look like this ๐
Content-Type: application/ocsp-response
Content-Length: 1000
Date: Mon, 20 Mar 2023 01:00:00 GMT
Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT
ETag: "97df3588b5a3f24babc3851b372f0ba7
1a9dcdded43b14b9d06961bfc1707d9d"
Expires: Tue, 21 Mar 2023 01:00:00 GMT
Cache-Control: max-age=86000,public,no-transform,must-revalidate
<...>OCSP clients MUST NOT include a no-cache HTTP header field in OCSP request messages, unless the client runs into an expired response. That can happen when an intermediate proxy cached stale data ๐ซ In that situation, clients SHOULD resend the request and tell proxies to be bypassed by including an appropriate HTTP header field in the request (i.e., Pragma: no-cache or Cache-Control: no-cache) ๐
7.3. Caching at Servers
Sometimes it's a great move to include OCSP response information inside the protocol that the client and OCSP responder are already using ๐ Doing it this way has a few really attractive effects ๐
First, it lets OCSP responses get cached on the OCSP responder, which lowers the number of hits ๐
Second, it makes certificate validation possible when the client isn't connected to a network, so clients don't have to set up a brand new HTTP session with the OCSP responder ๐
Third, it cuts down on the number of round trips a client has to make to finish a handshake ๐โโ๏ธ
Fourth, it simplifies the client-side OCSP implementation, because the client only needs the ability to parse and recognize OCSP responses ๐งฉ
This functionality is specified as an extension to the TLS protocol in Section 4.4.2 of [RFC9846], but it can be applied to any client-server protocol ๐
It is RECOMMENDED by this profile that both TLS clients and servers implement the certificate status request extension mechanism for TLS ๐
More info on caching issues can be found in [RFC3143] ๐
8. Security Considerations ๐
These considerations apply in addition to the security considerations covered in Section 5 of [RFC6960]. Pay attention bestie, this part is serious ๐จ
8.1. Replay Attacks
Because nonces are optional in this profile, an out-of-date OCSP response could get replayed ๐ฑ That could make a client accept a "good" response when there's actually a more up-to-date response saying the status is "revoked". To mitigate this attack, clients MUST have access to an accurate source of time and make sure the OCSP responses they receive are fresh enough ๐ฐ๏ธ
Clients that don't have an accurate source of date and time are open to service disruption ๐ For example, a client with a clock that runs too fast may reject a fresh OCSP response. On the flip side, a client with a clock that runs too slow may incorrectly accept expired, still-valid responses for certificates that may actually be revoked ๐
Future versions of OCSP may give clients a way to find out whether a responder supports nonces or doesn't support nonces ๐ฎ If a client can determine that the responder supports nonces, it MUST reject a reply that doesn't contain an expected nonce. Otherwise, clients that choose to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse just because the expected nonce doesn't exist, but they MUST fall back to validating the OCSPResponse based on time โณ
8.2. On-Path Attacks
To reduce the risk from this class of attack, the client MUST properly validate the signature on the response ๐ก๏ธ
Signed responses in OCSP are what authenticate the identity of the OCSP responder and verify that it's authorized to sign responses on the CA's behalf ๐ชช
Clients MUST ensure that they're communicating with an authorized responder by following the rules described in Section 4.2.2.2 of [RFC6960] ๐
8.3. Impersonation Attacks
Signed responses in OCSP are what authenticate the identity of the OCSP responder ๐ญ
As detailed in [RFC6960], clients must properly validate the signature of the OCSP response and the signature on the OCSP response signer certificate, so they can make sure an authorized responder created it ๐ซฃ
8.4. Denial-of-Service Attacks ๐ก๏ธ
Okay bestie, OCSP responders SHOULD take measures to prevent or mitigate denial-of-service attacks. Here's the tea: this profile uses unsigned OCSPRequests, so access to the responder may be implicitly given to everyone who can send a request to it ๐. That means the ability to mount a denial-of-service attack with a flood of requests may be greater. For example, a responder could limit the rate of incoming requests from a particular IP address if it spots questionable behavior ๐ซ.
8.5. Modification of HTTP Header Fields ๐
Values included in HTTP header fields, as described in Sections 6 and 7, are not cryptographically protected ๐, so an attacker may manipulate them. Clients SHOULD use these values for caching guidance only, and ultimately SHOULD rely only on the values present in the signed OCSPResponse (Section 4.2.2.1 of [RFC6960]). Clients SHOULD NOT rely on cached responses beyond the nextUpdate time โฐ.
8.6. Request Authentication and Authorization ๐
The suggested use of unsigned requests in this environment removes an option that lets the responder determine the authenticity of incoming requests ๐ต๏ธโโ๏ธ. So access to the responder may be implicitly given to everyone who can send a request to it. Environments where explicit authorization to access the OCSP responder is necessary can utilize other mechanisms to authenticate requestors or restrict or meter service ๐.
8.7. Use of SHA-1 for the Calculation of CertID Field Values ๐งฎ
Using SHA-1 for the calculation of CertID field values is not a concern from a cryptographic security standpoint ๐. But the continued use of SHA-1 in an ecosystem means software that interoperates with that ecosystem has to keep supporting SHA-1. This adds implementation complexity and potential attack surface for the software in question ๐ฌ. So keeping SHA-1 around to maintain interoperability with legacy software must be weighed against that extra complexity and attack surface.
9. IANA Considerations ๐ญ
This document has no IANA actions.
10. References ๐
10.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
https://www.rfc-editor.org/info/rfc3986. - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
https://www.rfc-editor.org/info/rfc4648. - [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", RFC 5019, DOI 10.17487/RFC5019, September 2007,
https://www.rfc-editor.org/info/rfc5019. - [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, DOI 10.17487/RFC5280, May 2008,
https://www.rfc-editor.org/info/rfc5280. - [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010,
https://www.rfc-editor.org/info/rfc5754. - [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013,
https://www.rfc-editor.org/info/rfc6960. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. - [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022,
https://www.rfc-editor.org/info/rfc9110. - [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022,
https://www.rfc-editor.org/info/rfc9111. - [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
https://www.rfc-editor.org/info/rfc9846.
10.2. Informative References
- [OCSPMP] Open Mobile Alliance, "Online Certificate Status Protocol Mobile Profile", Candidate Version V1.0, 27 January 2004,
https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pd. - [RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", RFC 3143, DOI 10.17487/RFC3143, June 2001,
https://www.rfc-editor.org/info/rfc3143. - [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
https://www.rfc-editor.org/info/rfc3174. - [RFC9500] Gutmann, P. and C. Bonnell, "Standard Public Key Cryptography (PKC) Test Keys", RFC 9500, DOI 10.17487/RFC9500, December 2023,
https://www.rfc-editor.org/info/rfc9500.
Appendix A. Differences from RFC 5019 ๐
This document obsoletes [RFC5019]. [RFC5019] defines a lightweight profile for OCSP that makes the protocol more suitable for use in high-volume environments. The lightweight profile specifies the mandatory use of SHA-1 when calculating the values of several fields in OCSP requests and responses. In recent years, weaknesses have been demonstrated with the SHA-1 algorithm. As a result, SHA-1 is increasingly falling out of use even for non-security-relevant use cases. This document obsoletes the lightweight profile as specified in [RFC5019] to instead recommend the use of SHA-256 where SHA-1 was previously required. An OCSP client compliant with [RFC5019] is still able to use SHA-1, but the use of SHA-1 may become obsolete in the future.
Substantive changes to RFC 5019:
- Section 3.1.1 requires new OCSP clients to use SHA-256 to support migration for OCSP clients.
- Section 3.2.2 requires new OCSP responders to use the
byKeyfield and support migration frombyNamefields. - Section 6 clarifies that OCSP clients MUST NOT include whitespace or any other characters that are not part of the base64 character repertoire in the base64-encoded string. ๐
Appendix B. Examples ๐ง
B.1. Root CA Certificate ๐
okay so B.1 is the root CA cert and it's self-signed, so the CA is basically signing its own paper ๐ It's the CA that issued the end-entity and OCSP-delegated responder example certificates below.
The key pair for the CA is the "testECCP521" key from Section 2.3 of [RFC9500]. ๐
-----BEGIN CERTIFICATE-----
MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF
K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3
+i2iYNjrYtbS9dZJJ44yFzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7F
quikKBc85W8A3psVfB5cgsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92KNC
MEAwHQYDVR0OBBYEFI7CFAlgduqQOOk5rhttUsQXfZ++MA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgIEMAoGCCqGSM49BAMEA4GLADCBhwJBbr/1SJiHCgXG
EJ7R+3er1LdWqrdZHgtCwyT7+wFBIJmVswEiom2LGh/oMuu5mD+u/+o1m07vmmZj
/+ipGp8TIwkCQgCoZ4bHte6XkFm7hUXascLN7vkv7qKwXyTsCvIDpEDTRCX8dUFe
73jGebitkumRHjVhlBJLo7n3FMJrFHNoeblMbw==
-----END CERTIFICATE-----Here's the decoded breakdown, the ASN.1 dump of the same cert, so you can see every little field ๐ง
0 552: SEQUENCE {
4 394: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 1: INTEGER 1
16 10: SEQUENCE {
18 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
28 56: SEQUENCE {
30 11: SET {
32 9: SEQUENCE {
34 3: OBJECT IDENTIFIER countryName (2 5 4 6)
39 2: PrintableString 'XX'
: }
: }
43 20: SET {
45 18: SEQUENCE {
47 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
52 11: UTF8String 'Certs 'r Us'
: }
: }
65 19: SET {
67 17: SEQUENCE {
69 3: OBJECT IDENTIFIER commonName (2 5 4 3)
74 10: UTF8String 'Issuing CA'
: }
: }
: }
86 30: SEQUENCE {
88 13: UTCTime 02/04/2024 12:37:47 GMT
103 13: UTCTime 02/04/2025 12:37:47 GMT
: }
118 56: SEQUENCE {
120 11: SET {
122 9: SEQUENCE {
124 3: OBJECT IDENTIFIER countryName (2 5 4 6)
129 2: PrintableString 'XX'
: }
: }
133 20: SET {
135 18: SEQUENCE {
137 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
142 11: UTF8String 'Certs 'r Us'
: }
: }
155 19: SET {
157 17: SEQUENCE {
159 3: OBJECT IDENTIFIER commonName (2 5 4 3)
164 10: UTF8String 'Issuing CA'
: }
: }
: }
176 155: SEQUENCE {
179 16: SEQUENCE {
181 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
190 5: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
: }
197 134: BIT STRING
: 04 01 D0 FD 72 57 A8 4C 74 7F 56 25 75 C0 73 85
: DB EB F2 F5 2B EA 58 08 3D B8 2F DD 15 31 D8 AA
: E3 CC 87 5F F0 2F F7 FA 2D A2 60 D8 EB 62 D6 D2
: F5 D6 49 27 8E 32 17 36 A0 62 8C BB B3 03 08 B6
: E6 18 DB 00 F6 2A D2 04 C6 46 03 59 BC 81 8A B8
: 96 1B F0 F0 FC 0E C5 AA E8 A4 28 17 3C E5 6F 00
: DE 9B 15 7C 1E 5C 82 C6 4F 56 2F CA DE FC 4A 4C
: 28 F6 D3 42 CF 3E F6 16 FC 82 D3 3B 72 85 C9 21
: F2 BF 36 FD D8
: }
334 66: [3] {
336 64: SEQUENCE {
338 29: SEQUENCE {
340 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
345 22: OCTET STRING, encapsulates {
347 20: OCTET STRING
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
369 15: SEQUENCE {
371 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
376 1: BOOLEAN TRUE
379 5: OCTET STRING, encapsulates {
381 3: SEQUENCE {
383 1: BOOLEAN TRUE
: }
: }
: }
386 14: SEQUENCE {
388 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
393 1: BOOLEAN TRUE
396 4: OCTET STRING, encapsulates {
398 2: BIT STRING 2 unused bits
: '100000'B (bit 5)
: }
: }
: }
: }
: }
402 10: SEQUENCE {
404 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
414 139: BIT STRING, encapsulates {
418 135: SEQUENCE {
421 65: INTEGER
: 6E BF F5 48 98 87 0A 05 C6 10 9E D1 FB 77 AB D4
: B7 56 AA B7 59 1E 0B 42 C3 24 FB FB 01 41 20 99
: 95 B3 01 22 A2 6D 8B 1A 1F E8 32 EB B9 98 3F AE
: FF EA 35 9B 4E EF 9A 66 63 FF E8 A9 1A 9F 13 23
: 09
488 66: INTEGER
: 00 A8 67 86 C7 B5 EE 97 90 59 BB 85 45 DA B1 C2
: CD EE F9 2F EE A2 B0 5F 24 EC 0A F2 03 A4 40 D3
: 44 25 FC 75 41 5E EF 78 C6 79 B8 AD 92 E9 91 1E
: 35 61 94 12 4B A3 B9 F7 14 C2 6B 14 73 68 79 B9
: 4C 6F
: }
: }
: }B.2. End-Entity Certificate ๐ฆ
this is the end-entity cert, and it's the one whose status gets requested and returned in the OCSP request and response examples below ๐
The key pair for the end-entity certificate is the "testECCP256" key from Section 2.3 of [RFC9500]. ๐๏ธ
-----BEGIN CERTIFICATE-----
MIIB2zCCATygAwIBAgIEAarwDTAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEU
MBIGA1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQw
NDAyMTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjAcMRowGAYDVQQDDBF4bi0tMThqNGQu
ZXhhbXBsZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERS
xyoeVY+9b3O+XkjpMjLMRcWxbEzRDEy41bihcTnpSILImSVymTQl9BQZq36QpCpJ
QnKjUDBOMB0GA1UdDgQWBBRbcKeYF/ef9jfS9+PcRGwhCde71DAfBgNVHSMEGDAW
gBSOwhQJYHbqkDjpOa4bbVLEF32fvjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAME
A4GMADCBiAJCAIot8SYNFkScrcsY5T81HSmNzhP/0GC87N3WI849CN0qmNa0nMXW
8HnDKGR5nv/D9x+T8uLMBlpFUWmHQmXAJPN8AkIBW8A0XsiyPJyZfaZieODmtnoI
obZP+eTLNWkGUFL6uCtLtQmYtrXpLAJfvkE6WYVqCUl495Kx9l6M9TBLK5X6V3w=
-----END CERTIFICATE-----And here's the ASN.1 breakdown of that one ๐
0 475: SEQUENCE {
4 316: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 4: INTEGER 27979789
19 10: SEQUENCE {
21 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
31 56: SEQUENCE {
33 11: SET {
35 9: SEQUENCE {
37 3: OBJECT IDENTIFIER countryName (2 5 4 6)
42 2: PrintableString 'XX'
: }
: }
46 20: SET {
48 18: SEQUENCE {
50 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
55 11: UTF8String 'Certs 'r Us'
: }
: }
68 19: SET {
70 17: SEQUENCE {
72 3: OBJECT IDENTIFIER commonName (2 5 4 3)
77 10: UTF8String 'Issuing CA'
: }
: }
: }
89 30: SEQUENCE {
91 13: UTCTime 02/04/2024 12:37:47 GMT
106 13: UTCTime 02/04/2025 12:37:47 GMT
: }
121 28: SEQUENCE {
123 26: SET {
125 24: SEQUENCE {
127 3: OBJECT IDENTIFIER commonName (2 5 4 3)
132 17: UTF8String 'xn--18j4d.example'
: }
: }
: }
151 89: SEQUENCE {
153 19: SEQUENCE {
155 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
164 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7)
: }
174 66: BIT STRING
: 04 42 25 48 F8 8F B7 82 FF B5 EC A3 74 44 52 C7
: 2A 1E 55 8F BD 6F 73 BE 5E 48 E9 32 32 CC 45 C5
: B1 6C 4C D1 0C 4C B8 D5 B8 A1 71 39 E9 48 82 C8
: 99 25 72 99 34 25 F4 14 19 AB 7E 90 A4 2A 49 42
: 72
: }
242 80: [3] {
244 78: SEQUENCE {
246 29: SEQUENCE {
248 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
253 22: OCTET STRING, encapsulates {
255 20: OCTET STRING
: 5B 70 A7 98 17 F7 9F F6 37 D2 F7 E3 DC 44 6C 21
: 09 D7 BB D4
: }
: }
277 31: SEQUENCE {
279 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
284 24: OCTET STRING, encapsulates {
286 22: SEQUENCE {
288 20: [0]
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
: }
310 12: SEQUENCE {
312 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
317 1: BOOLEAN TRUE
320 2: OCTET STRING, encapsulates {
322 0: SEQUENCE {}
: }
: }
: }
: }
: }
324 10: SEQUENCE {
326 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
336 140: BIT STRING, encapsulates {
340 136: SEQUENCE {
343 66: INTEGER
: 00 8A 2D F1 26 0D 16 44 9C AD CB 18 E5 3F 35 1D
: 29 8D CE 13 FF D0 60 BC EC DD D6 23 CE 3D 08 DD
: 2A 98 D6 B4 9C C5 D6 F0 79 C3 28 64 79 9E FF C3
: F7 1F 93 F2 E2 CC 06 5A 45 51 69 87 42 65 C0 24
: F3 7C
411 66: INTEGER
: 01 5B C0 34 5E C8 B2 3C 9C 99 7D A6 62 78 E0 E6
: B6 7A 08 A1 B6 4F F9 E4 CB 35 69 06 50 52 FA B8
: 2B 4B B5 09 98 B6 B5 E9 2C 02 5F BE 41 3A 59 85
: 6A 09 49 78 F7 92 B1 F6 5E 8C F5 30 4B 2B 95 FA
: 57 7C
: }
: }
: }B.3. OCSP Responder Certificate ๐ง
this is the cert for the OCSP-delegated response that signed the OCSP response example below โจ so it's the one doing the signing in that example ๐๏ธ
The key pair for the OCSP responder certificate is the "testECCP384" key from Section 2.3 of [RFC9500]. ๐
-----BEGIN CERTIFICATE-----
MIICSzCCAa6gAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA8MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
Q2VydHMgJ3IgVXMxFzAVBgNVBAMMDk9DU1AgUmVzcG9uZGVyMHYwEAYHKoZIzj0C
AQYFK4EEACIDYgAEWwkBuIUjKW65GdUP+hqcs3S8TUCVhigr/soRsdla27VHNK9X
C/grcijPImvPTCXdvP47GjrTlDDv92Ph1o0uFR2Rcgt3lbWNprNGOWE6j7m1qNpI
xnRxF/mRnoQk837Io4GHMIGEMB0GA1UdDgQWBBQK46D+ndQldpi163Lrygznvz31
8TAfBgNVHSMEGDAWgBSOwhQJYHbqkDjpOa4bbVLEF32fvjAMBgNVHRMBAf8EAjAA
MA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDCTAPBgkrBgEFBQcw
AQUEAgUAMAoGCCqGSM49BAMEA4GKADCBhgJBFCqM1gpsZcd0Zd8RW8H/+L4OIbTa
GtpT2QY0pd6JBw91lFqNCxj+F1k9XJrKSQAVVAa/b3JaZOsRrH6vihlO3MYCQUkL
C0mmLubTRDH2v+6A1aycIVKIpR3G6+PuaD2Um3PSF7FElkoU4NYkbl1SH/8FzbDy
/LCBhih25e7hAtyg/XsI
-----END CERTIFICATE-----0 587: SEQUENCE {
4 430: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 1: INTEGER 1
16 10: SEQUENCE {
18 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
28 56: SEQUENCE {
30 11: SET {
32 9: SEQUENCE {
34 3: OBJECT IDENTIFIER countryName (2 5 4 6)
39 2: PrintableString 'XX'
: }
: }
43 20: SET {
45 18: SEQUENCE {
47 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
52 11: UTF8String 'Certs 'r Us'
: }
: }
65 19: SET {
67 17: SEQUENCE {
69 3: OBJECT IDENTIFIER commonName (2 5 4 3)
74 10: UTF8String 'Issuing CA'
: }
: }
: }
86 30: SEQUENCE {
88 13: UTCTime 02/04/2024 12:37:47 GMT
103 13: UTCTime 02/04/2025 12:37:47 GMT
: }
118 60: SEQUENCE {
120 11: SET {
122 9: SEQUENCE {
124 3: OBJECT IDENTIFIER countryName (2 5 4 6)
129 2: PrintableString 'XX'
: }
: }
133 20: SET {
135 18: SEQUENCE {
137 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
142 11: UTF8String 'Certs 'r Us'
: }
: }
155 23: SET {
157 21: SEQUENCE {
159 3: OBJECT IDENTIFIER commonName (2 5 4 3)
164 14: UTF8String 'OCSP Responder'
: }
: }
: }
180 118: SEQUENCE {
182 16: SEQUENCE {
184 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
193 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
: }
200 98: BIT STRING
: 04 5B 09 01 B8 85 23 29 6E B9 19 D5 0F FA 1A 9C
: B3 74 BC 4D 40 95 86 28 2B FE CA 11 B1 D9 5A DB
: B5 47 34 AF 57 0B F8 2B 72 28 CF 22 6B CF 4C 25
: DD BC FE 3B 1A 3A D3 94 30 EF F7 63 E1 D6 8D 2E
: 15 1D 91 72 0B 77 95 B5 8D A6 B3 46 39 61 3A 8F
: B9 B5 A8 DA 48 C6 74 71 17 F9 91 9E 84 24 F3 7E
: C8
: }
300 135: [3] {
303 132: SEQUENCE {
306 29: SEQUENCE {
308 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
313 22: OCTET STRING, encapsulates {
315 20: OCTET STRING
: 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7
: BF 3D F5 F1
: }
: }
337 31: SEQUENCE {
339 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
344 24: OCTET STRING, encapsulates {
346 22: SEQUENCE {
348 20: [0]
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
: }
370 12: SEQUENCE {
372 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
377 1: BOOLEAN TRUE
380 2: OCTET STRING, encapsulates {
382 0: SEQUENCE {}
: }
: }
384 14: SEQUENCE {
386 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
391 1: BOOLEAN TRUE
394 4: OCTET STRING, encapsulates {
396 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: }
400 19: SEQUENCE {
402 3: OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
407 12: OCTET STRING, encapsulates {
409 10: SEQUENCE {
411 8: OBJECT IDENTIFIER ocspSigning (1 3 6 1 5 5 7 3 9)
: }
: }
: }
421 15: SEQUENCE {
423 9: OBJECT IDENTIFIER ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
434 2: OCTET STRING, encapsulates {
436 0: NULL
: }
: }
: }
: }
: }
438 10: SEQUENCE {
440 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
450 138: BIT STRING, encapsulates {
454 134: SEQUENCE {
457 65: INTEGER
: 14 2A 8C D6 0A 6C 65 C7 74 65 DF 11 5B C1 FF F8
: BE 0E 21 B4 DA 1A DA 53 D9 06 34 A5 DE 89 07 0F
: 75 94 5A 8D 0B 18 FE 17 59 3D 5C 9A CA 49 00 15
: 54 06 BF 6F 72 5A 64 EB 11 AC 7E AF 8A 19 4E DC
: C6
524 65: INTEGER
: 49 0B 0B 49 A6 2E E6 D3 44 31 F6 BF EE 80 D5 AC
: 9C 21 52 88 A5 1D C6 EB E3 EE 68 3D 94 9B 73 D2
: 17 B1 44 96 4A 14 E0 D6 24 6E 5D 52 1F FF 05 CD
: B0 F2 FC B0 81 86 28 76 E5 EE E1 02 DC A0 FD 7B
: 08
: }
: }
: }Appendix B. Examples
B.4. OCSP Request โจ
okay so this one is the OCSP request for the end-entity certificate above ๐ it's base64-encoded, so it comes out as one little blob you can copy around ๐
MGEwXzBdMFswWTANBglghkgBZQMEAgEFAAQgOplGd1aAc6cHv95QGGNF5M1hNNsI
Xrqh0QQl8DtvCOoEIEdKbKMB8j3J9/cHhwThx/X8lucWdfbtiC56tlw/WEVDAgQB
qvANand here's the decoded version, so you can see the structure lol ๐ง
0 97: SEQUENCE {
2 95: SEQUENCE {
4 93: SEQUENCE {
6 91: SEQUENCE {
8 89: SEQUENCE {
10 13: SEQUENCE {
12 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
23 0: NULL
: }
25 32: OCTET STRING
: 3A 99 46 77 56 80 73 A7 07 BF DE 50 18 63 45 E4
: CD 61 34 DB 08 5E BA A1 D1 04 25 F0 3B 6F 08 EA
59 32: OCTET STRING
: 47 4A 6C A3 01 F2 3D C9 F7 F7 07 87 04 E1 C7 F5
: FC 96 E7 16 75 F6 ED 88 2E 7A B6 5C 3F 58 45 43
93 4: INTEGER 27979789
: }
: }
: }
: }
: }B.5. OCSP Response ๐
and now the OCSP response for that same end-entity certificate ๐ฆ this one is base64-encoded too, and it's a whole lot longer, so get comfy ๐ญ๐ซถ
MIIDnwoBAKCCA5gwggOUBgkrBgEFBQcwAQEEggOFMIIDgTCBsKIWBBQK46D+ndQl
dpi163Lrygznvz318RgPMjAyNDA0MDIxMjM3NDdaMIGEMIGBMFkwDQYJYIZIAWUD
BAIBBQAEIDqZRndWgHOnB7/eUBhjReTNYTTbCF66odEEJfA7bwjqBCBHSmyjAfI9
yff3B4cE4cf1/JbnFnX27YguerZcP1hFQwIEAarwDYAAGA8yMDI0MDQwMzEyMzc0
N1qgERgPMjAyNDA0MTAxMjM3NDdaMAoGCCqGSM49BAMDA2kAMGYCMQDRmVmiIb4D
m9yEXiv2XtoeQi6ftpjLmlBqqRIi+3htfF/OyjdHnFuh38cQKYqqrWYCMQDKiPct
Vu7SQs587d2ZBEHQH20j5AFiGGsbI1b3+C9ZK6NIzgD6DnWlDwpSfilEarOgggJT
MIICTzCCAkswggGuoAMCAQICAQEwCgYIKoZIzj0EAwQwODELMAkGA1UEBhMCWFgx
FDASBgNVBAoMC0NlcnRzICdyIFVzMRMwEQYDVQQDDApJc3N1aW5nIENBMB4XDTI0
MDQwMjEyMzc0N1oXDTI1MDQwMjEyMzc0N1owPDELMAkGA1UEBhMCWFgxFDASBgNV
BAoMC0NlcnRzICdyIFVzMRcwFQYDVQQDDA5PQ1NQIFJlc3BvbmRlcjB2MBAGByqG
SM49AgEGBSuBBAAiA2IABFsJAbiFIyluuRnVD/oanLN0vE1AlYYoK/7KEbHZWtu1
RzSvVwv4K3IozyJrz0wl3bz+Oxo605Qw7/dj4daNLhUdkXILd5W1jaazRjlhOo+5
tajaSMZ0cRf5kZ6EJPN+yKOBhzCBhDAdBgNVHQ4EFgQUCuOg/p3UJXaYtety68oM
57899fEwHwYDVR0jBBgwFoAUjsIUCWB26pA46TmuG21SxBd9n74wDAYDVR0TAQH/
BAIwADAOBgNVHQ8BAf8EBAMCB4AwEwYDVR0lBAwwCgYIKwYBBQUHAwkwDwYJKwYB
BQUHMAEFBAIFADAKBggqhkjOPQQDBAOBigAwgYYCQRQqjNYKbGXHdGXfEVvB//i+
DiG02hraU9kGNKXeiQcPdZRajQsY/hdZPVyaykkAFVQGv29yWmTrEax+r4oZTtzG
AkFJCwtJpi7m00Qx9r/ugNWsnCFSiKUdxuvj7mg9lJtz0hexRJZKFODWJG5dUh//
Bc2w8vywgYYoduXu4QLcoP17CA==0 927: SEQUENCE {
4 1: ENUMERATED 0
7 920: [0] {
11 916: SEQUENCE {
15 9: OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)
26 901: OCTET STRING, encapsulates {
30 897: SEQUENCE {
34 176: SEQUENCE {
37 22: [2] {
39 20: OCTET STRING
: 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7
: BF 3D F5 F1
: }
61 15: GeneralizedTime 02/04/2024 12:37:47 GMT
78 132: SEQUENCE {
81 129: SEQUENCE {
84 89: SEQUENCE {
86 13: SEQUENCE {
88 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
99 0: NULL
: }
101 32: OCTET STRING
: 3A 99 46 77 56 80 73 A7 07 BF DE 50 18 63 45 E4
: CD 61 34 DB 08 5E BA A1 D1 04 25 F0 3B 6F 08 EA
135 32: OCTET STRING
: 47 4A 6C A3 01 F2 3D C9 F7 F7 07 87 04 E1 C7 F5
: FC 96 E7 16 75 F6 ED 88 2E 7A B6 5C 3F 58 45 43
169 4: INTEGER 27979789
: }
175 0: [0]
177 15: GeneralizedTime 03/04/2024 12:37:47 GMT
194 17: [0] {
196 15: GeneralizedTime 10/04/2024 12:37:47 GMT
: }
: }
: }
: }
213 10: SEQUENCE {
215 8: OBJECT IDENTIFIER
: ecdsaWithSHA384 (1 2 840 10045 4 3 3)
: }
225 105: BIT STRING, encapsulates {
228 102: SEQUENCE {
230 49: INTEGER
: 00 D1 99 59 A2 21 BE 03 9B DC 84 5E 2B F6 5E DA
: 1E 42 2E 9F B6 98 CB 9A 50 6A A9 12 22 FB 78 6D
: 7C 5F CE CA 37 47 9C 5B A1 DF C7 10 29 8A AA AD
: 66
281 49: INTEGER
: 00 CA 88 F7 2D 56 EE D2 42 CE 7C ED DD 99 04 41
: D0 1F 6D 23 E4 01 62 18 6B 1B 23 56 F7 F8 2F 59
: 2B A3 48 CE 00 FA 0E 75 A5 0F 0A 52 7E 29 44 6A
: B3
: }
: }
332 595: [0] {
336 591: SEQUENCE {
340 587: SEQUENCE {
344 430: SEQUENCE {
348 3: [0] {
350 1: INTEGER 2
: }
353 1: INTEGER 1
356 10: SEQUENCE {
358 8: OBJECT IDENTIFIER
: ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
368 56: SEQUENCE {
370 11: SET {
372 9: SEQUENCE {
374 3: OBJECT IDENTIFIER countryName (2 5 4 6)
379 2: PrintableString 'XX'
: }
: }
383 20: SET {
385 18: SEQUENCE {
387 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
392 11: UTF8String 'Certs 'r Us'
: }
: }
405 19: SET {
407 17: SEQUENCE {
409 3: OBJECT IDENTIFIER commonName (2 5 4 3)
414 10: UTF8String 'Issuing CA'
: }
: }
: }
426 30: SEQUENCE {
428 13: UTCTime 02/04/2024 12:37:47 GMT
443 13: UTCTime 02/04/2025 12:37:47 GMT
: }
458 60: SEQUENCE {
460 11: SET {
462 9: SEQUENCE {
464 3: OBJECT IDENTIFIER countryName (2 5 4 6)
469 2: PrintableString 'XX'
: }
: }
473 20: SET {
475 18: SEQUENCE {
477 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
482 11: UTF8String 'Certs 'r Us'
: }
: }
495 23: SET {
497 21: SEQUENCE {
499 3: OBJECT IDENTIFIER commonName (2 5 4 3)
504 14: UTF8String 'OCSP Responder'
: }
: }
: }
520 118: SEQUENCE {
522 16: SEQUENCE {
524 7: OBJECT IDENTIFIER
: ecPublicKey (1 2 840 10045 2 1)
533 5: OBJECT IDENTIFIER
: secp384r1 (1 3 132 0 34)
: }
540 98: BIT STRING
: 04 5B 09 01 B8 85 23 29 6E B9 19 D5 0F FA 1A 9C
: B3 74 BC 4D 40 95 86 28 2B FE CA 11 B1 D9 5A DB
: B5 47 34 AF 57 0B F8 2B 72 28 CF 22 6B CF 4C 25
: DD BC FE 3B 1A 3A D3 94 30 EF F7 63 E1 D6 8D 2E
: 15 1D 91 72 0B 77 95 B5 8D A6 B3 46 39 61 3A 8F
: B9 B5 A8 DA 48 C6 74 71 17 F9 91 9E 84 24 F3 7E
: C8
: }
640 135: [3] {
643 132: SEQUENCE {
646 29: SEQUENCE {
648 3: OBJECT IDENTIFIER
: subjectKeyIdentifier (2 5 29 14)
653 22: OCTET STRING, encapsulates {
655 20: OCTET STRING
: 0A E3 A0 FE 9D D4 25 76 98 B5 EB 72 EB CA 0C E7
: BF 3D F5 F1
: }
: }
677 31: SEQUENCE {
679 3: OBJECT IDENTIFIER
: authorityKeyIdentifier (2 5 29 35)
684 24: OCTET STRING, encapsulates {
686 22: SEQUENCE {
688 20: [0]
: 8E C2 14 09 60 76 EA 90 38 E9 39 AE 1B 6D 52 C4
: 17 7D 9F BE
: }
: }
: }
710 12: SEQUENCE {
712 3: OBJECT IDENTIFIER
: basicConstraints (2 5 29 19)
717 1: BOOLEAN TRUE
720 2: OCTET STRING, encapsulates {
722 0: SEQUENCE {}
: }
: }
724 14: SEQUENCE {
726 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
731 1: BOOLEAN TRUE
734 4: OCTET STRING, encapsulates {
736 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: }
740 19: SEQUENCE {
742 3: OBJECT IDENTIFIER
: extKeyUsage (2 5 29 37)
747 12: OCTET STRING, encapsulates {
749 10: SEQUENCE {
751 8: OBJECT IDENTIFIER
: ocspSigning (1 3 6 1 5 5 7 3 9)
: }
: }
: }
761 15: SEQUENCE {
763 9: OBJECT IDENTIFIER
: ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
774 2: OCTET STRING, encapsulates {
776 0: NULL
: }
: }
: }
: }
: }
778 10: SEQUENCE {
780 8: OBJECT IDENTIFIER
: ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: }
790 138: BIT STRING, encapsulates {
794 134: SEQUENCE {
797 65: INTEGER
: 14 2A 8C D6 0A 6C 65 C7 74 65 DF 11 5B C1 FF F8
: BE 0E 21 B4 DA 1A DA 53 D9 06 34 A5 DE 89 07 0F
: 75 94 5A 8D 0B 18 FE 17 59 3D 5C 9A CA 49 00 15
: 54 06 BF 6F 72 5A 64 EB 11 AC 7E AF 8A 19 4E DC
: C6
864 65: INTEGER
: 49 0B 0B 49 A6 2E E6 D3 44 31 F6 BF EE 80 D5 AC
: 9C 21 52 88 A5 1D C6 EB E3 EE 68 3D 94 9B 73 D2
: 17 B1 44 96 4A 14 E0 D6 24 6E 5D 52 1F FF 05 CD
: B0 F2 FC B0 81 86 28 76 E5 EE E1 02 DC A0 FD 7B
: 08
: }
: }
: }
: }
: }
: }
: }
: }
: }
: }Acknowledgments โจ
Huge shoutout to Alex Deacon and Ryan Hurst ๐ซถ for all their work producing the original version of the lightweight profile for OCSP. They built the foundation, and we're so grateful. ๐
The authors of this version also want to thank Paul Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and Wendy Brown for their reviews, feedback, and suggestions. Honestly, these people are the reason this doc is so much cleaner. ๐ง
The authors also wish to thank Magnus Nystrom of RSA Security, Inc., Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet, Ltd. for their contributions to the original [RFC5019] specification. The organizational affiliations listed reflect where everyone worked at the time RFC 5019 was published, so they're a little snapshot in time. ๐ธ
Authors' Addresses ๐
- Tadahiko Ito
- SECOM CO., LTD.
- Email: tadahiko.ito.public@gmail.com
- Additional contact information:
- ไผ่ค ๅฟ ๅฝฆ
- SECOM CO., LTD.
- Clint Wilson
- Apple, Inc.
- Email: clintw@apple.com
- Corey Bonnell
- DigiCert, Inc.
- Email: corey.bonnell@digicert.com
- Sean Turner
- sn3rd
- Email: sean@sn3rd.com
๐ฆ where this page comes from
- ietf: rfc9919 2026-07
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms