rfc9891.original   rfc9891.txt 
Automated Certificate Management Environment B. Sipos Internet Engineering Task Force (IETF) B. Sipos
Internet-Draft RKF Engineering Request for Comments: 9891 RKF Engineering
Intended status: Experimental 4 June 2025 Category: Experimental November 2025
Expires: 6 December 2025 ISSN: 2070-1721
Automated Certificate Management Environment (ACME) Delay-Tolerant Automated Certificate Management Environment (ACME) Delay-Tolerant
Networking (DTN) Node ID Validation Extension Networking (DTN) Node ID Validation Extension
draft-ietf-acme-dtnnodeid-18
Abstract Abstract
This document specifies an extension to the Automated Certificate This document specifies an extension to the Automated Certificate
Management Environment (ACME) protocol which allows an ACME server to Management Environment (ACME) protocol that allows an ACME server to
validate the Delay-Tolerant Networking (DTN) Node ID for an ACME validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
client. A DTN Node ID is an identifier used in the Bundle Protocol client. A DTN Node ID is an identifier used in the Bundle Protocol
(BP) to name a "singleton endpoint", one which is registered on a (BP) to name a "singleton endpoint": an endpoint that is registered
single BP node. The DTN Node ID is encoded as a certificate Subject on a single BP Node. The DTN Node ID is encoded both as a
Alternative Name (SAN) of type otherName with a name form of certificate Subject Alternative Name (SAN) identity of type otherName
BundleEID and as an ACME Identifier type "bundleEID". with an Other Name form of BundleEID and as an ACME Identifier type
"bundleEID".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 6 December 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9891.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope
1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 4 1.2. Authorization Strategy
1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Use of CDDL
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology
1.5. Experiment Scope . . . . . . . . . . . . . . . . . . . . 7 1.5. Experiment Scope
2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 9 2. Bundle EID ACME Identifier
2.1. Subsets of Bundle Endpoint ID . . . . . . . . . . . . . . 9 2.1. Subsets of Bundle EID
3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 10 3. DTN Node ID Validation
3.1. DTN Node ID Challenge Object . . . . . . . . . . . . . . 13 3.1. DTN Node ID Challenge Object
3.2. DTN Node ID Response Object . . . . . . . . . . . . . . . 14 3.2. DTN Node ID Response Object
3.3. ACME Node ID Validation Challenge Bundle . . . . . . . . 15 3.3. ACME Node ID Validation Challenge Bundle
3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 16 3.3.1. Challenge Bundle Checks
3.4. ACME Node ID Validation Response Bundles . . . . . . . . 17 3.4. ACME Node ID Validation Response Bundles
3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 18 3.4.1. Response Bundle Checks
3.5. Multi-Perspective Validation . . . . . . . . . . . . . . 19 3.5. Multi-Perspective Validation
4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 19 4. Bundle Integrity Gateway
5. Certificate Request Profile . . . . . . . . . . . . . . . . . 20 5. Certificate Request Profile
5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 20 5.1. Multiple Identity Claims
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-Only or Signing-Only Bundle Security
Certificates . . . . . . . . . . . . . . . . . . . . . . 21 Certificates
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations
6.1. Threat: Passive Leak of Validation Data . . . . . . . . . 22 6.1. Threat: Passive Leak of Validation Data
6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 22 6.2. Threat: BP Node Impersonation
6.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 22 6.3. Threat: Bundle Replay
6.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 23 6.4. Threat: Denial of Service
6.5. Inherited Security Considerations . . . . . . . . . . . . 23 6.5. Inherited Security Considerations
6.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 24 6.6. Out-of-Scope BP Agent Communication
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations
7.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 24 7.1. ACME Identifier Types
7.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 25 7.2. ACME Validation Methods
7.3. Bundle Administrative Record Types . . . . . . . . . . . 25 7.3. Bundle Administrative Record Types
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 27 8.2. Informative References
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 28 Appendix A. Administrative Record Types CDDL
Appendix B. Example Authorization . . . . . . . . . . . . . . . 29 Appendix B. Example Authorization
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 30 B.1. Challenge Bundle
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 30 B.2. Response Bundle
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 Acknowledgements
Implementation Status . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Although the original purpose of the Automatic Certificate Management Although the original purpose of the Automatic Certificate Management
Environment (ACME) [RFC8555] was to allow Public Key Infrastructure Environment (ACME) [RFC8555] was to allow Public Key Infrastructure
Using X.509 (PKIX) Certification Authorities (CAs) to validate using X.509 (PKIX) Certification Authorities (CAs) to validate
network domain names of clients, the same mechanism can be used to network domain names of clients, the same mechanism can be used to
validate any of the subject claims supported by the PKIX profile validate any of the subject identity claims supported by the PKIX
[RFC5280]. profile [RFC5280].
In the case of this specification, the claim being validated is a In this specification, the claim being validated is a Subject
Subject Alternative Name (SAN) of type otherName with a name form of Alternative Name (SAN) identity of type otherName with an Other Name
BundleEID, which used to represent a Bundle Protocol (BP) Endpoint ID form of BundleEID, which is used to represent a Bundle Protocol (BP)
(EID) in a Delay-Tolerant Networking (DTN) overlay network. A DTN Endpoint ID (EID) in a Delay-Tolerant Networking (DTN) overlay
Node ID is any EID which can uniquely identify a BP node, as defined network. A DTN Node ID is any EID that can uniquely identify a BP
in Section 4.2.5.2 of [RFC9171], which is equivalent to the EID being Node, as defined in Section 4.2.5.2 of [RFC9171], which is equivalent
usable as a singleton endpoint. One common EID used as a Node ID is to the EID being usable as a singleton endpoint. One common EID used
the Administrative EID, which is guaranteed to exist on any BP node. as a Node ID is the Administrative EID, which is guaranteed to exist
Currently the URI schemes "dtn" and "ipn" as defined in [RFC9171] are on any BP Node. At the time of writing, the URI schemes "dtn" and
valid for a singleton endpoint and thus a Node ID. Because the "ipn" as defined in Section 4.2.5.1 of [RFC9171] are valid for a
BundleEID claim is new to ACME, a new ACME Identifier type singleton endpoint and, thus, a Node ID. Because the BundleEID claim
"bundleEID" is needed to manage this claim within ACME messaging. is new to ACME, a new ACME Identifier type "bundleEID" is needed to
manage this claim within ACME messaging.
Once an ACME server validates a Node ID, either as a pre- Once an ACME server validates a Node ID, either as a pre-
authorization of the "bundleEID" or as one of the authorizations of authorization of an identifier type "bundleEID" as one of the
an order containing a "bundleEID", the client can finalize the order authorizations of an order containing an identifier type "bundleEID",
using an associated certificate signing request (CSR). Because a the client can finalize the order using an associated Certificate
single order can contain multiple identifiers of multiple types, Signing Request (CSR). Because a single order can contain multiple
there can be operational issues for a client attempting to, and identifiers of multiple types, there can be operational issues for a
possibly failing to, validate those multiple identifiers as described client attempting to, and possibly failing to, validate those
in Section 5.1. Once a certificate is issued for a Node ID, how the multiple identifiers as described in Section 5.1. Once a certificate
ACME client configures the BP Agent with the new certificate is an is issued for a Node ID, how the ACME client configures the BP Agent
implementation matter. with the new certificate is an implementation matter.
1.1. Scope 1.1. Scope
This document describes the ACME message contents [RFC8555], Bundle This document describes the ACME message contents [RFC8555], Bundle
Protocol version 7 (BPv7) payloads [RFC9171], and Bundle protocol Protocol version 7 (BPv7) payloads [RFC9171], and Bundle Protocol
Security (BPSec) operations [RFC9172] needed to validate claims of Security (BPSec) operations [RFC9172] needed to validate claims of
Node ID ownership. Node ID ownership.
This document does not address: This document does not address:
* Mechanisms for communication between ACME client or ACME server * Mechanisms for communication between an ACME client or ACME server
and their associated BP agent(s). This document only describes and their associated BP Agent(s), depicted as steps 1, 2, 5, and 6
exchanges between ACME client--server pairs and between their BP of Figure 1. This document only describes exchanges between ACME
agents. client-server pairs and between their respective associated BP
Agents.
* Specific BP extension blocks or BPSec security contexts necessary * Specific BP extension blocks or BPSec contexts necessary to
to fulfill the security requirements of this protocol. The exact fulfill the security requirements of this protocol. The exact
security context needed, and their parameters, are network- security context needed, and its parameters, is network specific.
specific.
* Policies or mechanisms for defining or configuring bundle * Policies or mechanisms for defining or configuring Bundle
integrity gateways, or trusting integrity gateways on an integrity gateways, or trusting integrity gateways on an
individual entity or across a network. individual entity or across a network.
* Mechanisms for locating or identifying other bundle entities * Mechanisms for locating or identifying other Bundle entities
(peers) within a network or across an internet. The mapping of (peers) within a network or across an internet. The mapping of a
Node ID to potential convergence layer (CL) protocol and network Node ID to a potential Convergence-Layer (CL) protocol and network
address is left to implementation and configuration of the BP address is left to implementation and configuration of the BP
Agent and its various potential routing strategies. Agent and its various potential routing strategies.
* 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 This protocol is involved only in creating Bundles at a source and
handling them at a destination. handling them at a destination.
* Logic for performing rate control and congestion control of bundle * Logic for performing rate control and congestion control of Bundle
transfers. The ACME server is responsible for rate control of transfers. The ACME server is responsible for rate control of
validation requests. validation requests.
* Policies or mechanisms for an ACME server to choose a prioritized * Policies or mechanisms for an ACME server to choose a prioritized
list of acceptable hash algorithms, or for an ACME client to list of acceptable hash algorithms or for an ACME client to choose
choose a set of acceptable hash algorithms. a set of acceptable hash algorithms.
* Policies or mechanisms for provisioning, deploying, or accessing * Policies or mechanisms for provisioning, deploying, or accessing
certificates and private keys; deploying or accessing certificate certificates and private keys; deploying or accessing Certificate
revocation lists (CRLs); or configuring security parameters on an Revocation Lists (CRLs); or configuring security parameters on an
individual entity or across a network. individual entity or across a network.
* Policies or mechanisms for an ACME server to handle mixed-use * Policies or mechanisms for an ACME server to handle mixed-use
certificate signing requests. This specification is focused only certificate signing requests. This specification is focused only
on single-use DTN-specific PKIX profiles. on single-use DTN-specific PKIX profiles.
1.2. Authorization Strategy 1.2. Authorization Strategy
The basic unit of data exchange in a DTN is a Bundle [RFC9171], which The basic unit of data exchange in a DTN is a Bundle [RFC9171], which
consists of a data payload with accompanying metadata. An Endpoint consists of a data payload with accompanying metadata. An EID is
ID is used as the destination of a Bundle and can indicate both a used as the destination of a Bundle and can indicate both a singleton
singleton or a group destination. A Node ID is used to identify the or a group destination. A Node ID is used to identify the source of
source of a Bundle and is used for routing through intermediate a Bundle and is used for routing through intermediate nodes,
nodes, including the final node(s) used to deliver a Bundle to its 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 destination endpoint. A Node ID can also be used as an endpoint for
administrative bundles. More detailed descriptions of the rationale administrative Bundles. More detailed descriptions of the rationale
and capabilities of these networks can be found in "Delay-Tolerant and capabilities of these networks can be found in the
Network Architecture" [RFC4838]. "Delay-Tolerant Networking Architecture" [RFC4838].
When an ACME client requests a pre-authorization or an order with a When an ACME client requests a pre-authorization or an order with an
"bundleEID" identifier type (Section 2), the ACME server offers a identifier type "bundleEID" (Section 2), the ACME server offers a
"bp-nodeid-00" challenge type (Section 3) to validate that Node ID. "bp-nodeid-00" challenge type (Section 3) to validate that Node ID.
If the ACME client attempts the authorization challenge to validate a If the ACME client attempts the authorization challenge to validate a
Node ID, the ACME server sends an ACME Node ID Validation Challenge Node ID, the ACME server sends an ACME Node ID Validation Challenge
Bundle with a destination of the Node ID being validated. The BP Bundle with a destination of the Node ID being validated. The BP
agent on that node receives the Challenge Bundle, generates an ACME Agent on that node receives the Challenge Bundle, generates an ACME
key authorization digest, and sends an ACME Node ID Validation Key Authorization digest, and sends an ACME Node ID Validation
Response Bundle in reply. An Integrity Gateway on the client side of Response Bundle in reply. An Integrity Gateway on the client side of
the DTN can be used to attest to the source of the Response Bundle. 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 Finally, the ACME server receives the Response Bundle and checks that
the digest was generated for the associated ACME challenge and from the digest was generated for the associated ACME challenge and from
the client account key associated with the original request. This the client account key associated with the original request. This
workflow is shown in the diagram of Figure 1. workflow is shown in Figure 1.
+------------+ +------------+ +------------+ +------------+
| ACME |<===== HTTPS exchanges =====>| ACME | | ACME |<===== HTTPS Exchanges =====>| 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 |<------------- Bundle -----| Server's | | | Client's |<------------- Bundle -----| Server's | |
| BP Agent | | BP Agent | | | BP Agent | | BP Agent | |
+--------------+ +--------------+ | +--------------+ +--------------+ |
| +----^---------+ | +----^---------+
| +-------------+ | | +-------------+ |
| | Integrity | (4) Response | | | Integrity | (4) Response |
+---->| Gateway |------ Bundle --------+ +---->| Gateway |------ Bundle --------+
+-------------+ +-------------+
Figure 1: The relationships and flows between Node ID Validation Figure 1: The Relationships and Flows Between Node ID Validation
entities Entities
Because the DTN Node ID is used both for routing bundles between BP Because the DTN Node ID is used both for routing Bundles between BP
agents and for multiplexing administrative services within a BP Agents and for multiplexing administrative services within a BP
agent, there is no possibility to separate the ACME validation of a Agent, there is no possibility to separate the ACME validation of a
Node ID from normal bundle handling for that same Node ID. This Node ID from normal Bundle handling for that same Node ID. This
leaves administrative record types as a way to keep the Node ID leaves administrative record types as a way to keep the Node ID
unchanged while disambiguating from other service data bundles. unchanged while disambiguating from other service data Bundles.
There is nothing in this protocol which requires network-topological There is nothing in this protocol that requires network-topological
co-location of either the ACME client or ACME server with their co-location of either the ACME client or ACME server with their
associated BP agent. While ACME requires a low-enough latency respective associated BP Agent. While ACME requires a low-enough
network to perform HTTPS exchanges between ACME client and server, latency network to perform HTTPS exchanges between the ACME client
the client's BP agent (the one being validated) could be on the far and server, the client's BP Agent (the one being validated) could be
side of a long-delay or multi-hop BP network. The means by which the on the far side of a long-delay or multi-hop BP network. The means
ACME client or server communicates with its associated BP agent is an by which the ACME client or server communicates with its associated
implementation matter. BP Agent is an implementation matter.
1.3. Use of CDDL 1.3. Use of CDDL
This document defines CBOR structure using the Concise Data This document defines Concise Binary Object Representation (CBOR)
Definition Language (CDDL) of [RFC8610]. The entire CDDL structure structure using the Concise Data Definition Language (CDDL)
can be extracted from the XML version of this document using the [RFC8610]. The entire CDDL structure can be extracted from the XML
XPath expression: version of this document using the XPath expression:
'//sourcecode[@type="cddl"]' '//sourcecode[@type="cddl"]'
The following initial fragment defines the top-level symbols of this The following initial fragment defines the top-level symbols of this
document's CDDL, which includes the example CBOR content. document's CDDL, which includes the example CBOR content.
start = acme-record / bundle / tstr start = acme-record / bundle / tstr
1.4. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Because this document combines two otherwise unrelated contexts, ACME Because this document combines two otherwise unrelated contexts, ACME
and DTN, when a protocol term applies to one of those areas and is and DTN, when a protocol term applies to one of those areas and is
used in the other its name is prefixed with either "ACME" or "DTN" used in the other its name is prefixed with either "ACME" or "DTN"
respectively. Thus within the ACME context the term is "DTN Node ID" respectively. Thus, within the ACME context the term is "DTN Node
while in the DTN context the name is just "Node ID". ID" while in the DTN context the name is just "Node ID".
In this document, several terms are shortened for the sake of In this document, several terms are shortened for the sake of
terseness. These terms are: brevity. These terms are as follows:
Challenge Object: 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 Challenge Object". It is a JSON object created by the ACME server
for challenge type "bp-nodeid-00" as defined in Section 3.1. for challenge type "bp-nodeid-00" as defined in Section 3.1.
Response Object: 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 Response Object". It is a JSON object created by the ACME client
to authorize a challenge type "bp-nodeid-00" as defined in to authorize a challenge type "bp-nodeid-00" as defined in
Section 3.2. Section 3.2.
Challenge Bundle: This is a shortened form of the full "ACME Node ID Challenge Bundle: This is a shortened form of the full "ACME Node ID
Validation Challenge Bundle". It is a Bundle created by the BP Validation Challenge Bundle". It is a Bundle created by the BP
agent managed by the ACME server to challenge a Node ID claim as Agent managed by the ACME server to challenge a Node ID claim as
defined in Section 3.3. defined in Section 3.3.
Response Bundle: This is a shortened form of the full "ACME Node ID Response Bundle: This is a shortened form of the full "ACME Node ID
Validation Response Bundle". It is a Bundle created by the BP Validation Response Bundle". It is a Bundle created by the BP
agent managed by the ACME client to validate a Node ID claim as Agent managed by the ACME client to validate a Node ID claim as
defined in Section 3.4. defined in Section 3.4.
Because this is an ACME document, the following DTN Bundle Protocol Because this is a document produced by the ACME WG, the following DTN
terms are defined here to clarify how they are used by this ACME BP terms are defined here to clarify how they are used by this ACME
identifier type and validation mechanism. identifier type and validation mechanism.
Endpoint ID: An Endpoint ID is an identifier for the ultimate Endpoint ID: An EID is an identifier for the ultimate destination of
destination of a bundle, independent of any intermediate a Bundle, independent of any intermediate forwarding needed to
forwarding needed to reach that destination. An endpoint can be a reach that destination. An endpoint can be a singleton or not, so
singleton or not, so an Endpoint ID can also represent a single an EID can also represent a single entity or a set of entities.
entity or a set of entities. This is formally defined in This is formally defined in Section 4.2.5.1 of [RFC9171].
Section 4.2.5.1 of [RFC9171].
Node ID: A Node ID is a (not guaranteed unique) identifier for a Node ID: A Node ID is an identifier (that is not guaranteed to be
specific node in a network in the form of a singleton Endpoint ID. unique) for a specific node in a network in the form of a
A single node can have any number of Node IDs but a typical (and singleton EID. A single node can have any number of Node IDs, but
expected) form of Node ID is the Administrative Endpoint ID a typical (and expected) form of Node ID is the Administrative EID
(described below). This is formally defined in Section 4.2.5.2 of (described below). This is formally defined in Section 4.2.5.2 of
[RFC9171]. [RFC9171].
Administrative Endpoint ID: An Administrative Endpoint ID is unique Administrative EID: An Administrative EID is unique for a node
for a node within a specific URI scheme. Although any Node ID can within a specific URI scheme. Although any Node ID can be a valid
be a valid bundle Source and Destination, the Administrative Bundle Source and Destination, the Administrative EID is a minimum
Endpoint ID is a minimum required Node ID for any node operating required Node ID for any node operating in a particular URI
in a particular URI scheme. For the "dtn" scheme this is the scheme. For the "dtn" scheme, this is the empty demux part; for
empty demux part and for the "ipn" scheme this is the service the "ipn" scheme, this is the service number zero. These are
number zero. These is formally defined under Section 4.2.5.1 of formally defined under Section 4.2.5.1 of [RFC9171].
[RFC9171].
1.5. Experiment Scope 1.5. Experiment Scope
The emergent properties of DTN naming and BP security are still being The emergent properties of DTN naming and BP security are still being
developed and explored, especially between different organizational developed and explored, especially between different organizational
and administrative domains, so the "experimental" status of this and administrative domains. Thus, the Experimental status of this
document is related more to the practical utility of this kind of document is related more to the practical utility of this kind of
Node ID validation than to the validation method itself. The Node ID validation than to the validation method itself. The
original use case is in large or cross-organizational networks where original use case is in large or cross-organizational networks where
a BP node can be trusted to be allocated and added to a network, but a BP Node can be trusted to be allocated and added to a network, but
the method of certificate validation and issuance is desired to be the method of certificate validation and issuance is desired to be
in-band on the network rather than configured solely through a side in-band on the network rather than configured solely through a side
channel using bespoke or manual protocols. Because this mechanism is channel using bespoke or manual protocols. Because this mechanism is
so similar to other validation methods, specifically [RFC8823], it is so similar to other validation methods, specifically email address
expected to have few implementation difficulties or interoperability validation [RFC8823], it is expected to have few implementation
issues. difficulties or interoperability issues.
Part of the experimental nature of the validation method defined in Part of the experimental nature of the validation method defined in
Section 3, and BP more generally, is understanding its vulnerability Section 3, and BP more generally, is understanding its vulnerability
to different kinds of on-path attacks. Some attacks could be based to different kinds of on-path attacks. Some attacks could be based
on the topology of the BP overlay network, while others could be on the topology of the BP overlay network, while others could be
based on the underlying (internet protocol) network topology. based on the underlying (IP) network topology. Because not all of
Because not all of the attack surfaces of this validation method are the attack surfaces of this validation method are known or fully
known or fully understood the usefulness of the multi-perspective understood, the usefulness of the multi-perspective technique
technique described in Section 3.5 is also not assured. The point of described in Section 3.5 is also not assured. The point of those
those multi-perspective requirements is so that both the ACME client multi-perspective requirements is that both the ACME client and
and server have consistent logic for handling the technique. server have consistent logic for handling the technique.
The usefulness of the integrity gateway defined in Section 4 to this The usefulness of the integrity gateway defined in Section 4 to this
validation method is experimental because it is not a settled matter validation method is experimental: the way that naming authority in a
how naming authority in a DTN is either allocated, delegated, or DTN is either allocated, delegated, or enforced is not a settled
enforced. It is also not defined how the organization running the CA matter. How the organization running the CA (and its ACME server)
(and its ACME server) can delegate some level of trust to a different can delegate some level of trust to a different organization running
organization running a connected DTN with a security gateway. The a connected DTN with a security gateway is also not defined. The
organization running the integrity gateway would need to apply some organization running the integrity gateway would need to apply some
minimal amount of policy to nodes running behind it, such as patterns minimal amount of policy to nodes running behind it, such as patterns
to their Node IDs, which would behave conceptually similar to to their Node IDs, which would behave conceptually similar to
delegation of sub-domains in the domain name system (DNS) but without delegation of subdomains in the Domain Name System (DNS), but without
the online interaction of DNS. the online interaction of DNS.
A successful experiment of this validation method would involve using A successful experiment of this validation method would involve using
the ACME protocol along with this Node ID validation to allow issuing the ACME protocol along with this Node ID validation to allow issuing
of identity certificates across administrative domains. One possible of identity certificates across administrative domains. One possible
scenario for this would be an issuing CA and an ACME server on the 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 edge of a BP transit network operated by some agency. This transit
accessed via edge routers operated by a second agency, used by edge network is used by edge nodes and accessed via edge routers of a peer
nodes known to and trusted by the second agency but not the first. network operated by a second agency. The nodes of the peer network
The transit network can refuse to route traffic that is not traceable are trusted by the second agency but not the first. The transit
to a valid identity certificate, which the edge nodes can obtain via network can refuse to route traffic from the peer network that is not
the ACME server. traceable to a valid identity certificate, which the edge nodes can
obtain via the ACME server.
A valuable result from any experiment, even unsuccessful, would be A valuable result from any experiment, even an unsuccessful one,
feedback about this method to improve later versions. That feedback would be feedback about this method to improve later versions. That
could include improvements to object or message structure, random vs. feedback could include improvements to object or message structure,
deterministic token values, client or server procedures, or naming random versus deterministic token values, client or server
more generally. procedures, or naming more generally.
2. Bundle Endpoint ID ACME Identifier 2. Bundle EID ACME Identifier
This specification is the first to make use of a Bundle Endpoint ID This specification is the first to make use of a Bundle EID to
to identify a claim for a certificate request in ACME. In this identify a claim for a certificate request in ACME. In this
document, the only purpose for which a Bundle Endpoint ID ACME document, the only purpose for which a Bundle EID ACME identifier is
identifier is validated is as a DTN Node ID (see Section 3), but validated is as a DTN Node ID (see Section 3), but other
other specifications can define challenge types for other Endpoint ID specifications can define challenge types for other EID uses.
uses.
Every identifier of type "bundleEID" SHALL have a value containing a Every ACME identifier type "bundleEID" SHALL have a value containing
text URI consistent with the requirements of Section 4.2.5.1 of a text URI consistent with the requirements of Section 4.2.5.1 of
[RFC9171] using one of the schemes available from the "Bundle [RFC9171] using one of the schemes available from the "Bundle
Protocol URI Scheme Types" registry of [IANA-BP]. Any "bundleEID" Protocol URI Scheme Types" registry [IANA-BP]. Any identifier type
value which fails to properly percent-decode SHALL be rejected with "bundleEID" value that fails to properly percent-decode SHALL be
an ACME error type of "malformed". rejected with an ACME error type of "malformed".
An ACME server supporting identifiers of type "bundleEID" SHALL An ACME server supporting identifier type "bundleEID" SHALL decode
decode and normalize (based on scheme-specific syntax) all such and normalize (based on scheme-specific syntax) all such received
received identifiers. Any "bundleEID" value for which the scheme- identifier values. Any identifier type "bundleEID" value for which
specific part does not match the scheme-specific syntax SHALL be the scheme-specific part does not match the scheme-specific syntax
rejected with an ACME error type of "malformed". Any "bundleEID" SHALL be rejected with an ACME error type of "malformed". Any
value which uses a scheme not handled by the ACME server SHALL be identifier type "bundleEID" value that uses a scheme not handled by
rejected with an ACME error type of "rejectedIdentifier". the ACME server SHALL be rejected with an ACME error type of
"rejectedIdentifier".
When an ACME server needs to request proof that a client controls a When an ACME server needs to request proof that a client controls a
Bundle EID, it SHALL create an authorization with the identifier type Bundle EID, it SHALL create an authorization with the identifier type
"bundleEID". An ACME server SHALL NOT attempt to dereference a "bundleEID". An ACME server SHALL NOT attempt to dereference a
Bundle EID value on its own. It is the responsibility of an ACME Bundle EID value on its own. It is the responsibility of an ACME
validation method to ensure the EID ownership using a method validation method to ensure the EID ownership using a method
authorized by the ACME client. authorized by the ACME client.
An identifier for the Node ID of "dtn://example/" would be formatted An identifier for the Node ID of "dtn://example/" would be formatted
as: as:
{ {
"type": "bundleEID", "type": "bundleEID",
"value": "dtn://example/" "value": "dtn://example/"
} }
2.1. Subsets of Bundle Endpoint ID 2.1. Subsets of Bundle EID
While the PKIX other name form of BundleEID can hold any Endpoint ID A PKIX certificate SAN identity containing an Other Name form of
value, the certificate profile used by [RFC9174] and supported by BundleEID can hold any EID value (as a text URI). But the
this ACME validation method in Section 3 requires that the value hold certificate profile used by the TCP Convergence Layer [RFC9174] and
a Node ID (Section 1.4). supported by the ACME validation method in Section 3 requires that
the value hold a Node ID (Section 1.4).
In addition to the narrowing of that certificate profile, this In addition to the narrowing of that certificate profile, this
validation method requires that the client's BP agent responds to validation method requires that the client's BP Agent respond to
administrative records sent to the Node ID being validated. This administrative records sent to the Node ID being validated.
typically is limited to an Administrative Endpoint ID (Section 1.4), Typically, this is limited to an Administrative EID (Section 1.4)
but there is no prohibition on the administrative element of a BP destination. However, the administrative element of a BP Node is not
node from receiving administrative records for, and sending records prohibited from receiving administrative records for, or sending
from, other Node IDs in order to support this validation method. records from, other Node IDs in order to support this validation
method.
Neither that certificate profile nor this validation method support Neither that certificate profile nor this validation method support
operating on non-singleton Endpoint IDs, but other validation methods operating on non-singleton EIDs, but other validation methods could
could be defined to do so in order to support other certificate be defined to do so in order to support other certificate profiles.
profiles.
3. DTN Node ID Validation 3. DTN Node ID Validation
The DTN Node ID validation method proves control over a Node ID by 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 requiring the ACME client to configure a BP Agent to respond to
specific Challenge Bundles sent from the ACME server. The ACME specific Challenge Bundles sent from the ACME server. The ACME
server validates control of the Node ID by verifying that received server validates control of the Node ID by verifying that received
Response Bundles correspond with the BP Node and client account key Response Bundles correspond with the BP Node and client account key
being validated. being validated.
Similar to the ACME use case for validating email address ownership Similar to the ACME use case for email-address validation [RFC8823],
[RFC8823], this challenge splits the token into several parts, each this challenge splits the token into several parts, each part being
being transported by a different channel, and the Key Authorization transported by a different channel, and the Key Authorization result
result requires combining all parts of the token. A separate requires combining all parts of the token. A separate challenge
challenge identifier is used as a filter by BP agents similarly to identifier is used as a filter by BP Agents similar to the challenge
the challenge "from" email address of [RFC8823]. "from" used by email validation in Section 3 of [RFC8823].
The token parts are: The token parts are as follows:
token-chal: This token is unique to each ACME authorization. It is token-chal:
contained in the Challenge Object of Section 3.1. Each This token is unique to each ACME authorization. It is contained
authorization can consist of multiple Challenge Bundles (e.g. in the Challenge Object of Section 3.1. Each authorization can
taking different routes), but they all share the same token-chal consist of multiple Challenge Bundles (e.g., taking different
value. This ensures that the Key Authorization is bound to the routes), but they all share the same token-chal value. This
specific ACME challenge (and parent ACME authorization). This ensures that the Key Authorization is bound to the specific ACME
token does not appear on the BP channel so that any eavesdropper challenge (and parent ACME authorization). This token does not
knowing the client's account key thumbprint (e.g. from some other appear on the BP channel; thus, any eavesdropper knowing the
validation method) is not able to impersonate the client. client's account key thumbprint (e.g., from some other validation
method) is not able to impersonate the client.
token-bundle: This token is unique to each Challenge Bundle sent by token-bundle:
the ACME server. It is contained in the Challenge Bundle of This token is unique to each Challenge Bundle sent by the ACME
Section 3.3 and Response Bundle of Section 3.4. This ensures that server. It is contained in the Challenge Bundle of Section 3.3
the Key Authorization is bound to the ability to receive the and Response Bundle of Section 3.4. This ensures that the Key
Challenge Bundle and not just have access to the ACME Challenge Authorization is bound to the ability to receive the Challenge
Object. This token is also accessible to DTN on-path Bundle and not just having access to the ACME Challenge Object.
eavesdroppers. This token is also accessible to DTN on-path eavesdroppers.
Because multiple Challenge Bundles can be sent to validate the same Because multiple Challenge Bundles can be sent to validate the same
Node ID, the token-bundle in the response is needed to correlate with Node ID, the token-bundle in the response is needed to correlate with
the expected Key Authorization digest. the expected Key Authorization digest.
The DTN Node ID Challenge SHALL only be allowed for an EID usable as The DTN Node ID Challenge Object SHALL only be allowed for an EID
a DTN Node ID, which is defined per-scheme in Section 4.2.5.1 of usable as a DTN Node ID, which is defined per-scheme in
[RFC9171]. When an ACME server supports Node ID validation, the ACME Section 4.2.5.1 of [RFC9171]. When an ACME server supports Node ID
server SHALL provide a challenge object in accordance with validation, the ACME server SHALL provide a Challenge Object in
Section 3.1. Once this challenge object is defined, the ACME client accordance with Section 3.1. Once this Challenge Object is defined,
may begin the validation. the ACME client may begin the validation.
To initiate a Node ID validation, the ACME client performs the To initiate a Node ID validation, the ACME client performs the
following steps: following steps:
1. The ACME client POSTs a newOrder or newAuthz request including 1. The ACME client POSTs a newOrder or newAuthz request including
the identifier of type "bundleEID" for the desired Node ID. From the identifier type "bundleEID" for the desired Node ID. From
either of these entry points an authorization for the "bundleEID" either of these entry points, an authorization for the identifier
type is indicated by the ACME server. See Section 7.4 of type "bundleEID" is indicated by the ACME server. See
[RFC8555] for more details. Section 7.4 of [RFC8555] for more details.
2. The ACME client obtains the id-chal and token-chal from the 2. The ACME client obtains the id-chal and token-chal from the
challenge object (Section 3.1) contained in an authorization Challenge Object (Section 3.1) contained in an authorization
object associated with the order in accordance with Section 7.1.4 object associated with the order in accordance with Section 7.1.4
of [RFC8555]. of [RFC8555].
3. The ACME client indicates to the administrative element of its BP 3. The ACME client indicates to the administrative element of its BP
agent the id-chal which is authorized for use along with the Agent the id-chal that is authorized for use along with the
associated token-chal and client account key thumbprint. The associated token-chal and client account key thumbprint. The
ACME client waits, if necessary, until the agent is configured ACME client waits, if necessary, until the Agent is configured
before proceeding to the next step. before proceeding to the next step.
4. The ACME client POSTs a response object (Section 3.2) to the 4. The ACME client POSTs a response object (Section 3.2) to the
challenge URL on the ACME server accordance with Section 7.5.1 of challenge URL on the ACME server in accordance with Section 7.5.1
[RFC8555]. The payload object is constructed in accordance with of [RFC8555]. The payload object is constructed in accordance
Section 3.2. with Section 3.2.
5. The administrative element waits for a Challenge Bundle to be 5. The administrative element waits for a Challenge Bundle to be
received with the authorized ACME parameters, including its id- received with the authorized ACME parameters, including its id-
chal payload, in accordance with Section 3.3. chal payload, in accordance with Section 3.3.
6. The administrative element concatenates token-bundle with token- 6. The administrative element concatenates token-bundle with token-
chal (each as base64url-encoded text strings) and computes the chal (each as base64url-encoded text strings) and computes the
Key Authorization in accordance with Section 8.1 of [RFC8555] Key Authorization in accordance with Section 8.1 of [RFC8555]
using the full token and client account key thumbprint. using the full token and client account key thumbprint.
7. The administrative element chooses the highest-priority hash 7. The administrative element chooses the highest-priority hash
algorithm supported by both the client and server, uses that algorithm supported by both the client and server, uses that
algorithm to compute the digest of the Key Authorization result, algorithm to compute the digest of the Key Authorization result,
and generates a Response Bundle to send back to the ACME server and generates a Response Bundle to send back to the ACME server
in accordance with Section 3.4. in accordance with Section 3.4.
8. The ACME client waits for the authorization to be finalized on 8. The ACME client waits for the authorization to be finalized on
the ACME server in accordance with Section 7.5.1 of [RFC8555]. the ACME server in accordance with Section 7.5.1 of [RFC8555].
9. Once the challenge is completed (successfully or not), the ACME 9. Once the challenge is completed (successfully or not), the ACME
client indicates to the BP agent that the id-chal is no longer client indicates to the BP Agent that the id-chal is no longer
usable. If the authorization fails, the ACME client MAY retry usable. If the authorization fails, the ACME client MAY retry
the challenge from Step 3. the challenge from Step 3.
The ACME server verifies the client's control over a Node ID by The ACME server verifies the client's control over a Node ID by
performing the following steps: performing the following steps:
1. The ACME server receives a newOrder or newAuthz request including 1. The ACME server receives a newOrder or newAuthz request including
the identifier of type "bundleEID", where the URI value is a Node the identifier type "bundleEID", where the URI value is a Node
ID. ID.
2. The ACME server generates an authorization for the Node ID with 2. The ACME server generates an authorization for the Node ID with
challenge type "bp-nodeid-00" in accordance with Section 3.1. challenge type "bp-nodeid-00" in accordance with Section 3.1.
3. The ACME server receives a POST to the challenge URL indicated 3. The ACME server receives a POST to the challenge URL indicated
from the authorization object. The payload is handled in from the authorization object. The payload is handled in
accordance with Section 3.2. accordance with Section 3.2.
4. The ACME server sends, via the administrative element of its BP 4. The ACME server sends, via the administrative element of its BP
agent, one or more Challenge Bundles in accordance with Agent, one or more Challenge Bundles in accordance with
Section 3.3. Each challenge bundle contains a distinct, random Section 3.3. Each Challenge Bundle contains a distinct, random
token-bundle to be able to correlate with a response bundle. token-bundle to be able to correlate with a Response Bundle.
Computing an expected Key Authorization digest is not necessary Computing an expected Key Authorization digest is not necessary
until a response is received with a chosen hash algorithm. until a response is received with a chosen hash algorithm.
5. The ACME server waits for Response Bundle(s) for a limited 5. The ACME server waits for a Response Bundle(s) for a limited
interval of time (based on the response object of Section 3.2). interval of time (based on the response object of Section 3.2).
Responses are encoded in accordance with Section 3.4. Responses are encoded in accordance with Section 3.4.
6. Once received and decoded, the ACME server checks the contents of 6. Once received and decoded, the ACME server checks the contents of
each Response Bundle in accordance with Section 3.4.1. After all each Response Bundle in accordance with Section 3.4.1. After all
Challenge Bundles have either been responded to or timed-out, the Challenge Bundles have either been responded to or timed-out, the
ACME server policy (see Section 3.5) determines whether the ACME server policy (see Section 3.5) determines whether the
validation is successful. If validation is not successful, a validation is successful. If validation is not successful, a
client may retry the challenge which starts in Step 3. client may retry the challenge that starts in Step 3.
When responding to a Challenge Bundle, a BP agent SHALL send a single When responding to a Challenge Bundle, a BP Agent SHALL send a single
Response Bundle in accordance with Section 3.4. A BP agent SHALL Response Bundle in accordance with Section 3.4. A BP Agent SHALL
respond to ACME challenges only within the interval of time and only respond to ACME challenges only within the interval of time and only
for the id-chal indicated by the ACME client. A BP agent SHALL for the id-chal indicated by the ACME client. A BP Agent SHALL
respond to multiple Challenge Bundles with the same ACME parameters respond to multiple Challenge Bundles with the same ACME parameters
but different bundle identities (source Node ID and timestamp); these but different Bundle identities (source Node ID and timestamp); these
correspond with the ACME server validating via multiple routing correspond with the ACME server validating via multiple routing
paths. paths.
3.1. DTN Node ID Challenge Object 3.1. DTN Node ID Challenge Object
The DTN Node ID Challenge object is included by the ACME server as The DTN Node ID Challenge Object is included by the ACME server as
defined in Section 7.5 of [RFC8555] when it supports validating Node defined in Section 7.5 of [RFC8555] when it supports validating Node
IDs. IDs.
The DTN Node ID Challenge object has the following content: The DTN Node ID Challenge Object has the following content:
type (required, string): The string "bp-nodeid-00". type (required, string): The string "bp-nodeid-00".
id-chal (required, string): This is a random value associated with a id-chal (required, string): This is a random value associated with a
challenge which allows a client to filter valid Challenge Bundles challenge that allows a client to filter valid Challenge Bundles
(Section 3.3). The same value is used for all Challenge Bundles (Section 3.3). The same value is used for all Challenge Bundles
associated with an ACME challenge, including multi-perspective associated with an ACME challenge, including multi-perspective
validation using multiple sources as described in Section 3.5. validation using multiple sources as described in Section 3.5.
This value SHALL have at least 128 bits of entropy. It SHALL NOT This value SHALL have at least 128 bits of entropy. It SHALL NOT
contain any characters outside the base64url alphabet as described contain any characters outside the base64url alphabet as described
in Section 5 of [RFC4648]. Trailing '=' padding characters SHALL in Section 5 of [RFC4648]. Trailing '=' padding characters SHALL
be stripped. See [RFC4086] for additional information on be stripped. See BCP 106 [RFC4086] for additional information on
randomness requirements. randomness requirements.
token-chal (required, string): This is a random value, used as part token-chal (required, string): This is a random value, used as part
of the Key Authorization algorithm, which is communicated to the of the Key Authorization algorithm, which is communicated to the
ACME client only over the ACME channel. This value SHALL have at ACME client only over the ACME channel. This value SHALL have at
least 128 bits of entropy. It SHALL NOT contain any characters least 128 bits of entropy. It SHALL NOT contain any characters
outside the base64url alphabet as described in Section 5 of outside the base64url alphabet as described in Section 5 of
[RFC4648]. Trailing '=' padding characters SHALL be stripped. [RFC4648]. Trailing '=' padding characters SHALL be stripped.
See [RFC4086] for additional information on randomness See BCP 106 [RFC4086] for additional information on randomness
requirements. requirements.
{ {
"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"
} }
The token-chal value included in this object applies to the entire The token-chal value included in this object applies to the entire
challenge, and may correspond with multiple separate token-bundle challenge and may correspond with multiple separate token-bundle
values when multiple Challenge Bundles are sent for a single values when multiple Challenge Bundles are sent for a single
validation. validation.
3.2. DTN Node ID Response Object 3.2. DTN Node ID Response Object
The DTN Node ID response object is sent by the ACME client when it The DTN Node ID response object is sent by the ACME client when it
authorizes validation of a Node ID as defined in Section 7.5.1 of authorizes validation of a Node ID as defined in Section 7.5.1 of
[RFC8555]. Because a DTN has the potential for significantly longer [RFC8555]. Because a DTN has the potential for significantly longer
(but roughly predictable) delays than a non-DTN network, the ACME (but roughly predictable) delays than a non-DTN network, the ACME
client is able to inform the ACME server if a particular validation client is able to inform the ACME server if a particular validation
round-trip is expected to take longer than non-DTN network delays (on round-trip is expected to take longer than non-DTN network delays (on
the order of seconds). the order of seconds).
The DTN Node ID response object has the following content: The DTN Node ID response object has the following content:
rtt (optional, number): An expected round-trip time (RTT), in rtt (optional, number): An expected Round-Trip Time (RTT), in
seconds, between sending a Challenge Bundle and receiving a seconds, between sending a Challenge Bundle and receiving a
Response Bundle. This value is a hint to the ACME server for how Response Bundle. This value is a hint to the ACME server for how
long to wait for responses but is not authoritative. The minimum long to wait for responses but is not authoritative. The minimum
RTT value SHALL be zero. There is no special significance to RTT value SHALL be zero. There is no special significance to
zero-value RTT, it simply indicates the response is expected in zero-value RTT, it simply indicates the response is expected in
less than the least significant unit used by the ACME client. less than the least significant unit used by the ACME client.
{ {
"rtt": 300.0 "rtt": 300.0
} }
A response object SHALL NOT be sent until the BP agent has been A response object SHALL NOT be sent until the BP Agent has been
configured to properly respond to the challenge. The RTT value is configured to properly respond to the challenge. The RTT value is
meant to indicate any node-specific path delays expected to be meant to indicate any node-specific path delays expected to be
encountered from the ACME server. Because there is no requirement on encountered from the ACME server. Because there is no requirement on
the path (or paths) which bundles may traverse between the ACME the path (or paths) regarding which Bundles may traverse between the
server and the BP agent, and the ACME server can attempt some path ACME server and the BP Agent, and the ACME server can attempt some
diversity, the RTT value SHOULD be pessimistic. path diversity, the RTT value SHOULD be pessimistic.
A default bundle response interval, used when the object does not A default Bundle response interval, used when the object does not
contain an RTT, SHOULD be a configurable parameter of the ACME contain an RTT, SHOULD be a configurable parameter of the ACME
server. If the ACME client indicated an RTT value in the object, the server. If the ACME client indicated an RTT value in the object, the
response interval SHOULD be twice the RTT (with limiting logic response interval SHOULD be twice the RTT (with limiting logic
applied as described below). The lower limit on response interval is applied as described below). The lower limit on the response
network-specific, but SHOULD NOT be shorter than one second. The interval is network specific, but it SHOULD NOT be shorter than one
upper limit on response interval is network-specific, but SHOULD NOT second. The upper limit on response interval is network specific,
be longer than one minute (60 seconds) for a terrestrial-only DTN. but it SHOULD NOT be longer than one minute (60 seconds) for a
terrestrial-only DTN.
3.3. ACME Node ID Validation Challenge Bundle 3.3. ACME Node ID Validation Challenge Bundle
Each ACME Node ID Validation Challenge Bundle SHALL be structured and Each ACME Node ID Validation Challenge Bundle SHALL be structured and
encoded in accordance with [RFC9171]. encoded in accordance with BPv7 [RFC9171].
Each Challenge Bundle has parameters as listed here: Each Challenge Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
primary block flags SHALL indicate that user application primary block flags SHALL indicate that user application
acknowledgement is requested; this flag distinguishes the acknowledgement is requested; this flag distinguishes the
Challenge Bundle from the Response Bundle. Challenge Bundle from the Response Bundle.
Destination EID: The Destination EID SHALL be the ACME-server- Destination EID: The Destination EID SHALL be the ACME-server-
normalized Node ID being validated. normalized Node ID being validated.
Source Node ID: The Source Node ID SHALL indicate the Node ID of a Source Node ID: The Source Node ID SHALL indicate the Node ID of a
BP agent of the ACME server performing the challenge. BP Agent of the ACME server performing the challenge.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the challenge was generated. The Lifetime to the time at which the challenge was generated. The Lifetime
SHALL indicate the response interval (of Section 3.2) for which SHALL indicate the response interval (of Section 3.2) for which
ACME server will accept responses to this challenge. the ACME server will accept responses to this challenge.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: This is set to the ACME Node ID
type code defined in Section 7.3. Validation type code defined in Section 7.3.
Administrative Record Content: The Challenge Bundle administrative Administrative Record Content: The Challenge Bundle administrative
record content SHALL consist of a CBOR map containing the record content SHALL consist of a CBOR map containing the
following three pairs: following three pairs:
* One pair SHALL consist of key 1 with value of ACME challenge * One pair SHALL consist of key 1 with a value of ACME challenge
id-chal, copied from the challenge object, represented as a id-chal, copied from the Challenge Object, represented as a
CBOR byte string. CBOR byte string.
* One pair SHALL consist of key 2 with value of ACME challenge * One pair SHALL consist of key 2 with a value of ACME challenge
token-bundle, represented as a CBOR byte string. The token- token-bundle, represented as a CBOR byte string. The token-
bundle is a random value that uniquely identifies the challenge bundle is a random value that uniquely identifies the Challenge
bundle. This value SHALL have at least 128 bits of entropy. Bundle. This value SHALL have at least 128 bits of entropy.
See [RFC4086] for additional information on randomness See BCP 106 [RFC4086] for additional information on randomness
requirements. requirements.
* One pair SHALL consist of key 4 with value of an array * One pair SHALL consist of key 4 with a value of an array
containing acceptable hash algorithm identifiers. The array containing acceptable hash algorithm identifiers. The array
SHALL be ordered in descending preference, with the first item SHALL be ordered in descending preference, with the first item
being the most preferred. The array SHALL contain at least one being the most preferred. The array SHALL contain at least one
item. Each algorithm identifier SHALL correspond to the Value item. Each algorithm identifier SHALL correspond to the Value
column (integer or text string) of the algorithm registered in column (integer or text string) of the algorithm registered in
the "COSE Algorithms" registry of [IANA-COSE]. the "COSE Algorithms" registry [IANA-COSE].
This structure is part of the extension CDDL in Appendix A. An This structure is part of the extension CDDL in Appendix A. An
example full Challenge Bundle is included in Appendix B.1 example full Challenge Bundle is included in Appendix B.1.
For interoperability, entities which use this validation method SHALL For interoperability, entities that use this validation method SHALL
support the hash algorithm "SHA-256" (-16) of [RFC9054], but can use support the hash algorithm "SHA-256" (value -16) [RFC9054]. This
other hash algorithms. This requirement allows for different requirement allows for different implementations to be configured to
implementations to be configured to use an interoperable algorithm, use an interoperable algorithm, but does not preclude the use of
but does not preclude the use of other algorithms. other algorithms with either higher or lower priority.
If the BP agent generating a Challenge Bundle does not have a well- If the BP Agent generating a Challenge Bundle does not have a well-
synchronized clock or the agent responding to the challenge is synchronized clock or the agent responding to the challenge is
expected to not have a well-synchronized clock, the bundle SHALL expected to not have a well-synchronized clock, the Bundle SHALL
include a Bundle Age extension block. include a Bundle Age extension block in accordance with Section 4.4.2
of [RFC9171].
Challenge Bundles SHALL include a Block Integrity Block (BIB) in Challenge Bundles SHALL include a Block Integrity Block (BIB) in
accordance with Section 4 or with a Security Source identical to the accordance with Section 4 or with a Security Source identical to the
bundle Source Node. Challenge Bundles SHALL NOT be directly Bundle Source Node. Challenge Bundles SHALL NOT be directly
encrypted by Block Confidentiality Block (BCB) or any other method encrypted by the Block Confidentiality Block (BCB) method or any
(see Section 6.1). other method (see Section 6.1).
3.3.1. Challenge Bundle Checks 3.3.1. Challenge Bundle Checks
A proper Challenge Bundle meets all of the following criteria: A proper Challenge Bundle meets all of the following criteria:
* The Challenge Bundle was received within the time interval allowed * The Challenge Bundle was received within the time interval allowed
for the challenge. The allowed interval starts at the Creation for the challenge. The allowed interval starts at the Creation
Timestamp and extends for the Lifetime of the Challenge Bundle. Timestamp and extends for the Lifetime of the Challenge Bundle.
* The Challenge Bundle contains a BIB which covers at least the * The Challenge Bundle contains a BIB that covers at least the
primary block and payload. That BIB has a security source which primary block and payload. That BIB has a Security Source that is
is trusted and passes security-context-specific validation (i.e. trusted and passes security-context-specific validation (i.e.,
MAC or signature verification). Message Authentication Code (MAC) or signature verification).
* The challenge payload contains the id-chal as indicated in the * The challenge payload contains the id-chal as indicated in the
ACME challenge object. ACME Challenge Object.
* The challenge payload contains a token-bundle meeting the * The challenge payload contains a token-bundle matching the
definition in Section 3.3. definition in Section 3.3.
* The challenge payload contains at least one hash algorithm * The challenge payload contains at least one hash algorithm
identifier acceptable to the client. identifier acceptable to the client.
Any of the failures above SHALL cause the challenge bundle to be Failure to match any of the above SHALL cause the Challenge Bundle to
otherwise ignored by the BP agent. It is an implementation matter of be otherwise ignored by the BP Agent. It is an implementation matter
how to react to such failures, which could include logging the event, of how to react to such failures, which could include logging the
incrementing counters, or raising alarms. event, incrementing counters, or raising alarms.
3.4. ACME Node ID Validation Response Bundles 3.4. ACME Node ID Validation Response Bundles
Each ACME Node ID Validation Response Bundle SHALL be structured and Each ACME Node ID Validation Response Bundle SHALL be structured and
encoded in accordance with [RFC9171]. encoded in accordance with BPv7 [RFC9171].
Each Response Bundle has parameters as listed here: Each Response Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
primary block flags SHALL NOT indicate that user application primary block flags SHALL NOT indicate that user application
acknowledgement is requested; this flag distinguishes the Response acknowledgement is requested; this flag distinguishes the Response
Bundle from the Challenge Bundle. Bundle from the Challenge Bundle.
Destination EID: The Destination EID SHALL be identical to the Destination EID: The Destination EID SHALL be identical to the
skipping to change at page 18, line 9 skipping to change at line 808
byte string. byte string.
* One pair SHALL consist of key 2 with value of ACME challenge * One pair SHALL consist of key 2 with value of ACME challenge
token-bundle, copied from the Request Bundle, represented as a token-bundle, copied from the Request Bundle, represented as a
CBOR byte string. CBOR byte string.
* One pair SHALL consist of key 3 with value of a two-element * One pair SHALL consist of key 3 with value of a two-element
array containing the pair of a hash algorithm identifier and array containing the pair of a hash algorithm identifier and
the hash byte string. The algorithm identifier SHALL the hash byte string. The algorithm identifier SHALL
correspond to the Value column (integer or text string) of the correspond to the Value column (integer or text string) of the
algorithm registered in the "COSE Algorithms" registry of algorithm registered in the "COSE Algorithms" registry
[IANA-COSE]. [IANA-COSE].
This structure is part of the extension CDDL in Appendix A. An This structure is part of the extension CDDL in Appendix A. An
example full Response Bundle is included in Appendix B.2 example full Response Bundle is included in Appendix B.2.
If the BP agent responding to a Challenge Bundle does not have a If the BP Agent responding to a Challenge Bundle does not have a
well-synchronized clock, it SHALL use any information about last-hop well-synchronized clock, it SHALL use any information about last-hop
delays and (if present) Bundle Age extension data to infer the age of delays and (if present) Bundle Age extension data to infer the age of
the Challenge Bundle and lifetime of the Response Bundle. the Challenge Bundle and Lifetime of the Response Bundle.
Response Bundles SHALL include a BIB in accordance with Section 4. Response Bundles SHALL include a BIB in accordance with Section 4.
Response Bundles SHALL NOT be directly encrypted by BCB or any other Response Bundles SHALL NOT be directly encrypted by BCB or any other
method (see Section 6.1 for explanation). method (see Section 6.1 for explanation).
3.4.1. Response Bundle Checks 3.4.1. Response Bundle Checks
A proper Response Bundle meets all of the following criteria: A proper Response Bundle meets all of the following criteria:
* The Response Bundle was received within the time interval allowed * The Response Bundle was received within the time interval allowed
for the challenge. The allowed interval starts at the Creation for the challenge. The allowed interval starts at the Creation
Timestamp and extends for the Lifetime of the associated Challenge Timestamp and extends for the Lifetime of the associated Challenge
Bundle. The interval of the Challenge Bundle is used here because Bundle. The interval of the Challenge Bundle is used here because
the interval of the Response Bundle could be made to disagree with the interval of the Response Bundle could be made to disagree with
the Challenge Bundle. the Challenge Bundle.
* The Response Bundle Source Node ID is identical to the Node ID * The Response Bundle Source Node ID is identical to the Node ID
being validated. The comparison of Node IDs SHALL use the being validated. The comparison of Node IDs SHALL use the
comparison logic of the NODE-ID from Section 4.4.1 of [RFC9174]. comparison logic of the NODE-ID from Section 4.4.1 of [RFC9174].
* The Response Bundle contains a BIB which covers at least the * The Response Bundle contains a BIB that covers at least the
primary block and payload. That BIB has a security source which primary block and payload. That BIB has a Security Source that is
is trusted and passes security-context-specific validation. trusted and passes security-context-specific validation.
* The response payload contains the same id-chal and token-bundle as * The response payload contains the same id-chal and token-bundle as
sent in the Challenge Bundle (this is also how the two bundles are sent in the Challenge Bundle (this is also how the two Bundles are
correlated). correlated).
* The response payload contains a hash algorithm identifier * The response payload contains a hash algorithm identifier
acceptable to the server (as indicated in the challenge bundle). acceptable to the server (as indicated in the Challenge Bundle).
* The response payload contains the expected Key Authorization * The response payload contains the expected Key Authorization
digest computed by the ACME server. digest computed by the ACME server.
Any of the failures above SHALL cause that single-perspective Any of the failures above SHALL cause that single-perspective
validation to fail. Any of the failures above SHOULD be validation to fail. Any of the failures above SHOULD be
distinguished as subproblems to the ACME client. The lack of a distinguished as subproblems to the ACME client. The lack of a
response within the expected response interval, as defined in response within the expected response interval, as defined in
Section 3.2, SHALL also be treated as a validation failure. Section 3.2, SHALL also be treated as a validation failure.
3.5. Multi-Perspective Validation 3.5. Multi-Perspective Validation
To avoid on-path attacks in certain networks, an ACME server can To avoid on-path attacks in certain networks, an ACME server can
perform a single validation using multiple challenge bundle sources perform a single validation using multiple Challenge Bundle sources
or via multiple routing paths. This technique is called multi- or via multiple routing paths. This technique is called "multi-
perspective validation as recommended in Section 10.2 of [RFC8555] perspective validation" as recommended in Section 10.2 of [RFC8555]
and an implementation used by Let's Encrypt is described in and an implementation is used by the Let's Encrypt service in its
[LE-multi-perspective]. The utility of a multi-perspective operational deployment [LE-multi-perspective]. The utility of a
validation is part of the experimental nature (Section 1.5) of this multi-perspective validation is part of the experimental nature (see
specification. Section 1.5) of this specification.
When required by policy, an ACME server SHALL send multiple challenge When required by policy, an ACME server SHALL send multiple Challenge
bundles from different sources in the BP network. When multiple Bundles from different sources in the BP network. When multiple
Challenge Bundles are sent for a single validation, it is a matter of 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 ACME server policy to determine whether or not the validation as a
whole is successful. The result of each single-source validation is whole is successful. The result of each single-source validation is
defined as success or failure in Section 3.4.1. defined as success or failure in Section 3.4.1.
A RECOMMENDED validation policy is to succeed if the challenge from a A RECOMMENDED validation policy is to succeed if the challenge from a
primary bundle source is successful and if there are no more than one primary Bundle source is successful and if there is no more than one
failure from a secondary source. The determination of which failure from a secondary source. The determination of which
perspectives are considered primary or secondary is an implementation perspectives are considered primary or secondary is an implementation
matter. matter.
Regardless of whether a validation is single- or multi-perspective, a Regardless of whether a validation is single- or multi-perspective, a
validation failure SHALL be indicated by an ACME error type of validation failure SHALL be indicated by an ACME error type of
"incorrectResponse". Each specific perspective failure SHOULD be "incorrectResponse". Each specific perspective failure SHOULD be
indicated to the ACME client as a validation subproblem. indicated to the ACME client as a validation subproblem.
4. Bundle Integrity Gateway 4. Bundle Integrity Gateway
This section defines a BIB use which closely resembles the function This section defines a BIB use that closely resembles the function of
of DKIM email signing [RFC6376]. In this mechanism a routing node in DKIM email signing [RFC6376]. In this mechanism, a routing node in a
a DTN sub-network attests to the origination of a bundle by adding a DTN subnetwork attests to the origination of a Bundle by adding a BIB
BIB before forwarding it. The bundle receiver then need not trust before forwarding it. The Bundle receiver then need not trust the
the source of the bundle, but only trust this security source node. source of the Bundle, it only needs to trust this Security Source
The receiver needs policy configuration to know which security node. The receiver needs policy configuration to know which Security
sources are permitted to attest for which bundle sources. The Sources are permitted to attest for which Bundle sources. The
utility of an integrity gateway is part of the experimental nature utility of an integrity gateway is part of the experimental nature
(Section 1.5) of this specification. (Section 1.5) of this specification.
An integrity gateway SHALL validate the Source Node ID of a bundle, An integrity gateway SHALL validate the Source Node ID of a Bundle,
using local-network-specific means, before adding a BIB to the using local-network-specific means, before adding a BIB to the
bundle. The exact means by which an integrity gateway validates a Bundle. The exact means by which an integrity gateway validates a
bundle's source is network-specific, but could use physical-layer, Bundle's source is network specific, but it could use physical-layer,
network-layer or BP-convergence-layer authentication. The bundle network-layer, or BP-convergence-layer authentication. The Bundle
source could also add its own BIB with a local-network-specific source could also add its own BIB with a local-network-specific
security context or local-network-specific key material (i.e. a group security context or local-network-specific key material (i.e., a
key shared within the local network). group key shared within the local network).
When an integrity gateway adds a BIB it SHALL be in accordance with When an integrity gateway adds a BIB, it SHALL be in accordance with
[RFC9172]. The BIB targets SHALL cover both the payload block and BPSec [RFC9172] requirements. The BIB targets SHALL cover both the
the primary block (either directly as a target or as additional payload block and the primary block (either directly as a target or
authenticated data for the payload block MAC/signature). The as additional authenticated data for the payload block MAC/
Security Source of this BIB SHALL be either the bundle source Node ID signature). The Security Source of this BIB SHALL be either the
itself or a routing node trusted by the destination node (see Bundle source Node ID itself or a routing node trusted by the
Section 6.2). destination node (see Section 6.2).
5. Certificate Request Profile 5. Certificate Request Profile
The ultimate purpose of this ACME validation is to allow a CA to The ultimate purpose of this ACME validation is to allow a CA to
issue certificates following the profiles of Section 4.4.2 of issue certificates following the profiles of Section 4.4.2 of
[RFC9174] and Section 4 of [I-D.ietf-dtn-bpsec-cose]. These purposes [RFC9174] and Section 4 of [BPSEC-COSE]. These purposes are referred
are referred to here as bundle security certificates. to here as "Bundle security certificates".
ACME identifiers of type "bundleEID" correlate to certificate The ACME identifier type "bundleEID" correlates to the PKIX
requests within in an extensionRequest attribute (see [RFC2985]) certificate and certificate request "NODE-ID" as defined in
containing a subjectAltName extension of type otherName with a name Section 4.4.1 of [RFC9174]. This NODE-ID is present in certificate
form of BundleEID, identified by id-on-bundleEID of [IANA-SMI]. This requests with an extensionRequest attribute (see [RFC2985])
form is referred to as a "NODE-ID" as defined in Section 4.4.1 of containing a SAN extension with identities of type otherName having
[RFC9174]. Because the BundleEID name form is encoded as an an Other Name form of BundleEID, identified by id-on-bundleEID from
IA5String it SHALL be treated as being in the percent-encoded form of the "SMI Security for PKIX Other Name Forms" registry [IANA-SMI].
Section 2.1 of [RFC3986]. Because the BundleEID Other Name form is encoded as an IA5String, it
SHALL be treated as being in the percent-encoded form of Section 2.1
of [RFC3986].
One defining aspect of bundle security certificates is the Extended One defining aspect of Bundle security certificates is the Extended
Key Usage key purpose id-kp-bundleSecurity of [IANA-SMI], as defined Key Usage key purpose id-kp-bundleSecurity [IANA-SMI], as defined in
in Section 4.4.2.1 of [RFC9174]. When requesting a certificate which Section 4.4.2.1 of [RFC9174]. When requesting a certificate that
includes a NODE-ID, the CSR SHOULD include an Extended Key Usage of includes a NODE-ID, the CSR SHOULD include an Extended Key Usage of
id-kp-bundleSecurity. When a bundle security certificate is issued id-kp-bundleSecurity. When a Bundle security certificate is issued
based on a validated NODE-ID, the certificate SHALL include an based on a validated NODE-ID, the certificate SHALL include an
Extended Key Usage of id-kp-bundleSecurity. Extended Key Usage of id-kp-bundleSecurity.
5.1. Multiple Identity Claims 5.1. Multiple Identity Claims
A single bundle security CSR MAY contain a mixed set of SAN A single Bundle security CSR MAY contain a mixed set of SAN
identifiers, including combinations of IP-ID, DNS-ID [RFC9525] and identifiers, including combinations of IP-ID [RFC9525], DNS-ID
NODE-ID [RFC9174] types. These correspond with ACME identifier types [RFC9525], and NODE-ID [RFC9174] types. These correspond with ACME
"ip", "dns", and "bundleEID" respectively. identifier types "ip", "dns", and "bundleEID", respectively.
There is no restriction on how a certificate combines these claims, There is no restriction on how a certificate combines these claims,
but each identifier SHALL be validated by an ACME server to issue but each identifier SHALL be validated by an ACME server to issue
such a certificate as part of an associated ACME order. This is no such a certificate as part of an associated ACME order. This is no
different than the existing behavior of [RFC8555] but is mentioned different than the existing behavior of ACME [RFC8555] but is
here to make sure that CA policy handles such situations; especially mentioned here to make sure that CA policy handles such situations,
related to validation failure of an identifier in the presence of especially related to validation failure of an identifier in the
multiple identifiers. The initial "ip" validations are defined in presence of multiple identifiers. Existing validation mechanisms are
[RFC8738] and initial "dns" validations are defined in [RFC8555]. defined for identifier types "ip" [RFC8738] and "dns" [RFC8555] among
others [IANA-ACME].
The specific use case of TLS-based security in [RFC9174] allows, and The specific use case of TLS-based security for BPv7 CL transport in
for some network policies requires, that a certificate authenticate Section 4.4 of [RFC9174] allows, and for some network policies
both the DNS name of an entity as well as the Node ID of the entity. requires, that a certificate authenticate both the DNS name of an
These authentications apply to each identifier type, used for entity as well as the Node ID of the entity. These authentications
different network layers, at different points during secure session apply to each identifier type, used for different network layers, at
establishment. different points during secure session establishment.
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-Only or Signing-Only Bundle Security
Certificates Certificates
ACME extensions specified in this document can be used to request ACME extensions specified in this document can be used to request
encryption-only or signing-only bundle security certificates. The encryption-only or signing-only Bundle security certificates. The
validity of a request for either a restricted-use or unrestricted-use validity of a request for either a restricted-use or unrestricted-use
certificate is dependent on both CA policy to issue such certificates certificate is dependent on both CA policy to issue such certificates
as well as constraints based on the requested key and algorithm as well as constraints based on the requested key and algorithm
types. types.
In order to request signing only bundle security certificate, the CSR In order to request a signing-only Bundle security certificate, the
SHALL include the key usage extension with digitalSignature and/or CSR SHALL include the key usage extension with the digitalSignature
nonRepudiation bits set and no other bits set. and/or nonRepudiation bits set and no other bits set.
In order to request encryption only bundle security certificate, the In order to request an encryption-only Bundle security certificate,
CSR SHALL include the key usage extension with keyEncipherment or the CSR SHALL include the key usage extension with the
keyAgreement bits set and no other bits set. keyEncipherment or keyAgreement bits set and no other bits set.
Presence of both of the above sets of key usage bits in the CSR, as Presence of both of the above sets of key usage bits in the CSR, as
well as absence of key usage extension in the CSR, signals to ACME well as absence of key usage extension in the CSR, signals the ACME
server to issue a bundle security certificate suitable for both server to issue a Bundle security certificate suitable for both
signing and encryption. signing and encryption.
6. Security Considerations 6. Security Considerations
This section separates security considerations into threat categories This section separates security considerations into threat categories
based on guidance of BCP 72 [RFC3552]. based on guidance of BCP 72 [RFC3552].
6.1. Threat: Passive Leak of Validation Data 6.1. Threat: Passive Leak of Validation Data
Because this challenge mechanism is used to bootstrap security Because this challenge mechanism is used to bootstrap security
between DTN Nodes, the challenge and its response are likely to be between DTN Nodes, the challenge and its response are likely to be
transferred in plaintext. The only ACME data present on-the-wire is transferred in plaintext. The only ACME data present on-the-wire is
a random token and a cryptographic digest, so there is no sensitive a random token and a cryptographic digest, so there is no sensitive
data to be leaked within the Node ID Validation bundle exchange. data to be leaked within the Node ID Validation Bundle exchange.
Because each challenge uses a separate token pair, there is no value Because each challenge uses a separate token pair, there is no value
in an on-path attacker seeing the tokens from past challenges and/or in an on-path attacker seeing the tokens from past challenges and/or
responses. responses.
It is possible for intermediate BP nodes to encapsulate-and-encrypt It is possible for intermediate BP Nodes to encapsulate-and-encrypt
Challenge and/or Response Bundles while they traverse untrusted Challenge Bundles and/or Response Bundles while they traverse
networks, but that is a DTN configuration matter outside of the scope untrusted networks, but that is a DTN configuration matter outside of
of this document. the scope of this document.
6.2. Threat: BP Node Impersonation 6.2. Threat: BP Node Impersonation
As described in Section 10.1 of [RFC8555], it is possible for an As described in Section 10.1 of [RFC8555], it is possible for an
active attacker to alter data on both ACME client channel and the DTN active attacker to alter data on both ACME client channel and the DTN
validation channel. validation channel.
The primary mitigation is to delegate bundle integrity sourcing to a The primary mitigation is to delegate Bundle integrity sourcing to a
trusted routing node near, in the sense of bundle routing topology, trusted routing node near, in the sense of Bundle routing topology,
to the bundle source node as defined in Section 4. This is the Bundle source node as defined in Section 4. This is functionally
functionally similar to DKIM signing of [RFC6376] and provides some similar to the DKIM signing [RFC6376] and provides some level of
level of bundle origination. secure Bundle origination.
Another way to mitigate single-path on-path attacks is to attempt Another way to mitigate on-path attacks is to attempt validation of
validation of the same Node ID from multiple sources or via multiple the same Node ID from multiple sources, hopefully via multiple Bundle
bundle routing paths, as defined in Section 3.5. It is not a trivial routing paths, as defined in Section 3.5. It is not a trivial task
task to guarantee bundle routing though, so more advanced techniques to guarantee Bundle routing though, so more advanced techniques such
such as onion routing (using bundle-in-bundle encapsulation) could be as onion routing (using Bundle-in-Bundle encapsulation) could be
employed. employed.
6.3. Threat: Bundle Replay 6.3. Threat: Bundle Replay
It is possible for an on-path attacker to replay both Challenge It is possible for an on-path attacker to replay both Challenge
Bundles or Response Bundles. Even in a properly-configured DTN it is Bundles or Response Bundles. Even in a properly configured DTN, it
possible that intermediate bundle routers to use multi-path is possible that intermediate Bundle routers would use multi-path
forwarding of a singleton-destination bundle. forwarding of a singleton-destination Bundle.
Ultimately, the point of the ACME bundle exchange is to derive a Key Ultimately, the point of the ACME Bundle exchange is to derive a Key
Authorization and its cryptographic digest and communicate it back to Authorization value and its cryptographic digest, and to communicate
the ACME server for validation, so the uniqueness of the Key that digest back to the ACME server for validation, so the uniqueness
Authorization directly determines the scope of replay validity. The of the Key Authorization directly determines the scope of replay
uniqueness of each token-bundle to each challenge bundle ensures that validity. The uniqueness of each token-bundle to each Challenge
the Key Authorization is unique to the challenge bundle. The Bundle ensures that the Key Authorization is unique to the Challenge
uniqueness of each token-chal to the ACME challenge ensures that the Bundle. The uniqueness of each token-chal to the ACME challenge
Key Authorization is unique to that ACME challenge and not based ensures that the Key Authorization is unique to that ACME challenge
solely on values visible to on-path eavesdroppers. and not based solely on values visible to on-path eavesdroppers.
Having each bundle's primary block and payload block covered by a BIB Having each Bundle's primary block and payload block covered by a BIB
from a trusted security source (see Section 4) ensures that a from a trusted Security Source (see Section 4) ensures that a
replayed bundle cannot be altered in the blocks used by ACME. All replayed Bundle cannot be altered in the blocks used by ACME. All
together, these properties mean that there is no degraded security together, these properties mean that there is no degraded security
caused by replay of either a Challenge Bundle or a Response Bundle 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 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 a BIB. The worst that can come of Bundle replay is the waste of
network resources as described in Section 6.4. network resources as described in Section 6.4.
6.4. Threat: Denial of Service 6.4. Threat: Denial of Service
The behaviors described in this section all amount to a potential The behaviors described in this section all amount to a potential
denial-of-service to a BP agent. denial-of-service to a BP Agent.
A malicious entity can continually send Challenge Bundles to a BP A malicious entity can continually send Challenge Bundles to a BP
agent. The victim BP agent can ignore Challenge Bundles which do not Agent. The victim BP Agent can ignore Challenge Bundles that do not
conform to the specific time interval and challenge token for which conform to the specific time interval and challenge token for which
the ACME client has informed the BP agent that challenges are the ACME client has informed the BP Agent that challenges are
expected. The victim BP agent can require all Challenge Bundles to expected. The victim BP Agent can require all Challenge Bundles to
be BIB-signed to ensure authenticity of the challenge. be BIB-signed to ensure authenticity of the challenge.
A malicious entity can continually send Response Bundles to a BP A malicious entity can continually send Response Bundles to a BP
agent. The victim BP agent can ignore Response Bundles which do not Agent. The victim BP Agent can ignore Response Bundles that do not
conform to the specific time interval or Source Node ID or challenge conform to the specific time interval or Source Node ID or challenge
token for an active Node ID validation. token for an active Node ID validation.
Similar to other validation methods, an ACME server validating a DTN Similar to other validation methods, an ACME server validating a DTN
Node ID could be used as a denial of service amplifier. For this Node ID could be used as a denial-of-service amplifier. For this
reason any ACME server can rate-limit validation activities for reason, any ACME server can rate-limit validation activities for
individual clients and individual certificate requests. individual clients and individual certificate requests.
6.5. Inherited Security Considerations 6.5. Inherited Security Considerations
Because this protocol relies on ACME for part of its operation, the Because this protocol relies on ACME for part of its operation, the
security considerations of [RFC8555] apply to all ACME client--server security considerations of ACME [RFC8555] apply to all ACME client-
exchanges during Node ID validation. server exchanges during Node ID validation.
Because this protocol relies on BPv7 for part of its operation, the Because this protocol relies on BPv7 for part of its operation, the
security considerations of [RFC9171] and [RFC9172] apply to all BP security considerations of BPv7 [RFC9171] and BPSec [RFC9172] apply
messaging during Node ID validation. to all BP messaging during Node ID validation.
6.6. Out-of-Scope BP Agent Communication 6.6. Out-of-Scope BP Agent Communication
Although messaging between an ACME client or ACME server an its Although messaging between an ACME client or ACME server and its
associated BP agent are out-of-scope for this document, both of those associated BP Agent are out-of-scope for this document, both of those
channels are critical to Node ID validation security. Either channel channels are critical to Node ID validation security. Either channel
can potentially leak data or provide attack vectors if not properly can potentially leak data or provide attack vectors if not properly
secured. These channels need to protect against spoofing of secured. These channels need to protect against spoofing of
messaging in both directions to avoid interruption of normal messaging in both directions to avoid interruption of normal
validation sequencing and to prevent false validations from validation sequencing and to prevent false validations from
succeeding. succeeding.
The ACME server and its BP agent exchange the outgoing id-chal, The ACME server and its BP Agent exchange the outgoing id-chal,
token-bundle, and Key Authorization digest but these values do not token-bundle, and Key Authorization digest, but these values do not
need to be confidential (they are also in plaintext over the BP need to be confidential (they are also in plaintext over the BP
channel). channel).
Depending on implementation details, the ACME client might transmit Depending on implementation details, the ACME client might transmit
the client account key thumbprint to its BP agent to allow computing the client account key thumbprint to its BP Agent to allow computing
the Key Authorization digest on the BP agent. If an ACME client does the Key Authorization digest on the BP Agent. If an ACME client does
transmit its client account key thumbprint to a BP agent, it is transmit its client account key thumbprint to a BP Agent, it is
important that this data is kept confidential because it provides the important that this data is kept confidential because it provides the
binding of the client account key to the Node ID validation (as well binding of the client account key to the Node ID validation (as well
as for all other types of ACME validation). Avoiding this as for all other types of ACME validation). Avoiding this
transmission would require a full round-trip between BP agent and transmission would require a full round-trip between BP Agent and
ACME client, which can be undesirable if the two are separated by a ACME client, which can be undesirable if the two are separated by a
long-delay network. long-delay network.
7. IANA Considerations 7. IANA Considerations
This specification adds to the ACME registry group and BP registry This specification adds to the "Automated Certificate Management
group for this behavior. Environment (ACME) Protocol" registry group and the "Bundle Protocol"
registry group.
7.1. ACME Identifier Types 7.1. ACME Identifier Types
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry group [IANA-ACME], the following entry has been Protocol" registry group [IANA-ACME], the following entry has been
added to the "ACME Identifier Types" registry. added to the "ACME Identifier Types" registry.
+===========+======================+ +===========+===========+
| Label | Reference | | Label | Reference |
+===========+======================+ +===========+===========+
| bundleEID | [This specification] | | bundleEID | RFC 9891 |
+-----------+----------------------+ +-----------+-----------+
Table 1 Table 1
7.2. ACME Validation Methods 7.2. ACME Validation Methods
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry group [IANA-ACME], the following entry has been Protocol" registry group [IANA-ACME], the following entry has been
added to the "ACME Validation Methods" registry. added to the "ACME Validation Methods" registry.
+==============+=================+======+======================+ +==============+=================+======+===========+
| Label | Identifier Type | ACME | Reference | | Label | Identifier Type | ACME | Reference |
+==============+=================+======+======================+ +==============+=================+======+===========+
| bp-nodeid-00 | bundleEID | Y | [This specification] | | bp-nodeid-00 | bundleEID | Y | RFC 9891 |
+--------------+-----------------+------+----------------------+ +--------------+-----------------+------+-----------+
Table 2 Table 2
7.3. Bundle Administrative Record Types 7.3. Bundle Administrative Record Types
Within the "Bundle Protocol" registry group [IANA-BP], the following Within the "Bundle Protocol" registry group [IANA-BP], the following
entries have been added to the "Bundle Administrative Record Types" entry has been added to the "Bundle Administrative Record Types"
registry. registry.
[NOTE to IANA: For [RFC5050] compatibility the AR-TBD value needs to +=========================+=======+==============+===========+
be no larger than 15, but such compatibility is not needed. For | Bundle Protocol Version | Value | Description | Reference |
BPbis the AR-TBD value needs to be no larger than 65535 as defined by +=========================+=======+==============+===========+
[RFC9713].] | 7 | 255 | ACME Node ID | RFC 9891 |
| | | Validation | |
+=========================+========+==============+================+ +-------------------------+-------+--------------+-----------+
| Bundle Protocol Version | Value | Description | Reference |
+=========================+========+==============+================+
| 7 | AR-TBD | ACME Node ID | [This |
| | | Validation | specification] |
+-------------------------+--------+--------------+----------------+
Table 3 Table 3
8. References 8. References
8.1. Normative References 8.1. Normative References
[IANA-ACME] [IANA-ACME]
IANA, "Automated Certificate Management Environment (ACME) IANA, "Automated Certificate Management Environment (ACME)
Protocol", <https://www.iana.org/assignments/acme/>. Protocol", <https://www.iana.org/assignments/acme/>.
[IANA-BP] IANA, "Bundle Protocol", [IANA-BP] IANA, "Bundle Protocol",
<https://www.iana.org/assignments/bundle/>. <https://www.iana.org/assignments/bundle/>.
[IANA-COSE] [IANA-COSE]
IANA, "CBOR Object Signing and Encryption (COSE)", IANA, "CBOR Object Signing and Encryption (COSE)",
<https://www.iana.org/assignments/cose/>. <https://www.iana.org/assignments/cose/>.
[IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers
(MIB Module Registrations)",
<https://www.iana.org/assignments/smi-numbers/>. <https://www.iana.org/assignments/smi-numbers/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000, DOI 10.17487/RFC2985, November 2000,
skipping to change at page 27, line 39 skipping to change at line 1260
Tolerant Networking TCP Convergence-Layer Protocol Version Tolerant Networking TCP Convergence-Layer Protocol Version
4", RFC 9174, DOI 10.17487/RFC9174, January 2022, 4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/info/rfc9174>. <https://www.rfc-editor.org/info/rfc9174>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023, RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>. <https://www.rfc-editor.org/info/rfc9525>.
8.2. Informative References 8.2. Informative References
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol [BPSEC-COSE]
Specification", RFC 5050, DOI 10.17487/RFC5050, November Sipos, B., "Bundle Protocol Security (BPSec) COSE
2007, <https://www.rfc-editor.org/info/rfc5050>. Context", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpsec-cose-10, 15 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpsec-cose-10>.
[LE-multi-perspective]
Aas, J., McCarney, D., and R. Shoemaker, "Multi-
Perspective Validation Improves Domain Validation
Security", 19 February 2020,
<https://letsencrypt.org/2020/02/19/multi-perspective-
validation.html>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8738] Shoemaker, R.B., "Automated Certificate Management [RFC8738] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) IP Identifier Validation Extension", Environment (ACME) IP Identifier Validation Extension",
RFC 8738, DOI 10.17487/RFC8738, February 2020, RFC 8738, DOI 10.17487/RFC8738, February 2020,
<https://www.rfc-editor.org/info/rfc8738>. <https://www.rfc-editor.org/info/rfc8738>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate [RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates", Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021, RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>. <https://www.rfc-editor.org/info/rfc8823>.
[RFC9713] Sipos, B., "Bundle Protocol Version 7 Administrative
Record Types Registry", RFC 9713, DOI 10.17487/RFC9713,
January 2025, <https://www.rfc-editor.org/info/rfc9713>.
[I-D.ietf-dtn-bpsec-cose]
Sipos, B., "Bundle Protocol Security (BPSec) COSE
Context", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpsec-cose-08, 3 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpsec-cose-08>.
[github-dtn-demo-agent]
Sipos, B., "Python implementation of basic BPv7-related
protocols",
<https://github.com/BrianSipos/dtn-demo-agent/>.
[github-dtn-wireshark]
Sipos, B., "Wireshark Dissectors for BPv7-related
Protocols",
<https://github.com/BrianSipos/dtn-wireshark/>.
[LE-multi-perspective]
Aas, J., McCarney, D., and R. Shoemaker, "Multi-
Perspective Validation Improves Domain Validation
Security", 19 February 2020,
<https://letsencrypt.org/2020/02/19/multi-perspective-
validation.html>.
Appendix A. Administrative Record Types CDDL Appendix A. Administrative Record Types CDDL
[NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the
"ACME Node ID Validation" administrative record type code.]
The extension of BPv7 from Appendix B of [RFC9171] for the ACME The extension of BPv7 from Appendix B of [RFC9171] for the ACME
bundles in Section 3.3 and Section 3.4 is the following CDDL. Bundles in Sections 3.3 and 3.4 is the following CDDL:
; 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 page 29, line 33 skipping to change at line 1325
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
Appendix B. Example Authorization Appendix B. Example Authorization
[NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced This example is a Bundle exchange for the ACME server with Node ID
by the "ACME Node ID Validation" administrative record type code.]
This example is a bundle exchange for the ACME server with Node ID
"dtn://acme-server/" performing a verification for ACME client Node "dtn://acme-server/" performing a verification for ACME client Node
ID "dtn://acme-client/". The example bundles use no block CRC or ID "dtn://acme-client/". The example Bundles use no block CRC or
BPSec integrity, which is for simplicity and is not recommended for BPSec integrity, which is for simplicity and is not recommended for
normal use. The provided figures are extended diagnostic notation normal use. The provided figures are extended diagnostic notation
[RFC8610]. [RFC8610].
For this example the ACME client key thumbprint has the base64url For this example, the ACME client key thumbprint has the base64url-
encoded value of: encoded value of:
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
And the ACME-server generated token-chal has the base64url-encoded and the ACME-server generated token-chal has the base64url-encoded
value of: value of:
"tPUZNY4ONIk6LxErRFEjVw" "tPUZNY4ONIk6LxErRFEjVw"
B.1. Challenge Bundle B.1. Challenge Bundle
For the single challenge bundle in this example, the token-bundle For the single Challenge Bundle in this example, the token-bundle
(transported as byte string via BP) has the base64url-encoded value (transported as byte string via BP) has the base64url-encoded value
of: of:
"p3yRYFU4KxwQaHQjJ2RdiQ" "p3yRYFU4KxwQaHQjJ2RdiQ"
The minimal-but-valid Challenge Bundle is shown in Figure 2. This The minimal-but-valid Challenge Bundle is shown in Figure 2. This
challenge requires that the ACME client respond within a 60 second challenge requires that the ACME client respond within a 60-second
time window. time window.
[_ [_
[ [
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 /
<<[ / 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 /
} }
]>> ]>>
] ]
] ]
Figure 2: Example Challenge Bundle Figure 2: Example Challenge Bundle
skipping to change at page 31, line 11 skipping to change at line 1396
Authorization value is the following, folded across lines for Authorization value is the following, folded across lines for
readability using the "single backslash" strategy of Section 7 of readability using the "single backslash" strategy of Section 7 of
[RFC8792]. [RFC8792].
/ NOTE: '\' line wrapping per RFC 8792 / / NOTE: '\' line wrapping per RFC 8792 /
"p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.\ "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.\
LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
The minimal-but-valid Response Bundle is shown in Figure 3. This The minimal-but-valid Response Bundle is shown in Figure 3. This
response indicates that there is 30 seconds remaining in the response response indicates that there are 30 seconds remaining in the
time window. response time window.
[_ [_
[ [
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 /
<<[ / 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 /
} }
]>> ]>>
] ]
] ]
Figure 3: Example Response Bundle Figure 3: Example Response Bundle
Acknowledgments Acknowledgements
This specification is based on DTN use cases related to PKIX This specification is based on DTN use cases related to PKIX
certificate issuance. certificate issuance.
The workflow and terminology of this validation method was originally The workflow and terminology of this validation method were
copied from the work of Alexey Melnikov in [RFC8823]. originally copied from the work of Alexey Melnikov for email
validation [RFC8823].
Implementation Status
This section is to be removed before publishing as an RFC.
[NOTE to the RFC Editor: please remove this section before
publication, as well as the reference to [RFC7942] and
[github-dtn-demo-agent] and [github-dtn-wireshark].]
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 based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that 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.
An example implementation of the this draft of ACME Node ID
Validation has been created as a GitHub project
[github-dtn-demo-agent] and is intended to use as a proof-of-concept
and as a possible source of interoperability testing.
A Wireshark dissector for of the this draft of ACME Node ID
Validation has been created as a GitHub project
[github-dtn-wireshark] and is intended to be used to inspect and
troubleshoot implementations.
Author's Address Author's Address
Brian Sipos Brian Sipos
RKF Engineering Solutions, LLC RKF Engineering Solutions, LLC
7500 Old Georgetown Road 7500 Old Georgetown Road
Suite 1275 Suite 1275
Bethesda, MD 20814-6198 Bethesda, MD 20814-6198
United States of America United States of America
Email: brian.sipos+ietf@gmail.com Email: brian.sipos+ietf@gmail.com
 End of changes. 182 change blocks. 
582 lines changed or deleted 530 lines changed or added

This html diff was produced by rfcdiff 1.48.