OCSP
OCSP (Online Certificate Status Protocol)
Within this page
OCSP RFCs (13)
RFC 9919: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
Proposed Standard- T. Ito
- C. Wilson
- C. Bonnell
- S. Turner
- July 2026
- IETF publication
- Security Area
Abstract
This specification defines a profile of the Online Certificate Status
Protocol (OCSP) that addresses the scalability issues inherent when
using OCSP in large scale (high volume) Public Key Infrastructure
(PKI) environments and/or in PKI environments that require a
lightweight solution to minimize communication bandwidth and client-
side processing.
This specification obsoletes RFC 5019. The profile specified in RFC
5019 has been updated to allow and recommend the use of SHA-256 over
SHA-1.
Abstract
This specification defines a profile of the Online Certificate Status
Protocol (OCSP) that addresses the scalability issues inherent when
using OCSP in large scale (high volume) Public Key Infrastructure
(PKI) environments and/or in PKI environments that require a
lightweight solution to minimize communication bandwidth and client-
side processing.
This specification obsoletes RFC 5019. The profile specified in RFC
5019 has been updated to allow and recommend the use of SHA-256 over
SHA-1.
RFC 9654: Online Certificate Status Protocol (OCSP) Nonce Extension
Proposed Standard- H. Sharma
- August 2024
- IETF publication
- Security Area
Abstract
RFC 8954 imposed size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message.
Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document also modifies the "Nonce" section of RFC 6960 to clearly define and differentiate the encoding format and values for easier implementation and understanding. This document obsoletes RFC 8954, which includes updated ASN.1 modules for OCSP, and updates RFC 6960.
Abstract
RFC 8954 imposed size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message.
Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document also modifies the "Nonce" section of RFC 6960 to clearly define and differentiate the encoding format and values for easier implementation and understanding. This document obsoletes RFC 8954, which includes updated ASN.1 modules for OCSP, and updates RFC 6960.
RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension
Proposed Standard- M. Sahni
- November 2020
- IETF publication
- Security Area
Abstract
This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 6960.
Obsoleted by RFC 9654
Abstract
This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 6960.
RFC 8739: Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
Proposed Standard- Y. Sheffer
- D. Lopez
- O. Gonzalez de Dios
- A. Pastor Perales
- T. Fossati
- March 2020
- IETF publication
- Security Area
Abstract
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.
Abstract
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.
RFC 6961: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
Proposed Standard- Y. Pettersen
- June 2013
- IETF publication
- Security Area
Abstract
This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.
Abstract
This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.
RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Proposed Standard- S. Santesson
- M. Myers
- R. Ankney
- A. Malpani
- S. Galperin
- C. Adams
- June 2013
- IETF publication
- Security Area
Abstract
This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.
Abstract
This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.
RFC 6664: S/MIME Capabilities for Public Key Definitions
Informational- J. Schaad
- July 2012
- IETF publication
- Security Area
Abstract
This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. This document is not an Internet Standards Track specification; it is published for informational purposes.
Abstract
This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC 6277: Online Certificate Status Protocol Algorithm Agility
Proposed Standard- S. Santesson
- P. Hallam-Baker
- June 2011
- IETF publication
- Security Area
Abstract
The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]
Obsoleted by RFC 6960
Abstract
The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]
RFC 5940: Additional Cryptographic Message Syntax (CMS) Revocation Information Choices
Proposed Standard- S. Turner
- R. Housley
- August 2010
- IETF publication
Abstract
The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]
Abstract
The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]
RFC 5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
Proposed Standard- A. Deacon
- R. Hurst
- September 2007
- IETF publication
- Security Area
Abstract
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]
Obsoleted by RFC 9919
Abstract
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]
RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Proposed Standard- M. Myers
- H. Tschofenig
- February 2007
- IETF publication
Abstract
While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]
Abstract
While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]
RFC 4557: Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Proposed Standard- L. Zhu
- K. Jaganathan
- N. Williams
- June 2006
- IETF publication
- Security Area
Abstract
This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]
Abstract
This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]
RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Proposed Standard- M. Myers
- R. Ankney
- A. Malpani
- S. Galperin
- C. Adams
- June 1999
- IETF publication
- Security Area
Abstract
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]
Obsoleted by RFC 6960
Abstract
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]
Subscribe to OCSP
Get notified when:
- RFC changes to status, obsoleted by, updates, updated by, or subseries.
- New RFC added to this subject or below
- The subject was merged into another.