[sinkog]

What

The T3 decision of the trust model plan (cic-primitive-forms docs/P5-TRUST-MODEL-PLAN.md, section 4): independent evidence that the three signed records existed before the certificate chain that signed them ends on 2026-12-31. Data and a verification script only: no code, no change to the records, the verifier or the release branches.

Why this could not wait

Every certificate of the chain ends on 2026-12-31 (13:22 UTC for the three that matter), and the present verifier judges validity at the moment of checking, so from 2027-01-01 it refuses these records (measured, forms #149). Evidence of existence before the end has to be made before it. A token obtained in 2027 would show a date after the end.

What was done

Three RFC 3161 requests to the DigiCert public time-stamp authority (http://timestamp.digicert.com), one per record. Sent: a SHA-256 digest, the algorithm, a random nonce and a request for the TSA certificate: 70 bytes each. Nothing else left the machine.

Release	Record SHA-256	Stamp (UTC)
v0.2.1	e5d8268aede0d24f...	2026-11-03 22:07:48
v0.2.0	955fab2d6d9638c7...	2026-11-03 22:09:44
v0.1.5	284e44bfcf62d79f...	2026-11-03 22:09:45

Verified offline, before reporting (and the verification can fail)

• Each reply: Granted, the digest equals the request, the nonce equals the request (the reply belongs to it), the TSA certificate has the critical Time Stamping key usage.
• openssl ts -verify against the request, against the record file read from git at its release commit, and at the time of the stamp (not "now"): OK for all three.
• The trust anchor is the self-signed DigiCert Trusted Root G4 (valid to 2038), not the cross-signed copy the reply carries (valid to 2031). Its SHA-256, SHA-1 and serial were checked against two independent sources: the operating system store (Ubuntu ca-certificates) and the figures DigiCert publishes. All three values are equal.
• Negative controls, each refused: a record changed by one byte, a wrong anchor, a damaged reply, a request with another nonce, a time before the TSA certificate existed. One expectation of mine was wrong and is recorded rather than hidden: verification without the intermediates still passes, because the reply carries them and OpenSSL uses them; the anchor is what matters, and the wrong-anchor control proves that.
• verify.sh re-checks everything from the stored files and the git history, and --selftest re-runs the negative controls. verify.sh itself was shown to fail on a damaged token, a changed manifest, a replaced anchor and missing commits.

What it proves, and what it does not

Each digest existed no later than the stamped time, according to DigiCert, bound to the request and to the exact bytes of the record. It does not show who signed, that a signature was valid that day, that the signer was allowed, or that the release is genuine; it supplies the one piece that could not be made late. The rest of the plan (anchor policy, authority, revocation, an as-of verifier mode) is unchanged and still open.

Limits, written down in the README

• No terms of use for the public endpoint were found. The search and DigiCert's documentation pages state neither permission nor restriction for uses other than code signing. The decision named "the endpoint and the terms to be checked"; the endpoint works, the terms could not be confirmed. Only digests of public records were sent. Another authority needs a new decision.
• Plain HTTP (port 443 did not answer from that machine); the replies are signed, so the check does not depend on the transport.
• The time rests on DigiCert and on one root, checked against the operating system store and the publisher's page.
• The decision also asks for a second, independent copy; that is not done here. The GitHub repository is one copy; where the second lives is for the owner to name.

Merge is for the owner.