<?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 transformationsdraft submitted inXML processors, including most browsersxml v3 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><!-- 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> <titleabbrev="draft-ietf-lamps-ocsp-nonce-update-11">Onlineabbrev="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 --><seriesInfoname="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 thecurrent 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 filestitle) for useby search engines.on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t> RFC 8954 imposedthesize constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is usedfor checkingto 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 foraneasier 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 inSection 4.4.1 of<xreftarget="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 andto avoidavoids 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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</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 otherstandardextensions 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, itwould beis included as one of the responseExtensions. In both the request and the response, the Noncewill beis identified by the object identifierid-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 NonceMUST<bcp14>MUST</bcp14> be at least 1 octet and can be up to 128 octets.[RFC8954]Implementations compliantimplementationswith <xref target="RFC8954"/> will not beunableable to process nonces generated per the new specification with sizes in excess of the limitof 32 octets that was(32 octets) specified in[RFC8954].<xref target="RFC8954"/>. </t> <t> An OCSP requester that implements the extension in this documentMUST<bcp14>MUST</bcp14> use a minimum length of 32 octets for Nonce in the Nonce extension. </t> <t> An OCSP responder, supportingthat supports the Nonceextension, MUSTextension <bcp14>MUST</bcp14> accept Nonce lengths of at least 16 octets and up to and including 32 octets.Responder MAYA responder <bcp14>MAY</bcp14> choose to respond without the Nonce extension for requestswherein which the length of the Nonce is in between 1 octet and 15 octets or 33 octets and 128 octets. </t> <t>Responders,Responders thatimplementsimplement the extension in this documentMUST<bcp14>MUST</bcp14> reject any OCSP request that has a Nonce with a length of either 0 octets ormoregreater than 128 octets, with the malformedRequest OCSPResponseStatus as described inSection 4.2.1 of [RFC6960].<xref target="RFC6960" sectionFormat="of" section="4.2.1"/>. </t> <t> The value of the NonceMUST<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 OCSPrequesterrequesters 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 with32 octeta 32-octet Nonce in hexadecimalformat.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,LengthLength, 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 responsemakes sureensures that the response is thelatestmost 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 wishfor the module identifier tothank Mohit Sahnireplace TBD1. The OID forhis workthe 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 toproduce <xref target="RFC8954"/>."id-mod-ocsp-2024-88". </t> <t>The authors wishFor the ASN.1 Module in Appendix A.2, IANA is requested tothank Russ Housley, Corey Bonnell, Michael StJohns and Carl Wallaceassign an object identifier (OID) for thefeedback and suggestions. </t> </section> <!-- NOTE:module identifier to replace TBD2. TheAcknowledgementsOID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0), andContributors sections are attheend of this templateDescription 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"/> <referenceanchor="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 theentirity of Section 5entirety of <xreftarget="RFC8954"/>.target="RFC8954" sectionFormat="of" section="5"/>. It addresses ErrataidID 5891 <xreftarget="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 themodules Appendix B.1 ofmodule in <xreftarget="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 inA.1,<xref target="asn-1998"/>, that conforms to the 2008 version of ASN.1. This module replaces the modules inSection 4 of<xreftarget="RFC5912"/>target="RFC5912" sectionFormat="of" section="4"/> andAppendix B.2 of<xreftarget="RFC6960"/>.target="RFC6960" sectionFormat="of" section="B.2"/>. Although a 2008 ASN.1 module is provided, the module inAppendix A.1<xref target="asn-1998"/> remains the normative moduleasper the policy of the PKIXworking 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>