RFC 5019
The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
RFC 5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments 🎀
Okay bestie, let's get into it 💖 First, the paperwork so you know who's behind this:
- Network Working Group 🌐
- Request for Comments: 5019
- Authors: A. Deacon (VeriSign) and R. Hurst (Microsoft) 👩💻
- Category: Standards Track
- Date: September 2007
- Obsoletes/Updates: The header doesn't say this one obsoletes or updates anything 🙈
Status of This Memo ✨
So this is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅
Abstract 🦋
This spec is a profile of the Online Certificate Status Protocol (OCSP) that tackles the scalability problems you run into when you use OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments, and/or in PKI environments that need a lightweight solution to keep bandwidth and client-side processing to a minimum 🌸
Table of Contents 📜
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................4
2. OCSP Message Profile ............................................4
2.1. OCSP Request Profile .......................................4
2.1.1. OCSPRequest Structure ...............................4
2.1.2. Signed OCSPRequests .................................5
2.2. OCSP Response Profile ......................................5
2.2.1. OCSPResponse Structure ..............................5
2.2.2. Signed OCSPResponses ................................6
2.2.3. OCSPResponseStatus Values ...........................6
2.2.4. thisUpdate, nextUpdate, and producedAt ..............7
3. Client Behavior .................................................7
3.1. OCSP Responder Discovery ...................................7
3.2. Sending an OCSP Request ....................................7
4. Ensuring an OCSPResponse Is Fresh ...............................8
5. Transport Profile ...............................................9
6. Caching Recommendations .........................................9
6.1. Caching at the Client .....................................10
6.2. HTTP Proxies ..............................................10
6.3. Caching at Servers ........................................12
7. Security Considerations ........................................12
7.1. Replay Attacks ............................................12
7.2. Man-in-the-Middle Attacks .................................13
7.3. Impersonation Attacks .....................................13
7.4. Denial-of-Service Attacks .................................13
7.5. Modification of HTTP Headers ..............................14
7.6. Request Authentication and Authorization ..................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Example OCSP Messages .................................16
A.1. OCSP Request ..............................................16
A.2. OCSP Response .............................................161. Introduction ✨
OCSP is the thing that tells you whether a digital certificate is still good, and it does that instead of using Certificate Revocation Lists (CRLs) 🔐 It's been around since 1999, it's been deployed in all kinds of environments, and it's genuinely proven to be a useful way to check certificate status. (Quick note, for brevity we say OCSP is used to verify certificate status, but this protocol only checks the revocation status of a certificate.)
Lowkey, a bunch of OCSP deployments have been keeping high-value transactions and super sensitive info safe, like in banking and finance 💰 Because of that, it's been a big deal that an OCSP responder can respond in "real time" (meaning it generates a fresh OCSP response for every single 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 is spreading into all sorts of new places, so we need a scalable and cost-effective certificate status mechanism 🌈 OCSP as it's currently defined and deployed works great for small to medium PKIs running on powerful systems over wired networks. But it has limits on how well it scales, in terms of both efficiency and cost. Mobile environments are the tricky part: network bandwidth can be scarce and client devices have limited processing power, so OCSP has to be used carefully to cut down on bandwidth usage and client-side processing complexity 📱 [OCSPMP]
PKI keeps getting deployed in places where millions, if not hundreds of millions, of certificates have been issued 🤯 In lots of these places, an even bigger crowd of users (also called relying parties) needs to know that the certificate they're relying on hasn't been revoked. So OCSP has to be used in a way that keeps the load on OCSP responders, and on the network infrastructure hosting them, as low as possible.
This document tackles those scalability issues by defining a message profile and clarifying how OCSP clients and responders should behave, so that the following become 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 has no way to signal responder capabilities inside the protocol itself. So clients that need to tell apart responses from conformant responders and non-conformant ones have to use out-of-band mechanisms to figure out when a responder is operating under this profile, and therefore when this profile's requirements apply. If out-of-band mechanisms aren't available, this profile still makes sure interoperability happens between a fully conformant OCSP 2560 client and a responder operating in a mode described in this specification 🫶
1.1. Requirements Terminology 🔑
Here's the decoder ring 💍 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 [RFC2119].
2. OCSP Message Profile 💌
This section defines a subset of OCSPRequest and OCSPResponse functionality, as defined in [OCSP].
2.1. OCSP Request Profile 📨
2.1.1. OCSPRequest Structure
OCSPRequests that conform to this profile MUST include only one Request in the OCSPRequest.RequestList structure 🎯
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.
Clients MUST NOT include the singleRequestExtensions structure. 🚫
Clients SHOULD NOT include the requestExtensions structure. If a requestExtensions structure is included, this profile RECOMMENDS that it contain only the nonce extension (id-pkix-ocsp-nonce). Check out Section 4 for the issues around using a nonce in high-volume OCSP environments 👀
2.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 servers MUST be prepared to receive unsigned OCSP requests that contain the requestorName field, but must realize that the provided value is not authenticated. Don't trust a name you can't verify, bestie 🙅♀️
2.2. OCSP Response Profile 🎁
2.2.1. OCSPResponse Structure
Responders MUST generate a BasicOCSPResponse, 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. They MAY include additional SingleResponse elements if that's necessary to improve response pre-generation performance or cache efficiency 🧚
The responder SHOULD NOT include responseExtensions. As specified in [OCSP], clients MUST ignore unrecognized non-critical responseExtensions in the response.
Here's a case where it gets a little messy 🙈 If a responder can't respond to an OCSP request that has an option the server doesn't support, it SHOULD return the most complete response it can. For example, if a responder only supports pre-produced responses and can't handle a request containing a nonce, it SHOULD return a response that does not include a nonce.
Clients SHOULD attempt to process a response even if it doesn't include a nonce. See Section 4 for details on validating responses that don't contain a nonce, and see also Section 7 for the relevant security considerations 🔒
Responders that can't respond to OCSP requests containing an unsupported option, such as a nonce, MAY forward the request to an OCSP responder that is capable of doing so 🦋
The responder MAY include the singleResponse.singleResponse extensions structure.
2.2.2. Signed OCSPResponses
Clients MUST validate the signature on the returned OCSPResponse. No skipping this part, periodt 💅
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 [OCSP], to tell the client it doesn't need to check the certificate's status. It's also RECOMMENDED that neither an OCSP authorityInfoAccess (AIA) extension nor a cRLDistributionPoints (CRLDP) extension be included in the OCSP responder's certificate. So, the responder's signing certificate SHOULD be relatively short-lived and renewed regularly 🔄
Clients MUST be able to identify OCSP responder certificates using both the byName and byKey ResponseData.ResponderID choices. Responders SHOULD use byKey to further reduce the size of the response in scenarios where reducing bandwidth is an issue 🍓
2.2.3. OCSPResponseStatus Values ✨
okay so this one is about when a responder gets to say "successful" 💅 As long as the OCSP infrastructure has authoritative records for a certificate, the OCSPResponseStatus is going to be "successful". But if the responder can't reach authoritative records for that certificate, it MUST return "unauthorized" 🙈 This profile basically stretches the RFC 2560 [OCSP] definition of "unauthorized" to cover this:
The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively.
Some examples: responders with no access to authoritative records for a requested certificate, like the ones that pre-generate and distribute OCSP responses ahead of time, can't properly send back a signed "successful" but "unknown" response. So they respond with "unauthorized" 💀 Also, to keep the revocation database from growing forever, the responder MAY remove the status records of expired certificates. If a client asks about a certificate whose record was removed, the answer is "unauthorized" too 🧚
Security considerations for unsigned responses are covered in [OCSP], so go check there 🫶
2.2.4. thisUpdate, nextUpdate, and producedAt 🌸
When a responder is pre-producing OCSPResponse messages, it MUST set thisUpdate, nextUpdate, and producedAt like this:
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.
Responders MUST always include this value to aid in
response caching. See Section 6 for additional
information on caching.
producedAt The time at which the OCSP response was signed.Note: In many cases the value of thisUpdate and producedAt will be the same. 🍓
For this profile, ASN.1-encoded GeneralizedTime values like thisUpdate, nextUpdate, and producedAt MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds, even when the seconds are zero. So the format is YYYYMMDDHHMMSSZ. GeneralizedTime values MUST NOT include fractional seconds. Strict, but it keeps everyone on the same page 🕰️✨
3. Client Behavior 🎀
3.1. OCSP Responder Discovery 🔍
Clients MUST support the authorityInfoAccess extension as defined in [PKIX], and they MUST recognize the id-ad-ocsp access method. This is how CAs tell clients where to reach the OCSP service. It's giving "here's the address, babe" 💖
Now, if a client is checking a certificate that has both an authorityInformationAccess (AIA) extension pointing to an OCSP responder and a cRLDistributionPoints extension pointing to a CRL, the client SHOULD try the OCSP responder first 👑 Clients MAY go for the CRL if no OCSPResponse comes back from the responder after a locally configured timeout and number of retries. Fallback energy, honestly iconic 🦋
3.2. Sending an OCSP Request 📨
To avoid pointless network traffic, applications MUST verify the signature of signed data before asking an OCSP client to check the status of the certificates used to verify that data. If the signature is invalid, or the application can't verify it, an OCSP check MUST NOT be requested. Don't waste the bandwidth, bestie 😭
Same deal for certificates in a chain: an application MUST validate the signature on each certificate before asking an OCSP client to check its status. If the certificate signature is invalid or can't be verified, an OCSP check MUST NOT be requested. And clients SHOULD NOT make a request to check the status of expired certificates. No thoughts, only vibes that are expired 💀
4. Ensuring an OCSPResponse Is Fresh ⏰
Okay this part is the main character moment ✨ The goal is that a client never accepts an out-of-date response saying 'good' when there's a newer response saying 'revoked' out there. That would be so not it 😤 So clients need to make sure the responses they get are fresh.
There are two main ways to check freshness. The first uses nonces, and the second is based on time. For time-based checks to work, both clients and responders MUST have access to an accurate source of time 🕰️
Here's the twist: this profile says clients SHOULD NOT include a requestExtensions structure in OCSPRequests (see Section 2.1). Because of that, clients MUST be able to determine OCSPResponse freshness based on an accurate source of time. 🫶 If a client does put a nonce in the request, it SHOULD NOT reject the matching OCSPResponse just because the expected nonce doesn't show up. Instead it MUST fall back to validating the OCSPResponse based on time. Plot twist, but make it make sense 🍓
Clients that don't include a nonce in the request MUST ignore any nonce that might be in the response. Don't read what you didn't ask for, periodt 🙈
Clients MUST check for the nextUpdate field, and they MUST make sure the current time, expressed in GMT as described in Section 2.2.4, falls between the thisUpdate and nextUpdate times. If nextUpdate is absent, the client MUST reject the response. No nextUpdate, no entry 🚫
If nextUpdate is present, the client MUST make sure it isn't earlier than the current time. If the client's current time is later than the nextUpdate time, the client MUST reject the response as stale. Stale is not it 💅 Clients MAY let people configure a small tolerance period for accepting responses after nextUpdate, to handle minor clock differences between the client and responders and caches. That tolerance should be picked based on how accurate and precise the time synchronization tech in the calling application environment is. For example, internet peers with low-latency connections usually expect NTP to keep them accurate within parts of a second. Higher-latency environments, or places where an NTP equivalent isn't available, may need to be more generous with their tolerance 🌈
For more on replay and man-in-the-middle attacks, see the security considerations in Section 7 🔐
5. Transport Profile 🚀
The OCSP responder MUST support requests and responses over HTTP. When a client sends a request that is less than or equal to 255 bytes in total (after encoding), counting the scheme and delimiters (http://), the server name, and the base64-encoded OCSPRequest structure, the client MUST use the GET method. That's how OCSP responses get cached 🧠 Requests larger than 255 bytes SHOULD use the POST method. In every case, clients MUST follow the descriptions in A.1.1 of [OCSP] when constructing these messages. Follow the rules, babe 📜
When building a GET message, OCSP clients MUST base64 encode the OCSPRequest structure and append it to the URI in the AIA extension [PKIX]. Clients MUST NOT include CR or LF characters in the base64-encoded string. And clients MUST properly URL-encode the base64-encoded OCSPRequest. Here's an example:
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg
%3D%3DFor properly formatted OCSPRequests that are cachable (meaning the responses contain a nextUpdate value), the responder will send back the binary DER encoding of the OCSPResponse, preceded by these HTTP [HTTP] headers:
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>See Section 6.2 for the details on how these headers get used 🎀
6. Caching Recommendations 💜
Caching OCSP responses throughout the network is a big deal for high-volume OCSP deployments 📈 This section covers the recommended caching behavior for OCSP clients and HTTP proxies, plus the steps you should take to cut down on how often OCSP clients "hit the wire" 🦋 It also talks about putting OCSP responses inside protocol exchanges (aka stapling or piggybacking), like what TLS defines.
6.1. Caching at the Client 🌷
To keep bandwidth usage low, clients MUST cache authoritative OCSP responses locally. That means a response whose signature has been successfully validated and which has an OCSPResponseStatus of 'successful' 💖
Most OCSP clients will send OCSPRequests at or near the nextUpdate time, which is when their cached response expires. To avoid big spikes in responder load when lots of clients refresh a cached response for a popular certificate all at once, responders MAY use the cache-control:max-age directive to tell clients when to fetch a fresh OCSP response. Clients SHOULD fetch the updated OCSP response on or after the max-age time. And so that clients actually get an updated response, OCSP responders MUST refresh the OCSP response before the max-age time ⏳✨
6.2. HTTP Proxies 🌸
Okay bestie, so the responder SHOULD set the HTTP headers on the OCSP response so that intermediate HTTP proxy servers can be used smartly 🧠✨. The full definitions of these headers, plus the correct format for any date and time values, live in [HTTP].
HTTP Header Description
=========== ====================================================
date The date and time at which the OCSP server 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. This profile RECOMMENDS that the
ETag value be the ASCII HEX representation of the
SHA1 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.The cache-control header is where the juicy caching directives live 💅. The table above spells them out, so here's the same goodness as a quick list:
max-age=<n>🕰️:nis a time value that's later than thisUpdate but earlier than nextUpdate.public🌍: makes a normally uncachable response cachable by both shared and nonshared caches.no-transform🙅♀️: a proxy cache can't change the type, length, or encoding of the object content.must-revalidate🔁: stops caches from intentionally returning stale responses.
OCSP responders MUST NOT include a Pragma: no-cache, Cache-Control: no-cache, or Cache-Control: no-store header in authoritative OCSP responses. Not me doing that to the authoritative ones 🙅♀️💀.
OCSP responders SHOULD include one or more of these headers in non-authoritative OCSP responses. Those are the ones where the vibe is more flexible 🫶.
Let's do an example! 🎀 Say an OCSP response has these timestamp values:
thisUpdate = May 1, 2005 01:00:00 GMT
nextUpdate = May 3, 2005 01:00:00 GMT
productedAt = May 1, 2005 01:00:00 GMTand an OCSP client requests the response on May 2, 2005 01:00:00 GMT. In that scenario, the HTTP response could look like this 👇:
content-type: application/ocsp-response
content-length: 1000
date: Fri, 02 May 2005 01:00:00 GMT
last-modified: Thu, 01 May 2005 01:00:00 GMT
ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713"
expires: Sat, 03 May 2005 01:00:00 GMT
cache-control: max-age=86000,public,no-transform,must-revalidate
<...>Now the client side 🧚. OCSP clients MUST NOT include a no-cache header in OCSP request messages, unless the client runs into an expired response, which might happen because 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 in the request (i.e., Pragma: no-cache or Cache-Control: no-cache). Proxy drama, but make it make sense 💅.
6.3. Caching at Servers 🍓
Sometimes it's a total glow-up to include OCSP response information inside the protocol that's already running between the client and the server ✨. Doing this has a few attractive effects, babe:
First, it lets OCSP responses get cached on the server, which means fewer hits to the OCSP responder 📉.
Second, it enables certificate validation when the client isn't connected to a network, so the client doesn't have to set up a brand new HTTP session with the responder 🙌.
Third, it cuts down on the number of round trips the client has to make to finish a handshake 🏃♀️💨.
Fourth, it makes the client-side OCSP implementation simpler, because the client only needs the ability to parse and recognize OCSP responses 🧠💖.
This functionality is specified as an extension to the TLS [TLS] protocol in Section 3.6 [TLSEXT], but it can be applied to any client-server protocol 🦋.
This profile RECOMMENDS that both TLS clients and servers implement the certificate status request extension mechanism for TLS 🔐.
If you want more tea on caching issues, check out RFC 3143 [RFC3143] ☕.
7. Security Considerations 🔐💀
Okay, this section is serious, so buckle up 😤. The following considerations apply in addition to the security considerations addressed in Section 5 of [OCSP].
7.1. Replay Attacks 🚨
Because the use of nonces in this profile is optional, there's a possibility that 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 sufficiently fresh ⏰.
Clients without an accurate source of date and time are open to service disruption 📉. For example, a client with a sufficiently fast clock may reject a fresh OCSP response. Similarly, a client with a sufficiently slow clock may incorrectly accept expired valid responses for certificates that may actually be revoked 🫠.
Future versions of the OCSP protocol may provide a way for the client to know whether the server supports nonces or does not support nonces. If a client can determine that the server supports nonces, it MUST reject a reply that does not contain an expected nonce. Otherwise, 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 🕰️🔄.
7.2. Man-in-the-Middle Attacks 🕵️♀️
To mitigate the risk of this class of attack, the client must properly validate the signature on the response 🔏.
The use of signed responses in OCSP serves to authenticate the identity of the OCSP responder and to verify that it is authorized to sign responses on the CA's behalf 🪪.
Clients MUST ensure that they are communicating with an authorized responder by the rules described in [OCSP], Section 4.2.2.2. No talking to random impostors, bestie 🙅♀️.
7.3. Impersonation Attacks 🎭
The use of signed responses in OCSP serves to authenticate the identity of the OCSP responder.
As detailed in [OCSP], clients must properly validate the signature of the OCSP response and the signature on the OCSP response signer certificate to ensure an authorized responder created it 🔍.
7.4. Denial-of-Service Attacks 🌊
OCSP responders should take measures to prevent or mitigate denial-of-service attacks 🛡️. Because this profile specifies the use of unsigned OCSPRequests, access to the responder may be implicitly given to everyone who can send a request to a responder. That means the ability to mount a denial-of-service attack via a flood of requests may be greater 😬. For example, a responder could limit the rate of incoming requests from a particular IP address if questionable behavior is detected 🚦.
7.5. Modification of HTTP Headers 📝
Values included in HTTP headers, as described in Sections 5 and 6, are not cryptographically protected, so they can be manipulated by an attacker 👀. Clients SHOULD use these values for caching guidance only, and ultimately SHOULD rely only on the values present in the signed OCSPResponse. Clients SHOULD NOT rely on cached responses beyond the nextUpdate time ⏳. Trust the signature, not the sticky note 💅.
7.6. Request Authentication and Authorization 🔑
The suggested use of unsigned requests in this environment removes an option that would let the responder determine the authenticity of incoming requests. Thus, access to the responder may be implicitly given to everyone who can send a request to a responder 🫣. Environments where explicit authorization to access the OCSP responder is necessary can use other mechanisms to authenticate requestors or to restrict or meter service 🎟️.
8. Acknowledgements 🫶
The authors 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 this specification. Iconic contributors, all of them 👑.
9. References 📚
9.1. Normative References
[HTTP] 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[OCSP] 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.
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security Protocol Version 1.1", RFC 4346, April 2006.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
9.2. Informative References
[OCSPMP] "OCSP Mobile Profile V1.0", Open Mobile Alliance, www.openmobilealliance.org.
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", RFC 3143, June 2001.
Appendix A. Example OCSP Messages 🧩
A.1. OCSP Request 🎀
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
}
}
}
}A.2. OCSP Response 💌
okay so this is the OCSP response, the answer that comes back once the server has checked on the certificate 👀 it's all nested SEQUENCEs and it's giving very layered energy, but every single byte matters 🫶
SEQUENCE {
ENUMERATED 0
[0] {
SEQUENCE {
OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)
OCTET STRING, encapsulates {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 0
}
[1] {
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
}
GeneralizedTime 07/11/2005 23:52:44 GMT
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
[0]
Error: Object has zero length.
GeneralizedTime 07/11/2005 23:52:44 GMT
[0] {
GeneralizedTime 14/11/2005 23:52:44 GMT
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING
0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2
F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98
8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7
3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84
EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1
42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A
A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC
BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30
[0] {
SEQUENCE {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 2
}
INTEGER
49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example CA'
}
}
}
SEQUENCE {
UTCTime 08/10/2005 00:00:00 GMT
UTCTime 06/01/2006 23:59:59 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING, encapsulates {
SEQUENCE {
INTEGER
00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D
D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A
00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F
81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C
A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5
0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41
04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E
D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2
[ Another 1 bytes skipped ]
INTEGER 65537
}
}
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
basicConstraints (2 5 29 19)
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates {
SEQUENCE {
OBJECT IDENTIFIER
ocspSigning (1 3 6 1 5 5 7 3 9)
}
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
OCTET STRING, encapsulates {
BIT STRING 7 unused bits
'1'B (bit 0)
}
}
SEQUENCE {
OBJECT IDENTIFIER
ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
OCTET STRING, encapsulates {
NULL
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING
3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE
1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73
C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB
80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29
14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5
8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B
9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4
3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A
}
}
}
}
}
}
}
}Authors' Addresses ✍️
The brains behind this one, and where to find them 🧚
Alex Deacon
VeriSign, Inc.
487 E. Middlefield Road
Mountain View, CA 94043
USA
Phone: 1-650-426-3478
EMail: alex@verisign.com
Ryan Hurst
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Phone: 1-425-707-8979
EMail: rmh@microsoft.comFull Copyright Statement 🎀
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set out there, the authors keep all of their rights 💜
This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🦋
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether any license under those rights might or might not be available, and it hasn't independently tried to find any such rights 🙈 Info on how rights work for RFC documents is in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 💅
📦 where this page comes from
- ietf: rfc5019 2007-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms