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://www.rfc-editor.org/info/rfc8954.¶

Copyright Notice

Copyright (c) 2020 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://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

This document updates the usage and format of the Nonce extension in OCSP request and response messages. This extension was previously defined in Section 4.4.1 of [RFC6960]. [RFC6960] does not mention any minimum or maximum length of the nonce in the Nonce extension. Lacking limits on the length of the nonce in the Nonce extension, OCSP responders that follow [RFC6960] may be vulnerable to various attacks, like Denial-of-Service attacks [RFC4732] or chosen-prefix attacks (to get a desired signature), and possible evasions using the Nonce extension data. This document specifies a lower limit of 1 and an upper limit of 32 for the length of the nonce in the Nonce extension. This document updates [RFC6960].¶

2. OCSP Extensions

The message formats for OCSP requests and responses are defined in [RFC6960]. [RFC6960] also defines the standard extensions for OCSP messages based on the extension model employed in X.509 version 3 certificates (see [RFC5280]). This document only specifies the new format for the Nonce extension and does not change the specifications of any of the other standard extensions defined in [RFC6960].¶

   id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
   id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

   Nonce ::= OCTET STRING(SIZE(1..32))

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 client's nonce value in the OCSP response makes sure that the response is the latest response from the server and not an old copy.¶

4. IANA Considerations

This document has no IANA actions.¶

5. Changes to Appendix B of RFC 6960

This section updates the ASN.1 definitions of the OCSP Nonce extension in Appendices B.1 and B.2 of [RFC6960]. Appendix B.1 defines OCSP using ASN.1 - 1998 Syntax; Appendix B.2 defines OCSP using ASN.1 - 2008 Syntax.¶

    Nonce ::= OCTET STRING(SIZE(1..32))

    re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
        BY id-pkix-ocsp-nonce }

    re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING(SIZE(1..32))
        IDENTIFIED BY id-pkix-ocsp-nonce }

Author's Address