RFC 9654: Online Certificate Status Protocol (OCSP) Nonce Extension
- H. Sharma, Ed.
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 cryptographical
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.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
The Nonce extension was previously defined in Section 4.4.1 of [RFC6960].
The Nonce cryptographical
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
2. OCSP Extensions
The message formats for OCSP requests and responses are defined in [RFC6960] and the Nonce extension was updated in [RFC8954]. [RFC6960] also defines the standard extensions for OCSP messages based on the extension model employed in X.509 version 3 certificates (see [RFC5280]). [RFC8954] replaces Section 4.4.1 of [RFC6960] 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 extensions defined in [RFC6960].¶
2.1. Nonce Extension
The Nonce cryptographical
An OCSP requester that implements the extension in this document MUST use a minimum length of 32 octets for Nonce in the Nonce extension.¶
An OCSP responder that supports the Nonce extension MUST accept Nonce lengths of at least 16 octets and up to and including 32 octets. A responder MAY choose to respond without the Nonce extension for requests in which the length of the Nonce is in between 1 octet and 15 octets or 33 octets and 128 octets.¶
Responders that implement the extension in this document MUST reject any OCSP
request that has a Nonce with a length of either 0 octets or greater
than 128 octets, with the malformed
The value of the Nonce MUST be generated using a cryptographical
The following is an example of an encoded OCSP Nonce extension with a 32-octet Nonce in hexadecimal format.¶
Here is the decoded version of the above example. Offset, Length, and Object Identifier are in decimal.¶
3. Security Considerations
The security considerations of OCSP, in general, are described in [RFC6960]. 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 ensures that the response is the most recent response from the server and not an old copy.¶
3.1. 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 [RFC5019], 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.¶
4. IANA Considerations
For the ASN.1 modules in Appendixes A.1 and
A.2, IANA has assigned the following
object identifiers (OIDs) in the "SMI Security for PKIX
Module Identifier" registry
5. References
5.1. Normative References
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC4086]
-
Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10
.17487 , , <https:///RFC4086 www >..rfc -editor .org /info /rfc4086 - [RFC5019]
-
Deacon, A. and R. Hurst, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", RFC 5019, DOI 10
.17487 , , <https:///RFC5019 www >..rfc -editor .org /info /rfc5019 - [RFC5280]
-
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10
.17487 , , <https:///RFC5280 www >..rfc -editor .org /info /rfc5280 - [RFC6960]
-
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10
.17487 , , <https:///RFC6960 www >..rfc -editor .org /info /rfc6960 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8954]
-
Sahni, M., Ed., "Online Certificate Status Protocol (OCSP) Nonce Extension", RFC 8954, DOI 10
.17487 , , <https:///RFC8954 www >..rfc -editor .org /info /rfc8954
5.2. Informative References
- [Err5891]
-
RFC Errata, Erratum ID 5891, RFC 6960, <https://
www >..rfc -editor .org /errata /eid5891 - [RFC5912]
-
Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10
.17487 , , <https:///RFC5912 www >..rfc -editor .org /info /rfc5912
Appendix A. ASN.1 Modules
This section includes the ASN.1 modules for OCSP and replaces the entirety of Section 5 of [RFC8954]. It addresses Errata ID 5891 [Err5891] 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 module in Appendix B.1 of [RFC6960].¶
Appendix A.2 includes an ASN.1 module, corresponding to the module present in Appendix A.1, that conforms to the 2008 version of ASN.1. This module replaces the modules in Section 4 of [RFC5912] and Appendix B.2 of [RFC6960]. Although a 2008 ASN.1 module is provided, the module in Appendix A.1 remains the normative module per the policy of the PKIX Working Group.¶
Acknowledgements
The authors of this document thank Mohit Sahni for his work to produce [RFC8954].¶
The authors also thank Russ Housley, Corey Bonnell, Michael StJohns, Tomas Gustavsson, and Carl Wallace for their feedback and suggestions.¶