rfc9891.original.xml		rfc9891.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?rfc toc="yes"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
	tf-acme-dtnnodeid-18" ipr="trust200902" submissionType="IETF" tocInclude="true"		tf-acme-dtnnodeid-18" number="9891" updates="" obsoletes="" sortRefs="true" symR
	version="3">		efs="true" ipr="trust200902" submissionType="IETF" tocInclude="true" version="3"
			xml:lang="en" consensus="true">
	<front>		<front>
	<title abbrev="ACME DTN Node ID">		<title abbrev="ACME DTN Node ID">Automated Certificate Management Environmen
	Automated Certificate Management Environment (ACME)		t (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension</title>
	Delay-Tolerant Networking (DTN) Node ID Validation Extension		<seriesInfo name="RFC" value="9891"/>
	</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-acme-dtnnodeid-18"/>
	<author fullname="Brian Sipos" initials="B." surname="Sipos">		<author fullname="Brian Sipos" initials="B." surname="Sipos">
	<organization abbrev="RKF Engineering">RKF Engineering Solutions, LLC</org anization>		<organization abbrev="RKF Engineering">RKF Engineering Solutions, LLC</org anization>
	<address>		<address>
	<postal>		<postal>
	<street>7500 Old Georgetown Road</street>		<street>7500 Old Georgetown Road</street>
	<street>Suite 1275</street>		<street>Suite 1275</street>
	<city>Bethesda</city>		<city>Bethesda</city>
	<region>MD</region>		<region>MD</region>
	<code>20814-6198</code>		<code>20814-6198</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>brian.sipos+ietf@gmail.com</email>		<email>brian.sipos+ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<date/>		<date month="November" year="2025"/>
	<area>Security</area>		<area>SEC</area>
	<workgroup>Automated Certificate Management Environment</workgroup>		<workgroup>acme</workgroup>
	<keyword>ACME</keyword>		<keyword>ACME</keyword>
	<keyword>DTN</keyword>		<keyword>DTN</keyword>
	<abstract>		<abstract>
	<t>		<t>
	This document specifies an extension to the Automated Certificate Management Env		This document specifies an extension to the Automated Certificate Management Env
	ironment (ACME) protocol which allows an ACME server to validate the Delay-Toler		ironment (ACME) protocol that allows an ACME server to validate the Delay-Tolera
	ant Networking (DTN) Node ID for an ACME client.		nt Networking (DTN) Node ID for an ACME client.
	A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singl		A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singl
	eton endpoint", one which is registered on a single BP node.		eton endpoint": an endpoint that is registered on a single BP Node.
	The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of ty		The DTN Node ID is encoded both as a certificate Subject Alternative Name (SAN)
	pe otherName with a name form of <tt>BundleEID</tt> and as an ACME Identifier ty		identity of type otherName with an Other Name form of <tt>BundleEID</tt> and as
	pe "bundleEID".		an ACME Identifier type "bundleEID".
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="sec-intro">		<section anchor="sec-intro">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	Although the original purpose of the Automatic Certificate Management Environmen t (ACME) <xref target="RFC8555"/> was to allow Public Key Infrastructure Using X .509 (PKIX) Certification Authorities (CAs) to validate network domain names of clients, the same mechanism can be used to validate any of the subject claims su pported by the PKIX profile <xref target="RFC5280"/>.		Although the original purpose of the Automatic Certificate Management Environmen t (ACME) <xref target="RFC8555"/> was to allow Public Key Infrastructure using X .509 (PKIX) Certification Authorities (CAs) to validate network domain names of clients, the same mechanism can be used to validate any of the subject identity claims supported by the PKIX profile <xref target="RFC5280"/>.
	</t>		</t>
	<t>		<t>
	In the case of this specification, the claim being validated is a Subject Altern		In this specification, the claim being validated is a Subject Alternative Name (
	ative Name (SAN) of type <tt>otherName</tt> with a name form of <tt>BundleEID</t		SAN) identity of type <tt>otherName</tt> with an Other Name form of <tt>BundleEI
	t>, which used to represent a Bundle Protocol (BP) Endpoint ID (EID) in a Delay-		D</tt>, which is used to represent a Bundle Protocol (BP) Endpoint ID (EID) in a
	Tolerant Networking (DTN) overlay network.		Delay-Tolerant Networking (DTN) overlay network.
	A DTN Node ID is any EID which can uniquely identify a BP node, as defined in <x		A DTN Node ID is any EID that can uniquely identify a BP Node, as defined in <xr
	ref section="4.2.5.2" target="RFC9171"/>, which is equivalent to the EID being u		ef section="4.2.5.2" target="RFC9171"/>, which is equivalent to the EID being us
	sable as a singleton endpoint.		able as a singleton endpoint.
	One common EID used as a Node ID is the Administrative EID, which is guaranteed		One common EID used as a Node ID is the Administrative EID, which is guaranteed
	to exist on any BP node.		to exist on any BP Node.
	Currently the URI schemes "dtn" and "ipn" as defined in <xref target="RFC9171"/>		At the time of writing, the URI schemes "dtn" and "ipn" as defined in <xref sect
	are valid for a singleton endpoint and thus a Node ID.		ion="4.2.5.1" target="RFC9171"/> are valid for a singleton endpoint and, thus, a
			Node ID.
	Because the <tt>BundleEID</tt> claim is new to ACME, a new ACME Identifier type "bundleEID" is needed to manage this claim within ACME messaging.		Because the <tt>BundleEID</tt> claim is new to ACME, a new ACME Identifier type "bundleEID" is needed to manage this claim within ACME messaging.
	</t>		</t>
	<t>		<t>
	Once an ACME server validates a Node ID, either as a pre-authorization of the "b undleEID" or as one of the authorizations of an order containing a "bundleEID", the client can finalize the order using an associated certificate signing reques t (CSR).		Once an ACME server validates a Node ID, either as a pre-authorization of an ide ntifier type "bundleEID" as one of the authorizations of an order containing an identifier type "bundleEID", the client can finalize the order using an associat ed Certificate Signing Request (CSR).
	Because a single order can contain multiple identifiers of multiple types, there can be operational issues for a client attempting to, and possibly failing to, validate those multiple identifiers as described in <xref target="sec-multiple-c laims"/>.		Because a single order can contain multiple identifiers of multiple types, there can be operational issues for a client attempting to, and possibly failing to, validate those multiple identifiers as described in <xref target="sec-multiple-c laims"/>.
	Once a certificate is issued for a Node ID, how the ACME client configures the B P Agent with the new certificate is an implementation matter.		Once a certificate is issued for a Node ID, how the ACME client configures the B P Agent with the new certificate is an implementation matter.
	</t>		</t>
	<section>		<section>
	<name>Scope</name>		<name>Scope</name>
	<t>		<t>
	This document describes the ACME message contents <xref target="RFC8555"/>, Bund le Protocol version 7 (BPv7) payloads <xref target="RFC9171"/>, and Bundle proto col Security (BPSec) operations <xref target="RFC9172"/> needed to validate clai ms of Node ID ownership.		This document describes the ACME message contents <xref target="RFC8555"/>, Bund le Protocol version 7 (BPv7) payloads <xref target="RFC9171"/>, and Bundle Proto col Security (BPSec) operations <xref target="RFC9172"/> needed to validate clai ms of Node ID ownership.
	</t>		</t>
	<t>		<t>
	This document does not address:		This document does not address:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	Mechanisms for communication between ACME client or ACME server and their associ		Mechanisms for communication between an ACME client or ACME server and their ass
	ated BP agent(s).		ociated BP Agent(s), depicted as steps 1, 2, 5, and 6 of <xref target="fig-entit
	This document only describes exchanges between ACME client--server pairs and bet		y-relations"/>.
	ween their BP agents.		This document only describes exchanges between ACME client-server pairs and betw
			een their respective associated BP Agents.
	</li>		</li>
	<li>		<li>
	Specific BP extension blocks or BPSec security contexts necessary to fulfill the		Specific BP extension blocks or BPSec contexts necessary to fulfill the security
	security requirements of this protocol.		requirements of this protocol.
	The exact security context needed, and their parameters, are network-specific.		The exact security context needed, and its parameters, is network specific.
	</li>		</li>
	<li>		<li>
	Policies or mechanisms for defining or configuring bundle integrity gateways, or trusting integrity gateways on an individual entity or across a network.		Policies or mechanisms for defining or configuring Bundle integrity gateways, or trusting integrity gateways on an individual entity or across a network.
	</li>		</li>
	<li>		<li>
	Mechanisms for locating or identifying other bundle entities (peers) within a ne		Mechanisms for locating or identifying other Bundle entities (peers) within a ne
	twork or across an internet.		twork or across an internet.
	The mapping of Node ID to potential convergence layer (CL) protocol and network		The mapping of a Node ID to a potential Convergence-Layer (CL) protocol and netw
	address is left to implementation and configuration of the BP Agent and its vari		ork address is left to implementation and configuration of the BP Agent and its
	ous potential routing strategies.		various potential routing strategies.
	</li>		</li>
	<li>		<li>
	Logic for routing bundles along a path toward a bundle's endpoint.		Logic for routing Bundles along a path toward a Bundle's endpoint.
	This protocol is involved only in creating bundles at a source and handling them		This protocol is involved only in creating Bundles at a source and handling them
	at a destination.		at a destination.
	</li>		</li>
	<li>		<li>
	Logic for performing rate control and congestion control of bundle transfers.		Logic for performing rate control and congestion control of Bundle transfers.
	The ACME server is responsible for rate control of validation requests.		The ACME server is responsible for rate control of validation requests.
	</li>		</li>
	<li>		<li>
	Policies or mechanisms for an ACME server to choose a prioritized list of accept able hash algorithms, or for an ACME client to choose a set of acceptable hash a lgorithms.		Policies or mechanisms for an ACME server to choose a prioritized list of accept able hash algorithms or for an ACME client to choose a set of acceptable hash al gorithms.
	</li>		</li>
	<li>		<li>
	Policies or mechanisms for provisioning, deploying, or accessing certificates an d private keys; deploying or accessing certificate revocation lists (CRLs); or c onfiguring security parameters on an individual entity or across a network.		Policies or mechanisms for provisioning, deploying, or accessing certificates an d private keys; deploying or accessing Certificate Revocation Lists (CRLs); or c onfiguring security parameters on an individual entity or across a network.
	</li>		</li>
	<li>		<li>
	Policies or mechanisms for an ACME server to handle mixed-use certificate signin g requests.		Policies or mechanisms for an ACME server to handle mixed-use certificate signin g requests.
	This specification is focused only on single-use DTN-specific PKIX profiles.		This specification is focused only on single-use DTN-specific PKIX profiles.
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section>		<section>
	<name>Authorization Strategy</name>		<name>Authorization Strategy</name>
	<t>		<t>
	The basic unit of data exchange in a DTN is a Bundle <xref target="RFC9171"/>, w hich consists of a data payload with accompanying metadata.		The basic unit of data exchange in a DTN is a Bundle <xref target="RFC9171"/>, w hich consists of a data payload with accompanying metadata.
	An Endpoint ID is used as the destination of a Bundle and can indicate both a si ngleton or a group destination.		An EID is used as the destination of a Bundle and can indicate both a singleton or a group destination.
	A Node ID is used to identify the source of a Bundle and is used for routing thr ough intermediate nodes, including the final node(s) used to deliver a Bundle to its destination endpoint.		A Node ID is used to identify the source of a Bundle and is used for routing thr ough intermediate nodes, including the final node(s) used to deliver a Bundle to its destination endpoint.
	A Node ID can also be used as an endpoint for administrative bundles.		A Node ID can also be used as an endpoint for administrative Bundles.
	More detailed descriptions of the rationale and capabilities of these networks c		More detailed descriptions of the rationale and capabilities of these networks c
	an be found in "Delay-Tolerant Network Architecture" <xref target="RFC4838"/>.		an be found in the "<xref target="RFC4838" format="title"/>" <xref target="RFC48
			38"/>.
	</t>		</t>
	<t>		<t>
	When an ACME client requests a pre-authorization or an order with a "bundleEID" identifier type (<xref target="sec-acme-uri"/>), the ACME server offers a "bp-no deid-00" challenge type (<xref target="sec-validate-nodeid"/>) to validate that Node ID.		When an ACME client requests a pre-authorization or an order with an identifier type "bundleEID" (<xref target="sec-acme-uri"/>), the ACME server offers a "bp-n odeid-00" challenge type (<xref target="sec-validate-nodeid"/>) to validate that Node ID.
	If the ACME client attempts the authorization challenge to validate a Node ID, t he ACME server sends an ACME Node ID Validation Challenge Bundle with a destinat ion of the Node ID being validated.		If the ACME client attempts the authorization challenge to validate a Node ID, t he ACME server sends an ACME Node ID Validation Challenge Bundle with a destinat ion of the Node ID being validated.
	The BP agent on that node receives the Challenge Bundle, generates an ACME key a uthorization digest, and sends an ACME Node ID Validation Response Bundle in rep ly.		The BP Agent on that node receives the Challenge Bundle, generates an ACME Key A uthorization digest, and sends an ACME Node ID Validation Response Bundle in rep ly.
	An Integrity Gateway on the client side of the DTN can be used to attest to the source of the Response Bundle.		An Integrity Gateway on the client side of the DTN can be used to attest to the source of the Response Bundle.
	Finally, the ACME server receives the Response Bundle and checks that the digest was generated for the associated ACME challenge and from the client account key associated with the original request.		Finally, the ACME server receives the Response Bundle and checks that the digest was generated for the associated ACME challenge and from the client account key associated with the original request.
	This workflow is shown in the diagram of <xref target="fig-entity-relations"/>.		This workflow is shown in <xref target="fig-entity-relations"/>.
	</t>		</t>
	<figure anchor="fig-entity-relations">		<figure anchor="fig-entity-relations">
	<name>The relationships and flows between Node ID Validation entities<		<name>The Relationships and Flows Between Node ID Validation Entities<
	/name>		/name>
	<artwork align="center" type="ascii-art">		<artwork align="center"><![CDATA[
	+------------+ +------------+		+------------+ +------------+
	| ACME |<===== HTTPS exchanges =====&gt;| ACME |		| ACME |<===== HTTPS Exchanges =====&gt;| ACME |
	| Client | | Server |		| Client | | Server |
	+------------+ +------------+		+------------+ +------------+
	| | ^		| | ^
	(1) Enable or (6) disable (2) Send | |		(1) Enable or (6) Disable (2) Send | |
	validation from server Challenge | |(5) Indicate		Validation from Server Challenge | |(5) Indicate
	| Non-DTN | | Response		| Non-DTN | | Response
	~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~		~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~
	V DTN V |		V DTN V |
	++------------++ ++------------++		++------------++ ++------------++
	|| Admin Elem.|| || Admin Elem.||-+		|| Admin Elem.|| || Admin Elem.||-+
	|+------------+| (3) Challenge |+------------+| |		|+------------+| (3) Challenge |+------------+| |
	| Client's |&lt;------------- Bundle -----| Server's | |		| Client's |<------------- Bundle -----| Server's | |
	| BP Agent | | BP Agent | |		| BP Agent | | BP Agent | |
	+--------------+ +--------------+ |		+--------------+ +--------------+ |
	| +----^---------+		| +----^---------+
	| +-------------+ |		| +-------------+ |
	| | Integrity | (4) Response |		| | Integrity | (4) Response |
	+----&gt;| Gateway |------ Bundle --------+		+---->| Gateway |------ Bundle --------+
	+-------------+		+-------------+
	</artwork>		]]></artwork>
	</figure>		</figure>
	<t>		<t>
	Because the DTN Node ID is used both for routing bundles between BP agents and f		Because the DTN Node ID is used both for routing Bundles between BP Agents and f
	or multiplexing administrative services within a BP agent, there is no possibili		or multiplexing administrative services within a BP Agent, there is no possibili
	ty to separate the ACME validation of a Node ID from normal bundle handling for		ty to separate the ACME validation of a Node ID from normal Bundle handling for
	that same Node ID.		that same Node ID.
	This leaves administrative record types as a way to keep the Node ID unchanged w		This leaves administrative record types as a way to keep the Node ID unchanged w
	hile disambiguating from other service data bundles.		hile disambiguating from other service data Bundles.
	</t>		</t>
	<t>		<t>
	There is nothing in this protocol which requires network-topological co-location		There is nothing in this protocol that requires network-topological co-location
	of either the ACME client or ACME server with their associated BP agent.		of either the ACME client or ACME server with their respective associated BP Age
	While ACME requires a low-enough latency network to perform HTTPS exchanges betw		nt.
	een ACME client and server, the client's BP agent (the one being validated) coul		While ACME requires a low-enough latency network to perform HTTPS exchanges betw
	d be on the far side of a long-delay or multi-hop BP network.		een the ACME client and server, the client's BP Agent (the one being validated)
	The means by which the ACME client or server communicates with its associated BP		could be on the far side of a long-delay or multi-hop BP network.
	agent is an implementation matter.		The means by which the ACME client or server communicates with its associated BP
			Agent is an implementation matter.
	</t>		</t>
	</section>		</section>
	<section>		<section>
	<name>Use of CDDL</name>		<name>Use of CDDL</name>
	<t>		<t>
	This document defines CBOR structure using the Concise Data Definition Language (CDDL) of <xref target="RFC8610"/>.		This document defines Concise Binary Object Representation (CBOR) structure usin g the Concise Data Definition Language (CDDL) <xref target="RFC8610"/>.
	The entire CDDL structure can be extracted from the XML version of this document using the XPath expression:		The entire CDDL structure can be extracted from the XML version of this document using the XPath expression:
	</t>		</t>
	<sourcecode>'//sourcecode[@type="cddl"]'</sourcecode>		<sourcecode><![CDATA['//sourcecode[@type="cddl"]']]></sourcecode>
	<t>		<t>
	The following initial fragment defines the top-level symbols of this document's CDDL, which includes the example CBOR content.		The following initial fragment defines the top-level symbols of this document's CDDL, which includes the example CBOR content.
	</t>		</t>
	<sourcecode type="cddl">		<sourcecode type="cddl"><![CDATA[
	start = acme-record / bundle / tstr		start = acme-record / bundle / tstr
	</sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="sec-terminology">		<section anchor="sec-terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>		<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	HOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	ment are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	target="RFC8174"/> when, and only when, they appear in all capitals, as shown h		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	ere.		"<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>		</t>
	<t>		<t>
	Because this document combines two otherwise unrelated contexts, ACME and DTN, w hen a protocol term applies to one of those areas and is used in the other its n ame is prefixed with either "ACME" or "DTN" respectively.		Because this document combines two otherwise unrelated contexts, ACME and DTN, w hen a protocol term applies to one of those areas and is used in the other its n ame is prefixed with either "ACME" or "DTN" respectively.
	Thus within the ACME context the term is "DTN Node ID" while in the DTN context the name is just "Node ID".		Thus, within the ACME context the term is "DTN Node ID" while in the DTN context the name is just "Node ID".
	</t>		</t>
	<t>		<t>
	In this document, several terms are shortened for the sake of terseness.		In this document, several terms are shortened for the sake of brevity.
	These terms are:		These terms are as follows:
	</t>		</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Challenge Object:</dt>		<dt>Challenge Object:</dt>
	<dd>		<dd>
	This is a shortened form of the full "DTN Node ID Challenge Object".		This is a shortened form of the full "DTN Node ID Challenge Object".
	It is a JSON object created by the ACME server for challenge type "bp-nodeid-00" as defined in <xref target="sec-nodeid-challenge-obj"/>.		It is a JSON object created by the ACME server for challenge type "bp-nodeid-00" as defined in <xref target="sec-nodeid-challenge-obj"/>.
	</dd>		</dd>
	<dt>Response Object:</dt>		<dt>Response Object:</dt>
	<dd>		<dd>
	This is a shortened form of the full "DTN Node ID Response Object".		This is a shortened form of the full "DTN Node ID Response Object".
	It is a JSON object created by the ACME client to authorize a challenge type "bp -nodeid-00" as defined in <xref target="sec-nodeid-response-obj"/>.		It is a JSON object created by the ACME client to authorize a challenge type "bp -nodeid-00" as defined in <xref target="sec-nodeid-response-obj"/>.
	</dd>		</dd>
	<dt>Challenge Bundle:</dt>		<dt>Challenge Bundle:</dt>
	<dd>		<dd>
	This is a shortened form of the full "ACME Node ID Validation Challenge Bundle".		This is a shortened form of the full "ACME Node ID Validation Challenge Bundle".
	It is a Bundle created by the BP agent managed by the ACME server to challenge a Node ID claim as defined in <xref target="sec-bundle-challenge"/>.		It is a Bundle created by the BP Agent managed by the ACME server to challenge a Node ID claim as defined in <xref target="sec-bundle-challenge"/>.
	</dd>		</dd>
	<dt>Response Bundle:</dt>		<dt>Response Bundle:</dt>
	<dd>		<dd>
	This is a shortened form of the full "ACME Node ID Validation Response Bundle".		This is a shortened form of the full "ACME Node ID Validation Response Bundle".
	It is a Bundle created by the BP agent managed by the ACME client to validate a Node ID claim as defined in <xref target="sec-bundle-response"/>.		It is a Bundle created by the BP Agent managed by the ACME client to validate a Node ID claim as defined in <xref target="sec-bundle-response"/>.
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	Because this is an ACME document, the following DTN Bundle Protocol terms are de fined here to clarify how they are used by this ACME identifier type and validat ion mechanism.		Because this is a document produced by the ACME WG, the following DTN BP terms a re defined here to clarify how they are used by this ACME identifier type and va lidation mechanism.
	</t>		</t>
	<dl>		<dl spacing="normal" newline="false">
	<dt anchor="term-endpoint-id">Endpoint ID:</dt>		<dt anchor="term-endpoint-id">Endpoint ID:</dt>
	<dd>		<dd>
	An Endpoint ID is an identifier for the ultimate destination of a bundle, indepe		An EID is an identifier for the ultimate destination of a Bundle, independent of
	ndent of any intermediate forwarding needed to reach that destination.		any intermediate forwarding needed to reach that destination.
	An endpoint can be a singleton or not, so an Endpoint ID can also represent a si		An endpoint can be a singleton or not, so an EID can also represent a single ent
	ngle entity or a set of entities.		ity or a set of entities.
	This is formally defined in <xref section="4.2.5.1" target="RFC9171"/>.		This is formally defined in <xref section="4.2.5.1" target="RFC9171"/>.
	</dd>		</dd>
	<dt anchor="term-node-id">Node ID:</dt>		<dt anchor="term-node-id">Node ID:</dt>
	<dd>		<dd>
	A Node ID is a (not guaranteed unique) identifier for a specific node in a netwo		A Node ID is an identifier (that is not guaranteed to be unique) for a specific
	rk in the form of a singleton Endpoint ID.		node in a network in the form of a singleton EID.
	A single node can have any number of Node IDs but a typical (and expected) form		A single node can have any number of Node IDs, but a typical (and expected) form
	of Node ID is the Administrative Endpoint ID (described below).		of Node ID is the Administrative EID (described below).
	This is formally defined in <xref section="4.2.5.2" target="RFC9171"/>.		This is formally defined in <xref section="4.2.5.2" target="RFC9171"/>.
	</dd>		</dd>
	<dt anchor="term-admin-eid">Administrative Endpoint ID:</dt>		<dt anchor="term-admin-eid">Administrative EID:</dt>
	<dd>		<dd>
	An Administrative Endpoint ID is unique for a node within a specific URI scheme.		An Administrative EID is unique for a node within a specific URI scheme.
	Although any Node ID can be a valid bundle Source and Destination, the Administr		Although any Node ID can be a valid Bundle Source and Destination, the Administr
	ative Endpoint ID is a minimum required Node ID for any node operating in a part		ative EID is a minimum required Node ID for any node operating in a particular U
	icular URI scheme.		RI scheme.
	For the "dtn" scheme this is the empty demux part and for the "ipn" scheme this		For the "dtn" scheme, this is the empty demux part; for the "ipn" scheme, this i
	is the service number zero.		s the service number zero.
	These is formally defined under <xref section="4.2.5.1" target="RFC9171"/>.		These are formally defined under <xref section="4.2.5.1" target="RFC9171"/>.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="sec-experiment">		<section anchor="sec-experiment">
	<name>Experiment Scope</name>		<name>Experiment Scope</name>
	<t>		<t>
	The emergent properties of DTN naming and BP security are still being developed		The emergent properties of DTN naming and BP security are still being developed
	and explored, especially between different organizational and administrative dom		and explored, especially between different organizational and administrative dom
	ains, so the "experimental" status of this document is related more to the pract		ains. Thus, the Experimental status of this document is related more to the pra
	ical utility of this kind of Node ID validation than to the validation method it		ctical utility of this kind of Node ID validation than to the validation method
	self.		itself.
	The original use case is in large or cross-organizational networks where a BP no		The original use case is in large or cross-organizational networks where a BP No
	de can be trusted to be allocated and added to a network, but the method of cert		de can be trusted to be allocated and added to a network, but the method of cert
	ificate validation and issuance is desired to be in-band on the network rather t		ificate validation and issuance is desired to be in-band on the network rather t
	han configured solely through a side channel using bespoke or manual protocols.		han configured solely through a side channel using bespoke or manual protocols.
	Because this mechanism is so similar to other validation methods, specifically <		Because this mechanism is so similar to other validation methods, specifically e
	xref target="RFC8823"/>, it is expected to have few implementation difficulties		mail address validation <xref target="RFC8823"/>, it is expected to have few imp
	or interoperability issues.		lementation difficulties or interoperability issues.
	</t>		</t>
	<t>		<t>
	Part of the experimental nature of the validation method defined in <xref target ="sec-validate-nodeid"/>, and BP more generally, is understanding its vulnerabil ity to different kinds of on-path attacks.		Part of the experimental nature of the validation method defined in <xref target ="sec-validate-nodeid"/>, and BP more generally, is understanding its vulnerabil ity to different kinds of on-path attacks.
	Some attacks could be based on the topology of the BP overlay network, while oth		Some attacks could be based on the topology of the BP overlay network, while oth
	ers could be based on the underlying (internet protocol) network topology.		ers could be based on the underlying (IP) network topology.
	Because not all of the attack surfaces of this validation method are known or fu		Because not all of the attack surfaces of this validation method are known or fu
	lly understood the usefulness of the multi-perspective technique described in <x		lly understood, the usefulness of the multi-perspective technique described in <
	ref target="sec-multi-perspective"/> is also not assured.		xref target="sec-multi-perspective"/> is also not assured.
	The point of those multi-perspective requirements is so that both the ACME clien		The point of those multi-perspective requirements is that both the ACME client a
	t and server have consistent logic for handling the technique.		nd server have consistent logic for handling the technique.
	</t>		</t>
	<t>		<t>
	The usefulness of the integrity gateway defined in <xref target="sec-bib-gateway		The usefulness of the integrity gateway defined in <xref target="sec-bib-gateway
	"/> to this validation method is experimental because it is not a settled matter		"/> to this validation method is experimental: the way that naming authority in
	how naming authority in a DTN is either allocated, delegated, or enforced.		a DTN is either allocated, delegated, or enforced is not a settled matter. How
	It is also not defined how the organization running the CA (and its ACME server)		the organization running the CA (and its ACME server) can delegate some level of
	can delegate some level of trust to a different organization running a connecte		trust to a different organization running a connected DTN with a security gatew
	d DTN with a security gateway.		ay is also not defined.
	The organization running the integrity gateway would need to apply some minimal		The organization running the integrity gateway would need to apply some minimal
	amount of policy to nodes running behind it, such as patterns to their Node IDs,		amount of policy to nodes running behind it, such as patterns to their Node IDs,
	which would behave conceptually similar to delegation of sub-domains in the dom		which would behave conceptually similar to delegation of subdomains in the Doma
	ain name system (DNS) but without the online interaction of DNS.		in Name System (DNS), but without the online interaction of DNS.
	</t>		</t>
	<t>		<t>
	A successful experiment of this validation method would involve using the ACME p rotocol along with this Node ID validation to allow issuing of identity certific ates across administrative domains.		A successful experiment of this validation method would involve using the ACME p rotocol along with this Node ID validation to allow issuing of identity certific ates across administrative domains.
	One possible scenario for this would be an issuing CA and an ACME server on the		One possible scenario for this would be an issuing CA and an ACME server on the
	edge of a BP transit network operated by one agency, which is accessed via edge		edge of a BP transit network operated by some agency.
	routers operated by a second agency, used by edge nodes known to and trusted by		This transit network is used by edge nodes and accessed via edge routers of a pe
	the second agency but not the first.		er network operated by a second agency.
	The transit network can refuse to route traffic that is not traceable to a valid		The nodes of the peer network are trusted by the second agency but not the first
	identity certificate, which the edge nodes can obtain via the ACME server.		.
			The transit network can refuse to route traffic from the peer network that is no
			t traceable to a valid identity certificate, which the edge nodes can obtain via
			the ACME server.
	</t>		</t>
	<t>		<t>
	A valuable result from any experiment, even unsuccessful, would be feedback abou		A valuable result from any experiment, even an unsuccessful one, would be feedba
	t this method to improve later versions.		ck about this method to improve later versions.
	That feedback could include improvements to object or message structure, random		That feedback could include improvements to object or message structure, random
	vs. deterministic token values, client or server procedures, or naming more gene		versus deterministic token values, client or server procedures, or naming more g
	rally.		enerally.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-acme-uri">		<section anchor="sec-acme-uri">
	<name>Bundle Endpoint ID ACME Identifier</name>		<name>Bundle EID ACME Identifier</name>
	<t>		<t>
	This specification is the first to make use of a Bundle Endpoint ID to identify		This specification is the first to make use of a Bundle EID to identify a claim
	a claim for a certificate request in ACME.		for a certificate request in ACME.
	In this document, the only purpose for which a Bundle Endpoint ID ACME identifie		In this document, the only purpose for which a Bundle EID ACME identifier is val
	r is validated is as a DTN Node ID (see <xref target="sec-validate-nodeid"/>), b		idated is as a DTN Node ID (see <xref target="sec-validate-nodeid"/>), but other
	ut other specifications can define challenge types for other Endpoint ID uses.		specifications can define challenge types for other EID uses.
	</t>		</t>
	<t>		<t>
	Every identifier of type "bundleEID" <bcp14>SHALL</bcp14> have a value containin		Every ACME identifier type "bundleEID" <bcp14>SHALL</bcp14> have a value contain
	g a text URI consistent with the requirements of <xref section="4.2.5.1" target=		ing a text URI consistent with the requirements of <xref section="4.2.5.1" targe
	"RFC9171"/> using one of the schemes available from the "Bundle Protocol URI Sch		t="RFC9171"/> using one of the schemes available from the "Bundle Protocol URI S
	eme Types" registry of <xref target="IANA-BP"/>.		cheme Types" registry <xref target="IANA-BP"/>.
	Any "bundleEID" value which fails to properly percent-decode <bcp14>SHALL</bcp14		Any identifier type "bundleEID" value that fails to properly percent-decode <bcp
	> be rejected with an ACME error type of "malformed".		14>SHALL</bcp14> be rejected with an ACME error type of "malformed".
	</t>		</t>
	<t>		<t>
	An ACME server supporting identifiers of type "bundleEID" <bcp14>SHALL</bcp14> d		An ACME server supporting identifier type "bundleEID" <bcp14>SHALL</bcp14> decod
	ecode and normalize (based on scheme-specific syntax) all such received identifi		e and normalize (based on scheme-specific syntax) all such received identifier v
	ers.		alues.
	Any "bundleEID" value for which the scheme-specific part does not match the sche		Any identifier type "bundleEID" value for which the scheme-specific part does no
	me-specific syntax <bcp14>SHALL</bcp14> be rejected with an ACME error type of "		t match the scheme-specific syntax <bcp14>SHALL</bcp14> be rejected with an ACME
	malformed".		error type of "malformed".
	Any "bundleEID" value which uses a scheme not handled by the ACME server <bcp14>		Any identifier type "bundleEID" value that uses a scheme not handled by the ACME
	SHALL</bcp14> be rejected with an ACME error type of "rejectedIdentifier".		server <bcp14>SHALL</bcp14> be rejected with an ACME error type of "rejectedIde
			ntifier".
	</t>		</t>
	<t>		<t>
	When an ACME server needs to request proof that a client controls a Bundle EID, it <bcp14>SHALL</bcp14> create an authorization with the identifier type "bundle EID".		When an ACME server needs to request proof that a client controls a Bundle EID, it <bcp14>SHALL</bcp14> create an authorization with the identifier type "bundle EID".
	An ACME server <bcp14>SHALL NOT</bcp14> attempt to dereference a Bundle EID valu e on its own.		An ACME server <bcp14>SHALL NOT</bcp14> attempt to dereference a Bundle EID valu e on its own.
	It is the responsibility of an ACME validation method to ensure the EID ownershi p using a method authorized by the ACME client.		It is the responsibility of an ACME validation method to ensure the EID ownershi p using a method authorized by the ACME client.
	</t>		</t>
	<t keepWithNext="true">		<t>
	An identifier for the Node ID of "dtn://example/" would be formatted as:		An identifier for the Node ID of "dtn://example/" would be formatted as:
	</t>		</t>
	<sourcecode type="json">		<sourcecode type="json"><![CDATA[
	{		{
	"type": "bundleEID",		"type": "bundleEID",
	"value": "dtn://example/"		"value": "dtn://example/"
	}		}]]></sourcecode>
	</sourcecode>
	<section anchor="sec-eid-uses">		<section anchor="sec-eid-uses">
	<name>Subsets of Bundle Endpoint ID</name>		<name>Subsets of Bundle EID</name>
	<t>		<t>
	While the PKIX other name form of <tt>BundleEID</tt> can hold any Endpoint ID va		A PKIX certificate SAN identity containing an Other Name form of <tt>BundleEID</
	lue, the certificate profile used by <xref target="RFC9174"/> and supported by t		tt> can hold any EID value (as a text URI).
	his ACME validation method in <xref target="sec-validate-nodeid"/> requires that		But the certificate profile used by the TCP Convergence Layer <xref target="RFC9
	the value hold a <xref target="term-node-id">Node ID</xref>.		174"/> and supported by the ACME validation method in <xref target="sec-validate
			-nodeid"/> requires that the value hold a Node ID (<xref target="term-node-id"><
			/xref>).
	</t>		</t>
	<t>		<t>
	In addition to the narrowing of that certificate profile, this validation method		In addition to the narrowing of that certificate profile, this validation method
	requires that the client's BP agent responds to administrative records sent to		requires that the client's BP Agent respond to administrative records sent to t
	the Node ID being validated.		he Node ID being validated.
	This typically is limited to an <xref target="term-admin-eid">Administrative End		Typically, this is limited to an Administrative EID (<xref target="term-admin-ei
	point ID</xref>, but there is no prohibition on the administrative element of a		d"></xref>) destination.
	BP node from receiving administrative records for, and sending records from, oth		However, the administrative element of a BP Node is not prohibited from receivin
	er Node IDs in order to support this validation method.		g administrative records for, or sending records from, other Node IDs in order t
			o support this validation method.
	</t>		</t>
	<t>		<t>
	Neither that certificate profile nor this validation method support operating on non-singleton Endpoint IDs, but other validation methods could be defined to do so in order to support other certificate profiles.		Neither that certificate profile nor this validation method support operating on non-singleton EIDs, but other validation methods could be defined to do so in o rder to support other certificate profiles.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-validate-nodeid">		<section anchor="sec-validate-nodeid">
	<name>DTN Node ID Validation</name>		<name>DTN Node ID Validation</name>
	<t>		<t>
	The DTN Node ID validation method proves control over a Node ID by requiring the ACME client to configure a BP agent to respond to specific Challenge Bundles se nt from the ACME server.		The DTN Node ID validation method proves control over a Node ID by requiring the ACME client to configure a BP Agent to respond to specific Challenge Bundles se nt from the ACME server.
	The ACME server validates control of the Node ID by verifying that received Resp onse Bundles correspond with the BP Node and client account key being validated.		The ACME server validates control of the Node ID by verifying that received Resp onse Bundles correspond with the BP Node and client account key being validated.
	</t>		</t>
	<t>		<t>
	Similar to the ACME use case for validating email address ownership <xref target		Similar to the ACME use case for email-address validation <xref target="RFC8823"
	="RFC8823"/>, this challenge splits the token into several parts, each being tra		/>, this challenge splits the token into several parts, each part being transpor
	nsported by a different channel, and the Key Authorization result requires combi		ted by a different channel, and the Key Authorization result requires combining
	ning all parts of the token.		all parts of the token.
	A separate challenge identifier is used as a filter by BP agents similarly to th		A separate challenge identifier is used as a filter by BP Agents similar to the
	e challenge "from" email address of <xref target="RFC8823"/>.		challenge "from" used by email validation in <xref section="3" target="RFC8823"/
			>.
	</t>		</t>
	<t>		<t>
	The token parts are:		The token parts are as follows:
	</t>		</t>
	<dl>		<dl spacing="normal" newline="true">
	<dt>		<dt>
	<tt>token-chal</tt>:		<tt>token-chal</tt>:
	</dt>		</dt>
	<dd>		<dd>
	This token is unique to each ACME authorization.		This token is unique to each ACME authorization.
	It is contained in the Challenge Object of <xref target="sec-nodeid-challenge-ob j"/>.		It is contained in the Challenge Object of <xref target="sec-nodeid-challenge-ob j"/>.
	Each authorization can consist of multiple Challenge Bundles (e.g. taking differ ent routes), but they all share the same <tt>token-chal</tt> value.		Each authorization can consist of multiple Challenge Bundles (e.g., taking diffe rent routes), but they all share the same <tt>token-chal</tt> value.
	This ensures that the Key Authorization is bound to the specific ACME challenge (and parent ACME authorization).		This ensures that the Key Authorization is bound to the specific ACME challenge (and parent ACME authorization).
	This token does not appear on the BP channel so that any eavesdropper knowing th e client's account key thumbprint (e.g. from some other validation method) is no t able to impersonate the client.		This token does not appear on the BP channel; thus, any eavesdropper knowing the client's account key thumbprint (e.g., from some other validation method) is no t able to impersonate the client.
	</dd>		</dd>
	<dt>		<dt>
	<tt>token-bundle</tt>:		<tt>token-bundle</tt>:
	</dt>		</dt>
	<dd>		<dd>
	This token is unique to each Challenge Bundle sent by the ACME server.		This token is unique to each Challenge Bundle sent by the ACME server.
	It is contained in the Challenge Bundle of <xref target="sec-bundle-challenge"/> and Response Bundle of <xref target="sec-bundle-response"/>.		It is contained in the Challenge Bundle of <xref target="sec-bundle-challenge"/> and Response Bundle of <xref target="sec-bundle-response"/>.
	This ensures that the Key Authorization is bound to the ability to receive the C hallenge Bundle and not just have access to the ACME Challenge Object.		This ensures that the Key Authorization is bound to the ability to receive the C hallenge Bundle and not just having access to the ACME Challenge Object.
	This token is also accessible to DTN on-path eavesdroppers.		This token is also accessible to DTN on-path eavesdroppers.
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	Because multiple Challenge Bundles can be sent to validate the same Node ID, the <tt>token-bundle</tt> in the response is needed to correlate with the expected Key Authorization digest.		Because multiple Challenge Bundles can be sent to validate the same Node ID, the <tt>token-bundle</tt> in the response is needed to correlate with the expected Key Authorization digest.
	</t>		</t>
	<t>		<t>
	The DTN Node ID Challenge <bcp14>SHALL</bcp14> only be allowed for an EID usable		The DTN Node ID Challenge Object <bcp14>SHALL</bcp14> only be allowed for an EID
	as a DTN Node ID, which is defined per-scheme in <xref section="4.2.5.1" target		usable as a DTN Node ID, which is defined per-scheme in <xref section="4.2.5.1"
	="RFC9171"/>.		target="RFC9171"/>.
	When an ACME server supports Node ID validation, the ACME server <bcp14>SHALL</b		When an ACME server supports Node ID validation, the ACME server <bcp14>SHALL</b
	cp14> provide a challenge object in accordance with <xref target="sec-nodeid-cha		cp14> provide a Challenge Object in accordance with <xref target="sec-nodeid-cha
	llenge-obj"/>.		llenge-obj"/>.
	Once this challenge object is defined, the ACME client may begin the validation.		Once this Challenge Object is defined, the ACME client may begin the validation.
	</t>		</t>
	<t>		<t>
	To initiate a Node ID validation, the ACME client performs the following steps:		To initiate a Node ID validation, the ACME client performs the following steps:
	</t>		</t>
	<ol type="1">		<ol type="1">
	<li>		<li>
	The ACME client POSTs a newOrder or newAuthz request including the identifier of		The ACME client POSTs a newOrder or newAuthz request including the identifier ty
	type "bundleEID" for the desired Node ID.		pe "bundleEID" for the desired Node ID.
	From either of these entry points an authorization for the "bundleEID" type is i		From either of these entry points, an authorization for the identifier type "bun
	ndicated by the ACME server.		dleEID" is indicated by the ACME server.
	See <xref section="7.4" target="RFC8555"/> for more details.		See <xref section="7.4" target="RFC8555"/> for more details.
	</li>		</li>
	<li>		<li>
	The ACME client obtains the <tt>id-chal</tt> and <tt>token-chal</tt> from the <x ref target="sec-nodeid-challenge-obj">challenge object</xref> contained in an au thorization object associated with the order in accordance with <xref section="7 .1.4" target="RFC8555"/>.		The ACME client obtains the <tt>id-chal</tt> and <tt>token-chal</tt> from the Ch allenge Object (<xref target="sec-nodeid-challenge-obj"></xref>) contained in a n authorization object associated with the order in accordance with <xref sectio n="7.1.4" target="RFC8555"/>.
	</li>		</li>
	<li anchor="step-client-authorize">		<li anchor="step-client-authorize">
	The ACME client indicates to the administrative element of its BP agent the <tt>		The ACME client indicates to the administrative element of its BP Agent the <tt>
	id-chal</tt> which is authorized for use along with the associated <tt>token-cha		id-chal</tt> that is authorized for use along with the associated <tt>token-chal
	l</tt> and client account key thumbprint.		</tt> and client account key thumbprint.
	The ACME client waits, if necessary, until the agent is configured before procee		The ACME client waits, if necessary, until the Agent is configured before procee
	ding to the next step.		ding to the next step.
	</li>		</li>
	<li>		<li>
	The ACME client POSTs a <xref target="sec-nodeid-response-obj">response object</ xref> to the challenge URL on the ACME server accordance with <xref section="7.5 .1" target="RFC8555"/>.		The ACME client POSTs a response object (<xref target="sec-nodeid-response-obj"> </xref>) to the challenge URL on the ACME server in accordance with <xref sectio n="7.5.1" target="RFC8555"/>.
	The payload object is constructed in accordance with <xref target="sec-nodeid-re sponse-obj"/>.		The payload object is constructed in accordance with <xref target="sec-nodeid-re sponse-obj"/>.
	</li>		</li>
	<li>		<li>
	The administrative element waits for a Challenge Bundle to be received with the authorized ACME parameters, including its <tt>id-chal</tt> payload, in accordanc e with <xref target="sec-bundle-challenge"/>.		The administrative element waits for a Challenge Bundle to be received with the authorized ACME parameters, including its <tt>id-chal</tt> payload, in accordanc e with <xref target="sec-bundle-challenge"/>.
	</li>		</li>
	<li>		<li>
	The administrative element concatenates <tt>token-bundle</tt> with <tt>token-cha l</tt> (each as base64url-encoded text strings) and computes the Key Authorizati on in accordance with <xref section="8.1" target="RFC8555"/> using the full toke n and client account key thumbprint.		The administrative element concatenates <tt>token-bundle</tt> with <tt>token-cha l</tt> (each as base64url-encoded text strings) and computes the Key Authorizati on in accordance with <xref section="8.1" target="RFC8555"/> using the full toke n and client account key thumbprint.
	</li>		</li>
	<li>		<li>
	The administrative element chooses the highest-priority hash algorithm supported by both the client and server, uses that algorithm to compute the digest of the Key Authorization result, and generates a Response Bundle to send back to the A CME server in accordance with <xref target="sec-bundle-response"/>.		The administrative element chooses the highest-priority hash algorithm supported by both the client and server, uses that algorithm to compute the digest of the Key Authorization result, and generates a Response Bundle to send back to the A CME server in accordance with <xref target="sec-bundle-response"/>.
	</li>		</li>
	<li>		<li>
	The ACME client waits for the authorization to be finalized on the ACME server i n accordance with <xref section="7.5.1" target="RFC8555"/>.		The ACME client waits for the authorization to be finalized on the ACME server i n accordance with <xref section="7.5.1" target="RFC8555"/>.
	</li>		</li>
	<li>		<li>
	Once the challenge is completed (successfully or not), the ACME client indicates		Once the challenge is completed (successfully or not), the ACME client indicates
	to the BP agent that the <tt>id-chal</tt> is no longer usable.		to the BP Agent that the <tt>id-chal</tt> is no longer usable.
	If the authorization fails, the ACME client <bcp14>MAY</bcp14> retry the challen		If the authorization fails, the ACME client <bcp14>MAY</bcp14> retry the challen
	ge from Step&nbsp;<xref format="counter" target="step-client-authorize"/>.		ge from Step <xref format="counter" target="step-client-authorize"/>.
	</li>		</li>
	</ol>		</ol>
	<t>		<t>
	The ACME server verifies the client's control over a Node ID by performing the f ollowing steps:		The ACME server verifies the client's control over a Node ID by performing the f ollowing steps:
	</t>		</t>
	<ol type="1">		<ol type="1">
	<li>		<li>
	The ACME server receives a newOrder or newAuthz request including the identifier of type "bundleEID", where the URI value is a Node ID.		The ACME server receives a newOrder or newAuthz request including the identifier type "bundleEID", where the URI value is a Node ID.
	</li>		</li>
	<li>		<li>
	The ACME server generates an authorization for the Node ID with challenge type " bp-nodeid-00" in accordance with <xref target="sec-nodeid-challenge-obj"/>.		The ACME server generates an authorization for the Node ID with challenge type " bp-nodeid-00" in accordance with <xref target="sec-nodeid-challenge-obj"/>.
	</li>		</li>
	<li anchor="step-server-authorize">		<li anchor="step-server-authorize">
	The ACME server receives a POST to the challenge URL indicated from the authoriz ation object.		The ACME server receives a POST to the challenge URL indicated from the authoriz ation object.
	The payload is handled in accordance with <xref target="sec-nodeid-response-obj" />.		The payload is handled in accordance with <xref target="sec-nodeid-response-obj" />.
	</li>		</li>
	<li>		<li>
	The ACME server sends, via the administrative element of its BP agent, one or mo		The ACME server sends, via the administrative element of its BP Agent, one or mo
	re Challenge Bundles in accordance with <xref target="sec-bundle-challenge"/>.		re Challenge Bundles in accordance with <xref target="sec-bundle-challenge"/>.
	Each challenge bundle contains a distinct, random <tt>token-bundle</tt> to be ab		Each Challenge Bundle contains a distinct, random <tt>token-bundle</tt> to be ab
	le to correlate with a response bundle.		le to correlate with a Response Bundle.
	Computing an expected Key Authorization digest is not necessary until a response is received with a chosen hash algorithm.		Computing an expected Key Authorization digest is not necessary until a response is received with a chosen hash algorithm.
	</li>		</li>
	<li>		<li>
	The ACME server waits for Response Bundle(s) for a limited interval of time (bas ed on the response object of <xref target="sec-nodeid-response-obj"/>).		The ACME server waits for a Response Bundle(s) for a limited interval of time (b ased on the response object of <xref target="sec-nodeid-response-obj"/>).
	Responses are encoded in accordance with <xref target="sec-bundle-response"/>.		Responses are encoded in accordance with <xref target="sec-bundle-response"/>.
	</li>		</li>
	<li>		<li>
	Once received and decoded, the ACME server checks the contents of each Response Bundle in accordance with <xref target="sec-response-check"/>.		Once received and decoded, the ACME server checks the contents of each Response Bundle in accordance with <xref target="sec-response-check"/>.
	After all Challenge Bundles have either been responded to or timed-out, the ACME server policy (see <xref target="sec-multi-perspective"/>) determines whether t he validation is successful.		After all Challenge Bundles have either been responded to or timed-out, the ACME server policy (see <xref target="sec-multi-perspective"/>) determines whether t he validation is successful.
	If validation is not successful, a client may retry the challenge which starts i n Step&nbsp;<xref format="counter" target="step-server-authorize"/>.		If validation is not successful, a client may retry the challenge that starts in Step <xref format="counter" target="step-server-authorize"/>.
	</li>		</li>
	</ol>		</ol>
	<t>		<t>
	When responding to a Challenge Bundle, a BP agent <bcp14>SHALL</bcp14> send a si		When responding to a Challenge Bundle, a BP Agent <bcp14>SHALL</bcp14> send a si
	ngle Response Bundle in accordance with <xref target="sec-bundle-response"/>.		ngle Response Bundle in accordance with <xref target="sec-bundle-response"/>.
	A BP agent <bcp14>SHALL</bcp14> respond to ACME challenges only within the inter		A BP Agent <bcp14>SHALL</bcp14> respond to ACME challenges only within the inter
	val of time and only for the <tt>id-chal</tt> indicated by the ACME client.		val of time and only for the <tt>id-chal</tt> indicated by the ACME client.
	A BP agent <bcp14>SHALL</bcp14> respond to multiple Challenge Bundles with the s		A BP Agent <bcp14>SHALL</bcp14> respond to multiple Challenge Bundles with the s
	ame ACME parameters but different bundle identities (source Node ID and timestam		ame ACME parameters but different Bundle identities (source Node ID and timestam
	p); these correspond with the ACME server validating via multiple routing paths.		p); these correspond with the ACME server validating via multiple routing paths.
	</t>		</t>
	<section anchor="sec-nodeid-challenge-obj">		<section anchor="sec-nodeid-challenge-obj">
	<name>DTN Node ID Challenge Object</name>		<name>DTN Node ID Challenge Object</name>
	<t>		<t>
	The DTN Node ID Challenge object is included by the ACME server as defined in <x ref section="7.5" target="RFC8555"/> when it supports validating Node IDs.		The DTN Node ID Challenge Object is included by the ACME server as defined in <x ref section="7.5" target="RFC8555"/> when it supports validating Node IDs.
	</t>		</t>
	<t>		<t>
	The DTN Node ID Challenge object has the following content:		The DTN Node ID Challenge Object has the following content:
	</t>		</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>type (required, string):</dt>		<dt>type (required, string):</dt>
	<dd>		<dd>
	The string "bp-nodeid-00".		The string "bp-nodeid-00".
	</dd>		</dd>
	<dt>id-chal (required, string):</dt>		<dt>id-chal (required, string):</dt>
	<dd>		<dd>
	This is a random value associated with a challenge which allows a client to filt er valid <xref target="sec-bundle-challenge">Challenge Bundles</xref>.		This is a random value associated with a challenge that allows a client to filte r valid Challenge Bundles (<xref target="sec-bundle-challenge"></xref>).
	The same value is used for all Challenge Bundles associated with an ACME challen ge, including multi-perspective validation using multiple sources as described i n <xref target="sec-multi-perspective"/>.		The same value is used for all Challenge Bundles associated with an ACME challen ge, including multi-perspective validation using multiple sources as described i n <xref target="sec-multi-perspective"/>.
	This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.		This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.
	It <bcp14>SHALL NOT</bcp14> contain any characters outside the base64url alphabe t as described in <xref section="5" target="RFC4648"/>.		It <bcp14>SHALL NOT</bcp14> contain any characters outside the base64url alphabe t as described in <xref section="5" target="RFC4648"/>.
	Trailing '=' padding characters <bcp14>SHALL</bcp14> be stripped.		Trailing '=' padding characters <bcp14>SHALL</bcp14> be stripped.
	See <xref target="RFC4086"/> for additional information on randomness requiremen ts.		See BCP 106 <xref target="RFC4086"/> for additional information on randomness re quirements.
	</dd>		</dd>
	<dt>token-chal (required, string):</dt>		<dt>token-chal (required, string):</dt>
	<dd>		<dd>
	This is a random value, used as part of the Key Authorization algorithm, which i s communicated to the ACME client only over the ACME channel.		This is a random value, used as part of the Key Authorization algorithm, which i s communicated to the ACME client only over the ACME channel.
	This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.		This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.
	It <bcp14>SHALL NOT</bcp14> contain any characters outside the base64url alphabe t as described in <xref section="5" target="RFC4648"/>.		It <bcp14>SHALL NOT</bcp14> contain any characters outside the base64url alphabe t as described in <xref section="5" target="RFC4648"/>.
	Trailing '=' padding characters <bcp14>SHALL</bcp14> be stripped.		Trailing '=' padding characters <bcp14>SHALL</bcp14> be stripped.
	See <xref target="RFC4086"/> for additional information on randomness requiremen ts.		See BCP 106 <xref target="RFC4086"/> for additional information on randomness re quirements.
	</dd>		</dd>
	</dl>		</dl>
	<sourcecode type="json">		<sourcecode type="json"><![CDATA[
	{		{
	"type": "bp-nodeid-00",		"type": "bp-nodeid-00",
	"url": "https://example.com/acme/chall/prV_B7yEyA4",		"url": "https://example.com/acme/chall/prV_B7yEyA4",
	"id-chal": "dDtaviYTPUWFS3NK37YWfQ",		"id-chal": "dDtaviYTPUWFS3NK37YWfQ",
	"token-chal": "tPUZNY4ONIk6LxErRFEjVw"		"token-chal": "tPUZNY4ONIk6LxErRFEjVw"
	}		}]]></sourcecode>
	</sourcecode>
	<t>		<t>
	The <tt>token-chal</tt> value included in this object applies to the entire chal lenge, and may correspond with multiple separate <tt>token-bundle</tt> values wh en multiple Challenge Bundles are sent for a single validation.		The <tt>token-chal</tt> value included in this object applies to the entire chal lenge and may correspond with multiple separate <tt>token-bundle</tt> values whe n multiple Challenge Bundles are sent for a single validation.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-nodeid-response-obj">		<section anchor="sec-nodeid-response-obj">
	<name>DTN Node ID Response Object</name>		<name>DTN Node ID Response Object</name>
	<t>		<t>
	The DTN Node ID response object is sent by the ACME client when it authorizes va lidation of a Node ID as defined in <xref section="7.5.1" target="RFC8555"/>.		The DTN Node ID response object is sent by the ACME client when it authorizes va lidation of a Node ID as defined in <xref section="7.5.1" target="RFC8555"/>.
	Because a DTN has the potential for significantly longer (but roughly predictabl e) delays than a non-DTN network, the ACME client is able to inform the ACME ser ver if a particular validation round-trip is expected to take longer than non-DT N network delays (on the order of seconds).		Because a DTN has the potential for significantly longer (but roughly predictabl e) delays than a non-DTN network, the ACME client is able to inform the ACME ser ver if a particular validation round-trip is expected to take longer than non-DT N network delays (on the order of seconds).
	</t>		</t>
	<t>		<t>
	The DTN Node ID response object has the following content:		The DTN Node ID response object has the following content:
	</t>		</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>rtt (optional, number):</dt>		<dt>rtt (optional, number):</dt>
	<dd>		<dd>
	An expected round-trip time (RTT), in seconds, between sending a Challenge Bundl e and receiving a Response Bundle.		An expected Round-Trip Time (RTT), in seconds, between sending a Challenge Bundl e and receiving a Response Bundle.
	This value is a hint to the ACME server for how long to wait for responses but i s not authoritative.		This value is a hint to the ACME server for how long to wait for responses but i s not authoritative.
	The minimum RTT value <bcp14>SHALL</bcp14> be zero.		The minimum RTT value <bcp14>SHALL</bcp14> be zero.
	There is no special significance to zero-value RTT, it simply indicates the resp onse is expected in less than the least significant unit used by the ACME client .		There is no special significance to zero-value RTT, it simply indicates the resp onse is expected in less than the least significant unit used by the ACME client .
	</dd>		</dd>
	</dl>		</dl>
	<sourcecode type="json">		<sourcecode type="json"><![CDATA[
	{		{
	"rtt": 300.0		"rtt": 300.0
	}		}]]></sourcecode>
	</sourcecode>
	<t>		<t>
	A response object <bcp14>SHALL NOT</bcp14> be sent until the BP agent has been c onfigured to properly respond to the challenge.		A response object <bcp14>SHALL NOT</bcp14> be sent until the BP Agent has been c onfigured to properly respond to the challenge.
	The RTT value is meant to indicate any node-specific path delays expected to be encountered from the ACME server.		The RTT value is meant to indicate any node-specific path delays expected to be encountered from the ACME server.
	Because there is no requirement on the path (or paths) which bundles may travers e between the ACME server and the BP agent, and the ACME server can attempt some path diversity, the RTT value <bcp14>SHOULD</bcp14> be pessimistic.		Because there is no requirement on the path (or paths) regarding which Bundles m ay traverse between the ACME server and the BP Agent, and the ACME server can at tempt some path diversity, the RTT value <bcp14>SHOULD</bcp14> be pessimistic.
	</t>		</t>
	<t>		<t>
	A default bundle response interval, used when the object does not contain an RTT , <bcp14>SHOULD</bcp14> be a configurable parameter of the ACME server.		A default Bundle response interval, used when the object does not contain an RTT , <bcp14>SHOULD</bcp14> be a configurable parameter of the ACME server.
	If the ACME client indicated an RTT value in the object, the response interval < bcp14>SHOULD</bcp14> be twice the RTT (with limiting logic applied as described below).		If the ACME client indicated an RTT value in the object, the response interval < bcp14>SHOULD</bcp14> be twice the RTT (with limiting logic applied as described below).
	The lower limit on response interval is network-specific, but <bcp14>SHOULD NOT<		The lower limit on the response interval is network specific, but it <bcp14>SHOU
	/bcp14> be shorter than one second.		LD NOT</bcp14> be shorter than one second.
	The upper limit on response interval is network-specific, but <bcp14>SHOULD NOT<		The upper limit on response interval is network specific, but it <bcp14>SHOULD N
	/bcp14> be longer than one minute (60 seconds) for a terrestrial-only DTN.		OT</bcp14> be longer than one minute (60 seconds) for a terrestrial-only DTN.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-bundle-challenge">		<section anchor="sec-bundle-challenge">
	<name>ACME Node ID Validation Challenge Bundle</name>		<name>ACME Node ID Validation Challenge Bundle</name>
	<t>		<t>
	Each ACME Node ID Validation Challenge Bundle <bcp14>SHALL</bcp14> be structured and encoded in accordance with <xref target="RFC9171"/>.		Each ACME Node ID Validation Challenge Bundle <bcp14>SHALL</bcp14> be structured and encoded in accordance with BPv7 <xref target="RFC9171"/>.
	</t>		</t>
	<t>		<t>
	Each Challenge Bundle has parameters as listed here:		Each Challenge Bundle has parameters as listed here:
	</t>		</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Bundle Processing Control Flags:</dt>		<dt>Bundle Processing Control Flags:</dt>
	<dd>		<dd>
	The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an adm inistrative record.		The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an adm inistrative record.
	The primary block flags <bcp14>SHALL</bcp14> indicate that user application ackn owledgement is requested; this flag distinguishes the Challenge Bundle from the Response Bundle.		The primary block flags <bcp14>SHALL</bcp14> indicate that user application ackn owledgement is requested; this flag distinguishes the Challenge Bundle from the Response Bundle.
	</dd>		</dd>
	<dt>Destination EID:</dt>		<dt>Destination EID:</dt>
	<dd>		<dd>
	The Destination EID <bcp14>SHALL</bcp14> be the ACME-server-normalized Node ID b eing validated.		The Destination EID <bcp14>SHALL</bcp14> be the ACME-server-normalized Node ID b eing validated.
	</dd>		</dd>
	<dt>Source Node ID:</dt>		<dt>Source Node ID:</dt>
	<dd>		<dd>
	The Source Node ID <bcp14>SHALL</bcp14> indicate the Node ID of a BP agent of th e ACME server performing the challenge.		The Source Node ID <bcp14>SHALL</bcp14> indicate the Node ID of a BP Agent of th e ACME server performing the challenge.
	</dd>		</dd>
	<dt>Creation Timestamp and Lifetime:</dt>		<dt>Creation Timestamp and Lifetime:</dt>
	<dd>		<dd>
	The Creation Timestamp <bcp14>SHALL</bcp14> be set to the time at which the chal lenge was generated.		The Creation Timestamp <bcp14>SHALL</bcp14> be set to the time at which the chal lenge was generated.
	The Lifetime <bcp14>SHALL</bcp14> indicate the response interval (of <xref targe t="sec-nodeid-response-obj"/>) for which ACME server will accept responses to th is challenge.		The Lifetime <bcp14>SHALL</bcp14> indicate the response interval (of <xref targe t="sec-nodeid-response-obj"/>) for which the ACME server will accept responses t o this challenge.
	</dd>		</dd>
	<dt>Administrative Record Type Code:</dt>		<dt>Administrative Record Type Code:</dt>
	<dd>		<dd>
	Set to the ACME Node ID Validation type code defined in <xref target="sec-iana-b		This is set to the ACME Node ID Validation type code defined in <xref
	p-admin-type"/>.		target="sec-iana-bp-admin-type"/>.
	</dd>		</dd>
	<dt>Administrative Record Content:</dt>		<dt>Administrative Record Content:</dt>
	<dd>		<dd>
	<t>		<t>
	The Challenge Bundle administrative record content <bcp14>SHALL</bcp14> consist of a CBOR map containing the following three pairs:		The Challenge Bundle administrative record content <bcp14>SHALL</bcp14> consist of a CBOR map containing the following three pairs:
	</t>		</t>
	<ul>		<ul>
	<li>		<li>
	One pair <bcp14>SHALL</bcp14> consist of key 1 with value of ACME challenge <tt> id-chal</tt>, copied from the challenge object, represented as a CBOR byte strin g.		One pair <bcp14>SHALL</bcp14> consist of key 1 with a value of ACME challenge <t t>id-chal</tt>, copied from the Challenge Object, represented as a CBOR byte str ing.
	</li>		</li>
	<li>		<li>
	One pair <bcp14>SHALL</bcp14> consist of key 2 with value of ACME challenge <tt>		One pair <bcp14>SHALL</bcp14> consist of key 2 with a value of ACME challenge <t
	token-bundle</tt>, represented as a CBOR byte string.		t>token-bundle</tt>, represented as a CBOR byte string.
	The <tt>token-bundle</tt> is a random value that uniquely identifies the challen		The <tt>token-bundle</tt> is a random value that uniquely identifies the Challen
	ge bundle.		ge Bundle.
	This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.		This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.
	See <xref target="RFC4086"/> for additional information on randomness requiremen ts.		See BCP 106 <xref target="RFC4086"/> for additional information on randomness re quirements.
	</li>		</li>
	<li>		<li>
	One pair <bcp14>SHALL</bcp14> consist of key 4 with value of an array containing acceptable hash algorithm identifiers.		One pair <bcp14>SHALL</bcp14> consist of key 4 with a value of an array containi ng acceptable hash algorithm identifiers.
	The array <bcp14>SHALL</bcp14> be ordered in descending preference, with the fir st item being the most preferred.		The array <bcp14>SHALL</bcp14> be ordered in descending preference, with the fir st item being the most preferred.
	The array <bcp14>SHALL</bcp14> contain at least one item.		The array <bcp14>SHALL</bcp14> contain at least one item.
	Each algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (i nteger or text string) of the algorithm registered in the "COSE Algorithms" regi stry of <xref target="IANA-COSE"/>.		Each algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (i nteger or text string) of the algorithm registered in the "COSE Algorithms" regi stry <xref target="IANA-COSE"/>.
	</li>		</li>
	</ul>		</ul>
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	This structure is part of the extension CDDL in <xref target="sec-cddl"/>.		This structure is part of the extension CDDL in <xref target="sec-cddl"/>.
	An example full Challenge Bundle is included in <xref target="sec-example-bundle -challenge"/>		An example full Challenge Bundle is included in <xref target="sec-example-bundle -challenge"/>.
	</t>		</t>
	<t>		<t>
	For interoperability, entities which use this validation method <bcp14>SHALL</bc		For interoperability, entities that use this validation method <bcp14>SHALL</bcp
	p14> support the hash algorithm "SHA-256" (-16) of <xref target="RFC9054"/>, but		14> support the hash algorithm "SHA-256" (value -16) <xref target="RFC9054"/>.
	can use other hash algorithms.		This requirement allows for different implementations to be configured to use an
	This requirement allows for different implementations to be configured to use an		interoperable algorithm, but does not preclude the use of other algorithms with
	interoperable algorithm, but does not preclude the use of other algorithms.		either higher or lower priority.
	</t>		</t>
	<t>		<t>
	If the BP agent generating a Challenge Bundle does not have a well-synchronized clock or the agent responding to the challenge is expected to not have a well-sy nchronized clock, the bundle <bcp14>SHALL</bcp14> include a Bundle Age extension block.		If the BP Agent generating a Challenge Bundle does not have a well-synchronized clock or the agent responding to the challenge is expected to not have a well-sy nchronized clock, the Bundle <bcp14>SHALL</bcp14> include a Bundle Age extension block in accordance with <xref section="4.4.2" target="RFC9171"/>.
	</t>		</t>
	<t>		<t>
	Challenge Bundles <bcp14>SHALL</bcp14> include a Block Integrity Block (BIB) in		Challenge Bundles <bcp14>SHALL</bcp14> include a Block Integrity Block (BIB) in
	accordance with <xref target="sec-bib-gateway"/> or with a Security Source ident		accordance with <xref target="sec-bib-gateway"/> or with a Security Source ident
	ical to the bundle Source Node.		ical to the Bundle Source Node.
	Challenge Bundles <bcp14>SHALL NOT</bcp14> be directly encrypted by Block Confid		Challenge Bundles <bcp14>SHALL NOT</bcp14> be directly encrypted by the Block Co
	entiality Block (BCB) or any other method (see <xref target="sec-security-leak"/		nfidentiality Block (BCB) method or any other method (see <xref target="sec-secu
	>).		rity-leak"/>).
	</t>		</t>
	<section anchor="sec-challenge-check">		<section anchor="sec-challenge-check">
	<name>Challenge Bundle Checks</name>		<name>Challenge Bundle Checks</name>
	<t>		<t>
	A proper Challenge Bundle meets all of the following criteria:		A proper Challenge Bundle meets all of the following criteria:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	The Challenge Bundle was received within the time interval allowed for the chall enge.		The Challenge Bundle was received within the time interval allowed for the chall enge.
	The allowed interval starts at the Creation Timestamp and extends for the Lifeti me of the Challenge Bundle.		The allowed interval starts at the Creation Timestamp and extends for the Lifeti me of the Challenge Bundle.
	</li>		</li>
	<li>		<li>
	The Challenge Bundle contains a BIB which covers at least the primary block and		The Challenge Bundle contains a BIB that covers at least the primary block and p
	payload.		ayload.
	That BIB has a security source which is trusted and passes security-context-spec		That BIB has a Security Source that is trusted and passes security-context-speci
	ific validation (i.e. MAC or signature verification).		fic validation (i.e., Message Authentication Code (MAC) or signature verificatio
			n).
	</li>		</li>
	<li>		<li>
	The challenge payload contains the <tt>id-chal</tt> as indicated in the ACME cha llenge object.		The challenge payload contains the <tt>id-chal</tt> as indicated in the ACME Cha llenge Object.
	</li>		</li>
	<li>		<li>
	The challenge payload contains a <tt>token-bundle</tt> meeting the definition in <xref target="sec-bundle-challenge"/>.		The challenge payload contains a <tt>token-bundle</tt> matching the definition i n <xref target="sec-bundle-challenge"/>.
	</li>		</li>
	<li>		<li>
	The challenge payload contains at least one hash algorithm identifier acceptable to the client.		The challenge payload contains at least one hash algorithm identifier acceptable to the client.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Any of the failures above <bcp14>SHALL</bcp14> cause the challenge bundle to be otherwise ignored by the BP agent.		Failure to match any of the above <bcp14>SHALL</bcp14> cause the Challenge Bundl e to be otherwise ignored by the BP Agent.
	It is an implementation matter of how to react to such failures, which could inc lude logging the event, incrementing counters, or raising alarms.		It is an implementation matter of how to react to such failures, which could inc lude logging the event, incrementing counters, or raising alarms.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-bundle-response">		<section anchor="sec-bundle-response">
	<name>ACME Node ID Validation Response Bundles</name>		<name>ACME Node ID Validation Response Bundles</name>
	<t>		<t>
	Each ACME Node ID Validation Response Bundle <bcp14>SHALL</bcp14> be structured and encoded in accordance with <xref target="RFC9171"/>.		Each ACME Node ID Validation Response Bundle <bcp14>SHALL</bcp14> be structured and encoded in accordance with BPv7 <xref target="RFC9171"/>.
	</t>		</t>
	<t>		<t>
	Each Response Bundle has parameters as listed here:		Each Response Bundle has parameters as listed here:
	</t>		</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Bundle Processing Control Flags:</dt>		<dt>Bundle Processing Control Flags:</dt>
	<dd>		<dd>
	The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an adm inistrative record.		The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an adm inistrative record.
	The primary block flags <bcp14>SHALL NOT</bcp14> indicate that user application acknowledgement is requested; this flag distinguishes the Response Bundle from t he Challenge Bundle.		The primary block flags <bcp14>SHALL NOT</bcp14> indicate that user application acknowledgement is requested; this flag distinguishes the Response Bundle from t he Challenge Bundle.
	</dd>		</dd>
	skipping to change at line 624 ¶		skipping to change at line 633 ¶
	<dd>		<dd>
	The Source Node ID <bcp14>SHALL</bcp14> be identical to the Destination EID of t he Challenge Bundle to which this response corresponds.		The Source Node ID <bcp14>SHALL</bcp14> be identical to the Destination EID of t he Challenge Bundle to which this response corresponds.
	</dd>		</dd>
	<dt>Creation Timestamp and Lifetime:</dt>		<dt>Creation Timestamp and Lifetime:</dt>
	<dd>		<dd>
	The Creation Timestamp <bcp14>SHALL</bcp14> be set to the time at which the resp onse was generated.		The Creation Timestamp <bcp14>SHALL</bcp14> be set to the time at which the resp onse was generated.
	The response Lifetime <bcp14>SHALL</bcp14> indicate the response interval remain ing if the Challenge Bundle indicated a limited Lifetime.		The response Lifetime <bcp14>SHALL</bcp14> indicate the response interval remain ing if the Challenge Bundle indicated a limited Lifetime.
	</dd>		</dd>
	<dt>Administrative Record Type Code:</dt>		<dt>Administrative Record Type Code:</dt>
	<dd>		<dd>
	Set to the ACME Node ID Validation type code defined in <xref target="sec-iana-b		Set to the ACME Node ID Validation type code defined in <xref target=
	p-admin-type"/>.		"sec-iana-bp-admin-type"/>.
	</dd>		</dd>
	<dt>Administrative Record Content:</dt>		<dt>Administrative Record Content:</dt>
	<dd>		<dd>
	<t>		<t>
	The Response Bundle administrative record content <bcp14>SHALL</bcp14> consist o f a CBOR map containing the following three pairs:		The Response Bundle administrative record content <bcp14>SHALL</bcp14> consist o f a CBOR map containing the following three pairs:
	</t>		</t>
	<ul>		<ul>
	<li>		<li>
	One pair <bcp14>SHALL</bcp14> consist of key 1 with value of ACME challenge <tt> id-chal</tt>, copied from the Request Bundle, represented as a CBOR byte string.		One pair <bcp14>SHALL</bcp14> consist of key 1 with value of ACME challenge <tt> id-chal</tt>, copied from the Request Bundle, represented as a CBOR byte string.
	</li>		</li>
	<li>		<li>
	One pair <bcp14>SHALL</bcp14> consist of key 2 with value of ACME challenge <tt> token-bundle</tt>, copied from the Request Bundle, represented as a CBOR byte st ring.		One pair <bcp14>SHALL</bcp14> consist of key 2 with value of ACME challenge <tt> token-bundle</tt>, copied from the Request Bundle, represented as a CBOR byte st ring.
	</li>		</li>
	<li>		<li>
	One pair <bcp14>SHALL</bcp14> consist of key 3 with value of a two-element array containing the pair of a hash algorithm identifier and the hash byte string.		One pair <bcp14>SHALL</bcp14> consist of key 3 with value of a two-element array containing the pair of a hash algorithm identifier and the hash byte string.
	The algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (in teger or text string) of the algorithm registered in the "COSE Algorithms" regis try of <xref target="IANA-COSE"/>.		The algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (in teger or text string) of the algorithm registered in the "COSE Algorithms" regis try <xref target="IANA-COSE"/>.
	</li>		</li>
	</ul>		</ul>
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	This structure is part of the extension CDDL in <xref target="sec-cddl"/>.		This structure is part of the extension CDDL in <xref target="sec-cddl"/>.
	An example full Response Bundle is included in <xref target="sec-example-bundle- response"/>		An example full Response Bundle is included in <xref target="sec-example-bundle- response"/>.
	</t>		</t>
	<t>		<t>
	If the BP agent responding to a Challenge Bundle does not have a well-synchroniz ed clock, it <bcp14>SHALL</bcp14> use any information about last-hop delays and (if present) Bundle Age extension data to infer the age of the Challenge Bundle and lifetime of the Response Bundle.		If the BP Agent responding to a Challenge Bundle does not have a well-synchroniz ed clock, it <bcp14>SHALL</bcp14> use any information about last-hop delays and (if present) Bundle Age extension data to infer the age of the Challenge Bundle and Lifetime of the Response Bundle.
	</t>		</t>
	<t>		<t>
	Response Bundles <bcp14>SHALL</bcp14> include a BIB in accordance with <xref tar get="sec-bib-gateway"/>.		Response Bundles <bcp14>SHALL</bcp14> include a BIB in accordance with <xref tar get="sec-bib-gateway"/>.
	Response Bundles <bcp14>SHALL NOT</bcp14> be directly encrypted by BCB or any ot her method (see <xref target="sec-security-leak"/> for explanation).		Response Bundles <bcp14>SHALL NOT</bcp14> be directly encrypted by BCB or any ot her method (see <xref target="sec-security-leak"/> for explanation).
	</t>		</t>
	<section anchor="sec-response-check">		<section anchor="sec-response-check">
	<name>Response Bundle Checks</name>		<name>Response Bundle Checks</name>
	<t>		<t>
	A proper Response Bundle meets all of the following criteria:		A proper Response Bundle meets all of the following criteria:
	</t>		</t>
	skipping to change at line 672 ¶		skipping to change at line 681 ¶
	<li>		<li>
	The Response Bundle was received within the time interval allowed for the challe nge.		The Response Bundle was received within the time interval allowed for the challe nge.
	The allowed interval starts at the Creation Timestamp and extends for the Lifeti me of the associated Challenge Bundle.		The allowed interval starts at the Creation Timestamp and extends for the Lifeti me of the associated Challenge Bundle.
	The interval of the Challenge Bundle is used here because the interval of the Re sponse Bundle could be made to disagree with the Challenge Bundle.		The interval of the Challenge Bundle is used here because the interval of the Re sponse Bundle could be made to disagree with the Challenge Bundle.
	</li>		</li>
	<li>		<li>
	The Response Bundle Source Node ID is identical to the Node ID being validated.		The Response Bundle Source Node ID is identical to the Node ID being validated.
	The comparison of Node IDs <bcp14>SHALL</bcp14> use the comparison logic of the NODE-ID from <xref section="4.4.1" target="RFC9174"/>.		The comparison of Node IDs <bcp14>SHALL</bcp14> use the comparison logic of the NODE-ID from <xref section="4.4.1" target="RFC9174"/>.
	</li>		</li>
	<li>		<li>
	The Response Bundle contains a BIB which covers at least the primary block and p		The Response Bundle contains a BIB that covers at least the primary block and pa
	ayload.		yload.
	That BIB has a security source which is trusted and passes security-context-spec		That BIB has a Security Source that is trusted and passes security-context-speci
	ific validation.		fic validation.
	</li>		</li>
	<li>		<li>
	The response payload contains the same <tt>id-chal</tt> and <tt>token-bundle</tt > as sent in the Challenge Bundle (this is also how the two bundles are correlat ed).		The response payload contains the same <tt>id-chal</tt> and <tt>token-bundle</tt > as sent in the Challenge Bundle (this is also how the two Bundles are correlat ed).
	</li>		</li>
	<li>		<li>
	The response payload contains a hash algorithm identifier acceptable to the serv er (as indicated in the challenge bundle).		The response payload contains a hash algorithm identifier acceptable to the serv er (as indicated in the Challenge Bundle).
	</li>		</li>
	<li>		<li>
	The response payload contains the expected Key Authorization digest computed by the ACME server.		The response payload contains the expected Key Authorization digest computed by the ACME server.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Any of the failures above <bcp14>SHALL</bcp14> cause that single-perspective val idation to fail.		Any of the failures above <bcp14>SHALL</bcp14> cause that single-perspective val idation to fail.
	Any of the failures above <bcp14>SHOULD</bcp14> be distinguished as subproblems to the ACME client.		Any of the failures above <bcp14>SHOULD</bcp14> be distinguished as subproblems to the ACME client.
	The lack of a response within the expected response interval, as defined in <xre f target="sec-nodeid-response-obj"/>, <bcp14>SHALL</bcp14> also be treated as a validation failure.		The lack of a response within the expected response interval, as defined in <xre f target="sec-nodeid-response-obj"/>, <bcp14>SHALL</bcp14> also be treated as a validation failure.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-multi-perspective">		<section anchor="sec-multi-perspective">
	<name>Multi-Perspective Validation</name>		<name>Multi-Perspective Validation</name>
	<t>		<t>
	To avoid on-path attacks in certain networks, an ACME server can perform a singl		To avoid on-path attacks in certain networks, an ACME server can perform a singl
	e validation using multiple challenge bundle sources or via multiple routing pat		e validation using multiple Challenge Bundle sources or via multiple routing pat
	hs.		hs.
	This technique is called multi-perspective validation as recommended in <xref se		This technique is called "multi-perspective validation" as recommended in <xref
	ction="10.2" target="RFC8555"/> and an implementation used by Let's Encrypt is d		section="10.2" target="RFC8555"/> and an implementation is used by the Let's Enc
	escribed in <xref target="LE-multi-perspective"/>.		rypt service in its operational deployment <xref target="LE-multi-perspective"/>
	The utility of a multi-perspective validation is part of the <xref target="sec-e		.
	xperiment">experimental nature</xref> of this specification.		The utility of a multi-perspective validation is part of the experimental nature
			(see <xref target="sec-experiment"></xref>) of this specification.
	</t>		</t>
	<t>		<t>
	When required by policy, an ACME server <bcp14>SHALL</bcp14> send multiple chall enge bundles from different sources in the BP network.		When required by policy, an ACME server <bcp14>SHALL</bcp14> send multiple Chall enge Bundles from different sources in the BP network.
	When multiple Challenge Bundles are sent for a single validation, it is a matter of ACME server policy to determine whether or not the validation as a whole is successful.		When multiple Challenge Bundles are sent for a single validation, it is a matter of ACME server policy to determine whether or not the validation as a whole is successful.
	The result of each single-source validation is defined as success or failure in <xref target="sec-response-check"/>.		The result of each single-source validation is defined as success or failure in <xref target="sec-response-check"/>.
	</t>		</t>
	<t>		<t>
	A <bcp14>RECOMMENDED</bcp14> validation policy is to succeed if the challenge fr om a primary bundle source is successful and if there are no more than one failu re from a secondary source.		A <bcp14>RECOMMENDED</bcp14> validation policy is to succeed if the challenge fr om a primary Bundle source is successful and if there is no more than one failur e from a secondary source.
	The determination of which perspectives are considered primary or secondary is a n implementation matter.		The determination of which perspectives are considered primary or secondary is a n implementation matter.
	</t>		</t>
	<t>		<t>
	Regardless of whether a validation is single- or multi-perspective, a validation failure <bcp14>SHALL</bcp14> be indicated by an ACME error type of "incorrectRe sponse".		Regardless of whether a validation is single- or multi-perspective, a validation failure <bcp14>SHALL</bcp14> be indicated by an ACME error type of "incorrectRe sponse".
	Each specific perspective failure <bcp14>SHOULD</bcp14> be indicated to the ACME client as a validation subproblem.		Each specific perspective failure <bcp14>SHOULD</bcp14> be indicated to the ACME client as a validation subproblem.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-bib-gateway">		<section anchor="sec-bib-gateway">
	<name>Bundle Integrity Gateway</name>		<name>Bundle Integrity Gateway</name>
	<t>		<t>
	This section defines a BIB use which closely resembles the function of DKIM emai		This section defines a BIB use that closely resembles the function of DKIM email
	l signing <xref target="RFC6376"/>.		signing <xref target="RFC6376"/>.
	In this mechanism a routing node in a DTN sub-network attests to the origination		In this mechanism, a routing node in a DTN subnetwork attests to the origination
	of a bundle by adding a BIB before forwarding it.		of a Bundle by adding a BIB before forwarding it.
	The bundle receiver then need not trust the source of the bundle, but only trust		The Bundle receiver then need not trust the source of the Bundle, it only needs
	this security source node.		to trust this Security Source node.
	The receiver needs policy configuration to know which security sources are permi		The receiver needs policy configuration to know which Security Sources are permi
	tted to attest for which bundle sources.		tted to attest for which Bundle sources.
	The utility of an integrity gateway is part of the <xref target="sec-experiment"		The utility of an integrity gateway is part of the experimental nature (<xref ta
	>experimental nature</xref> of this specification.		rget="sec-experiment"></xref>) of this specification.
	</t>		</t>
	<t>		<t>
	An integrity gateway <bcp14>SHALL</bcp14> validate the Source Node ID of a bundl		An integrity gateway <bcp14>SHALL</bcp14> validate the Source Node ID of a Bundl
	e, using local-network-specific means, before adding a BIB to the bundle.		e, using local-network-specific means, before adding a BIB to the Bundle.
	The exact means by which an integrity gateway validates a bundle's source is net		The exact means by which an integrity gateway validates a Bundle's source is net
	work-specific, but could use physical-layer, network-layer or BP-convergence-lay		work specific, but it could use physical-layer, network-layer, or BP-convergence
	er authentication.		-layer authentication.
	The bundle source could also add its own BIB with a local-network-specific secur		The Bundle source could also add its own BIB with a local-network-specific secur
	ity context or local-network-specific key material (i.e. a group key shared with		ity context or local-network-specific key material (i.e., a group key shared wit
	in the local network).		hin the local network).
	</t>		</t>
	<t>		<t>
	When an integrity gateway adds a BIB it <bcp14>SHALL</bcp14> be in accordance wi th <xref target="RFC9172"/>.		When an integrity gateway adds a BIB, it <bcp14>SHALL</bcp14> be in accordance w ith BPSec <xref target="RFC9172"/> requirements.
	The BIB targets <bcp14>SHALL</bcp14> cover both the payload block and the primar y block (either directly as a target or as additional authenticated data for the payload block MAC/signature).		The BIB targets <bcp14>SHALL</bcp14> cover both the payload block and the primar y block (either directly as a target or as additional authenticated data for the payload block MAC/signature).
	The Security Source of this BIB <bcp14>SHALL</bcp14> be either the bundle source Node ID itself or a routing node trusted by the destination node (see <xref tar get="sec-security-impersonate"/>).		The Security Source of this BIB <bcp14>SHALL</bcp14> be either the Bundle source Node ID itself or a routing node trusted by the destination node (see <xref tar get="sec-security-impersonate"/>).
	</t>		</t>
	</section>		</section>
	<section>		<section>
	<name>Certificate Request Profile</name>		<name>Certificate Request Profile</name>
	<t>		<t>
	The ultimate purpose of this ACME validation is to allow a CA to issue certifica tes following the profiles of <xref section="4.4.2" target="RFC9174"/> and <xref section="4" target="I-D.ietf-dtn-bpsec-cose"/>.		The ultimate purpose of this ACME validation is to allow a CA to issue certifica tes following the profiles of <xref section="4.4.2" target="RFC9174"/> and <xref section="4" target="I-D.ietf-dtn-bpsec-cose"/>.
	These purposes are referred to here as bundle security certificates.		These purposes are referred to here as "Bundle security certificates".
	</t>		</t>
	<t>		<t>
	ACME identifiers of type "bundleEID" correlate to certificate requests within in		The ACME identifier type "bundleEID" correlates to the PKIX certificate and cert
	an <tt>extensionRequest</tt> attribute (see <xref target="RFC2985"/>) containin		ificate request "NODE-ID" as defined in <xref section="4.4.1" target="RFC9174"/>
	g a <tt>subjectAltName</tt> extension of type <tt>otherName</tt> with a name for		.
	m of <tt>BundleEID</tt>, identified by <tt>id-on-bundleEID</tt> of <xref target=		This NODE-ID is present in certificate requests with an <tt>extensionRequest</tt
	"IANA-SMI"/>.		> attribute (see <xref target="RFC2985"/>) containing a SAN extension with ident
	This form is referred to as a "NODE-ID" as defined in <xref section="4.4.1" targ		ities of type <tt>otherName</tt> having an Other Name form of <tt>BundleEID</tt>
	et="RFC9174"/>.		, identified by <tt>id-on-bundleEID</tt> from the "SMI Security for PKIX Other N
	Because the <tt>BundleEID</tt> name form is encoded as an IA5String it <bcp14>SH		ame Forms" registry <xref target="IANA-SMI"/>.
	ALL</bcp14> be treated as being in the percent-encoded form of <xref section="2.		Because the <tt>BundleEID</tt> Other Name form is encoded as an IA5String, it <b
	1" target="RFC3986"/>.		cp14>SHALL</bcp14> be treated as being in the percent-encoded form of <xref sect
			ion="2.1" target="RFC3986"/>.
	</t>		</t>
	<t>		<t>
	One defining aspect of bundle security certificates is the Extended Key Usage ke		One defining aspect of Bundle security certificates is the Extended Key Usage ke
	y purpose <tt>id-kp-bundleSecurity</tt> of <xref target="IANA-SMI"/>, as defined		y purpose <tt>id-kp-bundleSecurity</tt> <xref target="IANA-SMI"/>, as defined in
	in <xref section="4.4.2.1" target="RFC9174"/>.		<xref section="4.4.2.1" target="RFC9174"/>.
	When requesting a certificate which includes a NODE-ID, the CSR <bcp14>SHOULD</b		When requesting a certificate that includes a NODE-ID, the CSR <bcp14>SHOULD</bc
	cp14> include an Extended Key Usage of <tt>id-kp-bundleSecurity</tt>.		p14> include an Extended Key Usage of <tt>id-kp-bundleSecurity</tt>.
	When a bundle security certificate is issued based on a validated NODE-ID, the c		When a Bundle security certificate is issued based on a validated NODE-ID, the c
	ertificate <bcp14>SHALL</bcp14> include an Extended Key Usage of <tt>id-kp-bundl		ertificate <bcp14>SHALL</bcp14> include an Extended Key Usage of <tt>id-kp-bundl
	eSecurity</tt>.		eSecurity</tt>.
	</t>		</t>
	<section anchor="sec-multiple-claims">		<section anchor="sec-multiple-claims">
	<name>Multiple Identity Claims</name>		<name>Multiple Identity Claims</name>
	<t>		<t>
	A single bundle security CSR <bcp14>MAY</bcp14> contain a mixed set of SAN ident		A single Bundle security CSR <bcp14>MAY</bcp14> contain a mixed set of SAN ident
	ifiers, including combinations of IP-ID, DNS-ID <xref target="RFC9525"/> and NOD		ifiers, including combinations of IP-ID <xref target="RFC9525"/>, DNS-ID <xref t
	E-ID <xref target="RFC9174"/> types.		arget="RFC9525"/>, and NODE-ID <xref target="RFC9174"/> types.
	These correspond with ACME identifier types "ip", "dns", and "bundleEID" respect		These correspond with ACME identifier types "ip", "dns", and "bundleEID", respec
	ively.		tively.
	</t>		</t>
	<t>		<t>
	There is no restriction on how a certificate combines these claims, but each ide ntifier <bcp14>SHALL</bcp14> be validated by an ACME server to issue such a cert ificate as part of an associated ACME order.		There is no restriction on how a certificate combines these claims, but each ide ntifier <bcp14>SHALL</bcp14> be validated by an ACME server to issue such a cert ificate as part of an associated ACME order.
	This is no different than the existing behavior of <xref target="RFC8555"/> but		This is no different than the existing behavior of ACME <xref target="RFC8555"/>
	is mentioned here to make sure that CA policy handles such situations; especiall		but is mentioned here to make sure that CA policy handles such situations, espe
	y related to validation failure of an identifier in the presence of multiple ide		cially related to validation failure of an identifier in the presence of multipl
	ntifiers.		e identifiers.
	The initial "ip" validations are defined in <xref target="RFC8738"/> and initial		Existing validation mechanisms are defined for identifier types "ip" <xref targe
	"dns" validations are defined in <xref target="RFC8555"/>.		t="RFC8738"/> and "dns" <xref target="RFC8555"/> among others <xref target="IANA
			-ACME"/>.
	</t>		</t>
	<t>		<t>
	The specific use case of TLS-based security in <xref target="RFC9174"/> allows, and for some network policies requires, that a certificate authenticate both the DNS name of an entity as well as the Node ID of the entity.		The specific use case of TLS-based security for BPv7 CL transport in <xref secti on="4.4" target="RFC9174"/> allows, and for some network policies requires, that a certificate authenticate both the DNS name of an entity as well as the Node I D of the entity.
	These authentications apply to each identifier type, used for different network layers, at different points during secure session establishment.		These authentications apply to each identifier type, used for different network layers, at different points during secure session establishment.
	</t>		</t>
	</section>		</section>
	<section>		<section>
	<name>Generating Encryption-only or Signing-only Bundle Security Certifi cates</name>		<name>Generating Encryption-Only or Signing-Only Bundle Security Certifi cates</name>
	<t>		<t>
	ACME extensions specified in this document can be used to request encryption-onl y or signing-only bundle security certificates.		ACME extensions specified in this document can be used to request encryption-onl y or signing-only Bundle security certificates.
	The validity of a request for either a restricted-use or unrestricted-use certif icate is dependent on both CA policy to issue such certificates as well as const raints based on the requested key and algorithm types.		The validity of a request for either a restricted-use or unrestricted-use certif icate is dependent on both CA policy to issue such certificates as well as const raints based on the requested key and algorithm types.
	</t>		</t>
	<t>		<t>
	In order to request signing only bundle security certificate, the CSR <bcp14>SHA LL</bcp14> include the key usage extension with digitalSignature and/or nonRepud iation bits set and no other bits set.		In order to request a signing-only Bundle security certificate, the CSR <bcp14>S HALL</bcp14> include the key usage extension with the digitalSignature and/or no nRepudiation bits set and no other bits set.
	</t>		</t>
	<t>		<t>
	In order to request encryption only bundle security certificate, the CSR <bcp14> SHALL</bcp14> include the key usage extension with keyEncipherment or keyAgreeme nt bits set and no other bits set.		In order to request an encryption-only Bundle security certificate, the CSR <bcp 14>SHALL</bcp14> include the key usage extension with the keyEncipherment or key Agreement bits set and no other bits set.
	</t>		</t>
	<t>		<t>
	Presence of both of the above sets of key usage bits in the CSR, as well as abse nce of key usage extension in the CSR, signals to ACME server to issue a bundle security certificate suitable for both signing and encryption.		Presence of both of the above sets of key usage bits in the CSR, as well as abse nce of key usage extension in the CSR, signals the ACME server to issue a Bundle security certificate suitable for both signing and encryption.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-security">		<section anchor="sec-security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This section separates security considerations into threat categories based on g uidance of BCP 72 <xref target="RFC3552"/>.		This section separates security considerations into threat categories based on g uidance of BCP 72 <xref target="RFC3552"/>.
	</t>		</t>
	<section anchor="sec-security-leak">		<section anchor="sec-security-leak">
	<name>Threat: Passive Leak of Validation Data</name>		<name>Threat: Passive Leak of Validation Data</name>
	<t>		<t>
	Because this challenge mechanism is used to bootstrap security between DTN Nodes , the challenge and its response are likely to be transferred in plaintext.		Because this challenge mechanism is used to bootstrap security between DTN Nodes , the challenge and its response are likely to be transferred in plaintext.
	The only ACME data present on-the-wire is a random token and a cryptographic dig est, so there is no sensitive data to be leaked within the Node ID Validation bu ndle exchange.		The only ACME data present on-the-wire is a random token and a cryptographic dig est, so there is no sensitive data to be leaked within the Node ID Validation Bu ndle exchange.
	Because each challenge uses a separate token pair, there is no value in an on-pa th attacker seeing the tokens from past challenges and/or responses.		Because each challenge uses a separate token pair, there is no value in an on-pa th attacker seeing the tokens from past challenges and/or responses.
	</t>		</t>
	<t>		<t>
	It is possible for intermediate BP nodes to encapsulate-and-encrypt Challenge an d/or Response Bundles while they traverse untrusted networks, but that is a DTN configuration matter outside of the scope of this document.		It is possible for intermediate BP Nodes to encapsulate-and-encrypt Challenge Bu ndles and/or Response Bundles while they traverse untrusted networks, but that i s a DTN configuration matter outside of the scope of this document.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-security-impersonate">		<section anchor="sec-security-impersonate">
	<name>Threat: BP Node Impersonation</name>		<name>Threat: BP Node Impersonation</name>
	<t>		<t>
	As described in <xref section="10.1" target="RFC8555"/>, it is possible for an a ctive attacker to alter data on both ACME client channel and the DTN validation channel.		As described in <xref section="10.1" target="RFC8555"/>, it is possible for an a ctive attacker to alter data on both ACME client channel and the DTN validation channel.
	</t>		</t>
	<t>		<t>
	The primary mitigation is to delegate bundle integrity sourcing to a trusted rou		The primary mitigation is to delegate Bundle integrity sourcing to a trusted rou
	ting node near, in the sense of bundle routing topology, to the bundle source no		ting node near, in the sense of Bundle routing topology, the Bundle source node
	de as defined in <xref target="sec-bib-gateway"/>.		as defined in <xref target="sec-bib-gateway"/>.
	This is functionally similar to DKIM signing of <xref target="RFC6376"/> and pro		This is functionally similar to the DKIM signing <xref target="RFC6376"/> and pr
	vides some level of bundle origination.		ovides some level of secure Bundle origination.
	</t>		</t>
	<t>		<t>
	Another way to mitigate single-path on-path attacks is to attempt validation of		Another way to mitigate on-path attacks is to attempt validation of the same Nod
	the same Node ID from multiple sources or via multiple bundle routing paths, as		e ID from multiple sources, hopefully via multiple Bundle routing paths, as defi
	defined in <xref target="sec-multi-perspective"/>.		ned in <xref target="sec-multi-perspective"/>.
	It is not a trivial task to guarantee bundle routing though, so more advanced te		It is not a trivial task to guarantee Bundle routing though, so more advanced te
	chniques such as onion routing (using bundle-in-bundle encapsulation) could be e		chniques such as onion routing (using Bundle-in-Bundle encapsulation) could be e
	mployed.		mployed.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-security-replay">		<section anchor="sec-security-replay">
	<name>Threat: Bundle Replay</name>		<name>Threat: Bundle Replay</name>
	<t>		<t>
	It is possible for an on-path attacker to replay both Challenge Bundles or Respo nse Bundles.		It is possible for an on-path attacker to replay both Challenge Bundles or Respo nse Bundles.
	Even in a properly-configured DTN it is possible that intermediate bundle router s to use multi-path forwarding of a singleton-destination bundle.		Even in a properly configured DTN, it is possible that intermediate Bundle route rs would use multi-path forwarding of a singleton-destination Bundle.
	</t>		</t>
	<t>		<t>
	Ultimately, the point of the ACME bundle exchange is to derive a Key Authorizati		Ultimately, the point of the ACME Bundle exchange is to derive a Key Authorizati
	on and its cryptographic digest and communicate it back to the ACME server for v		on value and its cryptographic digest, and to communicate that digest back to th
	alidation, so the uniqueness of the Key Authorization directly determines the sc		e ACME server for validation, so the uniqueness of the Key Authorization directl
	ope of replay validity.		y determines the scope of replay validity.
	The uniqueness of each <tt>token-bundle</tt> to each challenge bundle ensures th		The uniqueness of each <tt>token-bundle</tt> to each Challenge Bundle ensures th
	at the Key Authorization is unique to the challenge bundle.		at the Key Authorization is unique to the Challenge Bundle.
	The uniqueness of each <tt>token-chal</tt> to the ACME challenge ensures that th e Key Authorization is unique to that ACME challenge and not based solely on val ues visible to on-path eavesdroppers.		The uniqueness of each <tt>token-chal</tt> to the ACME challenge ensures that th e Key Authorization is unique to that ACME challenge and not based solely on val ues visible to on-path eavesdroppers.
	</t>		</t>
	<t>		<t>
	Having each bundle's primary block and payload block covered by a BIB from a tru sted security source (see <xref target="sec-bib-gateway"/>) ensures that a repla yed bundle cannot be altered in the blocks used by ACME.		Having each Bundle's primary block and payload block covered by a BIB from a tru sted Security Source (see <xref target="sec-bib-gateway"/>) ensures that a repla yed Bundle cannot be altered in the blocks used by ACME.
	All together, these properties mean that there is no degraded security caused by replay of either a Challenge Bundle or a Response Bundle even in the case where the primary or payload block is not covered by a BIB.		All together, these properties mean that there is no degraded security caused by replay of either a Challenge Bundle or a Response Bundle even in the case where the primary or payload block is not covered by a BIB.
	The worst that can come of bundle replay is the waste of network resources as de scribed in <xref target="sec-security-dos"/>.		The worst that can come of Bundle replay is the waste of network resources as de scribed in <xref target="sec-security-dos"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-security-dos">		<section anchor="sec-security-dos">
	<name>Threat: Denial of Service</name>		<name>Threat: Denial of Service</name>
	<t>		<t>
	The behaviors described in this section all amount to a potential denial-of-serv ice to a BP agent.		The behaviors described in this section all amount to a potential denial-of-serv ice to a BP Agent.
	</t>		</t>
	<t>		<t>
	A malicious entity can continually send Challenge Bundles to a BP agent.		A malicious entity can continually send Challenge Bundles to a BP Agent.
	The victim BP agent can ignore Challenge Bundles which do not conform to the spe		The victim BP Agent can ignore Challenge Bundles that do not conform to the spec
	cific time interval and challenge token for which the ACME client has informed t		ific time interval and challenge token for which the ACME client has informed th
	he BP agent that challenges are expected.		e BP Agent that challenges are expected.
	The victim BP agent can require all Challenge Bundles to be BIB-signed to ensure		The victim BP Agent can require all Challenge Bundles to be BIB-signed to ensure
	authenticity of the challenge.		authenticity of the challenge.
	</t>		</t>
	<t>		<t>
	A malicious entity can continually send Response Bundles to a BP agent.		A malicious entity can continually send Response Bundles to a BP Agent.
	The victim BP agent can ignore Response Bundles which do not conform to the spec		The victim BP Agent can ignore Response Bundles that do not conform to the speci
	ific time interval or Source Node ID or challenge token for an active Node ID va		fic time interval or Source Node ID or challenge token for an active Node ID val
	lidation.		idation.
	</t>		</t>
	<t>		<t>
	Similar to other validation methods, an ACME server validating a DTN Node ID cou		Similar to other validation methods, an ACME server validating a DTN Node ID cou
	ld be used as a denial of service amplifier.		ld be used as a denial-of-service amplifier.
	For this reason any ACME server can rate-limit validation activities for individ		For this reason, any ACME server can rate-limit validation activities for indivi
	ual clients and individual certificate requests.		dual clients and individual certificate requests.
	</t>		</t>
	</section>		</section>
	<section>		<section>
	<name>Inherited Security Considerations</name>		<name>Inherited Security Considerations</name>
	<t>		<t>
	Because this protocol relies on ACME for part of its operation, the security con siderations of <xref target="RFC8555"/> apply to all ACME client--server exchang es during Node ID validation.		Because this protocol relies on ACME for part of its operation, the security con siderations of ACME <xref target="RFC8555"/> apply to all ACME client-server exc hanges during Node ID validation.
	</t>		</t>
	<t>		<t>
	Because this protocol relies on BPv7 for part of its operation, the security con siderations of <xref target="RFC9171"/> and <xref target="RFC9172"/> apply to al l BP messaging during Node ID validation.		Because this protocol relies on BPv7 for part of its operation, the security con siderations of BPv7 <xref target="RFC9171"/> and BPSec <xref target="RFC9172"/> apply to all BP messaging during Node ID validation.
	</t>		</t>
	</section>		</section>
	<section>		<section>
	<name>Out-of-Scope BP Agent Communication</name>		<name>Out-of-Scope BP Agent Communication</name>
	<t>		<t>
	Although messaging between an ACME client or ACME server an its associated BP ag ent are out-of-scope for this document, both of those channels are critical to N ode ID validation security.		Although messaging between an ACME client or ACME server and its associated BP A gent are out-of-scope for this document, both of those channels are critical to Node ID validation security.
	Either channel can potentially leak data or provide attack vectors if not proper ly secured.		Either channel can potentially leak data or provide attack vectors if not proper ly secured.
	These channels need to protect against spoofing of messaging in both directions to avoid interruption of normal validation sequencing and to prevent false valid ations from succeeding.		These channels need to protect against spoofing of messaging in both directions to avoid interruption of normal validation sequencing and to prevent false valid ations from succeeding.
	</t>		</t>
	<t>		<t>
	The ACME server and its BP agent exchange the outgoing <tt>id-chal</tt>, <tt>tok en-bundle</tt>, and Key Authorization digest but these values do not need to be confidential (they are also in plaintext over the BP channel).		The ACME server and its BP Agent exchange the outgoing <tt>id-chal</tt>, <tt>tok en-bundle</tt>, and Key Authorization digest, but these values do not need to be confidential (they are also in plaintext over the BP channel).
	</t>		</t>
	<t>		<t>
	Depending on implementation details, the ACME client might transmit the client a		Depending on implementation details, the ACME client might transmit the client a
	ccount key thumbprint to its BP agent to allow computing the Key Authorization d		ccount key thumbprint to its BP Agent to allow computing the Key Authorization d
	igest on the BP agent.		igest on the BP Agent.
	If an ACME client does transmit its client account key thumbprint to a BP agent,		If an ACME client does transmit its client account key thumbprint to a BP Agent,
	it is important that this data is kept confidential because it provides the bin		it is important that this data is kept confidential because it provides the bin
	ding of the client account key to the Node ID validation (as well as for all oth		ding of the client account key to the Node ID validation (as well as for all oth
	er types of ACME validation).		er types of ACME validation).
	Avoiding this transmission would require a full round-trip between BP agent and		Avoiding this transmission would require a full round-trip between BP Agent and
	ACME client, which can be undesirable if the two are separated by a long-delay n		ACME client, which can be undesirable if the two are separated by a long-delay n
	etwork.		etwork.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-iana">		<section anchor="sec-iana">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	This specification adds to the ACME registry group and BP registry group for thi s behavior.		This specification adds to the "Automated Certificate Management Environment (AC ME) Protocol" registry group and the "Bundle Protocol" registry group.
	</t>		</t>
	<section anchor="sec-iana-acme-identifier">		<section anchor="sec-iana-acme-identifier">
	<name>ACME Identifier Types</name>		<name>ACME Identifier Types</name>
	<t>		<t>
	Within the "Automated Certificate Management Environment (ACME) Protocol" regist ry group <xref target="IANA-ACME"/>, the following entry has been added to the " ACME Identifier Types" registry.		Within the "Automated Certificate Management Environment (ACME) Protocol" regist ry group <xref target="IANA-ACME"/>, the following entry has been added to the " ACME Identifier Types" registry.
	</t>		</t>
	<table>		<table>
	<thead>		<thead>
	<tr>		<tr>
	<th>Label</th>		<th>Label</th>
	<th>Reference</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>bundleEID</td>		<td>bundleEID</td>
	<td>[This specification]</td>		<td>RFC 9891</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="sec-iana-acme-method">		<section anchor="sec-iana-acme-method">
	<name>ACME Validation Methods</name>		<name>ACME Validation Methods</name>
	<t>		<t>
	Within the "Automated Certificate Management Environment (ACME) Protocol" regist ry group <xref target="IANA-ACME"/>, the following entry has been added to the " ACME Validation Methods" registry.		Within the "Automated Certificate Management Environment (ACME) Protocol" regist ry group <xref target="IANA-ACME"/>, the following entry has been added to the " ACME Validation Methods" registry.
	</t>		</t>
	<table>		<table>
	skipping to change at line 919 ¶		skipping to change at line 931 ¶
	<th>Identifier Type</th>		<th>Identifier Type</th>
	<th>ACME</th>		<th>ACME</th>
	<th>Reference</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>bp-nodeid-00</td>		<td>bp-nodeid-00</td>
	<td>bundleEID</td>		<td>bundleEID</td>
	<td>Y</td>		<td>Y</td>
	<td>[This specification]</td>		<td>RFC 9891</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="sec-iana-bp-admin-type">		<section anchor="sec-iana-bp-admin-type">
	<name>Bundle Administrative Record Types</name>		<name>Bundle Administrative Record Types</name>
	<t>		<t>
	Within the "Bundle Protocol" registry group <xref target="IANA-BP"/>, the follow		Within the "Bundle Protocol" registry group <xref target="IANA-BP"/>, the follow
	ing entries have been added to the "Bundle Administrative Record Types" registry		ing entry has been added to the "Bundle Administrative Record Types" registry.
	.
	</t>
	<t>
	[NOTE to IANA: For <xref target="RFC5050"/> compatibility the AR-TBD value needs
	to be no larger than 15, but such compatibility is not needed. For BPbis the AR
	-TBD value needs to be no larger than 65535 as defined by <xref target="RFC9713"
	/>.]
	</t>		</t>
	<table>		<table>
	<thead>		<thead>
	<tr>		<tr>
	<th>Bundle Protocol Version</th>		<th>Bundle Protocol Version</th>
	<th>Value</th>		<th>Value</th>
	<th>Description</th>		<th>Description</th>
	<th>Reference</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>7</td>		<td>7</td>
	<td>AR-TBD</td>		<td>255</td>
	<td>ACME Node ID Validation</td>		<td>ACME Node ID Validation</td>
	<td>[This specification]</td>		<td>RFC 9891</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-dtn-bpsec-cose" to="BPSEC-COSE"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="IANA-ACME" target="https://www.iana.org/assignments/a cme/">		<reference anchor="IANA-ACME" target="https://www.iana.org/assignments/a cme/">
	<front>		<front>
	<title>Automated Certificate Management Environment (ACME) Protocol< /title>		<title>Automated Certificate Management Environment (ACME) Protocol< /title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	skipping to change at line 987 ¶		skipping to change at line 998 ¶
	<front>		<front>
	<title>CBOR Object Signing and Encryption (COSE)</title>		<title>CBOR Object Signing and Encryption (COSE)</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="IANA-SMI" target="https://www.iana.org/assignments/sm i-numbers/">		<reference anchor="IANA-SMI" target="https://www.iana.org/assignments/sm i-numbers/">
	<front>		<front>
	<title>Structure of Management Information (SMI) Numbers</title>		<title>Structure of Management Information (SMI) Numbers (MIB Module Registrations)</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	ence.RFC.2119.xml"/>		119.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	ence.RFC.2985.xml"/>		985.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	ence.RFC.3552.xml"/>		552.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	ence.RFC.3986.xml"/>		986.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ence.RFC.4086.xml"/>		086.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ence.RFC.4648.xml"/>		648.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ence.RFC.4838.xml"/>		838.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	ence.RFC.5280.xml"/>		280.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8174.xml"/>		174.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8555.xml"/>		555.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8610.xml"/>		610.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ence.RFC.9054.xml"/>		054.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ence.RFC.9171.xml"/>		171.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ence.RFC.9172.xml"/>		172.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ence.RFC.9174.xml"/>		174.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ence.RFC.9525.xml"/>		525.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	ence.RFC.5050.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		376.xml"/>
	ence.RFC.6376.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		738.xml"/>
	ence.RFC.7942.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		792.xml"/>
	ence.RFC.8738.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		823.xml"/>
	ence.RFC.8792.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<!-- [I-D.ietf-dtn-bpsec-cose]
	ence.RFC.8823.xml"/>		draft-ietf-dtn-bpsec-cose-08
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		IESG State: I-D Exists as of 08/15/25
	ence.RFC.9713.xml"/>		-->
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/r		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	eference.I-D.ietf-dtn-bpsec-cose.xml"/>		.ietf-dtn-bpsec-cose.xml"/>
	<reference anchor="github-dtn-demo-agent" target="https://github.com/Bri
	anSipos/dtn-demo-agent/">
	<front>
	<title>Python implementation of basic BPv7-related protocols</title>
	<author fullname="Brian Sipos" initials="B." surname="Sipos">
	</author>
	<date/>
	</front>
	</reference>
	<reference anchor="github-dtn-wireshark" target="https://github.com/Bria
	nSipos/dtn-wireshark/">
	<front>
	<title>Wireshark Dissectors for BPv7-related Protocols</title>
	<author fullname="Brian Sipos" initials="B." surname="Sipos">
	</author>
	<date/>
	</front>
	</reference>
	<reference anchor="LE-multi-perspective" target="https://letsencrypt.org /2020/02/19/multi-perspective-validation.html">		<reference anchor="LE-multi-perspective" target="https://letsencrypt.org /2020/02/19/multi-perspective-validation.html">
	<front>		<front>
	<title>Multi-Perspective Validation Improves Domain Validation Secur ity</title>		<title>Multi-Perspective Validation Improves Domain Validation Secur ity</title>
	<author fullname="Josh Aas"/>		<author fullname="Josh Aas"/>
	<author fullname="Daniel McCarney"/>		<author fullname="Daniel McCarney"/>
	<author fullname="Roland Shoemaker"/>		<author fullname="Roland Shoemaker"/>
	<date day="19" month="Feb" year="2020"/>		<date day="19" month="Feb" year="2020"/>
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="sec-cddl">		<section anchor="sec-cddl">
	<name>Administrative Record Types CDDL</name>		<name>Administrative Record Types CDDL</name>
	<t>		<t>
	[NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the "ACME Node		The extension of BPv7 from <xref section="B" target="RFC9171"/> for the ACME Bun
	ID Validation" administrative record type code.]		dles in Sections <xref target="sec-bundle-challenge" format="counter"/> and <xre
	</t>		f target="sec-bundle-response" format="counter"/> is the following CDDL:
	<t keepWithNext="true">
	The extension of BPv7 from <xref section="B" target="RFC9171"/> for the ACME bun
	dles in <xref target="sec-bundle-challenge"/> and <xref target="sec-bundle-respo
	nse"/> is the following CDDL.
	</t>		</t>
	<sourcecode type="cddl">		<sourcecode type="cddl"><![CDATA[
	; All ACME records have the same structure		; All ACME records have the same structure
	$admin-record /= [0xFFFF, acme-record]		$admin-record /= [0xFF, acme-record]
	acme-record = acme-challenge-record / acme-response-record		acme-record = acme-challenge-record / acme-response-record
	acme-challenge-record = {		acme-challenge-record = {
	id-chal,		id-chal,
	token-bundle,		token-bundle,
	alg-list		alg-list
	}		}
	acme-response-record = {		acme-response-record = {
	id-chal,		id-chal,
	token-bundle,		token-bundle,
	key-auth-digest		key-auth-digest
	skipping to change at line 1080 ¶		skipping to change at line 1076 ¶
	id-chal = (1: bstr)		id-chal = (1: bstr)
	token-bundle = (2: bstr)		token-bundle = (2: bstr)
	key-auth-digest = (3: [		key-auth-digest = (3: [
	alg: alg-id,		alg: alg-id,
	value: bstr		value: bstr
	])		])
	alg-list = (4: [+ alg-id])		alg-list = (4: [+ alg-id])
	; From the IANA COSE registry, only hash algorithms allowed		; From the IANA COSE registry, only hash algorithms allowed
	alg-id = tstr / int		alg-id = tstr / int
	</sourcecode>		]]></sourcecode>
	</section>		</section>
	<section>		<section>
	<name>Example Authorization</name>		<name>Example Authorization</name>
	<t>		<t>
	[NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced by the "ACM		This example is a Bundle exchange for the ACME server with Node ID "dtn://acme-s
	E Node ID Validation" administrative record type code.]		erver/" performing a verification for ACME client Node ID "dtn://acme-client/".
	</t>		The example Bundles use no block CRC or BPSec integrity, which is for simplicity
	<t>		and is not recommended for normal use.
	This example is a bundle exchange for the ACME server with Node ID "dtn://acme-s
	erver/" performing a verification for ACME client Node ID "dtn://acme-client/".
	The example bundles use no block CRC or BPSec integrity, which is for simplicity
	and is not recommended for normal use.
	The provided figures are extended diagnostic notation <xref target="RFC8610"/>.		The provided figures are extended diagnostic notation <xref target="RFC8610"/>.
	</t>		</t>
	<t>		<t>
	For this example the ACME client key thumbprint has the base64url encoded value of:		For this example, the ACME client key thumbprint has the base64url-encoded value of:
	</t>		</t>
	<sourcecode type="cbor">		<sourcecode type="cbor"><![CDATA[
	"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"		"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"]]></sourcecode>
	</sourcecode>
	<t>		<t>
	And the ACME-server generated <tt>token-chal</tt> has the base64url-encoded valu e of:		and the ACME-server generated <tt>token-chal</tt> has the base64url-encoded valu e of:
	</t>		</t>
	<sourcecode type="cbor">		<sourcecode type="cbor"><![CDATA[
	"tPUZNY4ONIk6LxErRFEjVw"		"tPUZNY4ONIk6LxErRFEjVw"]]></sourcecode>
	</sourcecode>
	<section anchor="sec-example-bundle-challenge">		<section anchor="sec-example-bundle-challenge">
	<name>Challenge Bundle</name>		<name>Challenge Bundle</name>
	<t>		<t>
	For the single challenge bundle in this example, the <tt>token-bundle</tt> (tran sported as byte string via BP) has the base64url-encoded value of:		For the single Challenge Bundle in this example, the <tt>token-bundle</tt> (tran sported as byte string via BP) has the base64url-encoded value of:
	</t>		</t>
	<sourcecode type="cbor">		<sourcecode type="cbor"><![CDATA[
	"p3yRYFU4KxwQaHQjJ2RdiQ"		"p3yRYFU4KxwQaHQjJ2RdiQ"]]></sourcecode>
	</sourcecode>
	<t>		<t>
	The minimal-but-valid Challenge Bundle is shown in <xref target="fig-example-bun dle-challenge"/>.		The minimal-but-valid Challenge Bundle is shown in <xref target="fig-example-bun dle-challenge"/>.
	This challenge requires that the ACME client respond within a 60 second time win dow.		This challenge requires that the ACME client respond within a 60-second time win dow.
	</t>		</t>
	<figure anchor="fig-example-bundle-challenge">		<figure anchor="fig-example-bundle-challenge">
	<name>Example Challenge Bundle</name>		<name>Example Challenge Bundle</name>
	<sourcecode type="cbor">		<sourcecode type="cbor"><![CDATA[
	[_		[_
	[		[
	7, / BP version /		7, / BP version /
	0x22, / flags: user-app-ack, payload-is-an-admin-record /		0x22, / flags: user-app-ack, payload-is-an-admin-record /
	0, / CRC type: none /		0, / CRC type: none /
	[1, "//acme-client/"], / destination /		[1, "//acme-client/"], / destination /
	[1, "//acme-server/"], / source /		[1, "//acme-server/"], / source /
	[1, 0], / report-to: none /		[1, 0], / report-to: none /
	[1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /		[1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /
	60000 / lifetime: 60s /		60000 / lifetime: 60s /
	],		],
	[		[
	1, / block type code /		1, / block type code /
	1, / block number /		1, / block number /
	0, / flags /		0, / flags /
	0, / CRC type: none /		0, / CRC type: none /
	&lt;&lt;[ / type-specific data /		<<[ / type-specific data /
	0xFFFF, / record-type-code /		0xFF, / record-type-code /
	{ / record-content /		{ / record-content /
	1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /		1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
	2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /		2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
	4: [-16] / alg-list: SHA-256 /		4: [-16] / alg-list: SHA-256 /
	}		}
	]>&gt;		]>&gt;
	]		]
	]		]]]></sourcecode>
	</sourcecode>
	</figure>		</figure>
	</section>		</section>
	<section anchor="sec-example-bundle-response">		<section anchor="sec-example-bundle-response">
	<name>Response Bundle</name>		<name>Response Bundle</name>
	<t>		<t>
	When the tokens are combined with the key thumbprint, the full Key Authorization value is the following, folded across lines for readability using the "single b ackslash" strategy of <xref section="7" target="RFC8792"/>.		When the tokens are combined with the key thumbprint, the full Key Authorization value is the following, folded across lines for readability using the "single b ackslash" strategy of <xref section="7" target="RFC8792"/>.
	</t>		</t>
	<sourcecode type="cbor">		<sourcecode type="cbor"><![CDATA[
	/ NOTE: '\' line wrapping per RFC 8792 /		/ NOTE: '\' line wrapping per RFC 8792 /
	"p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.\		"p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.\
	LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"		LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"]]></sourcecode>
	</sourcecode>
	<t>		<t>
	The minimal-but-valid Response Bundle is shown in <xref target="fig-example-bund le-response"/>.		The minimal-but-valid Response Bundle is shown in <xref target="fig-example-bund le-response"/>.
	This response indicates that there is 30 seconds remaining in the response time window.		This response indicates that there are 30 seconds remaining in the response time window.
	</t>		</t>
	<figure anchor="fig-example-bundle-response">		<figure anchor="fig-example-bundle-response">
	<name>Example Response Bundle</name>		<name>Example Response Bundle</name>
	<sourcecode type="cbor">		<sourcecode type="cbor"><![CDATA[
	[_		[_
	[		[
	7, / BP version /		7, / BP version /
	0x02, / flags: payload-is-an-admin-record /		0x02, / flags: payload-is-an-admin-record /
	0, / CRC type: none /		0, / CRC type: none /
	[1, "//acme-server/"], / destination /		[1, "//acme-server/"], / destination /
	[1, "//acme-client/"], / source /		[1, "//acme-client/"], / source /
	[1, 0], / report-to: none /		[1, 0], / report-to: none /
	[1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 /		[1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 /
	30000 / lifetime: 30s /		30000 / lifetime: 30s /
	],		],
	[		[
	1, / block type code /		1, / block type code /
	1, / block number /		1, / block number /
	0, / flags /		0, / flags /
	0, / CRC type: none /		0, / CRC type: none /
	&lt;&lt;[ / block-type-specific data /		<<[ / block-type-specific data /
	0xFFFF, / record-type-code /		0xFF, / record-type-code /
	{ / record-content /		{ / record-content /
	1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /		1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
	2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /		2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
	3: [-16, b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew']		3: [-16, b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew']
	/ SHA-256 key auth. digest /		/ SHA-256 key auth. digest /
	}		}
	]>&gt;		]>&gt;
	]		]
	]		]]]></sourcecode>
	</sourcecode>
	</figure>		</figure>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-doc-ack" numbered="false">		<section anchor="sec-doc-ack" numbered="false">
	<name>Acknowledgments</name>		<name>Acknowledgements</name>
	<t>		<t>
	This specification is based on DTN use cases related to PKIX certificate issuanc e.		This specification is based on DTN use cases related to PKIX certificate issuanc e.
	</t>		</t>
	<t>		<t>
	The workflow and terminology of this validation method was originally copied fro		The workflow and terminology of this validation method were originally copied fr
	m the work of Alexey Melnikov in <xref target="RFC8823"/>.		om the work of <contact fullname="Alexey Melnikov"/> for email validation <xref
	</t>		target="RFC8823"/>.
	</section>
	<section numbered="false" removeInRFC="true">
	<name>Implementation Status</name>
	<t>
	[NOTE to the RFC Editor: please remove this section before publication, as well
	as the reference to <xref target="RFC7942"/> and <xref target="github-dtn-demo-a
	gent"/> and <xref target="github-dtn-wireshark"/>.]
	</t>
	<t>
	This section records the status of known implementations of the protocol defined
	by this specification at the time of posting of this Internet-Draft, and is bas
	ed on a proposal described in <xref target="RFC7942"/>.
	The description of implementations in this section is intended to assist the IET
	F in its decision processes in progressing drafts to RFCs.
	Please note that the listing of any individual implementation here does not impl
	y endorsement by the IETF.
	Furthermore, no effort has been spent to verify the information presented here t
	hat was supplied by IETF contributors.
	This is not intended as, and must not be construed to be, a catalog of available
	implementations or their features.
	Readers are advised to note that other implementations can exist.
	</t>
	<t>
	An example implementation of the this draft of ACME Node ID Validation has been
	created as a GitHub project <xref target="github-dtn-demo-agent"/> and is intend
	ed to use as a proof-of-concept and as a possible source of interoperability tes
	ting.
	</t>
	<t>
	A Wireshark dissector for of the this draft of ACME Node ID Validation has been
	created as a GitHub project <xref target="github-dtn-wireshark"/> and is intende
	d to be used to inspect and troubleshoot implementations.
	</t>		</t>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 199 change blocks.
	588 lines changed or deleted		547 lines changed or added
This html diff was produced by rfcdiff 1.48.