rfc9919v2.txt		rfc9919.txt
	skipping to change at line 81 ¶		skipping to change at line 81 ¶
	4.1. OCSP Responder Discovery		4.1. OCSP Responder Discovery
	4.2. Sending an OCSP Request		4.2. Sending an OCSP Request
	5. Ensuring an OCSPResponse Is Fresh		5. Ensuring an OCSPResponse Is Fresh
	6. Transport Profile		6. Transport Profile
	7. Caching Recommendations		7. Caching Recommendations
	7.1. Caching at the Client		7.1. Caching at the Client
	7.2. HTTP Proxies		7.2. HTTP Proxies
	7.3. Caching at Servers		7.3. Caching at Servers
	8. Security Considerations		8. Security Considerations
	8.1. Replay Attacks		8.1. Replay Attacks
	8.2. Man-in-the-Middle Attacks		8.2. On-Path Attacks
	8.3. Impersonation Attacks		8.3. Impersonation Attacks
	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
	skipping to change at line 212 ¶		skipping to change at line 212 ¶
	reqCert CertID,		reqCert CertID,
	singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }		singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
	CertID ::= SEQUENCE {		CertID ::= SEQUENCE {
	hashAlgorithm AlgorithmIdentifier,		hashAlgorithm AlgorithmIdentifier,
	issuerNameHash OCTET STRING, -- Hash of issuer's DN		issuerNameHash OCTET STRING, -- Hash of issuer's DN
	issuerKeyHash OCTET STRING, -- Hash of issuer's public key		issuerKeyHash OCTET STRING, -- Hash of issuer's public key
	serialNumber CertificateSerialNumber }		serialNumber CertificateSerialNumber }
	OCSPRequests that conform to the profile in this document MUST		OCSPRequests that conform to the profile in this document MUST
	include only one Request in the OCSPRequest.RequestList structure.		include only one Request in the OCSPRequest.requestList structure.
	The CertID.issuerNameHash and CertID.issuerKeyHash fields contain		The CertID.issuerNameHash and CertID.issuerKeyHash fields contain
	hashes of the issuer's distinguished name (DN) and public key,		hashes of the issuer's distinguished name (DN) and public key,
	respectively. OCSP clients that conform with this profile MUST use		respectively. OCSP clients that conform with this profile MUST use
	SHA-256, as defined in Section 2.2 of [RFC5754], as the hashing		SHA-256, as defined in Section 2.2 of [RFC5754], as the hashing
	algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash		algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash
	values.		values.
	Older OCSP clients that provide backward compatibility with [RFC5019]		Older OCSP clients that provide backward compatibility with [RFC5019]
	use SHA-1, as defined in [RFC3174], as the hashing algorithm for the		use SHA-1, as defined in [RFC3174], as the hashing algorithm for the
	skipping to change at line 285 ¶		skipping to change at line 285 ¶
	responses SEQUENCE OF SingleResponse,		responses SEQUENCE OF SingleResponse,
	responseExtensions [1] EXPLICIT Extensions OPTIONAL }		responseExtensions [1] EXPLICIT Extensions OPTIONAL }
	SingleResponse ::= SEQUENCE {		SingleResponse ::= SEQUENCE {
	certID CertID,		certID CertID,
	certStatus CertStatus,		certStatus CertStatus,
	thisUpdate GeneralizedTime,		thisUpdate GeneralizedTime,
	nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,		nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
	singleExtensions [1] EXPLICIT Extensions OPTIONAL }		singleExtensions [1] EXPLICIT Extensions OPTIONAL }
	Responders MUST generate a BasicOCSPResponse as identified by the id-		Responders MUST generate a BasicOCSPResponse as identified by the
	pkix-ocsp-basic OID. Clients MUST be able to parse and accept a		id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a
	BasicOCSPResponse. OCSPResponses that conform to this profile SHOULD		BasicOCSPResponse. OCSPResponses that conform to this profile SHOULD
	include only one SingleResponse in the ResponseData.responses		include only one SingleResponse in the ResponseData.responses
	structure but MAY include additional SingleResponse elements if		structure but MAY include additional SingleResponse elements if
	necessary to improve response pre-generation performance or cache		necessary to improve response pre-generation performance or cache
	efficiency and to ensure backward compatibility. For instance, to		efficiency and to ensure backward compatibility. For instance, to
	provide support to OCSP clients that do not yet support the use of		provide support to OCSP clients that do not yet support the use of
	SHA-256 for CertID hash calculation, the OCSP responder MAY include		SHA-256 for CertID hash calculation, the OCSP responder MAY include
	two SingleResponses in a BasicOCSPResponse. In that		two SingleResponse elements in a BasicOCSPResponse. In that
	BasicOCSPResponse, the CertID of one of the SingleResponses uses		BasicOCSPResponse, the CertID of one of the SingleResponse structures
	SHA-1 for the hash calculation, and the CertID in the other		uses SHA-1 for the hash calculation, and the CertID in the other
	SingleResponse uses SHA-256. OCSP responders SHOULD NOT distribute		SingleResponse uses SHA-256. OCSP responders SHOULD NOT distribute
	OCSP responses that contain CertIDs that use SHA-1 if the OCSP		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		responder has no clients that require the use of SHA-1. Operators of
	OCSP responders may consider logging the hash algorithm used by OCSP		OCSP responders may consider logging the hash algorithm used by OCSP
	clients to inform their determination of when it is appropriate to		clients to inform their determination of when it is appropriate to
	obsolete the distribution of OCSP responses that employ SHA-1 for		obsolete the distribution of OCSP responses that employ SHA-1 for
	CertID field hashes. See Section 8.7 for more information on the		CertID field hashes. See Section 8.7 for more information on the
	security considerations for the continued use of SHA-1.		security considerations for the continued use of SHA-1.
	The responder SHOULD NOT include responseExtensions. As specified in		The responder SHOULD NOT include responseExtensions. As specified in
	skipping to change at line 326 ¶		skipping to change at line 326 ¶
	Clients SHOULD attempt to process a response even if the response		Clients SHOULD attempt to process a response even if the response
	does not include a nonce. See Section 5 for details on validating		does not include a nonce. See Section 5 for details on validating
	responses that do not contain a nonce. See also Section 8 for		responses that do not contain a nonce. See also Section 8 for
	relevant security considerations.		relevant security considerations.
	Responders that do not have the ability to respond to OCSP requests		Responders that do not have the ability to respond to OCSP requests
	that contain an unsupported option such as a nonce MAY forward the		that contain an unsupported option such as a nonce MAY forward the
	request to an OCSP responder capable of doing so.		request to an OCSP responder capable of doing so.
	The responder MAY include the singleResponse.singleResponse		The responder MAY include the SingleResponse.SingleExtensions
	extensions structure.		extensions structure.
	3.2.2. Signed OCSPResponses		3.2.2. Signed OCSPResponses
	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.
	skipping to change at line 366 ¶		skipping to change at line 366 ¶
	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
	certificate is not available, the responder MUST return an		certificate is not available, the responder MUST return an
	OCSPResponseStatus of "unauthorized". As such, this profile extends		OCSPResponseStatus of "unauthorized".
	the [RFC6960] definition of "unauthorized" as follows:
	The response "unauthorized" is returned in cases where the client is
	not authorized to make this query to this responder or the responder
	is not capable of responding authoritatively.
	For example, OCSP responders that do not have access to authoritative		For example, OCSP responders that do not have access to authoritative
	records for a requested certificate, such as those that generate and		records for a requested certificate, such as those that generate and
	distribute OCSP responses in advance and thus do not have the ability		distribute OCSP responses in advance and thus do not have the ability
	to properly respond with a signed "successful" yet "unknown"		to properly respond with a signed "successful" yet "unknown"
	response, will respond with an OCSPResponseStatus of "unauthorized".		response, will respond with an OCSPResponseStatus of "unauthorized".
	Also, in order to ensure the database of revocation information does		Also, in order to ensure the database of revocation information does
	not grow unbounded over time, the responder MAY remove the status		not grow unbounded over time, the responder MAY remove the status
	records of expired certificates. Requests from clients for		records of expired certificates. Requests from clients for
	certificates whose record has been removed will result in an		certificates whose record has been removed will result in an
	skipping to change at line 704 ¶		skipping to change at line 699 ¶
	Future versions of OCSP may provide a way for the client to know		Future versions of OCSP may provide a way for the client to know
	whether the responder supports nonces or does not support nonces. If		whether the responder supports nonces or does not support nonces. If
	a client can determine that the responder supports nonces, it MUST		a client can determine that the responder supports nonces, it MUST
	reject a reply that does not contain an expected nonce. Otherwise,		reject a reply that does not contain an expected nonce. Otherwise,
	clients that opt to include a nonce in the request SHOULD NOT reject		clients that opt to include a nonce in the request SHOULD NOT reject
	a corresponding OCSPResponse solely on the basis of the nonexistent		a corresponding OCSPResponse solely on the basis of the nonexistent
	expected nonce but MUST fall back to validating the OCSPResponse		expected nonce but MUST fall back to validating the OCSPResponse
	based on time.		based on time.
	8.2. Man-in-the-Middle Attacks		8.2. On-Path 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.
	Clients MUST ensure that they are communicating with an authorized		Clients MUST ensure that they are communicating with an authorized
	responder by the rules described in Section 4.2.2.2 of [RFC6960].		responder by the rules described in Section 4.2.2.2 of [RFC6960].
End of changes. 7 change blocks.
	15 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48.