<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="exp" docName="draft-ietf-acme-dtnnodeid-18" number="9891" updates="" obsoletes="" sortRefs="true" symRefs="true" ipr="trust200902" submissionType="IETF" tocInclude="true" xml:lang="en" consensus="true" prepTime="2025-11-20T13:48:20" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid-18" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9891" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ACME DTN Node ID">Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension</title>
    <seriesInfo name="RFC" value="9891" stream="IETF"/>
    <author fullname="Brian Sipos" initials="B." surname="Sipos">
      <organization abbrev="RKF Engineering" showOnFrontPage="true">RKF Engineering Solutions, LLC</organization>
      <address>
        <postal>
          <street>7500 Old Georgetown Road</street>
          <street>Suite 1275</street>
          <city>Bethesda</city>
          <region>MD</region>
          <code>20814-6198</code>
          <country>United States of America</country>
        </postal>
        <email>brian.sipos+ietf@gmail.com</email>
      </address>
    </author>
    <date month="11" year="2025"/>
    <area>SEC</area>
    <workgroup>acme</workgroup>
    <keyword>ACME</keyword>
    <keyword>DTN</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol that allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client.
A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint": an endpoint that is registered on a single BP Node.
The DTN Node ID is encoded both as a certificate Subject Alternative Name (SAN) identity of type otherName with an Other Name form of <tt>BundleEID</tt> and as an ACME Identifier type "bundleEID".
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This document is a product of the Internet Engineering
            Task Force (IETF).  It represents the consensus of the IETF 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. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9891" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scope">Scope</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-strategy">Authorization Strategy</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-cddl">Use of CDDL</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.4">
                <t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent="1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.5">
                <t indent="0" pn="section-toc.1-1.1.2.5.1"><xref derivedContent="1.5" format="counter" sectionFormat="of" target="section-1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-experiment-scope">Experiment Scope</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bundle-eid-acme-identifier">Bundle EID ACME Identifier</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-subsets-of-bundle-eid">Subsets of Bundle EID</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtn-node-id-validation">DTN Node ID Validation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtn-node-id-challenge-objec">DTN Node ID Challenge Object</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtn-node-id-response-object">DTN Node ID Response Object</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-node-id-validation-cha">ACME Node ID Validation Challenge Bundle</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-challenge-bundle-checks">Challenge Bundle Checks</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-node-id-validation-res">ACME Node ID Validation Response Bundles</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.4.2">
                  <li pn="section-toc.1-1.3.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.1.1"><xref derivedContent="3.4.1" format="counter" sectionFormat="of" target="section-3.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response-bundle-checks">Response Bundle Checks</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-perspective-validatio">Multi-Perspective Validation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bundle-integrity-gateway">Bundle Integrity Gateway</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certificate-request-profile">Certificate Request Profile</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-identity-claims">Multiple Identity Claims</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-encryption-only-">Generating Encryption-Only or Signing-Only Bundle Security Certificates</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threat-passive-leak-of-vali">Threat: Passive Leak of Validation Data</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threat-bp-node-impersonatio">Threat: BP Node Impersonation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threat-bundle-replay">Threat: Bundle Replay</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threat-denial-of-service">Threat: Denial of Service</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-inherited-security-consider">Inherited Security Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-out-of-scope-bp-agent-commu">Out-of-Scope BP Agent Communication</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-identifier-types">ACME Identifier Types</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-validation-methods">ACME Validation Methods</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bundle-administrative-recor">Bundle Administrative Record Types</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-administrative-record-types">Administrative Record Types CDDL</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-authorization">Example Authorization</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-challenge-bundle">Challenge Bundle</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="B.2" format="counter" sectionFormat="of" target="section-appendix.b.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response-bundle">Response Bundle</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec-intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
Although the original purpose of the Automatic Certificate Management Environment (ACME) <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> was to allow Public Key Infrastructure using X.509 (PKIX) Certification Authorities (CAs) to validate network domain names of clients, the same mechanism can be used to validate any of the subject identity claims supported by the PKIX profile <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.
      </t>
      <t indent="0" pn="section-1-2">
In this specification, the claim being validated is a Subject Alternative Name (SAN) identity of type <tt>otherName</tt> with an Other Name form of <tt>BundleEID</tt>, which is used to represent 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 <xref section="4.2.5.2" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.2" derivedContent="RFC9171"/>, which is equivalent to the EID being usable as a singleton endpoint.
One 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" as defined in <xref section="4.2.5.1" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1" derivedContent="RFC9171"/> are valid for a singleton endpoint and, thus, a Node ID.
Because the <tt>BundleEID</tt> claim is new to ACME, a new ACME Identifier type "bundleEID" is needed to manage this claim within ACME messaging.
      </t>
      <t indent="0" pn="section-1-3">
Once an ACME server validates a Node ID, either as a pre-authorization of an identifier type "bundleEID" or as one of the authorizations of an order containing an identifier type "bundleEID", the client can finalize the order using an associated Certificate Signing Request (CSR).
Because a single order can contain multiple identifiers of multiple types, there can be operational issues for a client attempting to, and possibly failing to, validate those multiple identifiers as described in <xref target="sec-multiple-claims" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.
Once a certificate is issued for a Node ID, how the ACME client configures the BP Agent with the new certificate is an implementation matter.
      </t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-scope">Scope</name>
        <t indent="0" pn="section-1.1-1">
This document describes the ACME message contents <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/>, Bundle Protocol version 7 (BPv7) payloads <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>, and Bundle Protocol Security (BPSec) operations <xref target="RFC9172" format="default" sectionFormat="of" derivedContent="RFC9172"/> needed to validate claims of Node ID ownership.
        </t>
        <t indent="0" pn="section-1.1-2">
This document does not address:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-3">
          <li pn="section-1.1-3.1">
Mechanisms for communication between an ACME client or ACME server and their associated BP Agent(s), depicted as steps 1, 2, 5, and 6 of <xref target="fig-entity-relations" format="default" sectionFormat="of" derivedContent="Figure 1"/>.
This document only describes exchanges between ACME client-server pairs and between their respective associated BP Agents.
          </li>
          <li pn="section-1.1-3.2">
Specific BP extension blocks or BPSec contexts necessary to fulfill the security requirements of this protocol.
The exact security context needed, and its parameters, is network specific.
          </li>
          <li pn="section-1.1-3.3">
Policies or mechanisms for defining or configuring Bundle integrity gateways, or trusting integrity gateways on an individual entity or across a network.
          </li>
          <li pn="section-1.1-3.4">
Mechanisms for locating or identifying other Bundle entities (peers) within a network or across an internet.
The mapping of a Node ID to a potential Convergence-Layer (CL) protocol and network address is left to implementation and configuration of the BP Agent and its various potential routing strategies.
          </li>
          <li pn="section-1.1-3.5">
Logic for routing Bundles along a path toward a Bundle's endpoint.
This protocol is involved only in creating Bundles at a source and handling them at a destination.
          </li>
          <li pn="section-1.1-3.6">
Logic for performing rate control and congestion control of Bundle transfers.
The ACME server is responsible for rate control of validation requests.
          </li>
          <li pn="section-1.1-3.7">
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.
          </li>
          <li pn="section-1.1-3.8">
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.
          </li>
          <li pn="section-1.1-3.9">
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.
          </li>
        </ul>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-authorization-strategy">Authorization Strategy</name>
        <t indent="0" pn="section-1.2-1">
The basic unit of data exchange in a DTN is a Bundle <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>, which consists of a data payload with accompanying metadata.
An EID is used as the destination of a Bundle and can indicate either a singleton or a group destination.
A Node ID is used to identify the source of a Bundle and is used for routing through intermediate nodes, including the final node(s) used to deliver a Bundle to its destination endpoint.
A Node ID can also be used as an endpoint for Bundles conveying administrative records as explained in <xref section="6" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-6" derivedContent="RFC9171"/>.
More detailed descriptions of the rationale and capabilities of these networks can be found in the "<xref target="RFC4838" format="title" sectionFormat="of" derivedContent="Delay-Tolerant Networking Architecture"/>" <xref target="RFC4838" format="default" sectionFormat="of" derivedContent="RFC4838"/>.
        </t>
        <t indent="0" pn="section-1.2-2">
When an ACME client requests a pre-authorization or an order with an identifier type "bundleEID" (<xref target="sec-acme-uri" format="default" sectionFormat="of" derivedContent="Section 2"/>), the ACME server offers a "bp-nodeid-00" challenge type (<xref target="sec-validate-nodeid" format="default" sectionFormat="of" derivedContent="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 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.
This workflow is shown in <xref target="fig-entity-relations" format="default" sectionFormat="of" derivedContent="Figure 1"/>.
        </t>
        <figure anchor="fig-entity-relations" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-the-relationships-and-flows">The Relationships and Flows Between Node ID Validation Entities</name>
          <artwork align="center" pn="section-1.2-3.1">
     +------------+                             +------------+
     |    ACME    |&lt;===== HTTPS Exchanges =====&gt;|    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   |&lt;------------- Bundle -----|   Server's   | |
    |   BP Agent   |                           |   BP Agent   | |
    +--------------+                           +--------------+ |
           |                                     +----^---------+
           |     +-------------+                      |
           |     |  Integrity  |   (4) Response       |
           +----&gt;|   Gateway   |------ Bundle --------+
                 +-------------+
</artwork>
        </figure>
        <t indent="0" pn="section-1.2-4">
Because the DTN Node ID is used both for routing Bundles between BP Agents and for multiplexing administrative services within a BP Agent, there is no possibility to separate the ACME validation of a Node ID from normal Bundle handling for that same Node ID.
This leaves administrative record types as a way to keep the Node ID unchanged while disambiguating from other service data Bundles.
        </t>
        <t indent="0" pn="section-1.2-5">
There is nothing in this protocol that requires network-topological co-location of either the ACME client or ACME server with their respective associated BP Agent.
While ACME requires a low-enough latency network to perform HTTPS exchanges between the ACME client and server, the client's BP Agent (the one being validated) could be on the far side of a long-delay or multi-hop BP network.
The means by which the ACME client or server communicates with its associated BP Agent is an implementation matter.
        </t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.3">
        <name slugifiedName="name-use-of-cddl">Use of CDDL</name>
        <t indent="0" pn="section-1.3-1">
This document defines Concise Binary Object Representation (CBOR) structure using the Concise Data Definition Language (CDDL) <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>.
The entire CDDL structure can be extracted from the XML version of this document using the XPath expression:
        </t>
        <sourcecode markers="false" pn="section-1.3-2">'//sourcecode[@type="cddl"]'</sourcecode>
        <t indent="0" pn="section-1.3-3">
The following initial fragment defines the top-level symbols of this document's CDDL, which includes the example CBOR content.
        </t>
        <sourcecode type="cddl" markers="false" pn="section-1.3-4">
start = acme-record / bundle / tstr
</sourcecode>
        <t indent="0" pn="section-1.3-5">
The definitions for the rule <tt>bundle</tt> and socket <tt>$admin-record</tt> are taken from <xref section="B" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#appendix-B" derivedContent="RFC9171"/>.
        </t>
      </section>
      <section anchor="sec-terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.4">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.4-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
        <t indent="0" pn="section-1.4-2">
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 is prefixed with either "ACME" or "DTN" respectively.
Thus, within the ACME context the term is "DTN Node ID" while in the DTN context the name is just "Node ID".
        </t>
        <t indent="0" pn="section-1.4-3">
In this document, several terms are shortened for the sake of brevity.
These terms are as follows:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-1.4-4">
          <dt pn="section-1.4-4.1">Challenge Object:</dt>
          <dd pn="section-1.4-4.2">
This is a shortened form of the full "DTN Node ID Challenge Object".
It is a JSON object created by the ACME server for challenge type "bp-nodeid-00" as defined in <xref target="sec-nodeid-challenge-obj" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
          </dd>
          <dt pn="section-1.4-4.3">Response Object:</dt>
          <dd pn="section-1.4-4.4">
This is a shortened form of the full "DTN Node ID Response Object".
It is a JSON object created by the ACME client to authorize a challenge type "bp-nodeid-00" as defined in <xref target="sec-nodeid-response-obj" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
          </dd>
          <dt pn="section-1.4-4.5">Challenge Bundle:</dt>
          <dd pn="section-1.4-4.6">
This is a shortened form of the full "ACME Node ID Validation Challenge Bundle".
It is a Bundle created by the BP Agent managed by the ACME server to challenge a Node ID claim as defined in <xref target="sec-bundle-challenge" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.
          </dd>
          <dt pn="section-1.4-4.7">Response Bundle:</dt>
          <dd pn="section-1.4-4.8">
This is a shortened form of the full "ACME Node ID Validation Response Bundle".
It is a Bundle created by the BP Agent managed by the ACME client to validate a Node ID claim as defined in <xref target="sec-bundle-response" format="default" sectionFormat="of" derivedContent="Section 3.4"/>.
          </dd>
        </dl>
        <t indent="0" pn="section-1.4-5">
Because this is a document produced by the ACME WG, the following DTN BP terms are defined here to clarify how they are used by this ACME identifier type and validation mechanism.
        </t>
        <dl spacing="normal" newline="false" indent="3" pn="section-1.4-6">
          <dt anchor="term-endpoint-id" pn="section-1.4-6.1">Endpoint ID:</dt>
          <dd pn="section-1.4-6.2">
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 <xref section="4.2.5.1" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1" derivedContent="RFC9171"/>.
          </dd>
          <dt anchor="term-node-id" pn="section-1.4-6.3">Node ID:</dt>
          <dd pn="section-1.4-6.4">
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 <xref section="4.2.5.2" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.2" derivedContent="RFC9171"/>.
          </dd>
          <dt anchor="term-admin-eid" pn="section-1.4-6.5">Administrative EID:</dt>
          <dd pn="section-1.4-6.6">
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 <xref section="4.2.5.1" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1" derivedContent="RFC9171"/>.
          </dd>
        </dl>
      </section>
      <section anchor="sec-experiment" numbered="true" removeInRFC="false" toc="include" pn="section-1.5">
        <name slugifiedName="name-experiment-scope">Experiment Scope</name>
        <t indent="0" pn="section-1.5-1">
The emergent properties of DTN naming and BP security are still being developed and explored, especially between different organizational and administrative domains.  Thus, the Experimental status of this document is related more to the practical utility of this kind of Node ID validation than to the validation method itself.
The 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 the method of certificate validation and issuance is desired to be in-band on the network rather than 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 <xref target="RFC8823" format="default" sectionFormat="of" derivedContent="RFC8823"/>, it is expected to have few implementation difficulties or interoperability issues.
        </t>
        <t indent="0" pn="section-1.5-2">
Part of the experimental nature of the validation method defined in <xref target="sec-validate-nodeid" format="default" sectionFormat="of" derivedContent="Section 3"/>, and 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 <xref target="sec-multi-perspective" format="default" sectionFormat="of" derivedContent="Section 3.5"/> is also not assured.
The point of those multi-perspective requirements is that both the ACME client and server have consistent logic for handling the technique.
        </t>
        <t indent="0" pn="section-1.5-3">
The usefulness of the integrity gateway defined in <xref target="sec-bib-gateway" format="default" sectionFormat="of" derivedContent="Section 4"/> to this validation method is experimental: the way that naming authority in a DTN is either 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, which would behave conceptually similar to delegation of subdomains in the Domain Name System (DNS), but without the online interaction of DNS.
        </t>
        <t indent="0" pn="section-1.5-4">
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 for this would be an issuing CA and an ACME server 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 is not traceable to a valid identity certificate, which the edge nodes can obtain via the ACME server.
        </t>
        <t indent="0" pn="section-1.5-5">
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.
        </t>
      </section>
    </section>
    <section anchor="sec-acme-uri" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-bundle-eid-acme-identifier">Bundle EID ACME Identifier</name>
      <t indent="0" pn="section-2-1">
This specification is the first to make use of a Bundle EID to identify a claim for a certificate request in ACME.
In this document, the only purpose for which a Bundle EID ACME identifier is validated is as a DTN Node ID (see <xref target="sec-validate-nodeid" format="default" sectionFormat="of" derivedContent="Section 3"/>), but other specifications can define challenge types for other EID uses.
      </t>
      <t indent="0" pn="section-2-2">
Every ACME identifier type "bundleEID" <bcp14>SHALL</bcp14> have a value containing a text URI consistent with the requirements of <xref section="4.2.5.1" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1" derivedContent="RFC9171"/> using one of the schemes available from the "Bundle Protocol URI Scheme Types" registry <xref target="IANA-BP" format="default" sectionFormat="of" derivedContent="IANA-BP"/>.
Any identifier type "bundleEID" value that fails to properly percent-decode <bcp14>SHALL</bcp14> be rejected with an ACME error type of "malformed".
      </t>
      <t indent="0" pn="section-2-3">
An ACME server supporting identifier type "bundleEID" <bcp14>SHALL</bcp14> decode and normalize (based on scheme-specific syntax) all such received identifier values.
Any identifier type "bundleEID" value for which the scheme-specific part does not match the scheme-specific syntax <bcp14>SHALL</bcp14> be rejected with an ACME error type of "malformed".
Any identifier type "bundleEID" value that uses a scheme not handled by the ACME server <bcp14>SHALL</bcp14> be rejected with an ACME error type of "rejectedIdentifier".
      </t>
      <t indent="0" pn="section-2-4">
When an ACME server needs to request proof that a client controls a Bundle EID, it <bcp14>SHALL</bcp14> create an authorization with the identifier type "bundleEID".
An ACME server <bcp14>SHALL NOT</bcp14> attempt to dereference a Bundle EID value on its own.
It is the responsibility of an ACME validation method to ensure the EID ownership using a method authorized by the ACME client.
      </t>
      <t indent="0" pn="section-2-5">
An identifier for the Node ID of "dtn://example/" would be formatted as:
      </t>
      <sourcecode type="json" markers="false" pn="section-2-6">
{
  "type": "bundleEID",
  "value": "dtn://example/"
}</sourcecode>
      <section anchor="sec-eid-uses" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-subsets-of-bundle-eid">Subsets of Bundle EID</name>
        <t indent="0" pn="section-2.1-1">
A PKIX certificate SAN identity containing an Other Name form of <tt>BundleEID</tt> can hold any EID value (as a text URI).
But the certificate profile used by the TCP CL in <xref section="4.4" target="RFC9174" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9174#section-4.4" derivedContent="RFC9174"/> and supported by the ACME validation method in <xref target="sec-validate-nodeid" format="default" sectionFormat="of" derivedContent="Section 3"/> requires that the value hold a Node ID (<xref target="term-node-id" format="default" sectionFormat="of" derivedContent="Section 1.4"/>).
        </t>
        <t indent="0" pn="section-2.1-2">
In addition to the narrowing of that certificate profile, this validation method requires that the client's BP Agent respond to administrative records sent to the Node ID being validated.
Typically, this is limited to an Administrative EID (<xref target="term-admin-eid" format="default" sectionFormat="of" derivedContent="Section 1.4"/>) destination.
However, the administrative element of a BP Node is not prohibited from receiving administrative records for, or sending records from, other Node IDs in order to support this validation method.
        </t>
        <t indent="0" pn="section-2.1-3">
Neither that certificate profile nor this validation method support operating on non-singleton EIDs, but other validation methods could be defined to do so in order to support other certificate profiles.
        </t>
      </section>
    </section>
    <section anchor="sec-validate-nodeid" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-dtn-node-id-validation">DTN Node ID Validation</name>
      <t indent="0" pn="section-3-1">
The DTN Node ID validation method proves control over a Node ID by requiring the ACME client to configure a BP Agent to respond to specific Challenge Bundles sent from the ACME server.
The ACME server validates control of the Node ID by verifying that received Response Bundles correspond with the BP Node and client account key being validated.
      </t>
      <t indent="0" pn="section-3-2">
Similar to the ACME use case for email-address validation <xref target="RFC8823" format="default" sectionFormat="of" derivedContent="RFC8823"/>, this challenge splits the token into several parts, each part being transported by a different channel, and the Key Authorization result requires combining all parts of the token.
A separate challenge identifier is used as a filter by BP Agents similar to the challenge "from" used by email validation in <xref section="3" target="RFC8823" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8823#section-3" derivedContent="RFC8823"/>.
      </t>
      <t indent="0" pn="section-3-3">
The token parts are as follows:
      </t>
      <dl spacing="normal" newline="true" indent="3" pn="section-3-4">
        <dt pn="section-3-4.1">
          <tt>token-chal</tt>:
        </dt>
        <dd pn="section-3-4.2">
This token is unique to each ACME authorization.
It is contained in the Challenge Object of <xref target="sec-nodeid-challenge-obj" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
Each authorization can consist of multiple Challenge Bundles (e.g., taking different routes), but they all share the same <tt>token-chal</tt> value.
This ensures that the Key Authorization is bound to the specific ACME challenge (and parent ACME authorization).
This token does not appear on the BP channel; thus, any eavesdropper knowing the client's account key thumbprint (e.g., from some other validation method) is not able to impersonate the client.
        </dd>
        <dt pn="section-3-4.3">
          <tt>token-bundle</tt>:
        </dt>
        <dd pn="section-3-4.4">
This token is unique to each Challenge Bundle sent by the ACME server.
It is contained in the Challenge Bundle of <xref target="sec-bundle-challenge" format="default" sectionFormat="of" derivedContent="Section 3.3"/> and Response Bundle of <xref target="sec-bundle-response" format="default" sectionFormat="of" derivedContent="Section 3.4"/>.
This ensures that the Key Authorization is bound to the ability to receive the Challenge Bundle and not just having access to the ACME Challenge Object.
This token is also accessible to DTN on-path eavesdroppers.
        </dd>
      </dl>
      <t indent="0" pn="section-3-5">
Because multiple Challenge Bundles can be sent to validate the same Node ID, the <tt>token-bundle</tt> in the response is needed to correlate with the expected Key Authorization digest.
      </t>
      <t indent="0" pn="section-3-6">
The DTN Node ID Challenge Object <bcp14>SHALL</bcp14> only be allowed for an EID usable as a DTN Node ID, which is defined per-scheme in <xref section="4.2.5.1" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.2.5.1" derivedContent="RFC9171"/>.
When an ACME server supports Node ID validation, the ACME server <bcp14>SHALL</bcp14> provide a Challenge Object in accordance with <xref target="sec-nodeid-challenge-obj" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
Once this Challenge Object is defined, the ACME client may begin the validation.
      </t>
      <t indent="0" pn="section-3-7">
To initiate a Node ID validation, the ACME client performs the following steps:
      </t>
      <ol type="1" indent="adaptive" spacing="normal" start="1" pn="section-3-8">
        <li pn="section-3-8.1" derivedCounter="1.">
The ACME client POSTs a newOrder or newAuthz request including the identifier type "bundleEID" for the desired Node ID.
From either of these entry points, an authorization for the identifier type "bundleEID" is indicated by the ACME server.
See <xref section="7.4" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.4" derivedContent="RFC8555"/> for more details.
        </li>
        <li pn="section-3-8.2" derivedCounter="2.">
The ACME client obtains the <tt>id-chal</tt> and <tt>token-chal</tt> from the Challenge Object  (<xref target="sec-nodeid-challenge-obj" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) contained in an authorization object associated with the order in accordance with <xref section="7.1.4" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.1.4" derivedContent="RFC8555"/>.
        </li>
        <li anchor="step-client-authorize" pn="section-3-8.3" derivedCounter="3.">
The ACME client indicates to the administrative element of its BP Agent the <tt>id-chal</tt> that is authorized for use along with the associated <tt>token-chal</tt> and client account key thumbprint.
The ACME client waits, if necessary, until the Agent is configured before proceeding to the next step.
        </li>
        <li pn="section-3-8.4" derivedCounter="4.">
The ACME client POSTs a Response Object (<xref target="sec-nodeid-response-obj" format="default" sectionFormat="of" derivedContent="Section 3.2"/>) to the challenge URL on the ACME server in accordance with <xref section="7.5.1" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.5.1" derivedContent="RFC8555"/>.
The payload object is constructed in accordance with <xref target="sec-nodeid-response-obj" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
        </li>
        <li pn="section-3-8.5" derivedCounter="5.">
The administrative element waits for a Challenge Bundle to be received with the authorized ACME parameters, including its <tt>id-chal</tt> payload, in accordance with <xref target="sec-bundle-challenge" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.
        </li>
        <li pn="section-3-8.6" derivedCounter="6.">
The administrative element concatenates <tt>token-bundle</tt> with <tt>token-chal</tt> (each as base64url-encoded text strings) and computes the Key Authorization in accordance with <xref section="8.1" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-8.1" derivedContent="RFC8555"/> using the full token and client account key thumbprint.
        </li>
        <li pn="section-3-8.7" derivedCounter="7.">
The administrative element chooses the highest-priority hash algorithm supported by both the client and server, uses that algorithm to compute the digest of the Key Authorization result, and generates a Response Bundle to send back to the ACME server in accordance with <xref target="sec-bundle-response" format="default" sectionFormat="of" derivedContent="Section 3.4"/>.
        </li>
        <li pn="section-3-8.8" derivedCounter="8.">
The ACME client waits for the authorization to be finalized on the ACME server in accordance with <xref section="7.5.1" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.5.1" derivedContent="RFC8555"/>.
        </li>
        <li pn="section-3-8.9" derivedCounter="9.">
Once the challenge is completed (successfully or not), the ACME client indicates to the BP Agent that the <tt>id-chal</tt> is no longer usable.
If the authorization fails, the ACME client <bcp14>MAY</bcp14> retry the challenge from Step <xref format="counter" target="step-client-authorize" sectionFormat="of" derivedContent="3"/>.
        </li>
      </ol>
      <t indent="0" pn="section-3-9">
The ACME server verifies the client's control over a Node ID by performing the following steps:
      </t>
      <ol type="1" indent="adaptive" spacing="normal" start="1" pn="section-3-10">
        <li pn="section-3-10.1" derivedCounter="1.">
The ACME server receives a newOrder or newAuthz request including the identifier type "bundleEID", where the URI value is a Node ID.
        </li>
        <li pn="section-3-10.2" derivedCounter="2.">
The ACME server generates an authorization for the Node ID with challenge type "bp-nodeid-00" in accordance with <xref target="sec-nodeid-challenge-obj" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
        </li>
        <li anchor="step-server-authorize" pn="section-3-10.3" derivedCounter="3.">
The ACME server receives a POST to the challenge URL indicated from the authorization object.
The payload is handled in accordance with <xref target="sec-nodeid-response-obj" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
        </li>
        <li pn="section-3-10.4" derivedCounter="4.">
The ACME server sends, via the administrative element of its BP Agent, one or more Challenge Bundles in accordance with <xref target="sec-bundle-challenge" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.
Each Challenge Bundle contains a distinct, random <tt>token-bundle</tt> to be able to correlate with a Response Bundle.
Computing an expected Key Authorization digest is not necessary until a response is received with a chosen hash algorithm.
        </li>
        <li pn="section-3-10.5" derivedCounter="5.">
The ACME server waits for a Response Bundle(s) for a limited interval of time (based on the Response Object of <xref target="sec-nodeid-response-obj" format="default" sectionFormat="of" derivedContent="Section 3.2"/>).
Responses are encoded in accordance with <xref target="sec-bundle-response" format="default" sectionFormat="of" derivedContent="Section 3.4"/>.
        </li>
        <li pn="section-3-10.6" derivedCounter="6.">
Once received and decoded, the ACME server checks the contents of each Response Bundle in accordance with <xref target="sec-response-check" format="default" sectionFormat="of" derivedContent="Section 3.4.1"/>.
After all Challenge Bundles have either been responded to or timed-out, the ACME server policy (see <xref target="sec-multi-perspective" format="default" sectionFormat="of" derivedContent="Section 3.5"/>) determines whether the validation is successful.
If validation is not successful, a client may retry the challenge that starts in Step <xref format="counter" target="step-server-authorize" sectionFormat="of" derivedContent="3"/>.
        </li>
      </ol>
      <t indent="0" pn="section-3-11">
When responding to a Challenge Bundle, a BP Agent <bcp14>SHALL</bcp14> send a single Response Bundle in accordance with <xref target="sec-bundle-response" format="default" sectionFormat="of" derivedContent="Section 3.4"/>.
A BP Agent <bcp14>SHALL</bcp14> respond to ACME challenges only within the interval of time and only for the <tt>id-chal</tt> indicated by the ACME client.
A BP Agent <bcp14>SHALL</bcp14> respond to multiple Challenge Bundles with the same ACME parameters but different Bundle identities (source Node ID and timestamp); these correspond with the ACME server validating via multiple routing paths.
      </t>
      <section anchor="sec-nodeid-challenge-obj" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-dtn-node-id-challenge-objec">DTN Node ID Challenge Object</name>
        <t indent="0" pn="section-3.1-1">
The DTN Node ID Challenge Object is included by the ACME server as defined in <xref section="7.5" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.5" derivedContent="RFC8555"/> when it supports validating Node IDs.
        </t>
        <t indent="0" pn="section-3.1-2">
The DTN Node ID Challenge Object has the following content:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.1-3">
          <dt pn="section-3.1-3.1">type (required, string):</dt>
          <dd pn="section-3.1-3.2">
The string "bp-nodeid-00".
          </dd>
          <dt pn="section-3.1-3.3">id-chal (required, string):</dt>
          <dd pn="section-3.1-3.4">
This is a random value associated with a challenge that allows a client to filter valid Challenge Bundles (<xref target="sec-bundle-challenge" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).
The same value is used for all Challenge Bundles associated with an ACME challenge, including multi-perspective validation using multiple sources as described in <xref target="sec-multi-perspective" format="default" sectionFormat="of" derivedContent="Section 3.5"/>.
This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.
It <bcp14>SHALL NOT</bcp14> contain any characters outside the base64url alphabet as described in <xref section="5" target="RFC4648" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent="RFC4648"/>.
Trailing '=' padding characters <bcp14>SHALL</bcp14> be stripped.
See BCP 106 <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for additional information on randomness requirements.
          </dd>
          <dt pn="section-3.1-3.5">token-chal (required, string):</dt>
          <dd pn="section-3.1-3.6">
This is a random value, used as part of the Key Authorization algorithm, which is communicated to the ACME client only over the ACME channel.
This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.
It <bcp14>SHALL NOT</bcp14> contain any characters outside the base64url alphabet as described in <xref section="5" target="RFC4648" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent="RFC4648"/>.
Trailing '=' padding characters <bcp14>SHALL</bcp14> be stripped.
See BCP 106 <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for additional information on randomness requirements.
          </dd>
        </dl>
        <sourcecode type="json" markers="false" pn="section-3.1-4">
{
  "type": "bp-nodeid-00",
  "url": "https://example.com/acme/chall/prV_B7yEyA4",
  "id-chal": "dDtaviYTPUWFS3NK37YWfQ",
  "token-chal": "tPUZNY4ONIk6LxErRFEjVw"
}</sourcecode>
        <t indent="0" pn="section-3.1-5">
The <tt>token-chal</tt> value included in this object applies to the entire challenge and may correspond with multiple separate <tt>token-bundle</tt> values when multiple Challenge Bundles are sent for a single validation.
        </t>
      </section>
      <section anchor="sec-nodeid-response-obj" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-dtn-node-id-response-object">DTN Node ID Response Object</name>
        <t indent="0" pn="section-3.2-1">
The DTN Node ID Response Object is sent by the ACME client when it authorizes validation of a Node ID as defined in <xref section="7.5.1" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.5.1" derivedContent="RFC8555"/>.
Because a DTN has the potential for significantly longer (but roughly predictable) delays than a non-DTN network, the ACME 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 the order of seconds).
        </t>
        <t indent="0" pn="section-3.2-2">
The DTN Node ID Response Object has the following content:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.2-3">
          <dt pn="section-3.2-3.1">rtt (optional, number):</dt>
          <dd pn="section-3.2-3.2">
An expected Round-Trip Time (RTT), in seconds, between sending a Challenge Bundle and receiving a Response Bundle.
This value is a hint to the ACME server for how long to wait for responses but is not authoritative.
The minimum RTT value <bcp14>SHALL</bcp14> be zero.
There is no special significance to zero-value RTT, it simply indicates the response is expected in less than the least significant unit used by the ACME client.
            </dd>
        </dl>
        <sourcecode type="json" markers="false" pn="section-3.2-4">
{
  "rtt": 300.0
}</sourcecode>
        <t indent="0" pn="section-3.2-5">
A Response Object <bcp14>SHALL NOT</bcp14> be sent until the BP Agent has been configured to properly respond to the challenge.
The RTT value is meant to indicate any node-specific path delays expected to be encountered from the ACME server.
Because there is no requirement on the path (or paths) regarding which Bundles may traverse between the ACME server and the BP Agent, and the ACME server can attempt some path diversity, the RTT value <bcp14>SHOULD</bcp14> be pessimistic.
        </t>
        <t indent="0" pn="section-3.2-6">
A default Bundle response interval, used when the object does not contain an RTT, <bcp14>SHOULD</bcp14> be a configurable parameter of the ACME server.
If the ACME client indicated an RTT value in the object, the response interval <bcp14>SHOULD</bcp14> be twice the RTT (with limiting logic applied as described below).
The lower limit on the response interval is network specific, but it <bcp14>SHOULD NOT</bcp14> be shorter than one second.
The upper limit on response interval is network specific, but it <bcp14>SHOULD NOT</bcp14> be longer than one minute (60 seconds) for a terrestrial-only DTN.
        </t>
      </section>
      <section anchor="sec-bundle-challenge" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-acme-node-id-validation-cha">ACME Node ID Validation Challenge Bundle</name>
        <t indent="0" pn="section-3.3-1">
Each ACME Node ID Validation Challenge Bundle <bcp14>SHALL</bcp14> be structured and encoded in accordance with BPv7 <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>.
        </t>
        <t indent="0" pn="section-3.3-2">
Each Challenge Bundle has parameters as listed here:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.3-3">
          <dt pn="section-3.3-3.1">Bundle Processing Control Flags:</dt>
          <dd pn="section-3.3-3.2">
The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an administrative record.
The primary block flags <bcp14>SHALL</bcp14> indicate that user application acknowledgement is requested; this flag distinguishes the Challenge Bundle from the Response Bundle.
          </dd>
          <dt pn="section-3.3-3.3">Destination EID:</dt>
          <dd pn="section-3.3-3.4">
The Destination EID <bcp14>SHALL</bcp14> be the ACME-server-normalized Node ID being validated.
          </dd>
          <dt pn="section-3.3-3.5">Source Node ID:</dt>
          <dd pn="section-3.3-3.6">
The Source Node ID <bcp14>SHALL</bcp14> indicate the Node ID of a BP Agent of the ACME server performing the challenge.
          </dd>
          <dt pn="section-3.3-3.7">Creation Timestamp and Lifetime:</dt>
          <dd pn="section-3.3-3.8">
The Creation Timestamp <bcp14>SHALL</bcp14> be set to the time at which the challenge was generated.
The Lifetime <bcp14>SHALL</bcp14> indicate the response interval (of <xref target="sec-nodeid-response-obj" format="default" sectionFormat="of" derivedContent="Section 3.2"/>) for which the ACME server will accept responses to this challenge.
          </dd>
          <dt pn="section-3.3-3.9">Administrative Record Type Code:</dt>
          <dd pn="section-3.3-3.10">
	    This is set to the ACME Node ID Validation type code defined in <xref target="sec-iana-bp-admin-type" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.
	  </dd>
          <dt pn="section-3.3-3.11">Administrative Record Content:</dt>
          <dd pn="section-3.3-3.12">
            <t indent="0" pn="section-3.3-3.12.1">
The Challenge Bundle administrative record content <bcp14>SHALL</bcp14> consist of a CBOR map containing the following three pairs:
            </t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.3-3.12.2">
              <li pn="section-3.3-3.12.2.1">
One pair <bcp14>SHALL</bcp14> consist of key 1 with a value of ACME challenge <tt>id-chal</tt>, copied from the Challenge Object, represented as a CBOR byte string.
              </li>
              <li pn="section-3.3-3.12.2.2">
One pair <bcp14>SHALL</bcp14> consist of key 2 with a value of ACME challenge <tt>token-bundle</tt>, represented as a CBOR byte string.
The <tt>token-bundle</tt> is a random value that uniquely identifies the Challenge Bundle.
This value <bcp14>SHALL</bcp14> have at least 128 bits of entropy.
See BCP 106 <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for additional information on randomness requirements.
              </li>
              <li pn="section-3.3-3.12.2.3">
One pair <bcp14>SHALL</bcp14> consist of key 4 with a value of an array containing acceptable hash algorithm identifiers.
The array <bcp14>SHALL</bcp14> be ordered in descending preference, with the first item being the most preferred.
The array <bcp14>SHALL</bcp14> contain at least one item.
Each algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry <xref target="IANA-COSE" format="default" sectionFormat="of" derivedContent="IANA-COSE"/>.
              </li>
            </ul>
          </dd>
        </dl>
        <t indent="0" pn="section-3.3-4">
This structure is part of the extension CDDL in <xref target="sec-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/>.
An example full Challenge Bundle is included in <xref target="sec-example-bundle-challenge" format="default" sectionFormat="of" derivedContent="Appendix B.1"/>.
        </t>
        <t indent="0" pn="section-3.3-5">
For interoperability, entities that use this validation method <bcp14>SHALL</bcp14> support the hash algorithm "SHA-256" (value -16) <xref target="RFC9054" format="default" sectionFormat="of" derivedContent="RFC9054"/>.
This requirement allows for 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.
        </t>
        <t indent="0" pn="section-3.3-6">
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 <bcp14>SHALL</bcp14> include a Bundle Age extension block in accordance with <xref section="4.4.2" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#section-4.4.2" derivedContent="RFC9171"/>.
        </t>
        <t indent="0" pn="section-3.3-7">
Challenge Bundles <bcp14>SHALL</bcp14> include a Block Integrity Block (BIB) in accordance with <xref target="sec-bib-gateway" format="default" sectionFormat="of" derivedContent="Section 4"/> or with a Security Source identical to the Bundle Source Node.
Challenge Bundles <bcp14>SHALL NOT</bcp14> be directly encrypted by the Block Confidentiality Block (BCB) method or any other method (see <xref target="sec-security-leak" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).
        </t>
        <section anchor="sec-challenge-check" numbered="true" removeInRFC="false" toc="include" pn="section-3.3.1">
          <name slugifiedName="name-challenge-bundle-checks">Challenge Bundle Checks</name>
          <t indent="0" pn="section-3.3.1-1">
A proper Challenge Bundle meets all of the following criteria:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3.1-2">
            <li pn="section-3.3.1-2.1">
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.
            </li>
            <li pn="section-3.3.1-2.2">
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).
            </li>
            <li pn="section-3.3.1-2.3">
The challenge payload contains the <tt>id-chal</tt> as indicated in the ACME Challenge Object.
            </li>
            <li pn="section-3.3.1-2.4">
The challenge payload contains a <tt>token-bundle</tt> matching the definition in <xref target="sec-bundle-challenge" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.
            </li>
            <li pn="section-3.3.1-2.5">
The challenge payload contains at least one hash algorithm identifier acceptable to the client.
            </li>
          </ul>
          <t indent="0" pn="section-3.3.1-3">
Failure to match any of the above <bcp14>SHALL</bcp14> 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.
          </t>
        </section>
      </section>
      <section anchor="sec-bundle-response" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-acme-node-id-validation-res">ACME Node ID Validation Response Bundles</name>
        <t indent="0" pn="section-3.4-1">
Each ACME Node ID Validation Response Bundle <bcp14>SHALL</bcp14> be structured and encoded in accordance with BPv7 <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/>.
        </t>
        <t indent="0" pn="section-3.4-2">
Each Response Bundle has parameters as listed here:
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.4-3">
          <dt pn="section-3.4-3.1">Bundle Processing Control Flags:</dt>
          <dd pn="section-3.4-3.2">
The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an administrative record.
The primary block flags <bcp14>SHALL NOT</bcp14> indicate that user application acknowledgement is requested; this flag distinguishes the Response Bundle from the Challenge Bundle.
          </dd>
          <dt pn="section-3.4-3.3">Destination EID:</dt>
          <dd pn="section-3.4-3.4">
The Destination EID <bcp14>SHALL</bcp14> be identical to the Source Node ID of the Challenge Bundle to which this response corresponds.
          </dd>
          <dt pn="section-3.4-3.5">Source Node ID:</dt>
          <dd pn="section-3.4-3.6">
The Source Node ID <bcp14>SHALL</bcp14> be identical to the Destination EID of the Challenge Bundle to which this response corresponds.
          </dd>
          <dt pn="section-3.4-3.7">Creation Timestamp and Lifetime:</dt>
          <dd pn="section-3.4-3.8">
The Creation Timestamp <bcp14>SHALL</bcp14> be set to the time at which the response was generated.
The response Lifetime <bcp14>SHALL</bcp14> indicate the response interval remaining if the Challenge Bundle indicated a limited Lifetime.
          </dd>
          <dt pn="section-3.4-3.9">Administrative Record Type Code:</dt>
          <dd pn="section-3.4-3.10">
	    Set to the ACME Node ID Validation type code defined in <xref target="sec-iana-bp-admin-type" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.
</dd>
          <dt pn="section-3.4-3.11">Administrative Record Content:</dt>
          <dd pn="section-3.4-3.12">
            <t indent="0" pn="section-3.4-3.12.1">
The Response Bundle administrative record content <bcp14>SHALL</bcp14> consist of a CBOR map containing the following three pairs:
            </t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.4-3.12.2">
              <li pn="section-3.4-3.12.2.1">
One pair <bcp14>SHALL</bcp14> consist of key 1 with value of ACME challenge <tt>id-chal</tt>, copied from the Request Bundle, represented as a CBOR byte string.
              </li>
              <li pn="section-3.4-3.12.2.2">
One pair <bcp14>SHALL</bcp14> consist of key 2 with value of ACME challenge <tt>token-bundle</tt>, copied from the Request Bundle, represented as a CBOR byte string.
              </li>
              <li pn="section-3.4-3.12.2.3">
One pair <bcp14>SHALL</bcp14> consist of key 3 with value of a two-element array containing the pair of a hash algorithm identifier and the hash byte string.
The algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry <xref target="IANA-COSE" format="default" sectionFormat="of" derivedContent="IANA-COSE"/>.
              </li>
            </ul>
          </dd>
        </dl>
        <t indent="0" pn="section-3.4-4">
This structure is part of the extension CDDL in <xref target="sec-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/>.
An example full Response Bundle is included in <xref target="sec-example-bundle-response" format="default" sectionFormat="of" derivedContent="Appendix B.2"/>.
        </t>
        <t indent="0" pn="section-3.4-5">
If the BP Agent responding to a Challenge Bundle does not have a well-synchronized clock, it <bcp14>SHALL</bcp14> use any information about last-hop delays and (if present) Bundle Age extension data to infer the age of the Challenge Bundle and Lifetime of the Response Bundle.
        </t>
        <t indent="0" pn="section-3.4-6">
Response Bundles <bcp14>SHALL</bcp14> include a BIB in accordance with <xref target="sec-bib-gateway" format="default" sectionFormat="of" derivedContent="Section 4"/>.
Response Bundles <bcp14>SHALL NOT</bcp14> be directly encrypted by BCB or any other method (see <xref target="sec-security-leak" format="default" sectionFormat="of" derivedContent="Section 6.1"/> for explanation).
        </t>
        <section anchor="sec-response-check" numbered="true" removeInRFC="false" toc="include" pn="section-3.4.1">
          <name slugifiedName="name-response-bundle-checks">Response Bundle Checks</name>
          <t indent="0" pn="section-3.4.1-1">
A proper Response Bundle meets all of the following criteria:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4.1-2">
            <li pn="section-3.4.1-2.1">
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.
            </li>
            <li pn="section-3.4.1-2.2">
The Response Bundle Source Node ID is identical to the Node ID being validated.
The comparison of Node IDs <bcp14>SHALL</bcp14> use the comparison logic of the NODE-ID from <xref section="4.4.1" target="RFC9174" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9174#section-4.4.1" derivedContent="RFC9174"/>.
            </li>
            <li pn="section-3.4.1-2.3">
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.
            </li>
            <li pn="section-3.4.1-2.4">
The response payload contains the same <tt>id-chal</tt> and <tt>token-bundle</tt> as sent in the Challenge Bundle (this is also how the two Bundles are correlated).
            </li>
            <li pn="section-3.4.1-2.5">
The response payload contains a hash algorithm identifier acceptable to the server (as indicated in the Challenge Bundle).
            </li>
            <li pn="section-3.4.1-2.6">
The response payload contains the expected Key Authorization digest computed by the ACME server.
            </li>
          </ul>
          <t indent="0" pn="section-3.4.1-3">
Any of the failures above <bcp14>SHALL</bcp14> cause that single-perspective validation to fail.
Any of the failures above <bcp14>SHOULD</bcp14> be distinguished as subproblems to the ACME client.
The lack of a response within the expected response interval, as defined in <xref target="sec-nodeid-response-obj" format="default" sectionFormat="of" derivedContent="Section 3.2"/>, <bcp14>SHALL</bcp14> also be treated as a validation failure.
          </t>
        </section>
      </section>
      <section anchor="sec-multi-perspective" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-multi-perspective-validatio">Multi-Perspective Validation</name>
        <t indent="0" pn="section-3.5-1">
To avoid on-path attacks in certain networks, an ACME server can perform a single validation using multiple Challenge Bundle sources or via multiple routing paths.
This technique is called "multi-perspective validation" as recommended in <xref section="10.2" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-10.2" derivedContent="RFC8555"/> and an implementation is used by the Let's Encrypt service in its operational deployment <xref target="LE-multi-perspective" format="default" sectionFormat="of" derivedContent="LE-multi-perspective"/>.
The utility of a multi-perspective validation is part of the experimental nature (see <xref target="sec-experiment" format="default" sectionFormat="of" derivedContent="Section 1.5"/>) of this specification.
        </t>
        <t indent="0" pn="section-3.5-2">
When required by policy, an ACME server <bcp14>SHALL</bcp14> send multiple Challenge Bundles from different sources in the BP network.
When multiple Challenge Bundles are sent for a single validation, it is a matter of ACME server policy to determine whether or not the validation as a whole is successful.
The result of each single-source validation is defined as success or failure in <xref target="sec-response-check" format="default" sectionFormat="of" derivedContent="Section 3.4.1"/>.
        </t>
        <t indent="0" pn="section-3.5-3">
A <bcp14>RECOMMENDED</bcp14> validation policy is to succeed if the challenge from a primary Bundle source is successful and if there is no more than one failure from a secondary source.
The determination of which perspectives are considered primary or secondary is an implementation matter.
        </t>
        <t indent="0" pn="section-3.5-4">
Regardless of whether a validation is single- or multi-perspective, a validation failure <bcp14>SHALL</bcp14> be indicated by an ACME error type of "incorrectResponse".
Each specific perspective failure <bcp14>SHOULD</bcp14> be indicated to the ACME client as a validation subproblem.
        </t>
      </section>
    </section>
    <section anchor="sec-bib-gateway" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-bundle-integrity-gateway">Bundle Integrity Gateway</name>
      <t indent="0" pn="section-4-1">
This section defines a BIB use that closely resembles the function of DKIM email signing <xref target="RFC6376" format="default" sectionFormat="of" derivedContent="RFC6376"/>.
In this mechanism, a routing node in a DTN subnetwork attests to the origination of a Bundle by adding a BIB before forwarding it.
The Bundle receiver then need not trust the source of the Bundle, it only needs to trust this Security Source node.
The receiver needs policy configuration to know which Security Sources are permitted to attest for which Bundle sources.
The utility of an integrity gateway is part of the experimental nature (<xref target="sec-experiment" format="default" sectionFormat="of" derivedContent="Section 1.5"/>) of this specification.
      </t>
      <t indent="0" pn="section-4-2">
An integrity gateway <bcp14>SHALL</bcp14> validate the Source Node ID of a Bundle, using local-network-specific means, before adding a BIB to the Bundle.
The exact means by which an integrity gateway validates a Bundle's source is 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).
      </t>
      <t indent="0" pn="section-4-3">
When an integrity gateway adds a BIB, it <bcp14>SHALL</bcp14> be in accordance with BPSec <xref target="RFC9172" format="default" sectionFormat="of" derivedContent="RFC9172"/> requirements.
The BIB integrity <bcp14>SHALL</bcp14> 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.
The Security Source of this BIB <bcp14>SHALL</bcp14> be either the Bundle source Node ID itself or a routing node trusted by the destination node (see <xref target="sec-security-impersonate" format="default" sectionFormat="of" derivedContent="Section 6.2"/>).
      </t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-certificate-request-profile">Certificate Request Profile</name>
      <t indent="0" pn="section-5-1">
The ultimate purpose of this ACME validation is to allow a CA to issue certificates following the profiles of <xref section="4.4.2" target="RFC9174" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9174#section-4.4.2" derivedContent="RFC9174"/> and <xref section="4" target="I-D.ietf-dtn-bpsec-cose" format="default" sectionFormat="of" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-cose-12#section-4" derivedContent="BPSEC-COSE"/>.
These purposes are referred to here as "Bundle security certificates".
      </t>
      <t indent="0" pn="section-5-2">
The ACME identifier type "bundleEID" correlates to the PKIX certificate and certificate request "NODE-ID" as defined in <xref section="4.4.1" target="RFC9174" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9174#section-4.4.1" derivedContent="RFC9174"/>.
This NODE-ID is present in certificate requests with an <tt>extensionRequest</tt> attribute (see <xref target="RFC2985" format="default" sectionFormat="of" derivedContent="RFC2985"/>) containing a SAN extension with identities of type <tt>otherName</tt> having an Other Name form of <tt>BundleEID</tt>, identified by <tt>id-on-bundleEID</tt> from the "SMI Security for PKIX Other Name Forms" registry <xref target="IANA-SMI" format="default" sectionFormat="of" derivedContent="IANA-SMI"/>.
Because the <tt>BundleEID</tt> Other Name form is encoded as an IA5String, it <bcp14>SHALL</bcp14> be treated as being in the percent-encoded form of <xref section="2.1" target="RFC3986" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-2.1" derivedContent="RFC3986"/>.
      </t>
      <t indent="0" pn="section-5-3">
One defining aspect of Bundle security certificates is the Extended Key Usage key purpose <tt>id-kp-bundleSecurity</tt> <xref target="IANA-SMI" format="default" sectionFormat="of" derivedContent="IANA-SMI"/>, as defined in <xref section="4.4.2.1" target="RFC9174" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9174#section-4.4.2.1" derivedContent="RFC9174"/>.
When requesting a certificate that includes a NODE-ID, the CSR <bcp14>SHOULD</bcp14> include an Extended Key Usage of <tt>id-kp-bundleSecurity</tt>.
When a Bundle security certificate is issued based on a validated NODE-ID, the certificate <bcp14>SHALL</bcp14> include an Extended Key Usage of <tt>id-kp-bundleSecurity</tt>.
      </t>
      <section anchor="sec-multiple-claims" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-multiple-identity-claims">Multiple Identity Claims</name>
        <t indent="0" pn="section-5.1-1">
A single Bundle security CSR <bcp14>MAY</bcp14> contain a mixed set of SAN identifiers, including combinations of IP-ID <xref target="RFC9525" format="default" sectionFormat="of" derivedContent="RFC9525"/>, DNS-ID <xref target="RFC9525" format="default" sectionFormat="of" derivedContent="RFC9525"/>, and NODE-ID <xref target="RFC9174" format="default" sectionFormat="of" derivedContent="RFC9174"/> types.
These correspond with ACME identifier type "ip", "dns", and "bundleEID", respectively.
        </t>
        <t indent="0" pn="section-5.1-2">
There is no restriction on how a certificate combines these claims, but each identifier <bcp14>SHALL</bcp14> be validated by an ACME server to issue such a certificate as part of an associated ACME order.
This is no different than the existing behavior of ACME <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> but is mentioned here to make sure that CA policy handles such situations, especially related to validation failure of an identifier in the presence of multiple identifiers.
Existing validation mechanisms are defined for identifier type "ip" <xref target="RFC8738" format="default" sectionFormat="of" derivedContent="RFC8738"/> and "dns" <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> among others <xref target="IANA-ACME" format="default" sectionFormat="of" derivedContent="IANA-ACME"/>.
        </t>
        <t indent="0" pn="section-5.1-3">
The specific use case of TLS-based security for the TCP CL in <xref section="4.4" target="RFC9174" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9174#section-4.4" derivedContent="RFC9174"/> allows, and for some network policies requires, that a certificate authenticate both the DNS name of an entity as well as the Node ID of the entity.
These authentications apply to each identifier type, used for different network layers, at different points during secure session establishment.
        </t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-generating-encryption-only-">Generating Encryption-Only or Signing-Only Bundle Security Certificates</name>
        <t indent="0" pn="section-5.2-1">
ACME extensions specified in this document can be used to request encryption-only or signing-only Bundle security certificates.
The validity of a request for either a restricted-use or unrestricted-use certificate is dependent on both CA policy to issue such certificates as well as constraints based on the requested key and algorithm types.
        </t>
        <t indent="0" pn="section-5.2-2">
In order to request a signing-only Bundle security certificate, the CSR <bcp14>SHALL</bcp14> include the key usage extension with the digitalSignature and/or nonRepudiation bits set and no other bits set.
        </t>
        <t indent="0" pn="section-5.2-3">
In order to request an encryption-only Bundle security certificate, the CSR <bcp14>SHALL</bcp14> include the key usage extension with the keyEncipherment or keyAgreement bits set and no other bits set.
        </t>
        <t indent="0" pn="section-5.2-4">
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 the ACME server to issue a Bundle security certificate suitable for both signing and encryption.
        </t>
      </section>
    </section>
    <section anchor="sec-security" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">
This section separates security considerations into threat categories based on guidance of BCP 72 <xref target="RFC3552" format="default" sectionFormat="of" derivedContent="RFC3552"/>.
      </t>
      <section anchor="sec-security-leak" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-threat-passive-leak-of-vali">Threat: Passive Leak of Validation Data</name>
        <t indent="0" pn="section-6.1-1">
Because this challenge mechanism is used to bootstrap security between DTN Nodes, the challenge and its response are likely to be transferred in plaintext.
The only ACME data present on-the-wire is a random token and a cryptographic digest, so there is no sensitive data to be leaked within the Node ID Validation Bundle exchange.
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 responses.
        </t>
        <t indent="0" pn="section-6.1-2">
It is possible for intermediate BP Nodes to encapsulate-and-encrypt Challenge Bundles and/or Response Bundles while they traverse untrusted networks, but that is a DTN configuration matter outside of the scope of this document.
        </t>
      </section>
      <section anchor="sec-security-impersonate" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-threat-bp-node-impersonatio">Threat: BP Node Impersonation</name>
        <t indent="0" pn="section-6.2-1">
As described in <xref section="10.1" target="RFC8555" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-10.1" derivedContent="RFC8555"/>, it is possible for an active attacker to alter data on both ACME client channel and the DTN validation channel.
        </t>
        <t indent="0" pn="section-6.2-2">
The primary mitigation is to delegate Bundle integrity sourcing to a trusted routing node near, in the sense of Bundle routing topology, the Bundle source node as defined in <xref target="sec-bib-gateway" format="default" sectionFormat="of" derivedContent="Section 4"/>.
This is functionally similar to DKIM email signing <xref target="RFC6376" format="default" sectionFormat="of" derivedContent="RFC6376"/> and provides some level of secure Bundle origination.
        </t>
        <t indent="0" pn="section-6.2-3">	  
Another way to mitigate on-path attacks is to attempt validation of the same Node ID from multiple sources, hopefully via multiple Bundle routing paths, as defined in <xref target="sec-multi-perspective" format="default" sectionFormat="of" derivedContent="Section 3.5"/>.
It is not a trivial task to guarantee Bundle routing though, so more advanced techniques such as onion routing (using Bundle-in-Bundle encapsulation) could be employed.
        </t>
      </section>
      <section anchor="sec-security-replay" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-threat-bundle-replay">Threat: Bundle Replay</name>
        <t indent="0" pn="section-6.3-1">
It is possible for an on-path attacker to replay both Challenge Bundles or Response Bundles.
Even in a properly configured DTN, it is possible that intermediate Bundle routers would use multi-path forwarding of a singleton-destination Bundle.
        </t>
        <t indent="0" pn="section-6.3-2">
Ultimately, the point of the ACME Bundle exchange is to derive a Key Authorization value and its cryptographic digest, and to communicate that digest back to the ACME server for validation, so the uniqueness of the Key Authorization directly determines the scope of replay validity.
The uniqueness of each <tt>token-bundle</tt> to each Challenge Bundle ensures that the Key Authorization is unique to the Challenge Bundle.
The uniqueness of each <tt>token-chal</tt> to the ACME challenge ensures that the Key Authorization is unique to that ACME challenge and not based solely on values visible to on-path eavesdroppers.
        </t>
        <t indent="0" pn="section-6.3-3">
Having each Bundle's primary block and payload block covered by a BIB from a trusted Security Source (see <xref target="sec-bib-gateway" format="default" sectionFormat="of" derivedContent="Section 4"/>) ensures that a replayed Bundle cannot be altered in the blocks used by ACME.
All together, these properties mean that there is no degraded security caused by replay of either a Challenge Bundle or a Response Bundle even in the case where the primary or payload block is not covered by a BIB.
The worst that can come of Bundle replay is the waste of network resources as described in <xref target="sec-security-dos" format="default" sectionFormat="of" derivedContent="Section 6.4"/>.
        </t>
      </section>
      <section anchor="sec-security-dos" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-threat-denial-of-service">Threat: Denial of Service</name>
        <t indent="0" pn="section-6.4-1">
The behaviors described in this section all amount to a potential denial-of-service to a BP Agent.
        </t>
        <t indent="0" pn="section-6.4-2">
A malicious entity can continually send Challenge Bundles to a BP Agent.
The victim BP Agent can ignore Challenge Bundles that do not conform to the specific time interval and challenge token for which the ACME client has informed the BP Agent that challenges are expected.
The victim BP Agent can require all Challenge Bundles to be BIB-signed to ensure authenticity of the challenge.
        </t>
        <t indent="0" pn="section-6.4-3">
A malicious entity can continually send Response Bundles to a BP Agent.
The victim BP Agent can ignore Response Bundles that do not conform to the specific time interval or Source Node ID or challenge token for an active Node ID validation.
        </t>
        <t indent="0" pn="section-6.4-4">
Similar to other validation methods, an ACME server validating a DTN Node ID could be used as a denial-of-service amplifier.
For this reason, any ACME server can rate-limit validation activities for individual clients and individual certificate requests.
        </t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-6.5">
        <name slugifiedName="name-inherited-security-consider">Inherited Security Considerations</name>
        <t indent="0" pn="section-6.5-1">
Because this protocol relies on ACME for part of its operation, the security considerations of ACME <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> apply to all ACME client-server exchanges during Node ID validation.
        </t>
        <t indent="0" pn="section-6.5-2">
Because this protocol relies on BPv7 for part of its operation, the security considerations of BPv7 <xref target="RFC9171" format="default" sectionFormat="of" derivedContent="RFC9171"/> and BPSec <xref target="RFC9172" format="default" sectionFormat="of" derivedContent="RFC9172"/> apply to all BP messaging during Node ID validation.
        </t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-6.6">
        <name slugifiedName="name-out-of-scope-bp-agent-commu">Out-of-Scope BP Agent Communication</name>
        <t indent="0" pn="section-6.6-1">
Although messaging between an ACME client or ACME server and its associated BP Agent are out-of-scope for this document, both of those channels are critical to Node ID validation security.
Either channel can potentially leak data or provide attack vectors if not properly secured.
These channels need to protect against spoofing of messaging in both directions to avoid interruption of normal validation sequencing and to prevent false validations from succeeding.
        </t>
        <t indent="0" pn="section-6.6-2">
The ACME server and its BP Agent exchange the outgoing <tt>id-chal</tt>, <tt>token-bundle</tt>, and Key Authorization digest, but these values do not need to be confidential (they are also in plaintext over the BP channel).
        </t>
        <t indent="0" pn="section-6.6-3">
Depending on implementation details, the ACME client might transmit 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 transmit its client account key thumbprint to a BP Agent, it is important that this data is kept confidential because it provides the binding of the client account key to the Node ID validation (as well as for all other types of ACME validation).
Avoiding this transmission would require a full round-trip between BP Agent and ACME client, which can be undesirable if the two are separated by a long-delay network.
        </t>
      </section>
    </section>
    <section anchor="sec-iana" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">
This specification adds to the "Automated Certificate Management Environment (ACME) Protocol" registry group and the "Bundle Protocol" registry group.
      </t>
      <section anchor="sec-iana-acme-identifier" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-acme-identifier-types">ACME Identifier Types</name>
        <t indent="0" pn="section-7.1-1">
Within the "Automated Certificate Management Environment (ACME) Protocol" registry group <xref target="IANA-ACME" format="default" sectionFormat="of" derivedContent="IANA-ACME"/>, the following entry has been added to the "ACME Identifier Types" registry.
        </t>
        <table align="center" pn="table-1">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Label</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">bundleEID</td>
              <td align="left" colspan="1" rowspan="1">RFC 9891</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="sec-iana-acme-method" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-acme-validation-methods">ACME Validation Methods</name>
        <t indent="0" pn="section-7.2-1">
Within the "Automated Certificate Management Environment (ACME) Protocol" registry group <xref target="IANA-ACME" format="default" sectionFormat="of" derivedContent="IANA-ACME"/>, the following entry has been added to the "ACME Validation Methods" registry.
        </t>
        <table align="center" pn="table-2">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Label</th>
              <th align="left" colspan="1" rowspan="1">Identifier Type</th>
              <th align="left" colspan="1" rowspan="1">ACME</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">bp-nodeid-00</td>
              <td align="left" colspan="1" rowspan="1">bundleEID</td>
              <td align="left" colspan="1" rowspan="1">Y</td>
              <td align="left" colspan="1" rowspan="1">RFC 9891</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="sec-iana-bp-admin-type" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-bundle-administrative-recor">Bundle Administrative Record Types</name>
        <t indent="0" pn="section-7.3-1">
Within the "Bundle Protocol" registry group <xref target="IANA-BP" format="default" sectionFormat="of" derivedContent="IANA-BP"/>, the following entry has been added to the "Bundle Administrative Record Types" registry.
        </t>
        <table align="center" pn="table-3">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bundle Protocol Version</th>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">255</td>
              <td align="left" colspan="1" rowspan="1">ACME Node ID Validation</td>
              <td align="left" colspan="1" rowspan="1">RFC 9891</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-dtn-bpsec-cose" to="BPSEC-COSE"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="IANA-ACME" target="https://www.iana.org/assignments/acme/" quoteTitle="true" derivedAnchor="IANA-ACME">
          <front>
            <title>Automated Certificate Management Environment (ACME) Protocol</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA-BP" target="https://www.iana.org/assignments/bundle/" quoteTitle="true" derivedAnchor="IANA-BP">
          <front>
            <title>Bundle Protocol</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA-COSE" target="https://www.iana.org/assignments/cose/" quoteTitle="true" derivedAnchor="IANA-COSE">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA-SMI" target="https://www.iana.org/assignments/smi-numbers/" quoteTitle="true" derivedAnchor="IANA-SMI">
          <front>
            <title>Structure of Management Information (SMI) Numbers (MIB Module Registrations)</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2985" target="https://www.rfc-editor.org/info/rfc2985" quoteTitle="true" derivedAnchor="RFC2985">
          <front>
            <title>PKCS #9: Selected Object Classes and Attribute Types Version 2.0</title>
            <author fullname="M. Nystrom" initials="M." surname="Nystrom"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <date month="November" year="2000"/>
            <abstract>
              <t indent="0">This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2985"/>
          <seriesInfo name="DOI" value="10.17487/RFC2985"/>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552" quoteTitle="true" derivedAnchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t indent="0">A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC4838" target="https://www.rfc-editor.org/info/rfc4838" quoteTitle="true" derivedAnchor="RFC4838">
          <front>
            <title>Delay-Tolerant Networking Architecture</title>
            <author fullname="V. Cerf" initials="V." surname="Cerf"/>
            <author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
            <author fullname="A. Hooke" initials="A." surname="Hooke"/>
            <author fullname="L. Torgerson" initials="L." surname="Torgerson"/>
            <author fullname="R. Durst" initials="R." surname="Durst"/>
            <author fullname="K. Scott" initials="K." surname="Scott"/>
            <author fullname="K. Fall" initials="K." surname="Fall"/>
            <author fullname="H. Weiss" initials="H." surname="Weiss"/>
            <date month="April" year="2007"/>
            <abstract>
              <t indent="0">This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4838"/>
          <seriesInfo name="DOI" value="10.17487/RFC4838"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8555" target="https://www.rfc-editor.org/info/rfc8555" quoteTitle="true" derivedAnchor="RFC8555">
          <front>
            <title>Automatic Certificate Management Environment (ACME)</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman-Andrews"/>
            <author fullname="D. McCarney" initials="D." surname="McCarney"/>
            <author fullname="J. Kasten" initials="J." surname="Kasten"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8555"/>
          <seriesInfo name="DOI" value="10.17487/RFC8555"/>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t indent="0">This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC9054" target="https://www.rfc-editor.org/info/rfc9054" quoteTitle="true" derivedAnchor="RFC9054">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Hash Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9054"/>
          <seriesInfo name="DOI" value="10.17487/RFC9054"/>
        </reference>
        <reference anchor="RFC9171" target="https://www.rfc-editor.org/info/rfc9171" quoteTitle="true" derivedAnchor="RFC9171">
          <front>
            <title>Bundle Protocol Version 7</title>
            <author fullname="S. Burleigh" initials="S." surname="Burleigh"/>
            <author fullname="K. Fall" initials="K." surname="Fall"/>
            <author fullname="E. Birrane, III" initials="E." surname="Birrane, III"/>
            <date month="January" year="2022"/>
            <abstract>
              <t indent="0">This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9171"/>
          <seriesInfo name="DOI" value="10.17487/RFC9171"/>
        </reference>
        <reference anchor="RFC9172" target="https://www.rfc-editor.org/info/rfc9172" quoteTitle="true" derivedAnchor="RFC9172">
          <front>
            <title>Bundle Protocol Security (BPSec)</title>
            <author fullname="E. Birrane, III" initials="E." surname="Birrane, III"/>
            <author fullname="K. McKeever" initials="K." surname="McKeever"/>
            <date month="January" year="2022"/>
            <abstract>
              <t indent="0">This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9172"/>
          <seriesInfo name="DOI" value="10.17487/RFC9172"/>
        </reference>
        <reference anchor="RFC9174" target="https://www.rfc-editor.org/info/rfc9174" quoteTitle="true" derivedAnchor="RFC9174">
          <front>
            <title>Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4</title>
            <author fullname="B. Sipos" initials="B." surname="Sipos"/>
            <author fullname="M. Demmer" initials="M." surname="Demmer"/>
            <author fullname="J. Ott" initials="J." surname="Ott"/>
            <author fullname="S. Perreault" initials="S." surname="Perreault"/>
            <date month="January" year="2022"/>
            <abstract>
              <t indent="0">This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9174"/>
          <seriesInfo name="DOI" value="10.17487/RFC9174"/>
        </reference>
        <reference anchor="RFC9525" target="https://www.rfc-editor.org/info/rfc9525" quoteTitle="true" derivedAnchor="RFC9525">
          <front>
            <title>Service Identity in TLS</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="R. Salz" initials="R." surname="Salz"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.</t>
              <t indent="0">This document obsoletes RFC 6125.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9525"/>
          <seriesInfo name="DOI" value="10.17487/RFC9525"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-dtn-bpsec-cose" target="https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-cose-12" quoteTitle="true" derivedAnchor="BPSEC-COSE">
          <front>
            <title>Bundle Protocol Security (BPSec) COSE Context</title>
            <author initials="B." surname="Sipos" fullname="Brian Sipos">
              <organization showOnFrontPage="true">The Johns Hopkins University Applied Physics Laboratory</organization>
            </author>
            <date month="November" day="12" year="2025"/>
            <abstract>
              <t indent="0">   This document defines a security context suitable for using CBOR
   Object Signing and Encryption (COSE) algorithms within Bundle
   Protocol Security (BPSec) integrity and confidentiality blocks.  A
   profile for COSE, focused on asymmetric-keyed algorithms, and for
   PKIX certificates are also defined for BPSec interoperation.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dtn-bpsec-cose-12"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="LE-multi-perspective" target="https://letsencrypt.org/2020/02/19/multi-perspective-validation.html" quoteTitle="true" derivedAnchor="LE-multi-perspective">
          <front>
            <title>Multi-Perspective Validation Improves Domain Validation Security</title>
            <author fullname="Josh Aas"/>
            <author fullname="Daniel McCarney"/>
            <author fullname="Roland Shoemaker"/>
            <date day="19" month="Feb" year="2020"/>
          </front>
        </reference>
        <reference anchor="RFC6376" target="https://www.rfc-editor.org/info/rfc6376" quoteTitle="true" derivedAnchor="RFC6376">
          <front>
            <title>DomainKeys Identified Mail (DKIM) Signatures</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="T. Hansen" initials="T." role="editor" surname="Hansen"/>
            <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy"/>
            <date month="September" year="2011"/>
            <abstract>
              <t indent="0">DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.</t>
              <t indent="0">This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="76"/>
          <seriesInfo name="RFC" value="6376"/>
          <seriesInfo name="DOI" value="10.17487/RFC6376"/>
        </reference>
        <reference anchor="RFC8738" target="https://www.rfc-editor.org/info/rfc8738" quoteTitle="true" derivedAnchor="RFC8738">
          <front>
            <title>Automated Certificate Management Environment (ACME) IP Identifier Validation Extension</title>
            <author fullname="R.B. Shoemaker" initials="R.B." surname="Shoemaker"/>
            <date month="February" year="2020"/>
            <abstract>
              <t indent="0">This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8738"/>
          <seriesInfo name="DOI" value="10.17487/RFC8738"/>
        </reference>
        <reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8792" quoteTitle="true" derivedAnchor="RFC8792">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>
        <reference anchor="RFC8823" target="https://www.rfc-editor.org/info/rfc8823" quoteTitle="true" derivedAnchor="RFC8823">
          <front>
            <title>Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates</title>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
            <date month="April" year="2021"/>
            <abstract>
              <t indent="0">This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8823"/>
          <seriesInfo name="DOI" value="10.17487/RFC8823"/>
        </reference>
      </references>
    </references>
    <section anchor="sec-cddl" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-administrative-record-types">Administrative Record Types CDDL</name>
      <t indent="0" pn="section-appendix.a-1">
The extension of BPv7 from <xref section="B" target="RFC9171" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9171#appendix-B" derivedContent="RFC9171"/> for the ACME Bundles in Sections <xref target="sec-bundle-challenge" format="counter" sectionFormat="of" derivedContent="3.3"/> and <xref target="sec-bundle-response" format="counter" sectionFormat="of" derivedContent="3.4"/> is the following CDDL:
      </t>
      <sourcecode type="cddl" markers="false" pn="section-appendix.a-2">
; 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
</sourcecode>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-example-authorization">Example Authorization</name>
      <t indent="0" pn="section-appendix.b-1">
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 <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>.
      </t>
      <t indent="0" pn="section-appendix.b-2">
For this example, the ACME client key thumbprint has the base64url-encoded value of:
      </t>
      <sourcecode type="cbor" markers="false" pn="section-appendix.b-3">
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"</sourcecode>
      <t indent="0" pn="section-appendix.b-4">
and the ACME-server generated <tt>token-chal</tt> has the base64url-encoded value of:
      </t>
      <sourcecode type="cbor" markers="false" pn="section-appendix.b-5">
"tPUZNY4ONIk6LxErRFEjVw"</sourcecode>
      <section anchor="sec-example-bundle-challenge" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.1">
        <name slugifiedName="name-challenge-bundle">Challenge Bundle</name>
        <t indent="0" pn="section-appendix.b.1-1">
For the single Challenge Bundle in this example, the <tt>token-bundle</tt> (transported as byte string via BP) has the base64url-encoded value of:
        </t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.1-2">
"p3yRYFU4KxwQaHQjJ2RdiQ"</sourcecode>
        <t indent="0" pn="section-appendix.b.1-3">
The minimal-but-valid Challenge Bundle is shown in <xref target="fig-example-bundle-challenge" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
This challenge requires that the ACME client respond within a 60-second time window.
        </t>
        <figure anchor="fig-example-bundle-challenge" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-example-challenge-bundle">Example Challenge Bundle</name>
          <sourcecode type="cbor" markers="false" pn="section-appendix.b.1-4.1">
[_
  [
    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 /
    &lt;&lt;[ / 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 /
      }
    ]&gt;&gt;
  ]
]</sourcecode>
        </figure>
      </section>
      <section anchor="sec-example-bundle-response" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.2">
        <name slugifiedName="name-response-bundle">Response Bundle</name>
        <t indent="0" pn="section-appendix.b.2-1">
When the tokens are combined with the key thumbprint, the full Key Authorization value is the following, folded across lines for readability using the "single backslash" strategy of <xref section="7" target="RFC8792" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8792#section-7" derivedContent="RFC8792"/>.
        </t>
        <sourcecode type="cbor" markers="false" pn="section-appendix.b.2-2">
/ NOTE: '\' line wrapping per RFC 8792 /

"p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.\
LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"</sourcecode>
        <t indent="0" pn="section-appendix.b.2-3">
The minimal-but-valid Response Bundle is shown in <xref target="fig-example-bundle-response" format="default" sectionFormat="of" derivedContent="Figure 3"/>.
This response indicates that there are 30 seconds remaining in the response time window.
        </t>
        <figure anchor="fig-example-bundle-response" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-example-response-bundle">Example Response Bundle</name>
          <sourcecode type="cbor" markers="false" pn="section-appendix.b.2-4.1">
[_
  [
    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 /
    &lt;&lt;[ / 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 /
      }
    ]&gt;&gt;
  ]
]</sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="sec-doc-ack" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.c-1">
This specification is based on DTN use cases related to PKIX certificate issuance.
      </t>
      <t indent="0" pn="section-appendix.c-2">
The workflow and terminology of this validation method were originally copied from the work of <contact fullname="Alexey Melnikov"/> for email validation <xref target="RFC8823" format="default" sectionFormat="of" derivedContent="RFC8823"/>.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Brian Sipos" initials="B." surname="Sipos">
        <organization abbrev="RKF Engineering" showOnFrontPage="true">RKF Engineering Solutions, LLC</organization>
        <address>
          <postal>
            <street>7500 Old Georgetown Road</street>
            <street>Suite 1275</street>
            <city>Bethesda</city>
            <region>MD</region>
            <code>20814-6198</code>
            <country>United States of America</country>
          </postal>
          <email>brian.sipos+ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
