INTERNET-DRAFT J. Fassbender Intended Status: Informational Umarise Expires: October 5, 2026 April 5, 2026 External Time Anchor Profile for SCITT Transparency Services draft-fassbender-scitt-time-anchor-00 Abstract SCITT Transparency Services record signed statements in append-only logs and issue receipts that include an internal timestamp derived from log inclusion. This timestamp depends on the service operator's own clock and log infrastructure. It cannot be independently verified by a party that does not trust the operator. This document defines an optional, additive profile that attaches an externally verifiable time anchor to an existing Origin Record. The anchor is a standard OpenTimestamps (.ots) proof ultimately committed to the Bitcoin blockchain. The resulting proof is self-contained and portable: it can be verified by any party holding the original file and the .ots proof, without contacting the Transparency Service, the anchoring service, or any trusted authority. No changes to SCITT protocols, signed statement formats, or receipt structures are required. 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 October 5, 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. 1. Introduction The IETF SCITT Working Group has defined architecture and building blocks for signed statements, receipts, and transparency services [SCITT-ARCH]. The working group deliberately left the underlying time source for Transparency Services open, relying primarily on the service operator's log for ordering and freshness. This design is appropriate for the primary SCITT use cases. However, a gap exists: SCITT receipts include a timestamp that is internal to the Transparency Service and is not derived from an independent external authority. Parties that do not trust the operator cannot independently verify when a statement was made. This document does not attempt to standardize external time sources, but to describe one concrete profile that can be used alongside existing SCITT deployments. This document addresses that gap by defining an External Time Anchor Profile. The profile is: Optional. No existing SCITT deployment is affected. Additive. It supplements existing receipt structures without modifying them. Independent. Verification is independent of any single operator or authority, based on Bitcoin consensus. Portable. The proof survives discontinuation of any service, including the anchoring service. 1.1. Relationship to RFC 3161 RFC 3161 [RFC3161] defines how a trusted Time-Stamping Authority (TSA) issues Time-Stamp Tokens to provide proof of existence at a specific time. RFC 9921 [RFC9921] defines how such tokens can be embedded in COSE structures aligned with SCITT. These are referenced here as prior art and for architectural context only. The two approaches differ in trust model. The TSA model requires trusting a designated authority and depends on that authority's continued operation. The profile defined here uses Bitcoin's proof-of-work consensus as the time bound: no authority is required to verify the proof, and the proof remains valid regardless of whether any service continues to operate. The approaches are architecturally complementary. Interoperability between this profile and RFC 3161 / RFC 9921 is not defined in this document. The semantic claim is identical in scope: the exact byte sequence existed no later than the moment of ledger inclusion. The difference is not what is claimed, but who must be trusted to verify it. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Terminology Origin Record: A record in a Transparency Service attesting that a specific hash was registered at a specific time. Time Anchor: A cryptographic proof binding a hash to a Bitcoin block, providing an upper bound on the time at which the hash existed. OTS proof: A standard OpenTimestamps proof file (.ots) as defined by the OpenTimestamps project. Bitcoin block The timestamp field of a Bitcoin block header, timestamp: accurate to within approximately two hours per consensus rules. Self-contained proof: A proof verifiable without contacting any online service. ------------------------------------------------------------------------ 2. The Gap SCITT receipts convey a time of log inclusion via a COSE countersignature. This time is: 1. Set by the Transparency Service operator. 2. Not derived from an independent external authority. 3. Not verifiable by a party that does not trust the operator. As confirmed by the SCITT Working Group, this is a known property of the current architecture, and operator-independent timestamping is outside the current working group charter. The gap matters in adversarial settings -- disputes, litigation, audit, regulatory examination -- where the party presenting evidence and the party operating the Transparency Service may be the same, or may be in conflict. In these settings, a receipt whose timestamp originates from the operator's own infrastructure is circular evidence. ------------------------------------------------------------------------ 3. External Time Anchor Profile 3.1. Overview The External Time Anchor Profile defines how to attach an OTS proof to an Origin Record, as specified in [IEC]. The OTS proof commits the SHA-256 hash of the original artifact to a Bitcoin block via a Merkle tree. Once the relevant Bitcoin block has sufficient confirmation depth, the proof can be independently verified. The profile does not modify any existing SCITT data structure. It defines an optional proof artifact that may accompany an Origin Record. 3.2. Proof Construction 1. Compute SHA-256(artifact) [FIPS180-4] on the client. The artifact bytes do not leave the originating device. 2. Submit the hash to an OTS calendar server. The calendar aggregates multiple hashes into a Merkle tree and commits the root to Bitcoin. 3. After Bitcoin confirmation (typically 10-20 minutes, 1-2 blocks), retrieve the completed .ots proof file. 4. The .ots proof file [OTS], together with the original artifact, constitutes a self-contained time anchor. 3.3. Proof Properties The completed proof establishes the following: o The SHA-256 hash of the artifact was committed to a Merkle tree no later than the timestamp of the Bitcoin block in which the root was included. o Bitcoin block timestamps are set by miners and can deviate from wall clock time by up to approximately two hours per Bitcoin consensus rules. The proof therefore provides an upper bound, not a precise timestamp. o The proof is verifiable by anyone holding the original artifact and the .ots file, using the OpenTimestamps CLI or any compliant verifier, without contacting the anchoring service. What this proof does not establish: Authorship. The proof establishes that a specific hash existed, not who created the artifact. Uniqueness. Earlier attestations of the same hash may exist. Semantic meaning. The proof is context-blind. What the hash represents is defined by whoever created it. 3.4. Verification Verification requires three inputs and no online dependencies: V(artifact, proof.ots, bitcoin_chain) -> valid | invalid Command-line verification: ots verify proof.ots -f artifact Or using a client-side verifier (zero network dependency on the anchoring service, queries Bitcoin directly via block explorers). 3.5. Self-Contained Distribution The proof artifact SHOULD be distributed as a ZIP archive containing: o certificate.json -- origin record metadata (hash, captured_at, bitcoin_block_height, origin_id) o proof.ots -- the OTS proof file o VERIFY.txt -- plain-text verification instructions This archive is the complete, self-contained proof. It verifies without any service, account, or login. ------------------------------------------------------------------------ 4. Relationship to SCITT Architecture This profile operates at a layer below SCITT's transparency log. It can be used independently of SCITT, or in combination with it. When used in combination: o The SCITT receipt provides the operator's log inclusion proof and internal timestamp. o The External Time Anchor provides the operator-independent time bound. o The two are complementary. Neither invalidates the other. No changes to SCITT protocols are required. A SCITT Transparency Service may optionally reference an External Time Anchor in statement metadata, but this is not normative. ------------------------------------------------------------------------ 5. Security Considerations 5.1. Bitcoin Block Timestamp Accuracy Bitcoin block timestamps are set by miners and must satisfy the median time past rule. They can deviate from UTC by up to approximately two hours within consensus. The time bound established by this profile is therefore accurate to approximately two hours, not to the second. Applications requiring higher temporal precision should use additional mechanisms. 5.2. Merkle Aggregation and Batching OTS calendars batch multiple hashes into a single Merkle tree before committing to Bitcoin. The aggregation window is typically seconds to minutes. The resulting proof covers all hashes in the batch. This does not affect the validity of any individual proof. 5.3. Confirmation Depth A proof anchored to a Bitcoin block with low confirmation depth is subject to chain reorganization. For most use cases, 1-2 confirmations (10-20 minutes) is sufficient. Applications requiring high assurance SHOULD wait for 6 or more confirmations. 5.4. OTS Calendar Availability The OTS calendar is required only during proof construction, not during verification. If the calendar is unavailable, proof construction must wait. Verification of completed proofs is unaffected. 5.5. Hash Function This profile specifies SHA-256. Artifact hashing is performed client-side. No artifact bytes are transmitted to any service. ------------------------------------------------------------------------ 6. IANA Considerations This document has no IANA actions. ------------------------------------------------------------------------ 7. References 7.1. Normative References [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-4, August 2015. [IEC] Fassbender, J., "Anchoring Specification v1.0", anchoring-spec.org, 2026. [OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", opentimestamps.org, 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. Referenced for architectural context as prior art in operator-independent timestamping. [RFC9921] Tschofenig, H., "COSE Header Parameter for Timestamp Tokens as Defined in RFC 3161", RFC 9921, 2024. Referenced for context on COSE-based timestamp embedding. [SCITT-ARCH] IETF SCITT Working Group, "An Architecture for Trustworthy and Transparent Digital Supply Chains", draft-ietf-scitt-architecture (work in progress). [verify-anchoring] Reference verifier, verify-anchoring.org, 2026. ------------------------------------------------------------------------ Appendix A. Example Verification Output $ ots verify proof.ots -f artifact.jpg Assuming target timestamp of 1707394920 Got 1 attestation(s) from cache Success! Bitcoin block 881234 attests existence as of 2026-02-08 14:22:00 UTC ------------------------------------------------------------------------ Appendix B. Mapping to SCITT Terminology +----------------------+------------------------------------------+ | SCITT concept | This profile | +----------------------+------------------------------------------+ | Statement | SHA-256 hash of artifact | | Receipt timestamp | Internal, operator-controlled | | Time anchor | OTS proof committed to Bitcoin | | Verification trust | Bitcoin consensus (no authority needed) | | Portability | Self-contained ZIP, survives any service | +----------------------+------------------------------------------+ ------------------------------------------------------------------------ Author's Address Jonna Fassbender Umarise Email: j.fassbender@umarise.com URI: https://umarise.com ------------------------------------------------------------------------ This Internet-Draft will expire on October 5, 2026. This document is an individual submission to the RFC Series via the Independent Submissions Editor (ISE) stream. It does not represent IETF consensus or SCITT Working Group endorsement. Comments welcome via the SCITT WG mailing list or GitHub (ietf-wg-scitt/draft-ietf-scitt-architecture).