RFC 9891

Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension

📅 published November 2025, from ietf

RFC 9891: ACME Delay-Tolerant Networking (DTN) Node ID Validation Extension 🦋

Okay bestie, this is RFC 9891 💖 It's an IETF document written by B. Sipos at RKF Engineering, dated November 2025. It's in the Experimental category, and its ISSN is 2070-1721 🧚 The header doesn't list anything it obsoletes or updates, so it stands on its own ✨

Abstract

Okay so the big idea: this doc is an extension to the Automated Certificate Management Environment (ACME) protocol 🔐 It lets an ACME server validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client, which is literally the whole point.

A DTN Node ID is an identifier the Bundle Protocol (BP) uses to name a "singleton endpoint," meaning an endpoint registered on one single BP Node 🌸 The Node ID gets encoded two ways: as a certificate Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID, and as an ACME Identifier type called "bundleEID" 💅

Status of This Memo

Real talk, this document is not an Internet Standards Track specification. It's published so people can examine it, try it out experimentally, and evaluate it 🧐

It does define an Experimental Protocol for the Internet community ⭐ It's a product of the IETF and reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full picture 🙈

For status info, errata, and feedback, head to https://www.rfc-editor.org/info/rfc9891 🎀

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as they stood on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 🌈

Table of Contents

1.  Introduction
  1.1.  Scope
  1.2.  Authorization Strategy
  1.3.  Use of CDDL
  1.4.  Terminology
  1.5.  Experiment Scope
2.  Bundle EID ACME Identifier
  2.1.  Subsets of Bundle EID
3.  DTN Node ID Validation
  3.1.  DTN Node ID Challenge Object
  3.2.  DTN Node ID Response Object
  3.3.  ACME Node ID Validation Challenge Bundle
    3.3.1.  Challenge Bundle Checks
  3.4.  ACME Node ID Validation Response Bundles
    3.4.1.  Response Bundle Checks
  3.5.  Multi-Perspective Validation
4.  Bundle Integrity Gateway
5.  Certificate Request Profile
  5.1.  Multiple Identity Claims
  5.2.  Generating Encryption-Only or Signing-Only Bundle Security
        Certificates
6.  Security Considerations
  6.1.  Threat: Passive Leak of Validation Data
  6.2.  Threat: BP Node Impersonation
  6.3.  Threat: Bundle Replay
  6.4.  Threat: Denial of Service
  6.5.  Inherited Security Considerations
  6.6.  Out-of-Scope BP Agent Communication
7.  IANA Considerations
  7.1.  ACME Identifier Types
  7.2.  ACME Validation Methods
  7.3.  Bundle Administrative Record Types
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Administrative Record Types CDDL
Appendix B.  Example Authorization
  B.1.  Challenge Bundle
  B.2.  Response Bundle
Acknowledgements
Author's Address

1. Introduction ✨

Okay so the original purpose of the Automatic Certificate Management Environment (ACME) [RFC8555] was to let Public Key Infrastructure using X.509 (PKIX) Certification Authorities (CAs) validate network domain names for clients 🌷 But the same mechanism works for any of the subject identity claims the PKIX profile [RFC5280] supports, which is honestly iconic 👑

Here, the claim being validated is a Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID. That's what represents a Bundle Protocol (BP) Endpoint ID (EID) in a Delay-Tolerant Networking (DTN) overlay network 🦋 A DTN Node ID is any EID that can uniquely identify a BP Node, as defined in Section 4.2.5.2 of [RFC9171]. That's the same as saying the EID is usable as a singleton endpoint. One super common EID used as a Node ID is the Administrative EID, which is guaranteed to exist on any BP Node 💜 At the time of writing, the URI schemes "dtn" and "ipn" from Section 4.2.5.1 of [RFC9171] are valid for a singleton endpoint, so they count as Node IDs too 🍓 Because the BundleEID claim is brand new to ACME, we need a new ACME Identifier type, "bundleEID," to manage it inside ACME messaging 🫶

Once an ACME server validates a Node ID, it can do that as a pre-authorization of identifier type "bundleEID", or as one of the authorizations in an order that contains an identifier type "bundleEID". Then the client can finalize the order using an associated Certificate Signing Request (CSR) 🎀 Here's the messy part: a single order can contain multiple identifiers of multiple types. A client trying to validate all of those might run into operational issues, and it could fail, as described in Section 5.1 💀 Once a certificate is issued for a Node ID, how the ACME client configures the BP Agent with that new certificate is an implementation matter, so that's on the implementers 🛠️

1.1. Scope

Okay, so this doc describes the ACME message contents [RFC8555], Bundle Protocol version 7 (BPv7) payloads [RFC9171], and Bundle Protocol Security (BPSec) operations [RFC9172] that are needed to validate claims of Node ID ownership 🔥

It does not cover the following, though:

  • Mechanisms for communication between an ACME client or ACME server and their associated BP Agent(s). Those are depicted as steps 1, 2, 5, and 6 of Figure 1. This document only describes exchanges between ACME client-server pairs and between their respective associated BP Agents 🙅‍♀️
  • Specific BP extension blocks or BPSec contexts needed to meet the security requirements of this protocol. The exact security context needed, and its parameters, is network specific 🌈
  • Policies or mechanisms for defining or configuring Bundle integrity gateways, or for trusting integrity gateways on an individual entity or across a network 💅
  • Mechanisms for locating or identifying other Bundle entities (peers) within a network or across an internet. Mapping a Node ID to a potential Convergence-Layer (CL) protocol and network address is left to the implementation and configuration of the BP Agent and its various potential routing strategies 🧚
  • Logic for routing Bundles along a path toward a Bundle's endpoint. This protocol is only involved in creating Bundles at a source and handling them at a destination 🚀
  • Logic for performing rate control and congestion control of Bundle transfers. The ACME server is responsible for rate control of validation requests 🌸
  • Policies or mechanisms for an ACME server to choose a prioritized list of acceptable hash algorithms, or for an ACME client to choose a set of acceptable hash algorithms 🔐
  • Policies or mechanisms for provisioning, deploying, or accessing certificates and private keys; deploying or accessing Certificate Revocation Lists (CRLs); or configuring security parameters on an individual entity or across a network 📜
  • Policies or mechanisms for an ACME server to handle mixed-use certificate signing requests. This specification is focused only on single-use DTN-specific PKIX profiles 💖

Part 1 of 7 is done, bestie 🎀 More parts are coming, so stay tuned 🦋

1.2. Authorization Strategy 🔐

Okay so, the basic unit of data exchange in a DTN is a Bundle [RFC9171] 📦. It's a data payload with metadata riding along. An EID is used as the destination of a Bundle, and it can be a singleton or a group destination. A Node ID identifies the source of a Bundle and gets used for routing through intermediate nodes, including the final node(s) that deliver a Bundle to its destination endpoint. A Node ID can also be an endpoint for Bundles carrying administrative records, as explained in Section 6 of [RFC9171]. If you want the rationale and the capabilities of these networks, go check the "Delay-Tolerant Networking Architecture" [RFC4838] 🧚

Now the main event 💅 When an ACME client requests a pre-authorization or an order with an identifier type "bundleEID" (Section 2), the ACME server offers a "bp-nodeid-00" challenge type (Section 3) to validate that Node ID. If the ACME client attempts the authorization challenge to validate a Node ID, the ACME server sends an ACME Node ID Validation Challenge Bundle with a destination of the Node ID being validated. The BP Agent on that node receives the Challenge Bundle, generates an ACME Key Authorization digest, and sends an ACME Node ID Validation Response Bundle back in reply. An Integrity Gateway on the client side of the DTN can be used to attest to the source of the Response Bundle. Finally, the ACME server receives the Response Bundle and checks that the digest was generated for the associated ACME challenge and from the client account key associated with the original request. The whole workflow is shown in Figure 1 🦋

     +------------+                             +------------+
     |    ACME    |<===== HTTPS Exchanges =====>|    ACME    |
     |   Client   |                             |   Server   |
     +------------+                             +------------+
           |                                       |   ^
(1) Enable or (6) Disable                 (2) Send |   |
   Validation from Server                 Challenge |   |(5) Indicate
           |                  Non-DTN              |   |   Response
~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~
           V                    DTN                V   |
    ++------------++                           ++------------++
    || Admin Elem.||                           || Admin Elem.||-+
    |+------------+|           (3) Challenge   |+------------+| |
    |   Client's   |<------------- Bundle -----|   Server's   | |
    |   BP Agent   |                           |   BP Agent   | |
    +--------------+                           +--------------+ |
           |                                     +----^---------+
           |     +-------------+                      |
           |     |  Integrity  |   (4) Response       |
           +---->|   Gateway   |------ Bundle --------+
                 +-------------+

   Figure 1: The Relationships and Flows Between Node ID Validation
                               Entities

Here's the tea ☕ Because the DTN Node ID is used both for routing Bundles between BP Agents and for multiplexing administrative services within a BP Agent, there's no way to separate the ACME validation of a Node ID from normal Bundle handling for that same Node ID. So administrative record types are the way to keep the Node ID unchanged while telling it apart from other service data Bundles. Iconic problem-solving, honestly 👑

Also, nothing in this protocol requires the ACME client or ACME server to be network-topologically co-located with their respective associated BP Agent 🌸 ACME does need a low-enough latency network to do its HTTPS exchanges between the ACME client and server, but the client's BP Agent (the one being validated) could be on the far side of a long-delay or multi-hop BP network. How the ACME client or server talks to its associated BP Agent is an implementation matter, so that part's up to you 🫶

1.3. Use of CDDL 🧩

This document defines Concise Binary Object Representation (CBOR) structure using the Concise Data Definition Language (CDDL) [RFC8610]. You can extract the entire CDDL structure from the XML version of this document using the XPath expression '//sourcecode[@type="cddl"]' 🔍

The following initial fragment defines the top-level symbols of this document's CDDL, which includes the example CBOR content:

start = acme-record / bundle / tstr

The definitions for the rule bundle and socket $admin-record are taken from Appendix B of [RFC9171] 💖

1.4. Terminology 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Capitals only, bestie, that's the rule 🙈

Because this document combines two otherwise unrelated contexts, ACME and DTN, when a protocol term applies to one of those areas and is used in the other, its name gets prefixed with either "ACME" or "DTN" respectively. So within the ACME context the term is "DTN Node ID", while in the DTN context the name is just "Node ID". Main character naming energy 🎀

In this document, several terms are shortened for the sake of brevity. Here they are:

Challenge Object: This is a shortened form of the full "DTN Node ID Challenge Object". It's a JSON object created by the ACME server 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". It's a JSON object created by the ACME client to authorize a challenge type "bp-nodeid-00", as defined in Section 3.2.

Challenge Bundle: This is a shortened form of the full "ACME Node ID Validation Challenge Bundle". It's a Bundle created by the BP Agent managed by the ACME server to challenge a Node ID claim, as defined in Section 3.3.

Response Bundle: This is a shortened form of the full "ACME Node ID Validation Response Bundle". It's a Bundle created by the BP Agent managed by the ACME client to validate a Node ID claim, as defined in Section 3.4.

Because this is a document produced by the ACME WG, the following DTN BP terms are defined here to clarify how they're used by this ACME identifier type and validation mechanism 🦄

Endpoint ID: An EID is an identifier for the ultimate destination of a Bundle, independent of any intermediate forwarding needed to reach that destination. An endpoint can be a singleton or not, so an EID can also represent a single entity or a set of entities. This is formally defined in Section 4.2.5.1 of [RFC9171].

Node ID: A Node ID is an identifier (that is not guaranteed to be unique) for a specific node in a network, in the form of a singleton EID. A single node can have any number of Node IDs, but a typical (and expected) form of Node ID is the Administrative EID (described below). This is formally defined in Section 4.2.5.2 of [RFC9171].

Administrative EID: An Administrative EID is unique for a node within a specific URI scheme. Although any Node ID can be a valid Bundle Source and Destination, the Administrative EID is a minimum required Node ID for any node operating in a particular URI scheme. For the "dtn" scheme, this is the empty demux part; for the "ipn" scheme, this is the service number zero. These are formally defined under Section 4.2.5.1 of [RFC9171] ✨

1.5. Experiment Scope 🧪

The emergent properties of DTN naming and BP security are still being developed and explored, especially between different organizational and administrative domains. So the Experimental status of this document is more about the practical usefulness of this kind of Node ID validation than the validation method itself 🤔 The original use case is large or cross-organizational networks where a BP Node can be trusted to be allocated and added to a network, but the method of certificate validation and issuance is wanted to happen in-band on the network, rather than being configured solely through a side channel using bespoke or manual protocols. Because this mechanism is so similar to other validation methods, specifically email address validation [RFC8823], it's expected to have few implementation difficulties or interoperability issues. Easy mode, lowkey 💜

Part of the experimental nature of the validation method defined in Section 3, and of BP more generally, is understanding its vulnerability to different kinds of on-path attacks. Some attacks could be based on the topology of the BP overlay network, while others could be based on the underlying (IP) network topology. Because not all of the attack surfaces of this validation method are known or fully understood, the usefulness of the multi-perspective technique described in Section 3.5 isn't assured either. The point of those multi-perspective requirements is that both the ACME client and server have consistent logic for handling the technique 🫣

The attack surface stuff is serious, bestie. Don't skip it, and don't treat the experiment as finished.

The usefulness of the integrity gateway defined in Section 4 to this validation method is experimental, because the way that naming authority in a DTN is allocated, delegated, or enforced is not a settled matter 💀 How the organization running the CA (and its ACME server) can delegate some level of trust to a different organization running a connected DTN with a security gateway is also not defined. The organization running the integrity gateway would need to apply some minimal amount of policy to nodes running behind it, such as patterns to their Node IDs. That would behave conceptually similar to delegation of subdomains in the Domain Name System (DNS), but without the online interaction of DNS 🌈

A successful experiment of this validation method would involve using the ACME protocol along with this Node ID validation to allow issuing of identity certificates across administrative domains. One possible scenario: an issuing CA and an ACME server sit on the edge of a BP transit network operated by some agency. This transit network is used by edge nodes and accessed via edge routers of a peer network operated by a second agency. The nodes of the peer network are trusted by the second agency but not the first. The transit network can refuse to route traffic from the peer network that isn't traceable to a valid identity certificate, which the edge nodes can obtain via the ACME server. That's giving gatekeeper vibes 🚪✨

A valuable result from any experiment, even an unsuccessful one, would be feedback about this method to improve later versions. That feedback could include improvements to object or message structure, random versus deterministic token values, client or server procedures, or naming more generally. Every outcome teaches us something, and that's so iconic 🌟

2. Bundle EID ACME Identifier ✨

okay bestie, this spec is the first one to use a Bundle EID to identify a claim for a certificate request in ACME 🦋 In this document, the only thing a Bundle EID ACME identifier gets validated for is as a DTN Node ID (see Section 3). Other specs can totally define challenge types for other EID uses later, though 💅

Every ACME identifier type "bundleEID" SHALL have a value containing a text URI that meets the requirements of Section 4.2.5.1 of [RFC9171]. It has to use one of the schemes listed in the "Bundle Protocol URI Scheme Types" registry [IANA-BP] 📋 Any identifier type "bundleEID" value that fails to percent-decode properly SHALL be rejected with an ACME error type of "malformed" 💀

An ACME server that supports identifier type "bundleEID" SHALL decode and normalize (based on the scheme-specific syntax) every one of these identifier values it receives 🧚 Any identifier type "bundleEID" value whose scheme-specific part doesn't match the scheme-specific syntax SHALL be rejected with an ACME error type of "malformed". And if a value uses a scheme the ACME server doesn't handle, it SHALL be rejected with an ACME error type of "rejectedIdentifier" 🙈

When an ACME server needs proof that a client controls a Bundle EID, it SHALL create an authorization with the identifier type "bundleEID". An ACME server SHALL NOT attempt to dereference a Bundle EID value on its own 🫶 It's the job of an ACME validation method to make sure the EID is actually owned, using a method the ACME client has authorized.

An identifier for the Node ID of "dtn://example/" would be formatted as:

{
  "type": "bundleEID",
  "value": "dtn://example/"
}

2.1. Subsets of Bundle EID 🌸

okay so a PKIX certificate SAN identity with an Other Name form of BundleEID can hold any EID value (as a text URI). But the certificate profile that the TCP CL uses in Section 4.4 of [RFC9174], and that the ACME validation method in Section 3 supports, requires the value to hold a Node ID (Section 1.4) 🎀

On top of narrowing that certificate profile, this validation method requires that the client's BP Agent respond to administrative records sent to the Node ID being validated. Usually that means an Administrative EID (Section 1.4) destination. The administrative element of a BP Node isn't banned from receiving administrative records for other Node IDs, or from sending records from them, as long as it's helping this validation method ✨

Neither that certificate profile nor this validation method supports non-singleton EIDs. Other validation methods could be defined to do that, though, to support other certificate profiles 🦋

3. DTN Node ID Validation 👑

the DTN Node ID validation method proves control over a Node ID by having the ACME client configure a BP Agent to respond to specific Challenge Bundles sent from the ACME server 💖 The ACME server confirms control of the Node ID by checking that the Response Bundles it receives match the BP Node and client account key being validated 🔥

This is kind of like the ACME email-address validation in [RFC8823] 📧 The challenge splits the token into several parts, and each part travels through a different channel. The Key Authorization result needs all the parts combined. There's also a separate challenge identifier that BP Agents use as a filter, similar to the challenge "from" in Section 3 of [RFC8823]. Main character energy 🧚

The token parts go like this:

  • token-chal: This token is unique to each ACME authorization. It's in the Challenge Object from Section 3.1. Each authorization can have multiple Challenge Bundles (say, taking different routes), but they all share the same token-chal value. That keeps the Key Authorization tied to this specific ACME challenge and its parent ACME authorization 🔒 This token never shows up on the BP channel, so an eavesdropper who knows the client's account key thumbprint (from some other validation method, for example) still can't impersonate the client 🙈
  • token-bundle: This token is unique to each Challenge Bundle the ACME server sends. It's in the Challenge Bundle from Section 3.3 and the Response Bundle from Section 3.4. This makes sure the Key Authorization is tied to actually being able to receive the Challenge Bundle, not just having access to the ACME Challenge Object 🦋 Heads up though: DTN on-path eavesdroppers can see this token too 👀

Since one Node ID can get several Challenge Bundles for the same validation, the token-bundle in the response is what lets the server match it up with the expected Key Authorization digest 🧩

The DTN Node ID Challenge Object SHALL only be allowed for an EID that's usable as a DTN Node ID, which is defined per scheme in Section 4.2.5.1 of [RFC9171] 💅 When an ACME server supports Node ID validation, it SHALL provide a Challenge Object following Section 3.1. Once that Challenge Object exists, the ACME client can start the validation ✨

To kick off a Node ID validation, the ACME client does the following:

  1. The ACME client POSTs a newOrder or newAuthz request that includes the identifier type "bundleEID" for the Node ID it wants. From either of those entry points, the ACME server indicates an authorization for the identifier type "bundleEID". See Section 7.4 of [RFC8555] for more details 📨
  2. The ACME client gets the id-chal and token-chal from the Challenge Object (Section 3.1) inside an authorization object tied to the order, following Section 7.1.4 of [RFC8555] 🎀
  3. The ACME client tells the administrative element of its BP Agent which id-chal is authorized for use, plus the matching token-chal and client account key thumbprint. If it needs to, the ACME client waits until the Agent is configured before moving on 🫶
  4. The ACME client POSTs a Response Object (Section 3.2) to the challenge URL on the ACME server, following Section 7.5.1 of [RFC8555]. The payload object is built according to Section 3.2 💌
  5. The administrative element waits for a Challenge Bundle with the authorized ACME parameters, including its id-chal payload, following Section 3.3 👀
  6. The administrative element joins token-bundle and token-chal (each as a base64url-encoded text string) and computes the Key Authorization following Section 8.1 of [RFC8555], using the full token and client account key thumbprint 🧪
  7. The administrative element picks the highest-priority hash algorithm that both the client and server support, uses it to compute the digest of the Key Authorization result, and generates a Response Bundle to send back to the ACME server following Section 3.4 🔐
  8. The ACME client waits for the authorization to be finalized on the ACME server, following Section 7.5.1 of [RFC8555] ⏳
  9. Once the challenge is completed (successfully or not), the ACME client tells the BP Agent that the id-chal isn't usable anymore. If the authorization fails, the ACME client MAY retry the challenge from Step 3 🔁

The ACME server checks the client's control over a Node ID like this:

  1. The ACME server gets a newOrder or newAuthz request that includes the identifier type "bundleEID", where the URI value is a Node ID 📥
  2. The ACME server makes an authorization for the Node ID with challenge type "bp-nodeid-00", following Section 3.1 🧁
  3. The ACME server gets a POST to the challenge URL listed in the authorization object. The payload gets handled according to Section 3.2 📬
  4. Through the administrative element of its BP Agent, the ACME server sends one or more Challenge Bundles following Section 3.3. Each Challenge Bundle has a distinct, random token-bundle so it can be matched with a Response Bundle later. Computing an expected Key Authorization digest isn't needed until a response comes back with a chosen hash algorithm 🌈
  5. The ACME server waits for Response Bundle(s) for a limited amount of time (based on the Response Object in Section 3.2). Responses are encoded following Section 3.4 ⏰
  6. Once they're received and decoded, the ACME server checks each Response Bundle's contents following Section 3.4.1. After every Challenge Bundle has been answered or timed out, the ACME server policy (see Section 3.5) decides whether the validation worked. If it didn't, a client may retry the challenge starting from Step 3 🥲

When a BP Agent responds to a Challenge Bundle, it SHALL send a single Response Bundle following Section 3.4 🍓 A BP Agent SHALL respond to ACME challenges only within the time interval and only for the id-chal the ACME client indicated 💜 A BP Agent SHALL respond to multiple Challenge Bundles that have the same ACME parameters but different Bundle identities (source Node ID and timestamp). Those correspond to the ACME server validating over multiple routing paths 🗺️

3.1. DTN Node ID Challenge Object 🧚‍♀️

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 IDs 🎀

The DTN Node ID Challenge Object has the following content:

  • type (required, string): The string "bp-nodeid-00".
  • id-chal (required, string): This is a random value tied to a challenge that lets a client filter valid Challenge Bundles (Section 3.3). The same value gets used for all Challenge Bundles tied to an ACME challenge, including multi-perspective validation with multiple sources as described in Section 3.5. This value SHALL have at least 128 bits of entropy. It SHALL NOT contain any characters outside the base64url alphabet described in Section 5 of [RFC4648]. Trailing '=' padding characters SHALL be stripped. See BCP 106 [RFC4086] for more on randomness requirements 🎲
  • token-chal (required, string): This is a random value used as part of the Key Authorization algorithm, and it's only communicated to the ACME client over the ACME channel 🤫 This value SHALL have at least 128 bits of entropy. It SHALL NOT contain any characters outside the base64url alphabet described in Section 5 of [RFC4648]. Trailing '=' padding characters SHALL be stripped. See BCP 106 [RFC4086] for more on randomness requirements 🔐

Here's an example object:

{
  "type": "bp-nodeid-00",
  "url": "https://example.com/acme/chall/prV_B7yEyA4",
  "id-chal": "dDtaviYTPUWFS3NK37YWfQ",
  "token-chal": "tPUZNY4ONIk6LxErRFEjVw"
}

The token-chal value in this object applies to the entire challenge. It can match up with several different token-bundle values when multiple Challenge Bundles get sent for one validation ✨

3.2. DTN Node ID Response Object 💌

okay bestie, the DTN Node ID Response Object is what the ACME client sends when it says "yep, I approve this Node ID validation" 💅 (see Section 7.5.1 of [RFC8555]). DTNs can have way longer delays than regular networks, but those delays are roughly predictable 🫶, so the client can tell the ACME server when a validation round-trip is gonna take longer than the usual non-DTN delays (like, on the order of seconds) ✨.

Here's what's inside the object 🎀:

  • rtt (optional, number) 🌸: the expected Round-Trip Time (RTT), in seconds, between sending a Challenge Bundle and receiving a Response Bundle. It's just a hint for how long to wait for replies, not an authoritative rule 🙈. The minimum RTT value SHALL be zero. Zero doesn't mean anything extra special. It just means the response is expected in less than the tiniest unit the ACME client counts in.

Example, bestie 🧚:

{
  "rtt": 300.0
}

A Response Object SHALL NOT be sent until the BP Agent has been set up to properly respond to the challenge 🚫. The RTT value is meant to show any node-specific path delays expected from the ACME server. There's no requirement on which path (or paths) Bundles may take between the ACME server and the BP Agent, and the ACME server can try some path diversity, so the RTT value SHOULD be pessimistic 😬.

A default Bundle response interval (for when the object has no RTT) SHOULD be a configurable parameter of the ACME server 🎛️. If the ACME client did send an RTT, the response interval SHOULD be twice the RTT, with the limiting logic described below applied 👀. The lower limit is network specific, but it SHOULD NOT be shorter than one second ⏱️. The upper limit is also network specific, but it SHOULD NOT be longer than one minute (60 seconds) for a terrestrial-only DTN 🌍.

3.3. ACME Node ID Validation Challenge Bundle 🎯

Each ACME Node ID Validation Challenge Bundle SHALL be structured and encoded in accordance with BPv7 [RFC9171] 📦.

Each Challenge Bundle has these parameters, listed here 📋:

  • Bundle Processing Control Flags: the primary block flags SHALL indicate that the payload is an administrative record 📝. The primary block flags SHALL also indicate that user application acknowledgement is requested. That flag is what tells the Challenge Bundle apart from the Response Bundle 👀.
  • Destination EID: the Destination EID SHALL be the ACME-server-normalized Node ID being validated 🎯.
  • Source Node ID: the Source Node ID SHALL indicate the Node ID of a BP Agent of the ACME server doing the challenge 🥊.
  • Creation Timestamp and Lifetime: the Creation Timestamp SHALL be set to the time the challenge got generated ⏰. The Lifetime SHALL indicate the response interval (of Section 3.2) for which the ACME server will accept responses to this challenge.
  • Administrative Record Type Code: this is set to the ACME Node ID Validation type code defined in Section 7.3 🏷️.
  • Administrative Record Content: the Challenge Bundle administrative record content SHALL consist of a CBOR map containing the following three pairs 🗂️:
    • One pair SHALL consist of key 1 with a value of ACME challenge id-chal, copied from the Challenge Object, represented as a CBOR byte string.
    • One pair SHALL consist of key 2 with a value of ACME challenge token-bundle, represented as a CBOR byte string. The token-bundle is a random value that uniquely identifies the Challenge Bundle 🔐. This value SHALL have at least 128 bits of entropy. See BCP 106 [RFC4086] for additional information on randomness requirements.
    • One pair SHALL consist of key 4 with a value of an array containing acceptable hash algorithm identifiers. The array SHALL be ordered in descending preference, with the first item being the most preferred. The array SHALL contain at least one item. Each algorithm identifier SHALL correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry [IANA-COSE] 🧁.

This structure is part of the extension CDDL in Appendix A. An example full Challenge Bundle is included in Appendix B.1 📖.

For interoperability, entities that use this validation method SHALL support the hash algorithm "SHA-256" (value -16) [RFC9054] 🤝. This requirement allows different implementations to be configured to use an interoperable algorithm, but does not preclude the use of other algorithms with either higher or lower priority 🌈.

If the BP Agent generating a Challenge Bundle does not have a well-synchronized clock, or the agent responding to the challenge is expected to not have a well-synchronized clock, the Bundle SHALL 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 accordance with Section 4 or with a Security Source identical to the Bundle Source Node 🛡️. Challenge Bundles SHALL NOT be directly encrypted by the Block Confidentiality Block (BCB) method or any other method (see Section 6.1) 🙅‍♀️.

3.3.1. Challenge Bundle Checks 🔍

A proper Challenge Bundle meets all of the following criteria, no cap 💯:

  • The Challenge Bundle was received within the time interval allowed for the challenge. The allowed interval starts at the Creation Timestamp and extends for the Lifetime of the Challenge Bundle.
  • The Challenge Bundle contains a BIB that covers at least the primary block and payload. That BIB has a Security Source that is trusted and passes security-context-specific validation (i.e., Message Authentication Code (MAC) or signature verification) 🔏.
  • The challenge payload contains the id-chal as indicated in the ACME Challenge Object.
  • The challenge payload contains a token-bundle matching the definition in Section 3.3.
  • The challenge payload contains at least one hash algorithm identifier acceptable to the client.

Failure to match any of the above SHALL cause the Challenge Bundle to be otherwise ignored by the BP Agent 🙃. It is an implementation matter of how to react to such failures, which could include logging the event, incrementing counters, or raising alarms 🚨.

3.4. ACME Node ID Validation Response Bundles 📨

Each ACME Node ID Validation Response Bundle SHALL be structured and encoded in accordance with BPv7 [RFC9171] 📦.

Each Response Bundle has these parameters, listed here 📋:

  • Bundle Processing Control Flags: the primary block flags SHALL indicate that the payload is an administrative record 📝. The primary block flags SHALL NOT indicate that user application acknowledgement is requested. This flag is what distinguishes the Response Bundle from the Challenge Bundle 👀.
  • Destination EID: the Destination EID SHALL be identical to the Source Node ID of the Challenge Bundle to which this response corresponds 🎯.
  • Source Node ID: the Source Node ID SHALL be identical to the Destination EID of the Challenge Bundle to which this response corresponds 🔁.
  • Creation Timestamp and Lifetime: the Creation Timestamp SHALL be set to the time at which the response was generated ⏰. The response Lifetime SHALL indicate the response interval remaining if the Challenge Bundle indicated a limited Lifetime.
  • Administrative Record Type Code: set to the ACME Node ID Validation type code defined in Section 7.3 🏷️.
  • Administrative Record Content: the Response Bundle administrative record content SHALL consist of a CBOR map containing the following three pairs 🗂️:
    • One pair SHALL consist of key 1 with value of ACME challenge id-chal, copied from the Request Bundle, represented as a CBOR byte string.
    • One pair SHALL consist of key 2 with value of ACME challenge token-bundle, copied from the Request Bundle, represented as a CBOR byte string.
    • One pair SHALL consist of key 3 with value of a two-element array containing the pair of a hash algorithm identifier and the hash byte string. The algorithm identifier SHALL correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry [IANA-COSE] 🧁.

This structure is part of the extension CDDL in Appendix A. An example full Response Bundle is included in Appendix B.2 📖.

If the BP Agent responding to a Challenge Bundle does not have a well-synchronized clock, it SHALL use any information about last-hop delays and (if present) Bundle Age extension data to infer the age of the Challenge Bundle and Lifetime of the Response Bundle 🕰️.

Response Bundles SHALL include a BIB in accordance with Section 4 🛡️. Response Bundles SHALL NOT be directly encrypted by BCB or any other method (see Section 6.1 for explanation) 🙅‍♀️.

3.4.1. Response Bundle Checks ✅

A proper Response Bundle meets all of the following criteria, periodt 💅:

  • The Response Bundle was received within the time interval allowed for the challenge. The allowed interval starts at the Creation Timestamp and extends for the Lifetime of the associated Challenge Bundle. The interval of the Challenge Bundle is used here because the interval of the Response Bundle could be made to disagree with the Challenge Bundle ⚠️.
  • The Response Bundle Source Node ID is identical to the Node ID being validated. The comparison of Node IDs SHALL use the comparison logic of the NODE-ID from Section 4.4.1 of [RFC9174] 🔤.
  • The Response Bundle contains a BIB that covers at least the primary block and payload. That BIB has a Security Source that is trusted and passes security-context-specific validation 🔏.
  • 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 correlated) 🔗.
  • The response payload contains a hash algorithm identifier acceptable to the server (as indicated in the Challenge Bundle) 🧁.
  • The response payload contains the expected Key Authorization digest computed by the ACME server 🔑.

Any of the failures above SHALL cause that single-perspective validation to fail 💀. Any of the failures above SHOULD be distinguished as subproblems to the ACME client 🧩. The lack of a response within the expected response interval, as defined in Section 3.2, SHALL also be treated as a validation failure ⏰🚫.

3.5. Multi-Perspective Validation ✨

okay so some networks are kinda sketchy 👀 and an on-path attacker could mess with a validation. to dodge that, an ACME server can run one validation but check it through multiple Challenge Bundle sources, or through multiple routing paths. this is called "multi-perspective validation" 🦋. it's what [RFC8555] recommends in Section 10.2 of [RFC8555], and one implementation of it is used by Let's Encrypt in its operational deployment [LE-multi-perspective]. whether it's actually useful is part of this spec being experimental (see Section 1.5), so no promises yet 🧪

when policy says so, an ACME server SHALL send multiple Challenge Bundles from different sources in the BP network. when several Challenge Bundles get sent for one validation, it's up to the ACME server's policy to decide if the validation as a whole counts as a success 💅 each single-source result is a success or failure, as defined in Section 3.4.1.

a RECOMMENDED validation policy is to succeed if the challenge from a primary Bundle source works out and there's no more than one failure from a secondary source 🌸 which perspectives count as primary or secondary is an implementation matter, so that's up to you bestie.

whether it's single- or multi-perspective, a validation failure SHALL be indicated with the ACME error type incorrectResponse 🙈 and each specific perspective failure SHOULD be shown to the ACME client as a validation subproblem.

4. Bundle Integrity Gateway 🛡️

this section defines a BIB use that's lowkey a dead ringer for DKIM email signing [RFC6376] 📧 here, a routing node in a DTN subnetwork vouches for where a Bundle came from by adding a BIB before forwarding it. so the Bundle receiver doesn't need to trust the original source at all, it only needs to trust this Security Source node 🫶 the receiver does need policy config to know which Security Sources are allowed to vouch for which Bundle sources. the utility of an integrity gateway is part of the experimental nature (Section 1.5) of this spec, so yep, same energy as before 🧪

an integrity gateway SHALL validate the Source Node ID of a Bundle, using local-network-specific means, before it adds a BIB to the Bundle 🔐 the exact method is network specific, but it could use physical-layer, network-layer, or BP-convergence-layer authentication. the Bundle source could also add its own BIB with a local-network-specific security context or local-network-specific key material (i.e., a group key shared within the local network) 🍓

when an integrity gateway adds a BIB, it SHALL follow the BPSec [RFC9172] requirements 💜 the BIB integrity SHALL cover both the payload block and the primary block, either directly as a target or as additional authenticated data for the payload block MAC/signature. and the Security Source of this BIB SHALL be either the Bundle source Node ID itself or a routing node trusted by the destination node (see Section 6.2) ✨

5. Certificate Request Profile 📜

the ultimate goal of this ACME validation is to let a CA issue certificates that follow the profiles of Section 4.4.2 of [RFC9174] and Section 4 of [BPSEC-COSE] 🎀 these are called "Bundle security certificates" and honestly they're giving main character energy.

the ACME identifier type bundleEID lines up with the PKIX certificate and certificate request "NODE-ID" from Section 4.4.1 of [RFC9174] 🧚 this NODE-ID shows up in certificate requests with an extensionRequest attribute (see [RFC2985]) that holds a SAN extension. the identities in it are of type otherName with an Other Name form of BundleEID, identified by id-on-bundleEID from the "SMI Security for PKIX Other Name Forms" registry [IANA-SMI]. the BundleEID Other Name form is encoded as an IA5String, so it SHALL be treated as being in the percent-encoded form of Section 2.1 of [RFC3986] 🔥

one thing that really defines Bundle security certificates is the Extended Key Usage key purpose id-kp-bundleSecurity [IANA-SMI], as defined in Section 4.4.2.1 of [RFC9174] 👑 when someone requests a certificate that includes a NODE-ID, the CSR SHOULD include an Extended Key Usage of id-kp-bundleSecurity. and when a Bundle security certificate gets issued based on a validated NODE-ID, the certificate SHALL include an Extended Key Usage of id-kp-bundleSecurity 💖

5.1. Multiple Identity Claims

hold up, this is a whole vibe 🌈 a single Bundle security CSR MAY contain a mixed set of SAN identifiers, including combos of IP-ID [RFC9525], DNS-ID [RFC9525], and NODE-ID [RFC9174] types. those map to the ACME identifier types ip, dns, and bundleEID, respectively.

there's no restriction on how a certificate combines these claims 🤷‍♀️ but every identifier SHALL be validated by an ACME server before it can issue such a certificate as part of an associated ACME order. this is no different from how ACME already works [RFC8555], but it's mentioned here so CA policy can handle these situations, especially when one identifier out of several fails validation 🙈 the existing validation mechanisms are defined for identifier type ip [RFC8738] and dns [RFC8555], among others [IANA-ACME].

the specific TLS-based security use case for the TCP CL in Section 4.4 of [RFC9174] allows, and for some network policies requires, that a certificate authenticate both the DNS name of an entity and its Node ID 🫶 these authentications apply to each identifier type, which get used at different network layers and at different points during secure session establishment.

5.2. Generating Encryption-Only or Signing-Only Bundle Security Certificates

the ACME extensions in this document can be used to request encryption-only or signing-only Bundle security certificates 🔑 whether a restricted-use or unrestricted-use certificate is valid depends on both CA policy for issuing such certificates and constraints based on the requested key and algorithm types. it's a whole balancing act, bestie 💅

to request a signing-only Bundle security certificate, the CSR SHALL include the key usage extension with the digitalSignature and/or nonRepudiation bits set and no other bits set ✍️

to request an encryption-only Bundle security certificate, the CSR SHALL include the key usage extension with the keyEncipherment or keyAgreement bits set and no other bits set 🔒

if the CSR has both of the above sets of key usage bits, or if it has no key usage extension at all, that signals the ACME server to issue a Bundle security certificate that's good for both signing and encryption 🌟

6. Security Considerations 🚨

okay bestie, this part is SERIOUS, so get comfy 😭 this section splits security considerations into threat categories, following the guidance of BCP 72 [RFC3552] 🕵️‍♀️

6.1. Threat: Passive Leak of Validation Data

because this challenge mechanism is used to bootstrap security between DTN Nodes, the challenge and its response are likely to get sent in plaintext 🙈 the only ACME data on the wire is a random token and a cryptographic digest, so there's no sensitive data to leak during the Node ID Validation Bundle exchange. and since each challenge uses a separate token pair, there's zero value for an on-path attacker in seeing tokens from past challenges and/or responses 🧁

it's possible for intermediate BP Nodes to encapsulate-and-encrypt Challenge Bundles and/or Response Bundles while they cross untrusted networks, but that's a DTN configuration matter and it's outside the scope of this document 🫧

6.2. Threat: BP Node Impersonation

as described in Section 10.1 of [RFC8555], an active attacker can alter data on both the ACME client channel and the DTN validation channel 😈

the main mitigation is to hand off Bundle integrity sourcing to a trusted routing node that's near the Bundle source node, near in the sense of Bundle routing topology, as defined in Section 4 💜 this is functionally similar to DKIM email signing [RFC6376] and it gives some level of secure Bundle origination.

another way to fight on-path attacks is to try validating the same Node ID from multiple sources, hopefully over multiple Bundle routing paths, as defined in Section 3.5 🦋 but guaranteeing Bundle routing isn't trivial, so more advanced techniques like onion routing (using Bundle-in-Bundle encapsulation) could be used.

6.3. Threat: Bundle Replay

it's possible for an on-path attacker to replay both Challenge Bundles and Response Bundles 🔁 even in a properly configured DTN, intermediate Bundle routers might use multi-path forwarding of a singleton-destination Bundle.

ultimately, the whole point of the ACME Bundle exchange is to derive a Key Authorization value and its cryptographic digest, then send that digest back to the ACME server for validation. so the uniqueness of the Key Authorization directly sets the scope of replay validity ✨ the uniqueness of each token-bundle makes the Key Authorization unique to the Challenge Bundle. and the uniqueness of each token-chal makes it unique to that ACME challenge, instead of being based only on values that on-path eavesdroppers can see 👀

having each Bundle's primary block and payload block covered by a BIB from a trusted Security Source (see Section 4) means a replayed Bundle can't be altered in the blocks ACME uses 🔐 put it all together and there's no degraded security from replaying a Challenge Bundle or a Response Bundle, even when the primary or payload block isn't covered by a BIB. the worst that can happen with Bundle replay is wasted network resources, as described in Section 6.4 🗑️

6.4. Threat: Denial of Service

everything in this section adds up to a potential denial-of-service against a BP Agent 😭

a malicious entity can keep sending Challenge Bundles to a BP Agent 📨 the victim BP Agent can ignore Challenge Bundles that don't match the specific time interval and challenge token the ACME client told the BP Agent to expect. the victim BP Agent can also require all Challenge Bundles to be BIB-signed, to make sure the challenge is authentic 🛡️

a malicious entity can also keep sending Response Bundles to a BP Agent 📬 the victim BP Agent can ignore Response Bundles that don't match the specific time interval, Source Node ID, or challenge token for an active Node ID validation.

similar to other validation methods, an ACME server validating a DTN Node ID could get abused as a denial-of-service amplifier 📈 for this reason, any ACME server can rate-limit validation activities for individual clients and individual certificate requests 🚦

6.5. Inherited Security Considerations

this protocol leans on ACME for part of its operation, so the security considerations of ACME [RFC8555] apply to all ACME client-server exchanges during Node ID validation 🧩

this protocol also leans on BPv7 for part of its operation, so the security considerations of BPv7 [RFC9171] and BPSec [RFC9172] apply to all BP messaging during Node ID validation 🌸

6.6. Out-of-Scope BP Agent Communication ✨

Okay so bestie, the messages going between an ACME client or ACME server and its BP Agent are technically out of scope for this doc 🙈 BUT they are still super critical to Node ID validation security, no cap. Either channel can leak data or become an attack vector if it isn't locked down properly 😭 Both channels need to protect against spoofed messages going in either direction, otherwise validation sequencing gets interrupted and somebody could sneak in a false validation that succeeds 💀🔥

The ACME server and its BP Agent swap the outgoing id-chal, the token-bundle, and the Key Authorization digest. Those values do not need to be confidential, bc they're already sent in plaintext over the BP channel anyway 🫶

Now the tea 🍵: depending on how an implementation is built, the ACME client might send its client account key thumbprint to its BP Agent so the BP Agent can compute the Key Authorization digest itself 🧚 If an ACME client does send its thumbprint over, it is important that this data stays confidential, because it's what binds the client account key to the Node ID validation (and to every other type of ACME validation too) 💜 Skipping that transmission would mean a full round-trip between the BP Agent and the ACME client, which can be really annoying when the two are on a long-delay network 🌈

7. IANA Considerations 🎀

Okay so this spec adds stuff to two registry groups: the "Automated Certificate Management Environment (ACME) Protocol" registry group and the "Bundle Protocol" registry group 🦋

7.1. ACME Identifier Types 🌸

Within the "Automated Certificate Management Environment (ACME) Protocol" registry group [IANA-ACME], one new entry got added to the "ACME Identifier Types" registry, and it looks like this:

                     +===========+===========+
                     | Label     | Reference |
                     +===========+===========+
                     | bundleEID | RFC 9891  |
                     +-----------+-----------+

                              Table 1

7.2. ACME Validation Methods 💅

Within the same ACME registry group [IANA-ACME], the "ACME Validation Methods" registry picked up a new entry too 👑

       +==============+=================+======+===========+
       | Label        | Identifier Type | ACME | Reference |
       +==============+=================+======+===========+
       | bp-nodeid-00 | bundleEID       | Y    | RFC 9891  |
       +--------------+-----------------+------+-----------+

                              Table 2

7.3. Bundle Administrative Record Types 🧚

Within the "Bundle Protocol" registry group [IANA-BP], the "Bundle Administrative Record Types" registry got a new entry, and yes it's giving main character energy ✨

  +=========================+=======+==============+===========+
  | Bundle Protocol Version | Value | Description  | Reference |
  +=========================+=======+==============+===========+
  | 7                       | 255   | ACME Node ID | RFC 9891  |
  |                         |       | Validation   |           |
  +-------------------------+-------+--------------+-----------+

                             Table 3

8. References 📚

8.1. Normative References 💜

These are the must-read ones, bestie 🫶

8.2. Informative References 🦋

Extra reading if you're curious, no pressure 🌈

Appendix A. Administrative Record Types CDDL 🧾

The extension of BPv7 from Appendix B of [RFC9171] for the ACME Bundles in Sections 3.3 and 3.4 is the following CDDL, and it's kinda iconic 💖

; All ACME records have the same structure
$admin-record /= [0xFF, acme-record]
acme-record = acme-challenge-record / acme-response-record
acme-challenge-record = {
  id-chal,
  token-bundle,
  alg-list
}
acme-response-record = {
  id-chal,
  token-bundle,
  key-auth-digest
}

id-chal = (1: bstr)
token-bundle = (2: bstr)
key-auth-digest = (3: [
    alg: alg-id,
    value: bstr
])
alg-list = (4: [+ alg-id])
; From the IANA COSE registry, only hash algorithms allowed
alg-id = tstr / int

Appendix B. Example Authorization 🌷

This example is a Bundle exchange for the ACME server with Node ID dtn://acme-server/ performing a verification for ACME client Node ID dtn://acme-client/. The example Bundles use no block CRC or BPSec integrity, which is for simplicity and is not recommended for normal use 🙈 The provided figures are extended diagnostic notation [RFC8610].

For this example, the ACME client key thumbprint has the base64url-encoded value of:

"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"

and the ACME-server generated token-chal has the base64url-encoded value of:

"tPUZNY4ONIk6LxErRFEjVw"

B.1. Challenge Bundle

okay so this is the example Challenge Bundle 🎀 The token-bundle (carried as a byte string over BP) has the base64url-encoded value of:

p3yRYFU4KxwQaHQjJ2RdiQ ✨

Here's the minimal-but-valid Challenge Bundle, Figure 2 💖 It's giving a 60-second window: the ACME client has to respond in that time 🕐

[_
  [
    7, / BP version /
    0x22, / flags: user-app-ack, payload-is-an-admin-record /
    0, / CRC type: none /
    [1, "//acme-client/"], / destination /
    [1, "//acme-server/"], / source /
    [1, 0], / report-to: none /
    [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /
    60000 / lifetime: 60s /
  ],
  [
    1, / block type code /
    1, / block number /
    0, / flags /
    0, / CRC type: none /
    <<[ / type-specific data /
      0xFF, / record-type-code /
      { / record-content /
        1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
        2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
        4: [-16] / alg-list: SHA-256 /
      }
    ]>>
  ]
]

Figure 2: Example Challenge Bundle 🦋

B.2. Response Bundle

okay bestie, this part is so satisfying 🥹 When the tokens get mixed with the key thumbprint, you get the full Key Authorization value. It's folded across lines so it's easier to read, using the "single backslash" strategy from Section 7 of [RFC8792] 💅

/ NOTE: '\' line wrapping per RFC 8792 /

"p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.\
LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"

And here's the minimal-but-valid Response Bundle, Figure 3 🌸 This one tells the client there are 30 seconds left in the response time window ⏳

[_
  [
    7, / BP version /
    0x02, / flags: payload-is-an-admin-record /
    0, / CRC type: none /
    [1, "//acme-server/"], / destination /
    [1, "//acme-client/"], / source /
    [1, 0], / report-to: none /
    [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 /
    30000 / lifetime: 30s /
  ],
  [
    1, / block type code /
    1, / block number /
    0, / flags /
    0, / CRC type: none /
    <<[ / block-type-specific data /
      0xFF, / record-type-code /
      { / record-content /
        1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
        2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
        3: [-16, b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew']
        / SHA-256 key auth. digest /
      }
    ]>>
  ]
]

Figure 3: Example Response Bundle 🦋

Acknowledgements ✨

this spec is built on DTN use cases for PKIX certificate issuance, so shoutout to everyone who brought those to the table 🙌

The workflow and terminology of this validation method were originally copied from the work of Alexey Melnikov for email validation [RFC8823]. Thank you, Alexey, you're iconic 👑💜

Author's Address 🌈

Brian Sipos
RKF Engineering Solutions, LLC
7500 Old Georgetown Road
Suite 1275
Bethesda, MD 20814-6198
United States of America
Email: brian.sipos+ietf@gmail.com
📦 where this page comes from