Skip to main content

TTTPS Deep-space Profile: Propagation-Aware Time Attestation
draft-helmprotocol-deepspace-00

Document Type Active Internet-Draft (individual)
Author 장동호
Last updated 2026-09-19
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-helmprotocol-deepspace-00
Network Working Group                                          H. Jorgen
Internet-Draft                                                  Kenosian
Intended status: Experimental                          19 September 2026
Expires: 23 March 2027

      TTTPS Deep-space Profile: Propagation-Aware Time Attestation
                    draft-helmprotocol-deepspace-00

Abstract

   This document defines an experimental deep-space profile for the TLS
   TimeToken Secure Protocol (TTTPS).  The profile preserves the Proof-
   of-Time record and cryptographic verification boundary while adding
   propagation-aware context for long and intermittent links.  It
   specifies one-way-light-time handling, epoch- and frame-bound
   physical context, relative coordinate-time conversion, peer
   projection, conservative aggregation, and explicit HOLD and
   UNVERIFIABLE outcomes.  It does not claim flight measurements, a live
   interplanetary mesh, or a replacement for CCSDS, DTN, or navigation
   standards.

Status of This Memo

   This document is an Internet-Draft and is submitted in full
   conformance with BCP 78 and BCP 79.  Internet- Drafts are working
   documents of the IETF and have no formal standing in the IETF
   standards process.

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 23 March 2027.

Jorgen                    Expires 23 March 2027                 [Page 1]
Internet-Draft          TTTPS Deep-space Profile          September 2026

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   4.  Deep-Space Verification Context . . . . . . . . . . . . . . .   4
   5.  Automatic Context and Profile Dispatch  . . . . . . . . . . .   4
   6.  Propagation-Aware Tolerance . . . . . . . . . . . . . . . . .   5
   7.  Numeric and Diagnostic Guardrails . . . . . . . . . . . . . .   5
   8.  Verification Processing . . . . . . . . . . . . . . . . . . .   5
   9.  Peer Projection and Aggregation . . . . . . . . . . . . . . .   6
   10. Sparse-Peer and Holdover Regimes  . . . . . . . . . . . . . .   6
   11. Physical Context and Evidence Schema  . . . . . . . . . . . .   7
   12. Confidence and Epi-Entropy Interaction  . . . . . . . . . . .   7
   13. Deep-Space G-Score and Epi-Entropy Contract . . . . . . . . .   8
   14. Deep-Space System Model . . . . . . . . . . . . . . . . . . .   9
   15. OWLT Model and Tier Selection . . . . . . . . . . . . . . . .   9
   16. Navigation, Ephemeris, and Precision  . . . . . . . . . . . .  10
   17. Peer Projection, Quorum, and Recovery . . . . . . . . . . . .  10
   18. End-to-End Processing Contract  . . . . . . . . . . . . . . .  11
   19. Evaluation Matrix and Non-Claims  . . . . . . . . . . . . . .  11
   20. Coordinate-Time Conventions and Integer Preservation  . . . .  12
   21. Position Sources and Admissibility  . . . . . . . . . . . . .  12
   22. Observation Ledger and Context Binding  . . . . . . . . . . .  13
   23. Consensus Regimes and Anchored Holdover . . . . . . . . . . .  13
   24. Evaluation Protocol and Evidence Denominators . . . . . . . .  14
   25. Deep-Space Tier and Propagation Envelope  . . . . . . . . . .  14
   26. Self-Extending D-Chain Model  . . . . . . . . . . . . . . . .  15
   27. Relative Link Observables . . . . . . . . . . . . . . . . . .  15
   28. Delay, Replay, and Path-Manipulation Defense  . . . . . . . .  16
   29. Trust Hierarchy and Recovery  . . . . . . . . . . . . . . . .  16
   30. Privacy and Minimal Physical Disclosure . . . . . . . . . . .  17
   31. GRG Link Framing and Fixed PoT Boundary . . . . . . . . . . .  17
   32. Failure Semantics and Recovery  . . . . . . . . . . . . . . .  18
   33. Security Considerations . . . . . . . . . . . . . . . . . . .  18
   34. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   35. Implementation and Evidence Status  . . . . . . . . . . . . .  19

Jorgen                    Expires 23 March 2027                 [Page 2]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   36. Normative References  . . . . . . . . . . . . . . . . . . . .  19
   37. Informative References  . . . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   TTTPS supplies a cryptographically verifiable temporal-attestation
   record.  A deep-space deployment adds a separate physical problem:
   propagation delay can be comparable to, or larger than, the ordinary
   freshness window, and connectivity can be intermittent.  A signed
   record remains a valid cryptographic object, but arrival time alone
   cannot establish when a remote event should be compared with a local
   event.

   This profile carries physical and peer evidence alongside the core
   record.  It does not change the meaning or wire encoding of the core
   PoT record.  An implementation that does not select this profile
   processes TTTPS according to the base specification.

2.  Scope and Non-Goals

   The profile applies to cislunar, interplanetary, space-relay, and
   other delay-tolerant links [RFC4838] where OWLT, clock drift,
   position uncertainty, or intermittent reachability materially affects
   comparison.

   It does not define a new astronomical timescale, navigation source,
   transport protocol, DTN convergence layer, or spacecraft flight
   procedure.  GNSS, ephemeris, pulsar, X-ray, and DSN data are not
   mandatory.  Offline or simulated evidence is not a flight
   measurement.

3.  Conventions and Terminology

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

   OWLT:  one-way light time for a declared source, epoch, frame, and
      link geometry.

   Context:  physical and policy inputs used to interpret a PoT
      observation.

   Applicable:  the predicate that context, precision, epoch, and policy
      are sufficient for the requested comparison.

Jorgen                    Expires 23 March 2027                 [Page 3]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   HOLD:  a conservative non-promotion or non-commit result for a
      potentially recoverable condition.

   UNVERIFIABLE:  a required authority or context input was not
      established.

4.  Deep-Space Verification Context

   A deep-space implementation MUST bind every propagation-aware
   decision to a context identifier.  The context MUST identify the
   reference epoch, coordinate-time convention, coordinate frame, OWLT
   estimate or interval, uncertainty budget, source authority,
   applicability policy, and effective peer-identity mapping.

   Arrival time MUST NOT substitute for OWLT.  OWLT MUST be derived from
   declared link geometry, an authority-labelled ephemeris, a measured
   or bounded navigation result, or an explicitly synthetic fixture.
   Missing or stale inputs MUST produce HOLD or UNVERIFIABLE according
   to policy; they MUST NOT silently become zero, a terrestrial
   constant, or the latest available value.

   The context identifier and evidence manifest SHOULD be retained with
   the verification receipt.  A context mismatch MUST invalidate reuse
   of a prior propagation result.

5.  Automatic Context and Profile Dispatch

   When a verifier receives a fixed PoT record, it MUST first complete
   the core integrity, holder-binding, and replay checks.  It MUST then
   resolve the protected context identifier against an authenticated
   context manifest.  The manifest selects a near-Earth/SAGIN context or
   this propagation-aware Deep-space context; the selection MUST NOT be
   inferred from arrival time, network address, source count, or an
   untrusted packet hint.

   The dispatch manifest MUST bind the selected profile to its epoch,
   time scale, coordinate frame, endpoints, OWLT interval, navigation or
   ephemeris authority, uncertainty budget, peer/provenance digest, and
   policy revision.  The verifier SHOULD retain the manifest digest and
   selected profile in the evidence receipt.

        fixed PoT -> core verify/replay -> ctx_id manifest authentication
             -> SAGIN or Deep-space profile selection
             -> OWLT/TCB/peer/Epi processing -> PASS/HOLD/UNVERIFIABLE

Jorgen                    Expires 23 March 2027                 [Page 4]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   A missing, stale, contradictory, or unauthorized manifest MUST result
   in HOLD or UNVERIFIABLE.  It MUST NOT cause a terrestrial default,
   zero OWLT, zero residual, or fabricated Epi input.  This profile does
   not add fields to the fixed PoT wire record; all physical context
   remains out of band.

6.  Propagation-Aware Tolerance

   For OWLT t_owlt, a base processing margin T_base, and an uncertainty
   allowance T_uncertainty, an implementation MAY use the reference
   rule:

           T_profile = T_base + 2 * t_owlt + T_uncertainty

   The factor of two represents a round-trip contribution only when the
   exchange requires a round trip.  A one-way or store-and-forward
   protocol MUST use a policy consistent with its actual message path.
   The selected value MUST be recorded with the context and MUST NOT
   exceed a configured safety bound without an explicit policy
   transition.

   Precision guardrails apply before comparison.  If OWLT, ephemeris,
   clock, or frame-conversion precision is insufficient for the
   requested tolerance, the result MUST be HOLD or UNVERIFIABLE.

7.  Numeric and Diagnostic Guardrails

   When a coordinate-time value is represented as integer nanoseconds,
   an implementation SHOULD preserve the integer value through the
   conversion boundary.  Relativistic or propagation correction factors
   MAY be evaluated in floating point, but the correction MUST be
   rounded under a declared rule and added back to the integer
   representation.  Direct conversion of a large absolute nanosecond
   epoch to binary floating point MUST NOT be treated as lossless.

   Epi-Entropy is an optional read-only shadow analysis for residual
   ambiguity.  A nonzero identity diameter, an empty admissible bundle,
   or missing physical constraints MAY request more evidence or cause
   HOLD, but MUST NOT alone cause REJECT or replace core integrity and
   admission checks.

8.  Verification Processing

   A propagation-aware verifier MUST conceptually process a candidate
   observation in this order:

   1.  verify core TTTPS integrity, holder binding, and replay
       conditions;

Jorgen                    Expires 23 March 2027                 [Page 5]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   2.  validate context identifier, epoch, frame, and policy;

   3.  derive or validate OWLT and the uncertainty envelope;

   4.  project comparable observations to the reference epoch;

   5.  apply admission, freshness, effective-identity, and quorum
       policy;

   6.  apply the configured robust aggregate and confidence
       qualification;

   7.  return PASS, HOLD, or UNVERIFIABLE with an evidence reason.

   An earlier failure MUST NOT be repaired by a later confidence score.
   Confidence is not integrity, and physical applicability is not proof
   that a record was authentic.

9.  Peer Projection and Aggregation

   Before aggregation, each peer observation MUST be associated with an
   effective identity and provenance group.  Duplicate labels mapping to
   one declared physical or provisioning identity MUST NOT increase the
   effective quorum.

   Peer projection MUST preserve observation epoch, source context,
   uncertainty, and provenance.  A verifier MAY use a Byzantine median
   or another declared robust aggregate, but it MUST retain the fault
   bound and admitted observation set.  Sparse or misaligned peer sets
   SHOULD produce HOLD rather than a fabricated aggregate.

   Correlation-aware confidence and Epi-style ambiguity evidence are
   optional qualification layers.  They MAY reduce authority at a commit
   boundary, but MUST NOT alter the cryptographic interpretation of an
   already-issued PoT record.

10.  Sparse-Peer and Holdover Regimes

   A deep-space profile MUST account for effective physical independence
   rather than raw peer count.  Let Roster be the admitted set and
   PhysicalEntity map a stable node identifier to its declared physical
   or provisioning origin:

           N_eff = | union_i PhysicalEntity(stable_node_id_i) |
           T_bound(t) = E_sync + sigma_clock * sqrt(t - tau_sync)
                       + 1/2 * gamma_drift * (t - tau_sync)^2

Jorgen                    Expires 23 March 2027                 [Page 6]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   When N_eff is below the configured threshold, the verifier MUST NOT
   manufacture a Byzantine quorum.  It MAY enter bounded anchored
   holdover (AHE) using the declared T_bound, but holdover age, drift
   model, anchor authority, and maximum duration MUST be recorded.
   Expired holdover produces HOLD or UNVERIFIABLE.

   For a median-style aggregate, the deployment MUST declare the assumed
   Byzantine bound and check the applicable condition before using the
   result.  The usual f < N_eff/2 condition does not become true merely
   because a roster contains more labels.

11.  Physical Context and Evidence Schema

   A propagation context SHOULD contain context identifier, observation
   and reference epochs, coordinate frame, coordinate-time convention,
   link endpoints, OWLT point or interval, ephemeris or navigation
   authority, clock-error model, uncertainty budget, peer roster digest,
   effective-identity digest, applicability decision, and evidence tier.

   The verifier MUST bind the context identifier to the decision.  A
   stale ephemeris, mismatched epoch, unsupported frame conversion, or
   missing authority is an applicability failure.  It MUST NOT be hidden
   by a wider average or a confidence score.

   TCB or other large coordinate-time values SHOULD remain integer
   nanoseconds at the representation boundary.  If a relativistic
   correction is evaluated as a floating-point factor, the correction
   alone MAY use floating point; it MUST be rounded under a declared
   rule and added to the integer epoch.

12.  Confidence and Epi-Entropy Interaction

   The Confidence companion profile supplies optional G-Score,
   correlation-aware von Neumann, Epi-Entropy, and AdaptiveSwitch
   qualification.  These computations are out of band and do not enlarge
   the TTTPS wire record.  A confidence result cannot authenticate a
   record, repair a replay, or turn an inapplicable physical context
   into a valid one.

   When the peer context is sparse or the admissible interpretation
   bundle has nonzero identity ambiguity, the conservative result is
   HOLD.  A deployment MAY use hysteresis and bounded recovery to avoid
   turning transient physical uncertainty into permanent denial of
   service.

Jorgen                    Expires 23 March 2027                 [Page 7]
Internet-Draft          TTTPS Deep-space Profile          September 2026

13.  Deep-Space G-Score and Epi-Entropy Contract

   Deep-space confidence qualification MUST operate on admitted,
   provenance-collapsed observations.  Raw signed-message count is not
   an independence count.  Let p be the declared agreement distribution
   over the effective sources:

           H(p) = -sum_i p_i ln(p_i)
           G(p) = H(p) / ln(n), n > 1; G(p) = 0 for n = 1

   G-Score measures marginal agreement concentration.  It MUST NOT be
   interpreted as proof of independent physical origins.  When aligned
   residual history or pairwise correlation is available, a deployment
   MAY construct a density operator rho and compute:

           S_VN(rho) = -Tr(rho log2 rho)

   The VN result is unavailable when the required aligned history is
   absent; absence MUST NOT be encoded as zero correlation.  The Epi
   shadow then represents residual ambiguity from physical context and
   peer constraints:

           B(C) = { R | R=R^dagger, R >= 0, Tr(R)=1,
                    Tr(R A_k) <= b_k for every k }
           EpiEnt(B) = [inf_R S_VN(R), sup_R S_VN(R)]
           Delta_id(B) = sup_(R,R' in B) 1/2 ||R-R'||_1

   For bounded execution, the implementation MAY publish the certified
   purity lower bound rather than the exact lower endpoint:

           lower_bound >= -log2(sup_(R in B) Tr(R^2))

   The value MUST be labelled as a bound.  An empty bundle, missing OWLT
   or ephemeris alignment, stale TCB context, or unresolved provenance
   MUST produce CONSTRAINT_INCONSISTENCY, HOLD, or UNVERIFIABLE under
   policy; it MUST NOT produce PASS by substituting zero uncertainty.  A
   nonzero identity diameter is an ambiguity signal, not proof that a
   peer is malicious.

   The required order is: core integrity and replay; context and
   physical applicability; provenance collapse and N_eff; peer
   projection and declared robust aggregate; G-Score and optional VN;
   then Epi qualification before a new promotion or commit.  Epi is
   read-only shadow evidence and MUST NOT rewrite an already issued PoT
   or expand the wire record.

Jorgen                    Expires 23 March 2027                 [Page 8]
Internet-Draft          TTTPS Deep-space Profile          September 2026

14.  Deep-Space System Model

   The profile separates four objects that are often conflated: the
   cryptographic PoT record, the physical context used to interpret it,
   the peer evidence used for comparison, and the policy decision made
   from those inputs.  A signed record can be authentic while its
   physical comparison is unavailable.  A plausible propagation model
   cannot authenticate a forged record.

   An implementation SHOULD retain a context manifest containing source
   authority, epoch, frame, link endpoints, OWLT estimate or interval,
   clock model, uncertainty budget, roster digest, and applicability
   decision.  The manifest is evidence metadata and is not a replacement
   for the core PoT wire record.

   Point estimate:  a single declared value with explicit uncertainty
      and authority.

   Interval:  a bounded range used when a source cannot justify a point
      value.

   Holdover:  a bounded continuation from a fresh anchor under a
      declared drift model.

   Applicability:  whether the context is sufficient for the requested
      comparison, independent of cryptographic validity.

15.  OWLT Model and Tier Selection

   For an endpoint separation and declared propagation model, a
   reference tolerance is:

           T_profile = T_base + 2 * t_owlt + T_uncertainty

   The factor two is valid only when the transaction requires a round-
   trip contribution.  A one-way or store-and-forward path MUST use a
   policy matching its actual message direction.  OWLT MUST be bound to
   epoch, coordinate frame, link endpoints, and authority; arrival time
   MUST NOT be treated as OWLT.

   A tier selector MAY choose local, cislunar, interplanetary, or
   extended-delay policy.  Promotion to a more permissive tier requires
   the new tier's context and precision predicates.  The selected tier
   and reason MUST be retained with the result.

Jorgen                    Expires 23 March 2027                 [Page 9]
Internet-Draft          TTTPS Deep-space Profile          September 2026

16.  Navigation, Ephemeris, and Precision

   Permitted position sources include an authority-labelled ephemeris,
   ranging or multilateration, XNAV or pulsar-derived position, and an
   explicitly synthetic fixture.  The profile does not make one source
   mandatory.  It does require that a verifier distinguish authority,
   freshness, precision, and applicability.

   An analytic or stale ephemeris MAY support a calculation only when
   its error bound is within the requested tolerance and policy permits
   it.  Otherwise the result is HOLD or UNVERIFIABLE.  Missing data MUST
   NOT be replaced by a zero residual, terrestrial default, or latest
   cached value without an explicit stale policy.

   For large absolute coordinate-time values, preserve integer
   nanoseconds.  Evaluate only the correction factor in floating point
   if necessary, apply a declared rounding rule, and add the rounded
   correction to the integer epoch.  The rounding mode and precision
   guard SHOULD be exposed in the evidence manifest.

17.  Peer Projection, Quorum, and Recovery

   Peer observations MUST first be projected to a declared reference
   epoch and context.  Projection retains original epoch, source,
   uncertainty, and provenance.  An aggregate is valid only for the set
   and fault model that produced it.

           N_eff = | union_i PhysicalEntity(stable_node_id_i) |
           T_bound(t) = E_sync + sigma_clock * sqrt(t - tau_sync)
                       + 1/2 * gamma_drift * (t - tau_sync)^2

   When N_eff is below the configured threshold, a verifier MUST NOT
   claim a Byzantine quorum.  It MAY enter bounded anchored holdover
   using T_bound.  The anchor, drift parameters, age, and maximum
   holdover MUST be recorded.  After expiry the result is HOLD or
   UNVERIFIABLE.

   A median or other robust aggregate MUST declare its fault assumption.
   The condition f < N_eff/2 is a condition on effective independent
   entities, not on signed message count.  Duplicate identities, common
   operators, and relays do not create new independent peers.

Jorgen                    Expires 23 March 2027                [Page 10]
Internet-Draft          TTTPS Deep-space Profile          September 2026

18.  End-to-End Processing Contract

   A profile implementation SHOULD process a candidate in this order:
   verify core integrity and replay; validate context and epoch; derive
   or validate OWLT; compute the uncertainty envelope; project peers;
   collapse effective identities; check quorum; apply a declared robust
   aggregate; run optional G-Score, VN, and Epi qualification; and
   return PASS, HOLD, UNVERIFIABLE, or REJECT with a reason.

   Later qualification cannot repair an earlier failure.  Epi-Entropy is
   attached after admission, physical applicability, and provenance
   collapse.  If its bundle is empty or identity ambiguity exceeds
   policy, it can withhold a new commit but cannot rewrite a prior PoT
   record.

   The evidence SHOULD identify the deciding stage, context and policy
   revision, and whether the input was implemented, simulated,
   synthetic, live black-box, or hardware-measured.  No current evidence
   in this profile claims interplanetary flight validation.

19.  Evaluation Matrix and Non-Claims

      +===============+=====================+======================+
      | Area          | Reference evidence  | Claim boundary       |
      +===============+=====================+======================+
      | TCB           | unit tests and      | integer-preserving   |
      | correction    | vectors             | software behavior    |
      +---------------+---------------------+----------------------+
      | OWLT and      | deterministic       | model result, not    |
      | tiering       | calculations        | flight measurement   |
      +---------------+---------------------+----------------------+
      | Peer median   | fault and partition | declared fault model |
      |               | simulations         | only                 |
      +---------------+---------------------+----------------------+
      | Navigation    | synthetic/XNAV      | authority and sensor |
      |               | fixtures            | quality remain       |
      |               |                     | deployment inputs    |
      +---------------+---------------------+----------------------+
      | Epi           | bundle and          | shadow evidence, not |
      | qualification | ambiguity tests     | integrity proof      |
      +---------------+---------------------+----------------------+

                   Table 1: Deep-space evidence classes

   Results MUST retain denominators, input fixtures, source revision,
   toolchain, policy hash, and disposition.  A successful simulation
   does not establish an operational spacecraft link, and a computed
   OWLT does not establish that physical range was measured.

Jorgen                    Expires 23 March 2027                [Page 11]
Internet-Draft          TTTPS Deep-space Profile          September 2026

20.  Coordinate-Time Conventions and Integer Preservation

   The context MUST distinguish TCB, TDB, and TT labels.  A value
   labelled TDB MUST NOT be inserted into a TCB chain by relabelling its
   unit, and a TT observation MUST NOT be compared with a barycentric
   value without an explicit conversion model.  The manifest SHOULD
   identify the epoch, BCRS or GCRS frame, ephemeris revision, unit, and
   conversion revision.

   For a local proper-time interval tau and a declared relativistic
   correction q, a reference relative propagation model is:

           Delta_t_TCB = round_q(tau * (1 + Phi/c^2 + v^2/(2c^2)))
           t_B_TCB = t_A_TCB + Delta_t_TCB

   The expression is a profile model, not a claim that a low-order
   potential approximation is sufficient for every mission.  A large
   absolute nanosecond epoch MUST remain an integer at the
   representation boundary.  Floating point MAY be used for the
   correction factor only; the rounded correction MUST be added to the
   integer epoch.  The rounding rule, precision, and residual MUST be
   retained in evidence.

   For multiple hops, each hop contribution and its uncertainty MUST
   remain distinguishable.  A conservative additive envelope MAY be used
   when error independence is not established.  RSS combination is an
   evidence-conditioned refinement and MUST NOT be treated as a
   guarantee in the presence of common ephemeris, clock, or relay bias.

21.  Position Sources and Admissibility

   Permitted position sources include an authority-labelled ephemeris,
   ranging or multilateration, XNAV or pulsar-derived constraints, and
   synthetic fixtures used for testing.  The profile does not make one
   source mandatory; it requires the verifier to retain source class,
   authority, age, uncertainty, and applicability.

   Let delta_r_ephem be the declared position error, delta_r_req the
   error tolerated by the requested propagation correction, and eta the
   configured policy factor.  An analytic ephemeris MAY be used for the
   precision-sensitive correction only when:

           delta_r_ephem <= eta * delta_r_req

   If the guardrail fails, the ephemeris MAY still support a coarse OWLT
   interval when policy permits, but MUST NOT support a false
   nanosecond-level correction.  The result is HOLD or UNVERIFIABLE
   until an authoritative source or a wider tolerance is established.

Jorgen                    Expires 23 March 2027                [Page 12]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   XNAV is an interface contract rather than a claim of detector
   operation.  A solver result MUST expose observation epoch, catalogue
   or ephemeris revision, residual, covariance or bound, and evidence
   class.  Missing detector evidence MUST be represented as unavailable;
   it MUST NOT be turned into a zero residual.

22.  Observation Ledger and Context Binding

   Each propagation observation SHOULD be recorded as an append-only
   logical entry containing source and destination identifiers, emission
   and reception epochs, direction, OWLT point or interval, frame, time
   scale, position source, clock model, uncertainty budget, policy
   revision, and provenance group.  The entry MUST bind to the context
   identifier used by the decision.

   A historical observation MAY remain useful evidence while being
   ineligible for a current decision.  Reuse of a prior propagation
   result requires a fresh age and applicability check.  Context
   mismatch, epoch mismatch, or a stale authority MUST prevent silent
   reuse.

   The evidence ledger SHOULD distinguish model output from measured
   input: OWLT computed from geometry is not a measured range, and a
   synthetic XNAV fixture is not flight detector evidence.  This
   distinction is required in receipts and in evaluation reports.

23.  Consensus Regimes and Anchored Holdover

   The normal peer regime requires an effective independent population
   and a declared fault bound.  The sparse regime is different: with two
   effective entities, the condition f < N_eff/2 implies f=0, so the
   verifier MUST NOT describe the result as Byzantine fault tolerant.
   With fewer than the policy minimum, it MUST enter HOLD, UNVERIFIABLE,
   or a separately named anchored holdover regime.

           E_holdover(t) = E_sync + sigma_clock * sqrt(t-tau_sync)
                          + 1/2 * gamma_drift * (t-tau_sync)^2

   The holdover bound is usable only while anchor provenance, oscillator
   parameters, age, maximum duration, and context applicability remain
   valid.  Holdover is not a second quorum and does not prove that a
   disconnected interval contained no Byzantine source.  The age and
   reduced authority MUST be visible to the caller.

Jorgen                    Expires 23 March 2027                [Page 13]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   On recovery, observations MUST be projected into the same reference
   context, checked for replay and freshness, and re-admitted before
   replacing the anchor.  A single delayed packet MUST NOT heal a
   partition or reset the holdover age without satisfying the complete
   recovery predicate.

24.  Evaluation Protocol and Evidence Denominators

   The deep-space evaluation is divided into independent groups:
   integer- preserving TCB conversion, OWLT propagation, ephemeris or
   reference-vector comparison, Byzantine median under the declared
   fault condition, low-peer and partition transitions, attack
   simulations, confidence qualification, and an end-to-end relay
   journey.  A passing group MUST NOT mask a missing authority or an
   unavailable group.

   Every result SHOULD include fixture revision, toolchain, policy hash,
   observation count, effective-identity count, fault count, false-
   promotion and false-hold counts, latency distribution, recovery
   duration, and the exact reason for HOLD or UNVERIFIABLE.  If no
   hardware or live link was present, the corresponding field is
   NOT_MEASURED, not zero.

   Attack simulations MAY exercise forgery, replay, delay manipulation,
   Sybil inflation, collusion, common-source failure, stale ephemeris,
   compromised navigation, and partition recovery.  They demonstrate
   behavior under the fixture and declared fault model; they do not
   establish spacecraft flight performance or universal attack
   detection.

25.  Deep-Space Tier and Propagation Envelope

   The deep-space extension carried by the earlier TTTPS deep-space
   design uses a dedicated propagation-aware tier, identified there as
   T-s1_dspace with value 0x4.  This profile describes the tier behavior
   and evidence contract; it does not redefine the core record layout or
   assign a new wire field.  A deployment selecting the tier MUST
   declare whether its tolerance is one-way, two-way, or asymmetric.

           tier_tolerance = T_base + 2 * d_owlt

   The factor of two is applicable only to a round-trip exchange.  For a
   one-way or store-and-forward path, the policy MUST use the actual
   message direction and MUST retain the one-way interval separately.
   T_base is a declared processing margin, not a universal constant.
   The Earth-Moon and Earth-Mars figures in the research material are
   illustrative geometry examples, not measured deployment guarantees.

Jorgen                    Expires 23 March 2027                [Page 14]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   Submissions beyond the selected propagation envelope MUST NOT be
   silently accepted as ordinary freshness.  The verifier MUST route
   them to the declared delayed, HOLD, or REJECT policy.  A valid
   signature does not erase a failed physical-applicability or recency
   predicate.

26.  Self-Extending D-Chain Model

   The deep-space model is a chain of locally characterized links rather
   than a claim that one terrestrial root is reachable at all times.
   The profile can be staged as SAGIN or near-Earth, cislunar, Solar-
   System relay, and extended delay links.  The stages use one context-
   bound evidence model while the propagation interval, position
   authority, and holdover policy change with the link.

           stage 1: terrestrial/SAGIN anchor -> cislunar relay
           stage 2: cislunar relay -> planetary relay
           stage 3: planetary relay -> deep-space node
           stage 4: extended-delay node -> next reachable neighbour

           t_B = t_A + Delta_tau_AB *
                 (1 + Phi_rel/c^2 + v_rel^2/(2*c^2))

   Each hop MUST identify its anchor, neighbor, epoch, frame, relative
   potential model, relative velocity or range-rate source, and
   uncertainty.  A multi-hop result MUST preserve the hop decomposition
   or a conservative composed bound.  The chain is not self-healing
   merely because a route exists: recovery requires a fresh
   authenticated neighbor exchange and revalidation of every applicable
   context predicate.

27.  Relative Link Observables

   The profile prefers relative quantities that can be characterized on
   the local link over an unstated absolute inertial solution.  Range-
   rate MAY be derived from successive round-trip range observations and
   MAY be cross- checked with an authenticated Doppler observation.  The
   verifier MUST record which source produced the value and whether the
   cross-check was available.

           v_rel ~= d(rho_AB)/dt
           hop_error = error(clock) + error(range-rate)
                     + error(ephemeris) + error(model)

   These relations are an evidence model, not a promise of sensor
   precision.  If the range-rate, potential, or frame authority is
   absent, the node MAY retain a coarse OWLT interval but MUST NOT issue
   a precision-sensitive TCB correction from an invented value.

Jorgen                    Expires 23 March 2027                [Page 15]
Internet-Draft          TTTPS Deep-space Profile          September 2026

28.  Delay, Replay, and Path-Manipulation Defense

   Deep-space delay defense has separate gates.  Context binding
   prevents a record from one execution context from being interpreted
   as another; nonce and D-chain freshness prevent replay within the
   declared retention window; and the propagation-aware recency gate
   rejects or holds observations outside the declared envelope.  These
   gates MUST remain distinguishable in the reason code.

   A path adversary MAY delay, reorder, or drop messages without
   possessing the issuer key.  Such an adversary cannot be treated as
   having forged the time value solely because the link is delayed.  The
   correct result is a physical delay or freshness disposition.  A
   modified timestamp still requires failure of the cryptographic
   integrity check and MUST NOT be converted to a confidence failure.

   Where multi-source time is used before a propagation estimate,
   sources SHOULD be drawn from distinct administrative or physical
   provenance groups.  A median resists a minority only under its
   declared independence and fault assumptions; duplicate keys, relays,
   and common operators MUST NOT be counted as new independent sources.

           context gate -> freshness/replay gate -> OWLT envelope gate
                |                  |                    |
              REJECT             REJECT/HOLD           HOLD/UNVERIFIABLE

29.  Trust Hierarchy and Recovery

   The profile separates issuer authentication, navigation authority,
   physical provenance, and peer health.  A node MAY prefer a JPL- or
   mission- authority-labelled anchor, but the label itself is not a
   substitute for signature verification, freshness, or an applicable
   ephemeris revision.

   When an anchor key, ephemeris authority, or neighbor path is
   compromised, recovery MUST revoke or quarantine the affected context,
   record the affected interval, and require a fresh anchor or
   independently authorized path.  A cached successful result MUST NOT
   silently bridge the authority gap.

   Health-aware routing MAY prioritize neighbors using serving capacity,
   recent trend, and link quality.  That score is a routing aid, not a
   proof of time correctness.  The time median MUST still use the
   declared evidence, identity, and fault checks.

Jorgen                    Expires 23 March 2027                [Page 16]
Internet-Draft          TTTPS Deep-space Profile          September 2026

30.  Privacy and Minimal Physical Disclosure

   Position, ephemeris, range-rate, relay topology, and provenance
   fields can reveal mission-sensitive information.  Implementations
   SHOULD use opaque context identifiers, commitments, and role-based
   disclosure while preserving an authorized audit path.  A verifier
   MUST receive enough authority and precision metadata to evaluate
   applicability; privacy minimization MUST NOT remove the fields needed
   to distinguish measured, modeled, and unavailable evidence.

31.  GRG Link Framing and Fixed PoT Boundary

   The Deep-space profile MAY be carried over a link that uses GRG
   compression, FEC, or interleaving, but GRG link framing is a separate
   physical/profile contract.  The fact that 180 is divisible by three
   does not by itself define sixty 24-bit codewords, and the fixed PoT
   record MUST NOT be reinterpreted as a GRG codeword stream without an
   explicit profile.

   The profile MUST identify the exact code and parameters.  In
   particular, Golay (23,12,7) and binary extended Golay [24,12,8] are
   different codes and MUST NOT be mixed.  A v1 143-octet record MUST
   remain 143 octets at the PoT boundary.  A 144-octet padded PHY frame,
   if desired, requires a new versioned link profile and an explicit
   padding/header rule; it is not an implicit change to v1.

   The current checked GRG reference path for this family of documents
   is the Golay (23,12,7) path.  The extended [24,12,8] code may exist
   as an independent implementation, but its presence does not change
   the selected profile and MUST NOT be inferred from a 180-octet record
   length.  Interoperability requires an explicit code identifier and
   matching test vectors before reception.

   An authenticated context manifest MAY bind the selected FEC code,
   Golomb-Rice parameter, interleaver depth, block order, padding rule,
   and decoder resource limits.  These parameters MUST be known before
   decoding.  A receiver MUST fail closed on code, length, syndrome,
   Rice-stream, or manifest mismatch and return UNVERIFIABLE or HOLD
   according to policy.

   The safe processing boundary is:

          profile manifest -> preconfigured deinterleave/FEC/Rice decode
            -> recovered fixed v1/v2 PoT -> core integrity/replay
            -> context/OWLT/TCB -> peer/N_eff -> G-Score/VN/Epi

Jorgen                    Expires 23 March 2027                [Page 17]
Internet-Draft          TTTPS Deep-space Profile          September 2026

   FEC correction can recover an erasure or bounded bit error under its
   declared code, but MUST NOT turn a failed PoT cryptographic integrity
   check into PASS.  G-Score and Epi-Entropy operate after the framing
   and semantic verification boundaries; they do not select a decoder or
   repair an invalid signature.

32.  Failure Semantics and Recovery

   PASS:  core and profile predicates cleared under the declared
      context.

   HOLD:  promotion or commit is withheld while a bounded condition
      remains.

   UNVERIFIABLE:  a required context or authority predicate was not
      established.

   REJECT:  core integrity, authentication, or replay validation failed.

   Recovery MUST require new or freshly revalidated evidence.  A timer,
   retransmission, or cached confidence result MUST NOT relabel
   unresolved context as PASS.  Evidence receipts SHOULD expose reason,
   context age, and relevant uncertainty.

33.  Security Considerations

   Propagation-aware tolerance can become a denial-of-service vector if
   it grows without a bound.  Implementations MUST configure maximum
   tolerances, reject stale context, and distinguish HOLD from REJECT.

   Shared navigation sources, common ephemeris origins, colluding peers,
   and duplicated credentials can create an appearance of independent
   evidence.  Provenance collapse and source-authority metadata are part
   of the security boundary.  Neither a signature nor a confidence score
   proves physical independence without an authoritative binding.

   Privacy policy SHOULD minimize disclosure of precise position,
   ephemeris, and peer-topology data.  Receipts MAY use opaque context
   identifiers and commitments while retaining authorized auditability.

34.  IANA Considerations

   This document makes no IANA request.  A future revision MAY request a
   profile identifier after interoperability, codepoint ownership, and
   coexistence with the TTTPS core registry have been reviewed.

Jorgen                    Expires 23 March 2027                [Page 18]
Internet-Draft          TTTPS Deep-space Profile          September 2026

35.  Implementation and Evidence Status

   The companion implementation evidence includes source-level checks,
   deterministic simulations, and offline reference-vector validation.
   These establish behavior of tested software and declared fixtures
   only.  They do not establish live interplanetary operation, flight
   hardware performance, or a connected deep-space mesh.

   The research companion is available as SSRN abstract 7487038:
   https://papers.ssrn.com/sol3/papers.cfm?abstract_id=7487038
   [DEEPSPACEPAPER].  The SSRN record is informative background; the
   normative boundary is this Internet-Draft and the applicable TTTPS
   core draft [TTTPS].

36.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

37.  Informative References

   [TTTPS]    Jorgen, H., "The TLS TimeToken Secure Protocol
              (tttps://)", Work in Progress, Internet-Draft, draft-
              helmprotocol-tttps-10, 2026,
              <https://datatracker.ietf.org/doc/draft-helmprotocol-
              tttps/>.

   [RFC4838]  Cerf, V., "Delay-Tolerant Networking Architecture",
              RFC 4838, April 2007,
              <https://www.rfc-editor.org/info/rfc4838>.

   [DEEPSPACEPAPER]
              Jorgen, H., "Deep-space companion research paper",
              SSRN 7487038, 2026, <https://papers.ssrn.com/sol3/
              papers.cfm?abstract_id=7487038>.

Author's Address

   Heime Jorgen
   Kenosian
   Email: heime.jorgen@proton.me

Jorgen                    Expires 23 March 2027                [Page 19]