wdiff rfc9654.original.xml rfc9654.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?> encoding="UTF-8"?>

<!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations draft submitted in XML processors, including most browsers xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"  category="std"  consensus="true" docName="draft-ietf-lamps-ocsp-nonce-update-11"  number="9654" tocInclude="true" sortRefs="true" symRefs="true" ipr="trust200902"  obsoletes="8954"  updates="6960"  submissionType="IETF" xml:lang="en"  version="3">

  <front>
    <title abbrev="draft-ietf-lamps-ocsp-nonce-update-11">Online abbrev="OCSP Nonce Extension">Online Certificate Status Protocol (OCSP) Nonce Extension</title>
    <!--  [REPLACE/DELETE] abbrev. The abbreviated title is required if the full title is longer than 39 characters -->
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-ocsp-nonce-update-11"/> name="RFC" value="9654"/>
    <author fullname="Himanshu Sharma" initials="H" role="editor" surname="Sharma">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->

    <!-- all of the following elements are optional -->
      <organization>Netskope Inc</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>2445 Augustine Dr 3rd floor</street>
          <city>Santa Clara</city>
          <region>California</region>
          <code>95054</code>
          <country>USA</country>
          <!-- Uses two letter country code -->
          <country>United States of America</country>
        </postal>
        <email>himanshu@netskope.com</email>
        <uri>www.netskope.com</uri>
      </address>
    </author>

    <date month="August" year="2024"/>

    <area>SEC</area>
    <workgroup>lamps</workgroup>

<!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not [rfced] Please insert any keywords (beyond those that appear in
the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is
          not present, the default is "Network Working Group", which is used by the RFC Editor as
          a nod to the history of the RFC Series. -->

    <keyword>Online Certificate Status Protocol (OCSP) Nonce Extension</keyword>
    <!-- [REPLACE/DELETE]. Multiple allowed.  Keywords are incorporated into HTML output files title) for use by search engines. on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
        <t>
            RFC 8954 imposed the size constraints on the
            optional Nonce extension for the Online Certificate Status Protocol (OCSP).
            OCSP is used for checking to check the status of a certificate, and the Nonce extension
            is used to cryptographically bind an OCSP response message to a particular
            OCSP request message.
        </t>
<!-- [rfced] Does "the Nonce section" refer to Section 4.4.1 of RFC 6960?  For clarity (because RFC 6960 has not yet been mentioned in the Abstract), we recommend updating this to "modifies the 'Nonce' section of RFC 6960".  Please let us know if this is incorrect. In addition, please clarify "and values distinctively."

Original:
   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.

Perhaps:
   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.
-->
        <t>
            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 the 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.
        </t>
    </abstract>

  </front>

  <middle>

    <section>
      <name>Introduction</name>
        <t>
            The Nonce extension was previously defined in Section 4.4.1 of <xref target="RFC6960"/>. target="RFC6960" sectionFormat="of" section="4.4.1"/>.
                The Nonce cryptographically binds an OCSP request and a response. It guarantees the freshness of an OCSP response and to avoid avoids replay attacks.
            This extension was updated in <xref target="RFC8954"/>.  <xref target="RFC8954"/> 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.
        </t>
      <section>
        <name>Requirements Language</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
          RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
      </section>
    </section>

    <section>
      <name>OCSP Extensions</name>
<!-- [rfced] For clarity, may we replace "this section" with "Section 4.4.1 of [RFC6960]"?  Please confirm the section and RFC are correct.

Original:
   The message formats for OCSP requests and responses are defined in
   [RFC6960] and 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 this section to limit the minimum and
   maximum length for the Nonce value.

Perhaps:
   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.
-->
      <t>
          The message formats for OCSP requests and responses are defined in
   <xref target="RFC6960"/> and the Nonce extension was updated in <xref target="RFC8954"/>.  <xref target="RFC6960"/>
   also defines the standard extensions for OCSP messages based on the
   extension model employed in X.509 version 3 certificates (see
   <xref target="RFC5280"/>).  <xref target="RFC8954"/> 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 <xref target="RFC6960"/>.
      </t>
   <section>
   <name>Nonce Extension</name>
   <t>
       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 is included as
       one of the responseExtensions.  In both the request and the response,
       the Nonce will be is identified by the object identifier id-pkix-ocsp-
       nonce, 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 <bcp14>MUST</bcp14> be at
       least 1 octet and can be up to 128 octets. [RFC8954] Implementations compliant
       implementations with <xref target="RFC8954"/>
       will not be unable able to process nonces
       generated per the new specification with sizes in excess of the limit
       of 32 octets that was (32 octets) specified in [RFC8954]. <xref target="RFC8954"/>.
   </t>
   <t>
        An OCSP requester that implements the extension in this document MUST <bcp14>MUST</bcp14> use a minimum
       length of 32 octets for Nonce in the Nonce extension.
   </t>
   <t>
       An OCSP responder , supporting that supports the Nonce extension, MUST extension <bcp14>MUST</bcp14> accept Nonce lengths
   of at least 16 octets and up to and including 32 octets. Responder MAY A responder <bcp14>MAY</bcp14> choose to respond without the Nonce extension
   for requests where in which the length of the Nonce is in between 1 octet and
       15 octets or 33 octets and 128 octets.
   </t>
   <t>
       Responders,
       Responders that implements implement the extension in this document MUST <bcp14>MUST</bcp14> reject any OCSP
   request that has a Nonce with a length of either 0 octets or more greater
   than 128 octets, with the malformedRequest OCSPResponseStatus as
       described in Section 4.2.1 of [RFC6960]. <xref target="RFC6960" sectionFormat="of" section="4.2.1"/>.
   </t>
   <t>
       The value of the Nonce MUST <bcp14>MUST</bcp14> be generated using a cryptographically
       strong pseudorandom number generator (see <xref target="RFC4086"/>). The minimum
           Nonce length of 1 octet is defined to provide backward compatibility
           with older OCSP requester requesters that follow <xref target="RFC6960"/>.
       </t>
    <artwork><![CDATA[
<!-- [rfced] Please review each artwork element and let us know if any should
be marked as sourcecode (or another element) instead.

We updated <artwork> to <sourcecode> for the first item in Section 2.1 and for the ASN.1 in Appendixes A and B. Please confirm that this is correct.

In addition, please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly.

The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->

    <sourcecode type="asn.1"><![CDATA[
id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Nonce ::= OCTET STRING(SIZE(1..128))
    ]]></artwork>
    <artwork><![CDATA[

   Example
    ]]></sourcecode>

<t>The following is an example of an encoded OCSP Nonce extension with 32 octet a 32-octet Nonce in
   hexadecimal format. format.</t>

    <artwork><![CDATA[
   30 2f 06 09 2b 06 01 05 05 07 30 01 02 04 22 04
   20 dd 49 d4 07 2c 44 9d a1 c3 17 bd 1c 1b df fe
   db e1 50 31 2e c4 cd 0a dd 18 e5 bd 6f 84 bf 14
   c8
]]></artwork>

<t>
   Here is the decoded version of the above example.
   Offset, Length Length, and Object Identifier are in decimal.
</t>
<artwork><![CDATA[
   Offset  Length
   0       47    : SEQUENCE {
   2       9     :   OBJECT IDENTIFIER ocspNonce (1 3 6 1 5 5 7 48 1 2)
   13      34    :   OCTET STRING, encapsulates {
   15      32    :     OCTET STRING
                 :       DD 49 D4 07 2C 44 9D A1 C3 17 BD 1C 1B DF FE DB
                 :       E1 50 31 2E C4 CD 0A DD 18 E5 BD 6F 84 BF 14 C8
                 :     }
                 :  }
    ]]></artwork>
    </section>
    </section>
    <section>
        <name>Security Considerations</name>
        <t>The security considerations of OCSP, in general, are described in
   <xref target="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 makes sure ensures that
   the response is the latest most recent response from the server and not an old
       copy.</t>
        <section>
            <name>Replay Attack</name>
            <t>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 <xref target="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.</t>
        </section>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>
<!-- [rfced] For clarity, we have updated the IANA Considerations text to include the assigned values in table format.  Please review and let us know if you have any concerns or prefer the paragraph form.

Original:
   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".
      </t>
      <t>

   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".
-->

      <t>
          For the ASN.1 modules in Appendixes <xref target="asn-1998" format="counter"/> and
<xref target="asn-2008" format="counter"/>, IANA has assigned the following
          object identifiers (OIDs) in the "SMI Security for PKIX
          Module Identifier" registry (1.3.6.1.5.5.7.0): </t>
    </section>
    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>

<table anchor="iana-tab">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>111</td>
      <td>id-mod-ocsp-2024-88</td>
    </tr>
    <tr>
      <td>112</td>
      <td>id-mod-ocsp-2024-08</td>
    </tr>
  </tbody>
</table>

<!--

<t>
          The authors of this document wish for the module identifier to thank Mohit Sahni replace TBD1. The
          OID for his work 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 produce <xref target="RFC8954"/>. "id-mod-ocsp-2024-88".
      </t>
      <t>
          The authors wish
          For the ASN.1 Module in Appendix A.2, IANA is requested to thank Russ Housley, Corey Bonnell,
          Michael StJohns and Carl Wallace assign an
          object identifier (OID) for the feedback and suggestions.

      </t>
    </section>
    <!-- NOTE: module identifier to replace TBD2. The Acknowledgements
          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 Contributors sections are at the end of this template Description
              for the new OID should be set to "id-mod-ocsp-2024-08".
      </t>
-->
    </section>

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5019.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8954.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->

    </references>
    <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>

<reference anchor="Errata5891" target="https://www.rfc-editor.org/errata/eid5891" quoteTitle="false"> anchor="Err5891" quote-title="false" target="https://www.rfc-editor.org/errata/eid5891">
   <front>
      <title>Erratum ID 5891</title>
      <author>
              <organization showOnFrontPage="true">RFC
         <organization>RFC Errata</organization>
      </author>
   </front>
   <refcontent>RFC 6960</refcontent>
</reference>

    </references>
    </references>

    <section anchor="asn-modules" title="ASN.1 Modules">
    <t>
        This section includes the ASN.1 modules for OCSP and replaces the entirity of Section 5 entirety of <xref target="RFC8954"/>. target="RFC8954" sectionFormat="of" section="5"/>.
        It addresses Errata id ID 5891 <xref target="Errata5891"/> target="Err5891"/> as well.
    </t>
    <t>
        Appendix A.1
        <xref target="asn-1998"/> 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 module in <xref target="RFC6960"/>. target="RFC6960" sectionFormat="of" section="B.1"/>.
    </t>
    <t>
        Appendix A.2
        <xref target="asn-2008"/> includes an ASN.1 module, corresponding to the module
        present in A.1, <xref target="asn-1998"/>, that conforms to the 2008 version of ASN.1.  This module
        replaces the modules in Section 4 of <xref target="RFC5912"/> target="RFC5912" sectionFormat="of" section="4"/> and Appendix B.2 of
        <xref target="RFC6960"/>. target="RFC6960" sectionFormat="of" section="B.2"/>. Although a 2008 ASN.1 module is provided, the module in
        Appendix A.1
        <xref target="asn-1998"/> remains the normative module as per the policy of the PKIX working group. Working Group.
    </t>
    <section anchor="asn-1998" title="OCSP in ASN.1 - 1998 Syntax">
        <artwork><![CDATA[
        <sourcecode type="asn.1"><![CDATA[
OCSP-2024-88
      {iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-ocsp-2024-88(TBD1)}
      id-mod-ocsp-2024-88(111)}

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS

   -- PKIX Certificate Extensions
      AuthorityInfoAccessSyntax, CRLReason, GeneralName
      FROM PKIX1Implicit88 { iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-implicit(19) }

      Name, CertificateSerialNumber, Extensions,
      id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier
      FROM PKIX1Explicit88 { iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-explicit(18) };

OCSPRequest ::= SEQUENCE {
   tbsRequest              TBSRequest,
   optionalSignature   [0] EXPLICIT Signature OPTIONAL }

TBSRequest ::= SEQUENCE {
   version             [0] EXPLICIT Version DEFAULT v1,
   requestorName       [1] EXPLICIT GeneralName OPTIONAL,
   requestList             SEQUENCE OF Request,
   requestExtensions   [2] EXPLICIT Extensions OPTIONAL }

Signature ::= SEQUENCE {
   signatureAlgorithm      AlgorithmIdentifier,
   signature               BIT STRING,
   certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Version ::= INTEGER { v1(0) }

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

Request ::= SEQUENCE {
   reqCert                     CertID,
   singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }

CertID ::= SEQUENCE {
   hashAlgorithm           AlgorithmIdentifier,
   issuerNameHash          OCTET STRING, -- Hash of issuer's DN
   issuerKeyHash           OCTET STRING, -- Hash of issuer's public key
   serialNumber            CertificateSerialNumber }

OCSPResponse ::= SEQUENCE {
   responseStatus          OCSPResponseStatus,
   responseBytes       [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
   successful          (0),  -- Response has valid confirmations
   malformedRequest    (1),  -- Illegal confirmation request
   internalError       (2),  -- Internal error in issuer
   tryLater            (3),  -- Try again later
                             -- (4) is not used
   sigRequired         (5),  -- Must sign the request
   unauthorized        (6)   -- Request unauthorized
}

ResponseBytes ::= SEQUENCE {
   responseType            OBJECT IDENTIFIER,
   response                OCTET STRING }

BasicOCSPResponse ::= SEQUENCE {
  tbsResponseData          ResponseData,
  signatureAlgorithm       AlgorithmIdentifier,
  signature                BIT STRING,
  certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

ResponseData ::= SEQUENCE {
   version             [0] EXPLICIT Version DEFAULT v1,
   responderID             ResponderID,
   producedAt              GeneralizedTime, -- The format for
                                            -- GeneralizedTime is as
                                            -- specified in Section
                                            -- 4.1.2.5.2 of [RFC5280]
   responses               SEQUENCE OF SingleResponse,
   responseExtensions  [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName              [1] Name,
   byKey               [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                         -- (i.e., the SHA-1 hash of the value of the
                         -- BIT STRING subjectPublicKey [excluding
                         -- the tag, length, and number of unused
                         -- bits] in the responder's certificate)

SingleResponse ::= SEQUENCE {
   certID                  CertID,
   certStatus              CertStatus,
   thisUpdate              GeneralizedTime,
   nextUpdate          [0] EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions    [1] EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
   good                [0] IMPLICIT NULL,
   revoked             [1] IMPLICIT RevokedInfo,
   unknown             [2] IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
   revocationTime          GeneralizedTime,
   revocationReason    [0] EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

ServiceLocator ::= SEQUENCE {
   issuer                  Name,
   locator                 AuthorityInfoAccessSyntax }

CrlID ::= SEQUENCE {
    crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
    crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
    crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
   sigIdentifier   AlgorithmIdentifier,
   certIdentifier  AlgorithmIdentifier OPTIONAL }

-- Object Identifiers

id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp                 OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic           OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce           OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl             OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response        OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs   OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }

END
            ]]>
    </artwork>
    </sourcecode>
    </section>
    <section anchor="asn-2008" title="OCSP in ASN.1 - 2008 Syntax">
        <artwork><![CDATA[
        <sourcecode type="asn.1"><![CDATA[
OCSP-2024-08
     {iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-ocsp-2024-08(TBD2)}
     id-mod-ocsp-2024-08(112)}

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS

Extensions{}, EXTENSION
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}

AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0)
   id-mod-algorithmInformation-02(58)}

AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions, CRLReason
FROM PKIX1Implicit-2009 -- From [RFC5912]
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate
FROM PKIX1Explicit-2009 -- From [RFC5912]
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}

sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1
FROM PKIXAlgs-2009 -- From [RFC5912]
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0)
   id-mod-pkix1-algorithms2008-02(56)};

OCSPRequest     ::=     SEQUENCE {
   tbsRequest                  TBSRequest,
   optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
   version             [0] EXPLICIT Version DEFAULT v1,
   requestorName       [1] EXPLICIT GeneralName OPTIONAL,
   requestList             SEQUENCE OF Request,
   requestExtensions   [2] EXPLICIT Extensions {{re-ocsp-nonce |
                    re-ocsp-response, ...,
                    re-ocsp-preferred-signature-algorithms}} OPTIONAL }

Signature       ::=     SEQUENCE {
   signatureAlgorithm   AlgorithmIdentifier
                            { SIGNATURE-ALGORITHM, {...}},
   signature            BIT STRING,
   certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Version  ::=  INTEGER  {  v1(0) }

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

Request ::=     SEQUENCE {
   reqCert                    CertID,
   singleRequestExtensions    [0] EXPLICIT Extensions
                                      { {re-ocsp-service-locator,
                                             ...}} OPTIONAL }

CertID ::= SEQUENCE {
   hashAlgorithm            AlgorithmIdentifier
                                {DIGEST-ALGORITHM, {...}},
   issuerNameHash     OCTET STRING, -- Hash of issuer's DN
   issuerKeyHash      OCTET STRING, -- Hash of issuer's public key
   serialNumber       CertificateSerialNumber }

OCSPResponse ::= SEQUENCE {
  responseStatus         OCSPResponseStatus,
  responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
   successful            (0), -- Response has valid confirmations
   malformedRequest      (1), -- Illegal confirmation request
   internalError         (2), -- Internal error in issuer
   tryLater              (3), -- Try again later
                              -- (4) is not used
   sigRequired           (5), -- Must sign the request
   unauthorized          (6)  -- Request unauthorized
}

RESPONSE ::= TYPE-IDENTIFIER

ResponseSet RESPONSE ::= {basicResponse, ...}

ResponseBytes ::=       SEQUENCE {
   responseType        RESPONSE.
                           &id ({ResponseSet}),
   response            OCTET STRING (CONTAINING RESPONSE.
                           &Type({ResponseSet}{@responseType}))}

basicResponse RESPONSE ::=
   { BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic }

BasicOCSPResponse       ::= SEQUENCE {
  tbsResponseData      ResponseData,
  signatureAlgorithm   AlgorithmIdentifier{SIGNATURE-ALGORITHM,
                           {sa-dsaWithSHA1 | sa-rsaWithSHA1 |
                                sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
  signature            BIT STRING,
  certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

ResponseData ::= SEQUENCE {
  version              [0] EXPLICIT Version DEFAULT v1,
  responderID              ResponderID,
  producedAt               GeneralizedTime,
  responses                SEQUENCE OF SingleResponse,
  responseExtensions   [1] EXPLICIT Extensions
                              {{re-ocsp-nonce, ...,
                                re-ocsp-extended-revoke}} OPTIONAL }

ResponderID ::= CHOICE {
  byName   [1] Name,
  byKey    [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                        -- (excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
  certID                       CertID,
  certStatus                   CertStatus,
  thisUpdate                   GeneralizedTime,
  nextUpdate           [0]     EXPLICIT GeneralizedTime OPTIONAL,
  singleExtensions     [1]     EXPLICIT Extensions{{re-ocsp-crl |
                                            re-ocsp-archive-cutoff |
                                            CrlEntryExtensions, ...}
                                            } OPTIONAL }

CertStatus ::= CHOICE {
   good                [0]     IMPLICIT NULL,
   revoked             [1]     IMPLICIT RevokedInfo,
   unknown             [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
   revocationTime              GeneralizedTime,
   revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet})

ServiceLocator ::= SEQUENCE {
   issuer    Name,
   locator   AuthorityInfoAccessSyntax }

CrlID ::= SEQUENCE {
   crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
   crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
   crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
  sigIdentifier  AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
  certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL
}

-- Certificate Extensions

ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED
                                BY id-pkix-ocsp-nocheck }

-- Request Extensions

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

re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED
                                BY id-pkix-ocsp-response }

re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator
                                       IDENTIFIED BY
                                       id-pkix-ocsp-service-locator }

re-ocsp-preferred-signature-algorithms EXTENSION ::= {
  SYNTAX PreferredSignatureAlgorithms
  IDENTIFIED BY id-pkix-ocsp-pref-sig-algs  }

-- Response Extensions

re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY
                               id-pkix-ocsp-crl }

re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff
                                      IDENTIFIED BY
                                      id-pkix-ocsp-archive-cutoff }

re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
                                       id-pkix-ocsp-extended-revoke }

-- Object Identifiers

id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp                 OBJECT IDENTIFIER ::= id-ad-ocsp
id-pkix-ocsp-basic           OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce           OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl             OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response        OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs   OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }

END
            ]]>
    </artwork>
    </sourcecode>
    </section>
    </section>

    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>
          The authors of this document thank <contact fullname="Mohit Sahni"/> for his work to produce <xref target="RFC8954"/>.
      </t>
      <t>
          The authors also thank <contact fullname="Russ Housley"/>, <contact fullname="Corey Bonnell"/>,
          <contact fullname="Michael StJohns"/>, and <contact fullname="Carl Wallace"/> for their feedback and suggestions.

      </t>
    </section>

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</back>
</rfc>