rfc9919v1.txt		rfc9919.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Internet Engineering Task Force (IETF) 伊藤 忠彦 (T. Ito)		Internet Engineering Task Force (IETF) 伊藤 忠彦 (T. Ito)
	Request for Comments: 9919 SECOM CO., LTD.		Request for Comments: 9919 SECOM CO., LTD.
	Obsoletes: 5019 C. Wilson		Obsoletes: 5019 C. Wilson
	Category: Standards Track Apple, Inc.		Category: Standards Track Apple, Inc.
	ISSN: 2070-1721 C. Bonnell		ISSN: 2070-1721 C. Bonnell
	DigiCert, Inc.		DigiCert, Inc.
	S. Turner		S. Turner
	sn3rd		sn3rd
	January 2026		January 2026
	Updates to the Lightweight Online Certificate Status Protocol (OCSP)		The Lightweight Online Certificate Status Protocol (OCSP) Profile for
	Profile for High Volume Environments		High-Volume Environments
	Abstract		Abstract
	This specification defines a profile of the Online Certificate Status		This specification defines a profile of the Online Certificate Status
	Protocol (OCSP) that addresses the scalability issues inherent when		Protocol (OCSP) that addresses the scalability issues inherent when
	using OCSP in large scale (high volume) Public Key Infrastructure		using OCSP in large scale (high volume) Public Key Infrastructure
	(PKI) environments and/or in PKI environments that require a		(PKI) environments and/or in PKI environments that require a
	lightweight solution to minimize communication bandwidth and client-		lightweight solution to minimize communication bandwidth and client-
	side processing.		side processing.
	skipping to change at line 93 ¶		skipping to change at line 93 ¶
	8.4. Denial-of-Service Attacks		8.4. Denial-of-Service Attacks
	8.5. Modification of HTTP Header Fields		8.5. Modification of HTTP Header Fields
	8.6. Request Authentication and Authorization		8.6. Request Authentication and Authorization
	8.7. Use of SHA-1 for the Calculation of CertID Field Values		8.7. Use of SHA-1 for the Calculation of CertID Field Values
	9. IANA Considerations		9. IANA Considerations
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	10.2. Informative References		10.2. Informative References
	Appendix A. Differences from RFC 5019		Appendix A. Differences from RFC 5019
	Appendix B. Examples		Appendix B. Examples
	B.1. Root Certification Authority Certificate		B.1. Root CA Certificate
	B.2. End-Entity Certificate		B.2. End-Entity Certificate
	B.3. OCSP Responder Certificate		B.3. OCSP Responder Certificate
	B.4. OCSP Request		B.4. OCSP Request
	B.5. OCSP Response		B.5. OCSP Response
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	The Online Certificate Status Protocol [RFC6960] specifies a		The Online Certificate Status Protocol [RFC6960] specifies a
	skipping to change at line 340 ¶		skipping to change at line 340 ¶
	Clients MUST validate the signature on the OCSPResponse.		Clients MUST validate the signature on the OCSPResponse.
	If the response is signed by a delegate of the issuing certification		If the response is signed by a delegate of the issuing certification
	authority (CA), a valid responder certificate MUST be referenced in		authority (CA), a valid responder certificate MUST be referenced in
	the BasicOCSPResponse.certs structure.		the BasicOCSPResponse.certs structure.
	It is RECOMMENDED that the OCSP responder's certificate contain the		It is RECOMMENDED that the OCSP responder's certificate contain the
	id-pkix-ocsp-nocheck extension, as defined in [RFC6960], to indicate		id-pkix-ocsp-nocheck extension, as defined in [RFC6960], to indicate
	to the client that it need not check the certificate's status. In		to the client that it need not check the certificate's status. In
	addition, it is RECOMMENDED that neither an OCSP authorityInfoAccess		addition, it is RECOMMENDED that neither an OCSP Authority
	(AIA) extension nor cRLDistributionPoints (CRLDP) extension be		Information Access (AIA) extension nor CRL Distribution Points
	included in the OCSP responder's certificate. Accordingly, the		(CRLDP) extension be included in the OCSP responder's certificate.
	responder's signing certificate SHOULD be relatively short-lived and		Accordingly, the responder's signing certificate SHOULD be relatively
	renewed regularly.		short-lived and renewed regularly.
	Clients MUST be able to identify OCSP responder certificates using		Clients MUST be able to identify OCSP responder certificates using
	the byKey field and SHOULD be able to identify OCSP responder		the byKey field and SHOULD be able to identify OCSP responder
	certificates using the byName field of the ResponseData.ResponderID		certificates using the byName field of the ResponseData.ResponderID
	[RFC6960] choices.		[RFC6960] choices.
	Older responders that provide backward compatibility with [RFC5019]		Older responders that provide backward compatibility with the
	MAY use the byName field to represent the ResponderID but should		protocol defined in [RFC5019] MAY use the byName field to represent
	transition to using the byKey field as soon as practical.		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		Newer responders that conform to this profile MUST use the byKey
	field to represent the ResponderID to reduce the size of the		field to represent the ResponderID to reduce the size of the
	response.		response.
	3.2.3. OCSPResponseStatus Values		3.2.3. OCSPResponseStatus Values
	As long as the OCSP infrastructure has authoritative records for a		As long as the OCSP infrastructure has authoritative records for a
	particular certificate, an OCSPResponseStatus of "successful" will be		particular certificate, an OCSPResponseStatus of "successful" will be
	returned. When access to authoritative records for a particular		returned. When access to authoritative records for a particular
	skipping to change at line 417 ¶		skipping to change at line 418 ¶
	For the purposes of this profile, ASN.1-encoded GeneralizedTime		For the purposes of this profile, ASN.1-encoded GeneralizedTime
	values, such as thisUpdate, nextUpdate, and producedAt, MUST be		values, such as thisUpdate, nextUpdate, and producedAt, MUST be
	expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,		expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
	times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.		times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
	GeneralizedTime values MUST NOT include fractional seconds.		GeneralizedTime values MUST NOT include fractional seconds.
	4. Client Behavior		4. Client Behavior
	4.1. OCSP Responder Discovery		4.1. OCSP Responder Discovery
	Clients MUST support the authorityInfoAccess extension as defined in		Clients MUST support the AIA extension as defined in [RFC5280] and
	[RFC5280] and MUST recognize the id-ad-ocsp access method. This		MUST recognize the id-ad-ocsp access method. This enables CAs to
	enables CAs to inform clients how they can contact the OCSP service.		inform clients how they can contact the OCSP service.
	In the case where a client is checking the status of a certificate		In the case where a client is checking the status of a certificate
	that contains both an authorityInformationAccess (AIA) extension		that contains both an AIA extension pointing to an OCSP responder and
	pointing to an OCSP responder and a cRLDistributionPoints extension		a CRLDP extension pointing to a CRL, the client SHOULD attempt to
	pointing to a CRL, the client SHOULD attempt to contact the OCSP		contact the OCSP responder first. Clients MAY attempt to retrieve
	responder first. Clients MAY attempt to retrieve the CRL if no		the CRL if no OCSPResponse is received from the responder after a
	OCSPResponse is received from the responder after a locally		locally configured timeout and number of retries.
	configured timeout and number of retries.
	4.2. Sending an OCSP Request		4.2. Sending an OCSP Request
	To avoid needless network traffic, applications MUST verify the		To avoid needless network traffic, applications MUST verify the
	signature of signed data before asking an OCSP client to check 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		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		invalid or the application is not able to verify it, an OCSP check
	MUST NOT be requested.		MUST NOT be requested.
	Similarly, an application MUST validate the signature on certificates		Similarly, an application MUST validate the signature on certificates
	skipping to change at line 488 ¶		skipping to change at line 488 ¶
	and caches. This tolerance period should be chosen based on the		and caches. This tolerance period should be chosen based on the
	accuracy and precision of time synchronization technology available		accuracy and precision of time synchronization technology available
	to the calling application environment. For example, Internet peers		to the calling application environment. For example, Internet peers
	with low latency connections typically expect NTP time		with low latency connections typically expect NTP time
	synchronization to keep them accurate within parts of a second;		synchronization to keep them accurate within parts of a second;
	higher latency environments or where an NTP analogue is not available		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		may have to be more liberal in their tolerance (e.g., allow one day
	difference).		difference).
	See the security considerations in Section 8 for additional details		See the security considerations in Section 8 for additional details
	on replay and man-in-the-middle attacks.		on replay and on-path attacks.
	6. Transport Profile		6. Transport Profile
	OCSP clients can send HTTP-based OCSP requests using either the GET		OCSP clients can send HTTP-based OCSP requests using either the GET
	or POST method. The OCSP responder MUST support requests and		or POST method. The OCSP responder MUST support requests and
	responses over HTTP. When sending requests that are less than or		responses over HTTP. When sending requests that are less than or
	equal to 255 bytes in total (after encoding) including the scheme and		equal to 255 bytes in total (after encoding), including the scheme
	delimiters (http://), server name and base64-encoded OCSPRequest		and delimiters (http://), server name, and base64-encoded OCSPRequest
	structure, clients MUST use the GET method (to enable OCSP response		structure, clients MUST use the GET method (to enable OCSP response
	caching). OCSP requests larger than 255 bytes SHOULD be submitted		caching). OCSP requests larger than 255 bytes SHOULD be submitted
	using the POST method. In all cases, clients MUST follow the		using the POST method. In all cases, clients MUST follow the
	descriptions in Appendix A.1 of [RFC6960] when constructing these		descriptions in Appendix A.1 of [RFC6960] when constructing these
	messages.		messages.
	When constructing a GET message, OCSP clients MUST base64-encode the		When constructing a GET message, OCSP clients MUST base64-encode the
	OCSPRequest structure according to Section 4 of [RFC4648]. Clients		OCSPRequest structure according to Section 4 of [RFC4648]. Clients
	MUST NOT include whitespace or any other characters that are not part		MUST NOT include whitespace or any other characters that are not part
	of the base64 character repertoire in the base64-encoded string.		of the base64 character repertoire in the base64-encoded string.
	skipping to change at line 619 ¶		skipping to change at line 619 ¶
	in authoritative OCSP responses.		in authoritative OCSP responses.
	OCSP responders SHOULD include one or more of these HTTP header		OCSP responders SHOULD include one or more of these HTTP header
	fields in non-authoritative OCSP responses.		fields in non-authoritative OCSP responses.
	For example, assume that an OCSP response has the following timestamp		For example, assume that an OCSP response has the following timestamp
	values:		values:
	thisUpdate = March 19, 2023 01:00:00 GMT		thisUpdate = March 19, 2023 01:00:00 GMT
	nextUpdate = March 21, 2023 01:00:00 GMT		nextUpdate = March 21, 2023 01:00:00 GMT
	productedAt = March 19, 2023 01:00:00 GMT		producedAt = March 19, 2023 01:00:00 GMT
	and that an OCSP client requests the response on March 20, 2023		and that an OCSP client requests the response on March 20, 2023
	01:00:00 GMT. In this scenario, the HTTP response may look like		01:00:00 GMT. In this scenario, the HTTP response may look like
	this:		this:
	Content-Type: application/ocsp-response		Content-Type: application/ocsp-response
	Content-Length: 1000		Content-Length: 1000
	Date: Mon, 20 Mar 2023 01:00:00 GMT		Date: Mon, 20 Mar 2023 01:00:00 GMT
	Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT		Last-Modified: Sun, 19 Mar 2023 01:00:00 GMT
	ETag: "97df3588b5a3f24babc3851b372f0ba7		ETag: "97df3588b5a3f24babc3851b372f0ba7
	skipping to change at line 665 ¶		skipping to change at line 665 ¶
	to establish a new HTTP session with the OCSP responder.		to establish a new HTTP session with the OCSP responder.
	Third, it reduces the number of round trips the client needs to make		Third, it reduces the number of round trips the client needs to make
	in order to complete a handshake.		in order to complete a handshake.
	Fourth, it simplifies the client-side OCSP implementation by enabling		Fourth, it simplifies the client-side OCSP implementation by enabling
	a situation where the client need only the ability to parse and		a situation where the client need only the ability to parse and
	recognize OCSP responses.		recognize OCSP responses.
	This functionality has been specified as an extension to the TLS		This functionality has been specified as an extension to the TLS
	protocol [RFC9846] in Section 4.4.2 of [RFC9846] but can be applied		protocol in Section 4.4.2 of [RFC9846] but can be applied to any
	to any client-server protocol.		client-server protocol.
	It is RECOMMENDED by this profile that both TLS clients and servers		It is RECOMMENDED by this profile that both TLS clients and servers
	implement the certificate status request extension mechanism for TLS.		implement the certificate status request extension mechanism for TLS.
	Further information regarding caching issues can be obtained from		Further information regarding caching issues can be obtained from
	[RFC3143].		[RFC3143].
	8. Security Considerations		8. Security Considerations
	The following considerations apply in addition to the security		The following considerations apply in addition to the security
	skipping to change at line 695 ¶		skipping to change at line 695 ¶
	order to mitigate this attack, clients MUST have access to an		order to mitigate this attack, clients MUST have access to an
	accurate source of time and ensure that the OCSP responses they		accurate source of time and ensure that the OCSP responses they
	receive are sufficiently fresh.		receive are sufficiently fresh.
	Clients that do not have an accurate source of date and time are		Clients that do not have an accurate source of date and time are
	vulnerable to service disruption. For example, a client with a		vulnerable to service disruption. For example, a client with a
	sufficiently fast clock may reject a fresh OCSP response. Similarly,		sufficiently fast clock may reject a fresh OCSP response. Similarly,
	a client with a sufficiently slow clock may incorrectly accept		a client with a sufficiently slow clock may incorrectly accept
	expired valid responses for certificates that may in fact be revoked.		expired valid responses for certificates that may in fact be revoked.
	Future versions of the OCSP protocol may provide a way for the client		Future versions of OCSP may provide a way for the client to know
	to know whether the responder supports nonces or does not support		whether the responder supports nonces or does not support nonces. If
	nonces. If a client can determine that the responder supports		a client can determine that the responder supports nonces, it MUST
	nonces, it MUST reject a reply that does not contain an expected		reject a reply that does not contain an expected nonce. Otherwise,
	nonce. Otherwise, clients that opt to include a nonce in the request		clients that opt to include a nonce in the request SHOULD NOT reject
	SHOULD NOT reject a corresponding OCSPResponse solely on the basis of		a corresponding OCSPResponse solely on the basis of the nonexistent
	the nonexistent expected nonce but MUST fall back to validating the		expected nonce but MUST fall back to validating the OCSPResponse
	OCSPResponse based on time.		based on time.
	8.2. Man-in-the-Middle Attacks		8.2. Man-in-the-Middle Attacks
	To mitigate risk associated with this class of attack, the client		To mitigate risk associated with this class of attack, the client
	MUST properly validate the signature on the response.		MUST properly validate the signature on the response.
	The use of signed responses in OCSP serves to authenticate the		The use of signed responses in OCSP serves to authenticate the
	identity of the OCSP responder and to verify that it is authorized to		identity of the OCSP responder and to verify that it is authorized to
	sign responses on the CA's behalf.		sign responses on the CA's behalf.
	skipping to change at line 830 ¶		skipping to change at line 830 ¶
	Ed., "HTTP Caching", STD 98, RFC 9111,		Ed., "HTTP Caching", STD 98, RFC 9111,
	DOI 10.17487/RFC9111, June 2022,		DOI 10.17487/RFC9111, June 2022,
	<https://www.rfc-editor.org/info/rfc9111>.		<https://www.rfc-editor.org/info/rfc9111>.
	[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 9846, DOI 10.17487/RFC9846, January		Version 1.3", RFC 9846, DOI 10.17487/RFC9846, January
	2026, <https://www.rfc-editor.org/info/rfc9846>.		2026, <https://www.rfc-editor.org/info/rfc9846>.
	10.2. Informative References		10.2. Informative References
	[OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0",		[OCSPMP] Open Mobile Alliance, "Online Certificate Status Protocol
	<https://www.openmobilealliance.org>.		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		[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching
	Problems", RFC 3143, DOI 10.17487/RFC3143, June 2001,		Problems", RFC 3143, DOI 10.17487/RFC3143, June 2001,
	<https://www.rfc-editor.org/info/rfc3143>.		<https://www.rfc-editor.org/info/rfc3143>.
	[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1		[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
	(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,		(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
	<https://www.rfc-editor.org/info/rfc3174>.		<https://www.rfc-editor.org/info/rfc3174>.
	[RFC9500] Gutmann, P. and C. Bonnell, "Standard Public Key		[RFC9500] Gutmann, P. and C. Bonnell, "Standard Public Key
	skipping to change at line 875 ¶		skipping to change at line 877 ¶
	* Section 3.2.2 requires new OCSP responders to use the byKey field		* Section 3.2.2 requires new OCSP responders to use the byKey field
	and support migration from byName fields.		and support migration from byName fields.
	* Section 6 clarifies that OCSP clients MUST NOT include whitespace		* Section 6 clarifies that OCSP clients MUST NOT include whitespace
	or any other characters that are not part of the base64 character		or any other characters that are not part of the base64 character
	repertoire in the base64-encoded string.		repertoire in the base64-encoded string.
	Appendix B. Examples		Appendix B. Examples
	B.1. Root Certification Authority Certificate		B.1. Root CA Certificate
	This is a self-signed certificate for the certification authority		This is a self-signed certificate for the CA that issued the end-
	that issued the end-entity certificate and OCSP-delegated responder		entity certificate and OCSP-delegated responder example certificates
	example certificates below.		below.
	The key pair for the certification authority is the "testECCP521" key		The key pair for the CA is the "testECCP521" key from Section 2.3 of
	from Section 2.3 of [RFC9500].		[RFC9500].
	-----BEGIN CERTIFICATE-----		-----BEGIN CERTIFICATE-----
	MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG		MIICKDCCAYqgAwIBAgIBATAKBggqhkjOPQQDBDA4MQswCQYDVQQGEwJYWDEUMBIG
	A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy		A1UECgwLQ2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwHhcNMjQwNDAy
	MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL		MTIzNzQ3WhcNMjUwNDAyMTIzNzQ3WjA4MQswCQYDVQQGEwJYWDEUMBIGA1UECgwL
	Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF		Q2VydHMgJ3IgVXMxEzARBgNVBAMMCklzc3VpbmcgQ0EwgZswEAYHKoZIzj0CAQYF
	K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3		K4EEACMDgYYABAHQ/XJXqEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3
	+i2iYNjrYtbS9dZJJ44yFzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7F		+i2iYNjrYtbS9dZJJ44yFzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7F
	quikKBc85W8A3psVfB5cgsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92KNC		quikKBc85W8A3psVfB5cgsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92KNC
	MEAwHQYDVR0OBBYEFI7CFAlgduqQOOk5rhttUsQXfZ++MA8GA1UdEwEB/wQFMAMB		MEAwHQYDVR0OBBYEFI7CFAlgduqQOOk5rhttUsQXfZ++MA8GA1UdEwEB/wQFMAMB
	skipping to change at line 1586 ¶		skipping to change at line 1588 ¶
	: }		: }
	: }		: }
	: }		: }
	: }		: }
	: }		: }
	Acknowledgments		Acknowledgments
	The authors of this version of the document wish to thank Alex Deacon		The authors of this version of the document wish to thank Alex Deacon
	and Ryan Hurst for their work to produce the original version of the		and Ryan Hurst for their work to produce the original version of the
	lightweight profile for the OCSP protocol.		lightweight profile for OCSP.
	The authors of this version of the document wish to thank Paul		The authors of this version of the document wish to thank Paul
	Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and Wendy Brown		Kyzivat, Russ Housley, Rob Stradling, Roman Danyliw, and Wendy Brown
	for their reviews, feedback, and suggestions.		for their reviews, feedback, and suggestions.
	The authors wish to thank Magnus Nystrom of RSA Security, Inc.,		The authors wish to thank Magnus Nystrom of RSA Security, Inc.,
	Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet,		Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet,
	Ltd. for their contributions to the original [RFC5019] specification.		Ltd. for their contributions to the original [RFC5019] specification.
	Listed organizational affiliations reflect the authors' affiliations		Listed organizational affiliations reflect the authors' affiliations
	at the time RFC 5019 was published.		at the time RFC 5019 was published.
End of changes. 16 change blocks.
	43 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48.