]> Netskope Inc

2445 Augustine Dr 3rd floor Santa Clara California 95054 USA himanshu@netskope.com www.netskope.com

General Internet Engineering Task Force Online Certificate Status Protocol (OCSP) Nonce Extension RFC 8954 imposed the size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used for checking 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 updates the maximum allowed length of Nonce to 128 octets. This document also modifies Nonce section to clearly define the encoding format and values distinctively for an easier implementation and understanding. This document obsoletes RFC 8954 and provides updated ASN.1 modules for OCSP, updates RFC 6960.

Introduction Nonce extension was previously defined in Section 4.4.1 of . The Nonce cryptographically binds an OCSP request and a response to prevent replay attacks. This extension was updated in . limits the maximum Nonce length to 32 octets. To support cryptographic algorithms that generate a Nonce that is longer than 32 octets, this document updates the maximum allowed size of the Nonce to 128 octets. In addition, this document recommends that the OCSP requester and responder use a Nonce with a minimum length of 32 octets.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

OCSP Extensions The message formats for OCSP requests and responses are defined in and Nonce extension was updated in . also defines the standard extensions for OCSP messages based on the extension model employed in X.509 version 3 certificates (see ). replaces this section to limit the minimum and maximum length for the Nonce value. This document extends the maximum allowed nonce length to 128 octets and does not change the specifications of any of the other standard extensions defined in .

Nonce Extension The Nonce cryptographically binds a request and a response to prevent replay attacks. The Nonce is included as one of the requestExtensions in requests; in responses, it would be included as one of the responseExtensions. In both the request and the response, the Nonce will be identified by the object identifier id-pkix-ocsp- nonce, while the extnValue is the encoded value of Nonce. If the Nonce extension is present, then the length of the Nonce MUST be at least 1 octet and can be up to 128 octets. [RFC8954] compliant implementations will be unable to process nonces generated per the new specification with sizes in excess of the limit of 32 octets that was specified in [RFC8954]. An OCSP requester that implements this document MUST use a minimum length of 32 octets for Nonce in the Nonce extension. An OCSP responder , supporting the Nonce extension, MUST accept Nonce lengths of at least 16 octets and up to and including 32 octets. Responder MAY choose to respond without the Nonce extension for requests where the length of the Nonce is in between 1 octet and 15 octets or 33 octets and 128 octets. Responders, that implements this document MUST reject any OCSP request that has a Nonce with a length of either 0 octets or more than 128 octets, with the malformedRequest OCSPResponseStatus as described in Section 4.2.1 of [RFC6960]. The value of the Nonce MUST be generated using a cryptographically strong pseudorandom number generator (see ). The minimum Nonce length of 1 octet is defined to provide backward compatibility with older OCSP requester that follow .

Security Considerations The security considerations of OCSP, in general, are described in . During the interval in which the previous OCSP response for a certificate is not expired but the responder has a changed status for that certificate, a copy of that OCSP response can be used to indicate that the status of the certificate is still valid. Including a requester's nonce value in the OCSP response makes sure that the response is the latest response from the server and not an old copy.

Replay Attack The Nonce extension is used to avoid replay attacks. Since the OCSP responder may choose not to send the Nonce extension in the OCSP response even if the requester has sent the Nonce extension in the request , an on-path attacker can intercept the OCSP request and respond with an earlier response from the server without the Nonce extension. This can be mitigated by configuring the server to use a short time interval between the thisUpdate and nextUpdate fields in the OCSP response.

IANA Considerations For the ASN.1 Module in Appendix A.1, IANA is requested to assign an object identifier (OID) for the module identifier to replace TBD1. The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0), and the Description for the new OID should be set to "id-mod-ocsp-2024-88". For the ASN.1 Module in Appendix A.2, IANA is requested to assign an object identifier (OID) for the module identifier to replace TBD2. The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0), and the Description for the new OID should be set to "id-mod-ocsp-2024-08".

Acknowledgements The authors of this document wish to thank Mohit Sahni for his work to produce . The authors wish to thank Russ Housley, Corey Bonnell, Michael StJohns and Carl Wallace for the feedback and suggestions.

References Normative References Informative References RFC Errata RFC 6960

This section includes the ASN.1 modules for OCSP and replaces the entirity of Section 5 of . It addresses Errata id 5891 as well. Appendix A.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1 for all syntax elements of OCSP. This module replaces the modules Appendix B.1 of . Appendix A.2 includes an ASN.1 module, corresponding to the module present in A.1, that conforms to the 2008 version of ASN.1. This module replaces the modules in Section 4 of and Appendix B.2 of . Although a 2008 ASN.1 module is provided, the module in Appendix A.1 remains the normative module as per the policy of the PKIX working group.