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

Network Working Group                                          H. Jorgen
Internet-Draft                                                  Kenosian
Intended status: Experimental                          29 September 2026
Expires: 2 April 2027

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

Abstract

   This document defines an experimental deep-space companion profile
   for the TLS TimeToken Secure Protocol (TTTPS).  It preserves the
   fixed Proof-of-Time core record and separates cryptographic validity
   from propagation-aware temporal applicability.  The profile binds
   physical context out of band, distinguishes one-way light time from
   two-way transaction delay, defines evidence and disposition
   boundaries, and composes peer aggregation with optional confidence
   qualification.  It does not claim flight performance, a live
   interplanetary mesh, or replacement of existing navigation or delay-
   tolerant networking standards.

Changes from -01

   Clarifies that optional L4 ingress filtering is an operational pre-
   parser measure and is outside the TTTPS disposition state machine.
   Specifies that peer observations absent after possible network loss
   remain missing evidence; when a policy-required effective quorum is
   not met, the result is HOLD rather than an inferred integrity or
   authentication failure.  Adds an evidence boundary distinguishing
   source inspection, mock controller execution, operator-reported
   canary deployment, and unmeasured live flood load.

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.

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

   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 2 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   4.  Deep-Space Verification Context . . . . . . . . . . . . . . .   4
   5.  Context Manifest Binding  . . . . . . . . . . . . . . . . . .   4
   6.  Propagation-Aware Tolerance . . . . . . . . . . . . . . . . .   5
   7.  Numeric and Diagnostic Guardrails . . . . . . . . . . . . . .   6
   8.  Coordinate-Time Adapter Boundary  . . . . . . . . . . . . . .   7
   9.  Position Source and Precision Policy  . . . . . . . . . . . .   7
   10. Verification Processing . . . . . . . . . . . . . . . . . . .   7
   11. Peer Projection and Aggregation . . . . . . . . . . . . . . .   8
   12. Confidence Qualification Boundary . . . . . . . . . . . . . .   9
   13. Scalar Aggregation Bound and Limitations  . . . . . . . . . .   9
   14. Failure Semantics and Recovery  . . . . . . . . . . . . . . .   9
   15. Optional External Framing and GRG Boundary  . . . . . . . . .  10
   16. Disposition Precedence  . . . . . . . . . . . . . . . . . . .  10
   17. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   19. Implementation and Evidence Status  . . . . . . . . . . . . .  11
   20. Normative References  . . . . . . . . . . . . . . . . . . . .  14
   21. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Appendix A.  Informative First-Order TCB Sensitivity
           Illustration  . . . . . . . . . . . . . . . . . . . . . .  15

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

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

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, field layout, or wire
   encoding of the selected TTTPS core record.  For the draft-11
   profile, the core record is 180 octets; implementations MUST verify
   the exact core version and record length before applying this
   profile.

   The base protocol is the TTTPS draft-11 specification [TTTPS].  This
   companion profile adds no fields to that fixed core record.

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, 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].

   ACCEPT:  all required predicates for the selected profile and
      application policy are established.

   HOLD:  a potentially recoverable condition currently prevents
      promotion or commit.

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

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

   REJECT:  a verified integrity, authentication, replay, or binding
      failure was found.

   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.

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.  Context Manifest Binding

   Let P be the exact 180-octet core bytes and D_P = SHA-256(P).  The
   issuer MUST allocate a 16-octet context identifier before core
   issuance and bind it through the authenticated core record.  Let M0
   be the versioned canonical manifest body containing that context
   identifier and D_P, but excluding its own digest and any later
   receipt that refers to the digest.  For a declared canonical encoding
   C_v, compute D_M = SHA-256(C_v(M0)).  The encoding identifier,
   immutable generation identifier, D_M, and later receipt link are
   carried in a detached digest envelope.  The context identifier MUST
   NOT be derived from D_M when M0 contains D_P for a core record that
   itself contains the context identifier; that construction is
   circular.  Self-hashing alone does not authenticate the envelope; its

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

   issuer or transport binding MUST be authenticated independently.

   The manifest MUST identify the profile/version, core digest, context
   and correlation identifiers, observation and node identifiers, event
   and receive epochs, time scale and reference frame, position source
   and revision, position/velocity values and uncertainty, range and
   OWLT uncertainty, transform revision, peer roster and fault bound,
   application policy, optional corruption-profile identifier, and
   parent-generation link.  The selected profile MUST define
   serialization, units, and normalization before claiming
   interoperability.  A verifier MUST reject digest or generation
   mismatch.  Missing authenticated mapping evidence yields
   UNVERIFIABLE; a verified mismatch yields REJECT.  Binding establishes
   evidence association, not physical accuracy.

   A decision receipt SHOULD include the per-axis statuses, stable
   reason code, uncertainty budget, evidence digest, transition
   identifier, policy revision, and the core, manifest, and confidence-
   snapshot generation identifiers.  Reassessment MUST create a new
   transition; it MUST NOT overwrite a historical disposition.

6.  Propagation-Aware Tolerance

   An implementation MAY use the one-way or two-way reference budget
   shown above, provided the selected terms match the actual message
   path and declared uncertainty model.

           One-way event budget:
             T_oneway = T_base + t_ij_owlt + U_propagation
                         + U_clock + U_queue

           Two-way transaction budget:
             T_roundtrip = T_base + t_ij_owlt + t_ji_owlt
                           + T_processing + T_queue + U_exchange

   The outbound and inbound OWLT values are distinct inputs.  An
   implementation MUST NOT infer either value as one half of a measured
   round-trip time unless a versioned policy explicitly declares and
   justifies link symmetry.  The expression T_base + 2 * t_owlt is a
   round-trip illustration only; it MUST NOT be applied as a universal
   one-way freshness rule.  The selected budget and its inputs MUST be
   bound to the context and MUST NOT exceed the application safety
   bound.

   For operational geometry, the one-way light-time is derived from a
   retarded-time relation in a common declared frame:

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

           t_r - t_e = ||x_r(t_r) - x_e(t_e)|| / c
                       + Delta_rel + Delta_media + Delta_model

   The fixed-distance expression d/c is a deterministic scale fixture,
   not a complete operational propagation model.  The profile MUST
   separately account for a conservative propagation uncertainty bound:

           U_prop = U_r/c + |r_dot| U_epoch/c
                    + U_interp + U_frame + U_rel + U_asym + U_model

   Root-sum-square combination is permitted only for components with
   justified independence and a declared statistical model.  Unknown
   correlation and common-mode terms remain additive.  The application
   declares B_application; it is not a protocol-wide constant.

   Propagation consistency MUST be evaluated separately from application
   freshness.  Let t_hat_r = t_e + t_OWLT and rho = t_r,observed -
   t_hat_r.  The profile policy MUST define a consistency bound and a
   hard contradiction bound.  A residual within the consistency bound is
   propagation-consistent; a residual between the bounds yields HOLD; a
   residual beyond the hard bound yields REJECT only when the model and
   authority evidence make the contradiction verifiable.  Application
   freshness is evaluated independently, so an event may remain valid
   historical evidence but be ineligible for a current state-changing
   action.

   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.

   Higher-order or D3-style residual diagnostics are informative shadow
   signals.  A residual anomaly MAY request more evidence or cause HOLD,
   but MUST NOT alone cause REJECT, establish physical truth, or replace
   core integrity and admission checks.

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

8.  Coordinate-Time Adapter Boundary

   A coordinate-time conversion used by this profile MUST identify the
   source and target time scales, frame, reference epoch, observer state
   or worldline inputs required by the selected convention, ephemeris
   authority and revision, adapter implementation and revision, output
   uncertainty, and validity interval.

   This profile does not define a replacement TCB, TDB, TCG, TT, or TAI
   transformation.  An implementation MUST use a declared, versioned
   convention or adapter.  A missing required input, unsupported scale/
   frame pair, or output uncertainty outside the application budget MUST
   result in HOLD or UNVERIFIABLE under the declared policy.  Adapter
   success alone does not establish navigation truth or flight
   qualification.

   Large absolute integer epochs SHOULD remain integer-valued across the
   adapter boundary.  Floating-point arithmetic MAY be used for a
   declared correction if the rounding rule is specified and the
   correction is applied without treating the full absolute epoch as
   losslessly representable.

9.  Position Source and Precision Policy

   Position is evidence-bearing input.  A deployment MAY select among
   authenticated GNSS, X-ray pulsar navigation (XNAV), neighbour
   ranging/multilateration, and analytic ephemeris according to declared
   authority and applicability policy.  Every selected source MUST carry
   its source identity, frame, epoch, validity interval, uncertainty,
   and authority status.  Incompatible frames MUST NOT be merged because
   their vectors have the same dimension.

   An analytic ephemeris may support coarse propagation while being
   inadequate for a precision-sensitive relativistic correction.  If a
   declared ephemeris position-error bound divided by c exceeds the
   application-scaled precision budget, the precision-sensitive
   correction MUST be suppressed or downgraded and the reason recorded
   as HOLD or UNVERIFIABLE; it MUST NOT be replaced by an assumed
   authoritative position.

10.  Verification Processing

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

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

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

   2.  authenticate the context identifier and manifest generation;

   3.  validate time scale, frame, epoch, authority, and policy;

   4.  derive or validate OWLT and its uncertainty envelope;

   5.  evaluate propagation applicability and application-specific
       freshness;

   6.  authenticate peer observations, collapse declared common
       provenance, and compute effective population and quorum;

   7.  project comparable observations to a common epoch and apply the
       declared robust aggregation;

   8.  evaluate optional confidence qualification and the policy commit
       boundary;

   9.  emit a typed disposition, reason, evidence digest, and append-
       only receipt.

   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.

   A peer observation that is absent, including one that may have been
   lost before reaching the verifier, is missing evidence.  If the
   selected policy requires quorum q and the admitted effective
   population N_eff is below q, the verifier MUST return HOLD (or the
   selected Confidence profile equivalent) and MUST NOT infer a
   signature, integrity, or context contradiction solely from that
   absence.  An independently received observation that fails
   cryptographic verification remains subject to the core REJECT rules.

11.  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.

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

   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.

   When N < 3, this profile makes no Byzantine-fault-tolerance claim.
   Under f < N/2, N=2 permits f=0 only.  A deployment MAY define an
   Anchored Holdover Estimator as a separate degraded profile with
   explicit anchor authority, age, clock-stability, drift, and maximum
   duration.  Holdover is not a second agreement algorithm and does not
   make an untrusted peer an honest anchor.

12.  Confidence Qualification Boundary

   When the separate Confidence profile is selected, its inputs MUST
   refer to the same context identifier, observation generation,
   admitted roster, and policy revision used for physical-applicability
   evaluation.  Provenance collapse and effective quorum precede
   construction of confidence statistics.  Missing aligned correlation
   data MUST be reported as unavailable; it MUST NOT be encoded as zero
   correlation.

   The Epi analyzer is read-only with respect to the core record and
   prior receipts.  A policy evaluator MAY consume current Epi or
   InsufficientKnowledge evidence to withhold a new state-changing
   commit and return HOLD.  Epi and AdaptiveSwitch MUST NOT authenticate
   a record, repair missing physical authority, or retroactively alter a
   prior decision.  The detailed confidence contract is defined in the
   Confidence companion profile [CONFIDENCE].

13.  Scalar Aggregation Bound and Limitations

   For scalar observations with N admitted effective identities and at
   most f Byzantine observations, a median lies within the interval
   spanned by the honest observations when f < N/2.  This bound assumes
   the declared effective-identity mapping and does not establish peer
   independence, agreement among verifiers, liveness, or physical
   correctness.

   A deployment MUST declare the fault bound and use the effective
   population after provenance collapse.  Shared clocks, ephemerides,
   detectors, software, relays, or administrative authorities MUST be
   recorded as possible common sources.  A median does not remove
   shared-source error.

14.  Failure Semantics and Recovery

   ACCEPT:  all required predicates for the selected profile and

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

      application policy are established.

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

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

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

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

15.  Optional External Framing and GRG Boundary

   This profile does not change the fixed PoT core record and does not
   define GRG code parameters.  A deployment using GRG MUST select and
   authenticate a separately specified profile revision, protected byte
   domain, framing, decoder limits, and result contract.  The 180-octet
   core MUST NOT be presumed to be a GRG codeword stream merely from its
   length.

   An external framing or integrity decoder MUST establish the declared
   core byte domain before the TTTPS core parser consumes it.  An
   unresolvable external-decoder result MUST NOT be promoted by physical
   applicability, confidence, or application policy.  This document
   makes no codepoint assignment.

16.  Disposition Precedence

   The verifier MUST apply disposition precedence deterministically.  A
   core integrity, authentication, replay, or verified binding failure
   yields REJECT.  Missing required authority or unreconstructable
   context yields UNVERIFIABLE.  Evidence that is potentially
   recoverable but currently insufficient yields HOLD.  ACCEPT is
   permitted only when every required predicate for the selected profile
   and application policy is established.

   Confidence, aggregation, or a later retry MUST NOT promote a prior
   REJECT.  A prior HOLD or UNVERIFIABLE result remains part of the
   record; reassessment uses fresh or revalidated evidence and creates a
   new receipt.

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

17.  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.

   An implementation MAY deploy an L4 ingress filter, including XDP/
   eBPF, as an optional operational mitigation strictly before the TTTPS
   core parser.  It imposes no protocol implementation requirement, has
   no visibility into TLS-encrypted agent contexts or the 180-octet PoT
   fields, and MUST NOT be used to derive OWLT, propagation uncertainty,
   peer provenance, or physical applicability.  A source-IP bucket is a
   traffic key, not an authenticated principal or effective peer
   identity; NAT, address sharing, spoofing, and distributed sources can
   affect its meaning and effectiveness.

   A packet discarded by such a pre-parser filter does not enter the
   TTTPS verification state machine and MUST NOT produce a TTTPS
   disposition, reason code, or verification receipt.  If the resulting
   observation loss prevents a policy-required quorum, the verifier
   applies the missing-evidence and HOLD rule in Section 8; packet loss
   alone is not evidence of a cryptographic contradiction.

18.  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.

19.  Implementation and Evidence Status

   The integrated research paper is a single work also deposited on more
   than one platform; this profile cites its SSRN record, abstract
   7487038 [DEEPSPACEPAPER].  The earlier V1 manuscript already
   described a fixed core with out-of-band context, one-way and round-
   trip light-time, asymmetric links, relative TCB correction, peer
   median aggregation, and separate confidence signals.  This document
   does not claim those concepts as new or claim empirical superiority

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

   over V1.  Its narrower refinement is a typed, generation-bound
   admission contract and explicit evidence boundary.

   The V9 paper reports successful execution of the official SOFA C
   Issue 2023-10-11 validation target and a CSPICE N0067 UTC-to-ET
   fixture.  The NAIF example at 2003-12-19T16:48:00Z matched the
   published ET value at printed precision; the selected positive leap-
   second sequence had adjacent one-second ET intervals.  These results
   validate the named libraries and fixtures only.  The designated
   project adapter at openttt-server@1a4c058 was not built or invoked,
   and the frozen IERS TN36 Chapter 10 adapter mapping was not run.
   Accordingly, library-level checks are reported as passed, while
   profile E07 adapter conformance remains incomplete and MUST NOT be
   represented as passed.

   A separate 13-epoch JPL Horizons Mars-barycenter/Earth-geocenter
   retarded-time regression reported a maximum equation residual of
   54.50 ns and a maximum vector difference of 1.67 m against a Horizons
   light-time-corrected vector.  This is a planetary ephemeris
   regression, not a spacecraft trajectory, mission-specific correction
   validation, X-ray detector result, or flight measurement.  The
   paper's V4 XNAV run is a static synthetic four-state solver using
   four SEXTANT target directions, with condition number 5.4553 and
   5,000 trials at each of 1 ns, 10 ns, 100 ns, and 1 microsecond TOA
   noise.  Reported position-error p95 values are 1.205 m, 12.262 m,
   121.272 m, and 1,202.599 m, respectively.  With one pulsar removed,
   the four-state system has rank 3; adding a clock-drift unknown to the
   four-observation system is also underdetermined and therefore
   UNVERIFIABLE without additional measurements or priors.  These are
   model-specific solver results, not navigation or detector validation.

   The paper identifies openttt-server@1a4c058 as the project-designated
   production server-side GRG implementation and @helm-protocol/ttt-
   mcp@0.4.7 as containing a GRG-facing schema and call path.  Those
   implementation facts are not denied by the independent-reference
   boundary.  The V9 candidate profile separately reports 4/4 top-level
   assertions, recovery of 15/15 four-of-six shard subsets, 240/240
   tested one-to-three-bit-per-Golay-word frames, zero accepted wrong
   payloads in 100 four-bit boundary challenges, and zero accepted wrong
   payloads across 1,280 burst frames.  These are candidate-reference
   results; the paper does not report a production-server build-to-
   candidate byte comparison or production known-answer interoperability
   run.  That missing comparison is not evidence that the designated
   production implementation is absent or nonfunctional.

   The V9 integrated registry uses E01-E16.  E08-E10 and the V4
   reference rows are attributed in the paper to run TTTPS-DSV4-REF-
   20260926-R1 under validation/v4-reference-run-20260926/; the

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

   SOFA/CSPICE/Horizons and candidate GRG supplement is identified under
   validation/v7-strict-execution-20260928/. Those are paper-reported
   artifact locations and run identity, not artifacts bundled with this
   Internet-Draft.  Its reported execution map is: E01, E02, E04, E06,
   E11, and E13-E16 not tested in the packaged run; E03 partial
   deterministic distance arithmetic; E05 tested range-error-to-time
   arithmetic; E07 library fixtures passed but project-adapter/IERS
   mapping not executed; E08 synthetic solver closure; E09 four XNAV
   noise scales with 5,000 trials each; E10 160,000 synthetic scalar-
   median cases; and E12 an independently tested candidate GRG pipeline,
   with production interoperability not observed.  E08 reports a 3.98 x
   10^-13 m algebraic closure residual.  E09 p95 values are 1.205 m,
   12.262 m, 121.272 m, and 1,202.599 m at 1 ns, 10 ns, 100 ns, and 1
   microsecond, respectively.  These entries describe the V9 paper's
   evidence mapping, not a new execution by this draft.

   The integrated paper's legacy test-ID crosswalk is semantic only: its
   earlier E05 time-scale-adapter label maps to current E07, while its
   earlier E07 ephemeris-residual label maps to current E05.  No old
   pass count transfers across that crosswalk.  The paper also reports a
   public read-only KPP receipt check, but no deep-space manifest
   submission, Confidence snapshot, GRG decoder invocation, or complete
   draft-11 admission trace; those API observations are not profile test
   results.

   For reproducibility, the paper's independent candidate GRG reference
   uses byte-oriented Golomb-Rice k = 4; systematic Vandermonde RS(6,4)
   over GF(256) with primitive polynomial 0x11d and evaluation points 1
   through 6; cyclic Golay (23,12,7), generator 0xAE3, identity
   interleaving; and 32-byte HMAC-SHA256 over domain-separated canonical
   metadata and all six canonical shards.  These candidate parameters
   and test results are informational reference evidence only.  They are
   not asserted to be the production server's byte profile, adopted by
   draft-11, or assigned a codepoint here.  The specified four-of-six RS
   candidate tolerates at most two erasures; per codeword its declared
   bound is 2e+s <= 2.

   The paper reports no completed full-profile E07 adapter conformance,
   production GRG interoperability measurement, spacecraft-specific
   trajectory validation, flight X-ray detector operation, target-
   hardware PTP/FPGA result, live interplanetary mesh, or independent
   external reproduction.  Historical suite totals and conflicting A0-A5
   cohorts remain reported-only because raw cell outputs and manifests
   were unavailable; they are not current results and MUST NOT be
   combined.  Confidence and D3 are separate optional qualification/
   diagnostic layers.  D3 remains shadow-only and MUST NOT independently
   reject or promote a record.  See the V9 paper for the complete run
   identities, tables, and limitations [DEEPSPACEPAPER].

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

   The related TTT-MCP ingress component is recorded only as deployment
   evidence, not as a Deep-space profile test.  In the inspected source
   snapshot openttt-mcp@e60bae0, the XDP program handles IPv4 TCP
   destination ports 8443 and 8090, maintains aggregate port buckets and
   source-IP buckets, and returns XDP_DROP when the configured packet
   window is exceeded; the generic-XDP loader and systemd units are
   present.  The packet-Epi controller was executed against mocked BPF-
   map fixtures: a 12,000-packet, one-source fixture produced 0.0 bits
   and a 5,000-packet ceiling; a 24,000-packet, four-equal-source
   fixture produced 2.0 bits and a 20,000-packet ceiling.  These results
   exercise controller policy and mock map updates, not kernel packet
   drops.  The operator reports a separate canary revision c5f7bda
   attached in generic XDP mode on ens4 with systemd active.  These are
   respectively source-observed, mock-tested, and deployment-reported
   evidence.  No preserved live flood/DDoS traffic artifact or kernel
   drop-load benchmark is included here; live flood-load effectiveness
   is NOT MEASURED.  None of these items establishes OWLT accuracy,
   physical applicability, or flight performance.

20.  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>.

21.  Informative References

   [TTTPS]    Jorgen, H., "The TLS TimeToken Secure Protocol
              (tttps://)", Work in Progress, Internet-Draft, draft-
              helmprotocol-tttps-11, 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., "Interplanetary Time Attestation Under Light-
              Time Delay", SSRN 7487038, 2026,
              <https://papers.ssrn.com/sol3/
              papers.cfm?abstract_id=7487038>.

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

   [CONFIDENCE]
              Jorgen, H., "Oracle Confidence Gating for TTTPS: G-Score,
              Correlation-Aware von Neumann Confidence, and
              AdaptiveSwitch", Work in Progress, Internet-Draft, draft-
              helmprotocol-confidence-02, 2026,
              <https://datatracker.ietf.org/doc/draft-helmprotocol-
              confidence/>.

Appendix A.  Informative First-Order TCB Sensitivity Illustration

   The following V1 engineering expression is retained only as a first-
   order magnitude illustration.  It is not a standards-defined TCB
   transformation and MUST NOT be used as a normative coordinate-time
   conversion or adapter-conformance claim.

           t_B,TCB = t_A,TCB + (tau_B - tau_A)
                     * (1 + Phi_rel/c^2 + v_rel^2/(2*c^2))

           E_route <= E_0 + sum_h(
             E_h,clock + E_h,range + E_h,model + E_h,round)

   A deployed transformation requires its declared convention, frame,
   epoch, worldline/state, authority, implementation revision, output
   uncertainty, and validity interval.  Range-rate is not a substitute
   for barycentric velocity.

Author's Address

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

Jorgen                    Expires 2 April 2027                 [Page 15]