Diff: rfc9654.original.xml

	rfc9654.original.xml	rfc9654.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<?xml-model href="rfc7991bis.rnc"?> <!-- Required for schema validation and sch
	ema-aware editing -->	<!-- draft submitted in xml v3 -->
	<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
	<!-- This third-party XSLT can be enabled for direct transformations in XML proc
	essors, including most browsers -->

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!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	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true
	xmlns:xi="http://www.w3.org/2001/XInclude"	" docName="draft-ietf-lamps-ocsp-nonce-update-11" number="9654" tocInclude="tru
	category="std"	e" sortRefs="true" symRefs="true" ipr="trust200902" obsoletes="8954" updates="
	consensus="true"	6960" submissionType="IETF" xml:lang="en" version="3">
	docName="draft-ietf-lamps-ocsp-nonce-update-11"
	ipr="trust200902"
	obsoletes="8954"
	updates="6960"
	submissionType="IETF"
	xml:lang="en"
	version="3">

	<front>	<front>

	<title abbrev="draft-ietf-lamps-ocsp-nonce-update-11">Online Certificate Sta	<title abbrev="OCSP Nonce Extension">Online Certificate Status Protocol (OCS
	tus Protocol (OCSP) Nonce Extension</title>	P) Nonce Extension</title>
	<!-- [REPLACE/DELETE] abbrev. The abbreviated title is required if the full	<seriesInfo name="RFC" value="9654"/>
	title is longer than 39 characters -->
	<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-ocsp-nonce-update-
	11"/>
	<author fullname="Himanshu Sharma" initials="H" role="editor" surname="Sharm a">	<author fullname="Himanshu Sharma" initials="H" role="editor" surname="Sharm a">

	<!-- [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>	<organization>Netskope Inc</organization>
	<address>	<address>
	<postal>	<postal>

	<!-- Reorder these if your country does things differently -->
	<street>2445 Augustine Dr 3rd floor</street>	<street>2445 Augustine Dr 3rd floor</street>
	<city>Santa Clara</city>	<city>Santa Clara</city>
	<region>California</region>	<region>California</region>
	<code>95054</code>	<code>95054</code>

	<country>USA</country>	<country>United States of America</country>
	<!-- Uses two letter country code -->
	</postal>	</postal>
	<email>himanshu@netskope.com</email>	<email>himanshu@netskope.com</email>
	<uri>www.netskope.com</uri>	<uri>www.netskope.com</uri>
	</address>	</address>
	</author>	</author>


	<date year="2024"/>	<date month="August" year="2024"/>
	<!-- 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, th
	e current day will
	be used
	* If the year is not the current one, it is necessary to specify at lea
	st a month and day="1" will be used.
	-->


	<area>General</area>	<area>SEC</area>
	<workgroup>Internet Engineering Task Force</workgroup>	<workgroup>lamps</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>	<!-- [rfced] Please insert any keywords (beyond those that appear in
	<!-- [REPLACE/DELETE]. Multiple allowed. Keywords are incorporated into HTM	the title) for use on https://www.rfc-editor.org/search. -->
	L output files for
	use by search engines. -->	<keyword>example</keyword>

	<abstract>	<abstract>
	<t>	<t>

	RFC 8954 imposed the size constraints on the	RFC 8954 imposed size constraints on the
	optional Nonce extension for the Online Certificate Status Protocol (OCSP).	optional Nonce extension for the Online Certificate Status Protocol (OCSP).

	OCSP is used for checking the status of a certificate, and the Nonce extension	OCSP is used to check the status of a certificate, and the Nonce ext ension
	is used to cryptographically bind an OCSP response message to a part icular	is used to cryptographically bind an OCSP response message to a part icular
	OCSP request message.	OCSP request message.
	</t>	</t>

		<!-- [rfced] Does "the Nonce section" refer to Section 4.4.1 of RFC 6960? For c
		larity (because RFC 6960 has not yet been mentioned in the Abstract), we recomme
		nd updating this to "modifies the 'Nonce' section of RFC 6960". Please let us k
		now 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>	<t>
	Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets.	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 oct	This document updates the maximum allowed length of Nonce to 128 oct
	ets. This document also modifies Nonce section to clearly define the encoding fo	ets. This document also modifies the Nonce section to clearly define the encodin
	rmat	g format
	and values distinctively for an easier implementation and understand	and values distinctively for easier implementation and understanding
	ing.	.
	This document obsoletes RFC 8954 and provides updated ASN.1 modules for OCSP, updates RFC 6960.	This document obsoletes RFC 8954 and provides updated ASN.1 modules for OCSP, updates RFC 6960.
	</t>	</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section>	<section>
	<name>Introduction</name>	<name>Introduction</name>
	<t>	<t>

	Nonce extension was previously defined in Section 4.4.1 of <xref tar	The Nonce extension was previously defined in <xref target="RFC6960"
	get="RFC6960"/>.	sectionFormat="of" section="4.4.1"/>.
	The Nonce cryptographically binds an OCSP request and a respons	The Nonce cryptographically binds an OCSP request and a response
	e. It guarantees the freshness of an OCSP response and to avoid replay attacks.	. It guarantees the freshness of an OCSP response and avoids replay attacks.
	This extension was updated in <xref target="RFC8954"/>. <xref targe t="RFC8954"/> limits the maximum Nonce	This extension was updated in <xref target="RFC8954"/>. <xref targe t="RFC8954"/> limits the maximum Nonce
	length to 32 octets. To support cryptographic algorithms that generate	length to 32 octets. To support cryptographic algorithms that generate
	a Nonce that is longer than 32 octets, this document updates the	a Nonce that is longer than 32 octets, this document updates the
	maximum allowed size of the Nonce to 128 octets. In addition, this	maximum allowed size of the Nonce to 128 octets. In addition, this
	document recommends that the OCSP requester and responder use a	document recommends that the OCSP requester and responder use a
	Nonce with a minimum length of 32 octets.	Nonce with a minimum length of 32 octets.
	</t>	</t>
	<section>	<section>
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",	<t>
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	interpreted as described in BCP 14 <xref target="RFC2119"/>	",
	<xref target="RFC8174"/> when, and only when, they appear in	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	all capitals, as shown here.</t>	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be
		interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>
	</section>	</section>
	</section>	</section>

	<section>	<section>
	<name>OCSP Extensions</name>	<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 minim
		um and
		maximum length for the Nonce value.
		-->
	<t>	<t>
	The message formats for OCSP requests and responses are defined in	The message formats for OCSP requests and responses are defined in

	<xref target="RFC6960"/> and Nonce extension was updated in <xref target="RFC 8954"/>. <xref target="RFC6960"/>	<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	also defines the standard extensions for OCSP messages based on the
	extension model employed in X.509 version 3 certificates (see	extension model employed in X.509 version 3 certificates (see
	<xref target="RFC5280"/>). <xref target="RFC8954"/> replaces this section to limit the minimum	<xref target="RFC5280"/>). <xref target="RFC8954"/> replaces this section to limit the minimum
	and maximum length for the Nonce value.	and maximum length for the Nonce value.
	This document extends the maximum allowed nonce length to 128 octets and does not change the specifications	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"/>.	of any of the other extensions defined in <xref target="RFC6960"/>.
	</t>	</t>
	<section>	<section>
	<name>Nonce Extension</name>	<name>Nonce Extension</name>
	<t>	<t>
	The Nonce cryptographically binds a request and a response to prevent	The Nonce cryptographically binds a request and a response to prevent
	replay attacks. The Nonce is included as one of the	replay attacks. The Nonce is included as one of the

	requestExtensions in requests; in responses, it would be included as	requestExtensions in requests; in responses, it is included as
	one of the responseExtensions. In both the request and the response,	one of the responseExtensions. In both the request and the response,

	the Nonce will be identified by the object identifier id-pkix-ocsp-	the Nonce is identified by the object identifier id-pkix-ocsp-nonce, whil
	nonce, while the extnValue is the encoded value of Nonce. If the	e the extnValue is the encoded value of Nonce. If the
	Nonce extension is present, then the length of the Nonce MUST be at	Nonce extension is present, then the length of the Nonce <bcp14>MUST</bcp
	least 1 octet and can be up to 128 octets. [RFC8954] compliant	14> be at
	implementations will be unable to process nonces	least 1 octet and can be up to 128 octets. Implementations compliant with
	generated per the new specification with sizes in excess of the limit	<xref target="RFC8954"/>
	of 32 octets that was specified in [RFC8954].	will not be able to process nonces
		generated per the new specification with sizes in excess of the limit (32
		octets) specified in <xref target="RFC8954"/>.
	</t>	</t>
	<t>	<t>

	An OCSP requester that implements this document MUST use a minimum	An OCSP requester that implements the extension in this document <bcp14> MUST</bcp14> use a minimum
	length of 32 octets for Nonce in the Nonce extension.	length of 32 octets for Nonce in the Nonce extension.
	</t>	</t>
	<t>	<t>

	An OCSP responder , supporting the Nonce extension, MUST accept Nonce len	An OCSP responder that supports the Nonce extension <bcp14>MUST</bcp14> a
	gths	ccept Nonce lengths
	of at least 16 octets and up to and including 32 octets. Responder MAY choose	of at least 16 octets and up to and including 32 octets. A responder <bcp14>M
	to respond without the Nonce extension	AY</bcp14> choose to respond without the Nonce extension
	for requests where the length of the Nonce is in between 1 octet and	for requests in which the length of the Nonce is in between 1 octet and
	15 octets or 33 octets and 128 octets.	15 octets or 33 octets and 128 octets.
	</t>	</t>
	<t>	<t>

	Responders, that implements this document MUST reject any OCSP	Responders that implement the extension in this document <bcp14>MUST</bcp
	request that has a Nonce with a length of either 0 octets or more	14> reject any OCSP
		request that has a Nonce with a length of either 0 octets or greater
	than 128 octets, with the malformedRequest OCSPResponseStatus as	than 128 octets, with the malformedRequest OCSPResponseStatus as

	described in Section 4.2.1 of [RFC6960].	described in <xref target="RFC6960" sectionFormat="of" section="4.2.1"/>.
	</t>	</t>
	<t>	<t>

	The value of the Nonce MUST be generated using a cryptographically	The value of the Nonce <bcp14>MUST</bcp14> be generated using a cryptogra phically
	strong pseudorandom number generator (see <xref target="RFC4086"/>). The minimum	strong pseudorandom number generator (see <xref target="RFC4086"/>). The minimum
	Nonce length of 1 octet is defined to provide backward compatibility	Nonce length of 1 octet is defined to provide backward compatibility

	with older OCSP requester that follow <xref target="RFC6960"/>.	with older OCSP requesters that follow <xref target="RFC6960"/>.
	</t>	</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 t
		he 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 OBJECT IDENTIFIER ::= { id-ad-ocsp }
	id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }	id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
	Nonce ::= OCTET STRING(SIZE(1..128))	Nonce ::= OCTET STRING(SIZE(1..128))

	]]></artwork>	]]></sourcecode>
	<artwork><![CDATA[


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


		<artwork><![CDATA[
	30 2f 06 09 2b 06 01 05 05 07 30 01 02 04 22 04	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	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	db e1 50 31 2e c4 cd 0a dd 18 e5 bd 6f 84 bf 14
	c8	c8

		]]></artwork>


		<t>
	Here is the decoded version of the above example.	Here is the decoded version of the above example.

	Offset, Length and Object Identifier are in decimal.	Offset, Length, and Object Identifier are in decimal.
		</t>
		<artwork><![CDATA[
	Offset Length	Offset Length
	0 47 : SEQUENCE {	0 47 : SEQUENCE {
	2 9 : OBJECT IDENTIFIER ocspNonce (1 3 6 1 5 5 7 48 1 2)	2 9 : OBJECT IDENTIFIER ocspNonce (1 3 6 1 5 5 7 48 1 2)
	13 34 : OCTET STRING, encapsulates {	13 34 : OCTET STRING, encapsulates {
	15 32 : OCTET STRING	15 32 : OCTET STRING
	: DD 49 D4 07 2C 44 9D A1 C3 17 BD 1C 1B DF FE DB	: 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	: E1 50 31 2E C4 CD 0A DD 18 E5 BD 6F 84 BF 14 C8
	: }	: }
	: }	: }
	]]></artwork>	]]></artwork>
	</section>	</section>
	</section>	</section>
	<section>	<section>
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>The security considerations of OCSP, in general, are described in	<t>The security considerations of OCSP, in general, are described in
	<xref target="RFC6960"/>. During the interval in which the previous OCSP res ponse	<xref target="RFC6960"/>. During the interval in which the previous OCSP res ponse
	for a certificate is not expired but the responder has a changed	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	status for that certificate, a copy of that OCSP response can be used
	to indicate that the status of the certificate is still valid.	to indicate that the status of the certificate is still valid.

	Including a requester's nonce value in the OCSP response makes sure that	Including a requester's nonce value in the OCSP response ensures that
	the response is the latest response from the server and not an old	the response is the most recent response from the server and not an old
	copy.</t>	copy.</t>
	<section>	<section>
	<name>Replay Attack</name>	<name>Replay Attack</name>
	<t>The Nonce extension is used to avoid replay attacks. Since the O CSP	<t>The Nonce extension is used to avoid replay attacks. Since the O CSP
	responder may choose not to send the Nonce extension in 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	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	request <xref target="RFC5019"/>, an on-path attacker can intercept the OCSP request
	and respond with an earlier response from the server without the	and respond with an earlier response from the server without the
	Nonce extension. This can be mitigated by configuring the server to	Nonce extension. This can be mitigated by configuring the server to
	use a short time interval between the thisUpdate and nextUpdate	use a short time interval between the thisUpdate and nextUpdate
	fields in the OCSP response.</t>	fields in the OCSP response.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="IANA">	<section anchor="IANA">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

		<!-- [rfced] For clarity, we have updated the IANA Considerations text to includ
		e the assigned values in table format. Please review and let us know if you hav
		e 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".

		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>	<t>

	For the ASN.1 Module in Appendix A.1, IANA is requested to assign an	For the ASN.1 modules in Appendixes <xref target="asn-1998" format="co
	object identifier (OID) for the module identifier to replace TBD1. The	unter"/> 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>

		<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> for the module identifier to replace TBD1. The
	OID for the module should be allocated in the "SMI Security for PKIX	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	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 new OID should be set to "id-mod-ocsp-2024-88".
	</t>	</t>
	<t>	<t>
	For the ASN.1 Module in Appendix A.2, IANA is requested to assign an	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	object identifier (OID) for the module identifier to replace TBD2. The
	OID for the module should be allocated in the "SMI Security for PKIX	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	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".	for the new OID should be set to "id-mod-ocsp-2024-08".
	</t>	</t>

		-->
	</section>	</section>

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


	</t>
	</section>
	<!-- NOTE: The Acknowledgements and Contributors sections are at the end of
	this template -->
	</middle>	</middle>

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

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 086.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 086.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 019.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 019.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 280.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 280.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 960.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 960.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 954.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 954.xml"/>

	<!-- The recommended and simplest way to include a well known reference -->

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

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

	</references>	</references>
	</references>	</references>

	<section anchor="asn-modules" title="ASN.1 Modules">	<section anchor="asn-modules" title="ASN.1 Modules">
	<t>	<t>

	This section includes the ASN.1 modules for OCSP and replaces the entiri	This section includes the ASN.1 modules for OCSP and replaces the entire
	ty of Section 5 of <xref target="RFC8954"/>.	ty of <xref target="RFC8954" sectionFormat="of" section="5"/>.
	It addresses Errata id 5891 <xref target="Errata5891"/> as well.	It addresses Errata ID 5891 <xref target="Err5891"/> as well.
	</t>	</t>
	<t>	<t>

	Appendix A.1 includes an ASN.1 module that conforms to the 1998	<xref target="asn-1998"/> includes an ASN.1 module that conforms to the 1998
	version of ASN.1 for all syntax elements of OCSP.	version of ASN.1 for all syntax elements of OCSP.

	This module replaces the modules Appendix B.1 of <xref target="RFC6960"/ >.	This module replaces the module in <xref target="RFC6960" sectionFormat= "of" section="B.1"/>.
	</t>	</t>
	<t>	<t>

	Appendix A.2 includes an ASN.1 module, corresponding to the module	<xref target="asn-2008"/> includes an ASN.1 module, corresponding to the
	present in A.1, that conforms to the 2008 version of ASN.1. This module	module
	replaces the modules in Section 4 of <xref target="RFC5912"/> and Append	present in <xref target="asn-1998"/>, that conforms to the 2008 version
	ix B.2 of	of ASN.1. This module
	<xref target="RFC6960"/>. Although a 2008 ASN.1 module is provided, the	replaces the modules in <xref target="RFC5912" sectionFormat="of" sectio
	module in	n="4"/> and
	Appendix A.1 remains the normative module as per the policy of the PKIX	<xref target="RFC6960" sectionFormat="of" section="B.2"/>. Although a 20
	working group.	08 ASN.1 module is provided, the module in
		<xref target="asn-1998"/> remains the normative module per the policy of
		the PKIX Working Group.
	</t>	</t>
	<section anchor="asn-1998" title="OCSP in ASN.1 - 1998 Syntax">	<section anchor="asn-1998" title="OCSP in ASN.1 - 1998 Syntax">

	<artwork><![CDATA[	<sourcecode type="asn.1"><![CDATA[
	OCSP-2024-88	OCSP-2024-88
	{iso(1) identified-organization(3) dod(6) internet(1)	{iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)	security(5) mechanisms(5) pkix(7) id-mod(0)

	id-mod-ocsp-2024-88(TBD1)}	id-mod-ocsp-2024-88(111)}

	DEFINITIONS EXPLICIT TAGS ::=	DEFINITIONS EXPLICIT TAGS ::=

	BEGIN	BEGIN

	IMPORTS	IMPORTS

	-- PKIX Certificate Extensions	-- PKIX Certificate Extensions
	AuthorityInfoAccessSyntax, CRLReason, GeneralName	AuthorityInfoAccessSyntax, CRLReason, GeneralName
	FROM PKIX1Implicit88 { iso(1) identified-organization(3)	FROM PKIX1Implicit88 { iso(1) identified-organization(3)

	skipping to change at line 446 ¶	skipping to change at line 502 ¶
	id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }	id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
	id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }	id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
	id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }	id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
	id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }	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-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
	id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }	id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
	id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }	id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }

	END	END
	]]>	]]>

	</artwork>	</sourcecode>
	</section>	</section>
	<section anchor="asn-2008" title="OCSP in ASN.1 - 2008 Syntax">	<section anchor="asn-2008" title="OCSP in ASN.1 - 2008 Syntax">

	<artwork><![CDATA[	<sourcecode type="asn.1"><![CDATA[
	OCSP-2024-08	OCSP-2024-08
	{iso(1) identified-organization(3) dod(6) internet(1)	{iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)	security(5) mechanisms(5) pkix(7) id-mod(0)

	id-mod-ocsp-2024-08(TBD2)}	id-mod-ocsp-2024-08(112)}

	DEFINITIONS EXPLICIT TAGS ::=	DEFINITIONS EXPLICIT TAGS ::=

	BEGIN	BEGIN

	IMPORTS	IMPORTS

	Extensions{}, EXTENSION	Extensions{}, EXTENSION
	FROM PKIX-CommonTypes-2009 -- From [RFC5912]	FROM PKIX-CommonTypes-2009 -- From [RFC5912]
	{iso(1) identified-organization(3) dod(6) internet(1) security(5)	{iso(1) identified-organization(3) dod(6) internet(1) security(5)

	skipping to change at line 664 ¶	skipping to change at line 720 ¶
	id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }	id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
	id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }	id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
	id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }	id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
	id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }	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-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
	id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }	id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
	id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }	id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }

	END	END
	]]>	]]>

	</artwork>	</sourcecode>
	</section>	</section>
	</section>	</section>


		<section anchor="Acknowledgements" numbered="false">
		<name>Acknowledgements</name>
		<t>
		The authors of this document thank <contact fullname="Mohit Sahni"/> f
		or his work to produce <xref target="RFC8954"/>.
		</t>
		<t>
		The authors also thank <contact fullname="Russ Housley"/>, <contact fu
		llname="Corey Bonnell"/>,
		<contact fullname="Michael StJohns"/>, and <contact fullname="Carl Wal
		lace"/> 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>	</back>
	</rfc>	</rfc>

End of changes. 53 change blocks.
	148 lines changed or deleted	240 lines changed or added
This html diff was produced by rfcdiff 1.48.