Signed Custody Receipts Carried in a Bundle Protocol Version 7 Extension Block

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.¶

Table of Contents

1. Introduction

In a delay/disruption tolerant network, a bundle may be held for minutes to hours by nodes run by different operators before it reaches its destination. When something goes wrong (a bundle arrives late, is lost, or arrives altered), each operator holds only its own local logs. Those logs are not portable evidence: another party cannot verify them without trusting the operator that wrote them.¶

BPv7 [RFC9171] does not include custody transfer; reliable hop-by-hop transfer is addressed separately [I-D.ietf-dtn-bibect]. Custody transfer answers "who is responsible for retransmission now". This document addresses a different question: "who can prove they held this bundle, and when". The mechanism is a signed receipt that travels with the bundle and can be verified by any party, at any later time, without contacting the nodes that produced it.¶

The design follows the end-to-end argument [SRC84]: forwarding nodes do nothing beyond normal BPv7 block processing. Only nodes whose operators choose to act as custodians produce receipts, and no node parses the payload: a custodian hashes the bytes it holds. A verifier at the destination, or any later auditor, does the checking.¶

This document is published as Experimental so that the format can be evaluated in multi-operator deployments. This revision defines version 2 receipts, a CBOR payload signed as a COSE_Sign1 and bound to the BPv7 bundle identity; the version 1 encoding of revision -00 is kept in Appendix A so that receipts already produced remain verifiable. Both have been run through five BPv7 paths built from four independent implementations; see Section 7.¶

2. Terminology

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

Custodian:

A node whose operator has chosen to sign receipts for bundles it holds. Being a custodian in this sense is independent of custody transfer and implies no retransmission responsibility.¶

Forwarder:

Any BPv7 node that is not acting as a custodian for a given bundle. A forwarder may or may not implement this specification.¶

Origin:

The first custodian for a bundle.¶

Custody receipt (receipt):

A signed statement by one custodian that it held one bundle, defined in Section 3. A receipt is not a BPv7 administrative record (Section 6.1 of [RFC9171]).¶

Receipt chain:

The ordered list of receipts carried in one Custody Receipt Block.¶

Uncustodied transit gap (gap):

A part of the route, visible to a verifier, for which no receipt exists.¶

3. Custody Receipt Format

A version 2 custody receipt is a COSE_Sign1 structure (Section 4.2 of [RFC9052]), untagged, whose payload is a CBOR [RFC8949] map signed by one custodian.¶

custody-receipt = COSE_Sign1         ; RFC 9052, untagged
receipt-payload = {
  1 => eid-text,                     ; prevHop
  2 => eid-text,                     ; thisHop
  3 => bundle-identity,
  4 => bstr .size 32,                ; payloadHash, SHA-256
  5 => uint,                         ; receivedAt, DTN time
  6 => uint,                         ; forwardedAt, DTN time
  ? 7 => tstr,                       ; subject
}
bundle-identity = [ eid-text, [ uint, uint ] ]   ; whole bundle
  / [ eid-text, [ uint, uint ], uint, uint ]      ; fragment
eid-text = tstr                      ; EID in text form

4. The Custody Receipt Block

custody-receipt-block-data = [ + custody-receipt ]   ; version 2
                           / [ + tstr ]              ; version 1

5. Processing

6. Interaction with BPSec

Because every custodian modifies the Custody Receipt Block, a Block Integrity Block [RFC9172] MUST NOT target it. Receipts carry their own signatures. A BIB that targets the payload or the primary block is unaffected by appending receipts, since appending changes neither. A Block Confidentiality Block MUST NOT target the Custody Receipt Block, because every custodian appends to it.¶

7. Implementation Status

Note to the RFC Editor: please remove this section before publication, as described in [RFC7942].¶

One implementation exists: dtn-custody-demo, Embryo Space Inc., Apache-2.0, JavaScript (Node.js) with no third-party dependencies, https://github.com/BSVKey/dtn-custody-demo. It includes its own BPv7 codec, checked byte for byte against the uD3TN project's Python library, and implements both receipt versions. In live runs the block, with version 1 or version 2 receipts and with a payload BIB beside it, was carried byte-identical across a scheduled contact gap by uD3TN, NASA HDTN, JPL ION and Aalyria Hardy, and along one path through uD3TN and then NASA HDTN; none of them implement it. The audit mode reported the unsigned stretch through each stack that adds a Previous Node block. uD3TN adds one only when built with a compile-time option that is off by default; with it enabled, the uD3TN path was reported the same way. Deployments that rely on the audit need forwarders that emit Previous Node blocks. Results and commands are in the repository (transport/bpv7/RESULTS.md).¶

Testing against JPL ION as a BIB acceptor and signer found that ION builds the integrity-protected plaintext for a payload target from the whole serialized block rather than from the block-type-specific data as a byte string (Section 3.7 of [RFC9173]), and omits the SHA variant parameter while signing with HMAC 256/256. This has been reported to the ION maintainers. The reference implementation interoperates with ION through an optional mode and uses the RFC 9173 construction by default.¶

8. Open Issues

• Key identification. Keys are found by thisHop. A COSE key identifier (kid) would allow key rotation without changing EIDs.¶
• Batching. The block grows by one receipt per custodian. A custodian could instead sign one receipt per contact over a Merkle root of the bundles it held, as the reference implementation does outside the block; how such a receipt is carried in each bundle is not yet specified.¶
• Other signature algorithms. Only EdDSA is required. Whether to require a second algorithm (for example ES256) for flight hardware with existing cryptographic support is open.¶
• Reassembly. A verifier that reassembles fragments could check whole-bundle receipts against the reassembled payload; the procedure is not yet specified.¶

9. Security Considerations

Key distribution. Receipts are only as meaningful as the binding between a custodian EID and its key. Verifiers MUST obtain keys independently of the receipts and MUST NOT trust a key carried with a receipt.¶

Stripping. Any forwarder can remove the block or truncate the array and recompute the CRC. This cannot be prevented by the block itself; it is detected because the removed custodians appear as gaps. A verifier MUST treat a gap as absence of evidence, not as evidence of absence.¶

Replay. A receipt copied to another bundle fails verification because it names the bundle identity and payload hash of what was held.¶

False times. A custodian can sign false receivedAt and forwardedAt values. Receipts bind a custodian to its claims; they do not prove the claims are true. Inconsistent times across adjacent receipts can be flagged by the verifier.¶

Denial of service. Verification cost and block size grow linearly with the number of receipts. A verifier SHOULD bound the number of receipts it will process.¶

Privacy. Receipts reveal the custodians on a route and their timing to anyone who can read the bundle.¶

10. IANA Considerations

IANA is requested to assign one value (TBD1) in the "Bundle Block Types" registry of the "Bundle Protocol" registry group:¶

Appendix A. Version 1 Receipts

Revision -00 of this document defined version 1 receipts, which remain in use. A version 1 receipt is a JSON object [RFC8259] carried in the block as its canonical form (keys sorted recursively by UTF-16 code unit, no insignificant whitespace). Its members are kind ("custody/1"), payloadId, bundleId, prevHop, thisHop, receivedAt and forwardedAt (milliseconds since 1970-01-01T00:00:00Z), claimId ("0x" and the lowercase hexadecimal SHA-256 of the canonical form without claimId, sig and signerPub), sig (base64 Ed25519 signature over the UTF-8 bytes of claimId) and signerPub (base64 DER SubjectPublicKeyInfo [RFC8410]). The origin sets payloadId and bundleId from the application data unit; later custodians copy them from the first receipt. An encoded version 1 receipt is about 530 octets.¶

Appendix B. Changes from -00

This section is to be removed before publishing as an RFC.¶

• Version 2 receipts: a CBOR payload signed as COSE_Sign1 (EdDSA), about 156 octets instead of about 530. Version 1 moved to Appendix A.¶
• Receipts are bound to the BPv7 bundle identity and a hash of the payload bytes held, so no custodian parses the payload and any verifier can check the binding.¶
• Fragment handling defined.¶
• Implementation status updated: a path through two implementations, version 2 receipts live, and the JPL ION BPSec report.¶

Author's Address