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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 21. Informative References [TTTPS] Jorgen, H., "The TLS TimeToken Secure Protocol (tttps://)", Work in Progress, Internet-Draft, draft- helmprotocol-tttps-11, 2026, . [RFC4838] Cerf, V., "Delay-Tolerant Networking Architecture", RFC 4838, April 2007, . [DEEPSPACEPAPER] Jorgen, H., "Interplanetary Time Attestation Under Light- Time Delay", SSRN 7487038, 2026, . 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, . 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]