[sinkog]

Documentation only: the storage and restore plan for the independent copy of the T3 time evidence (docs/en/T3-EVIDENCE-STORAGE-AND-RESTORE-PLAN.md). Nothing is uploaded. No provider, account, region, bucket or permission is chosen or approved, and no credential appears. The state of the second copy is and stays NOT BACKED UP until the conditions of section 8 are met. The plan does not touch the evidence directory it protects (#32), so the archive keeps what it was built from. Review does not authorize merge.

• What and why. The three RFC 3161 time stamps (v0.2.1, v0.2.0, v0.1.5) made on 2026-11-03 before the signing chain ends on 2026-12-31 ~13:22 UTC; they cannot be made again afterwards. The archive cic-primitives-t3-evidence-2026-11-03.tar.gz (721 205 bytes, SHA-256 e1795fcf...cddab5) holds the evidence directory, the git bundle verify.sh reads from, and the manifest with the original release commits; it was verified locally, offline, with every negative control caught. It lives in a temporary directory of one machine: not a backup. All data is public (public repository, public certificates and replies); a pattern scan of the unpacked text files and of the 167 commits of the bundle for token and key shapes found nothing (not a proof of absence; repeated before each upload). The requirement is integrity, availability and provenance, not confidentiality.
• What it has to survive: repository or account loss, loss of the one machine, accidental deletion or overwrite, a replacement with an altered archive, bit rot, the provider's account closed, obsolete tools years from now (offline, no original environment), and lost knowledge of how to restore.
• Requirements on the place (from the review): a failure boundary independent of GitHub; encryption in transit and at rest; controlled access (named principals, least privilege, MFA, a write identity apart from the read identity); versioning and immutability against deletion and overwrite; SHA-256 checked before and after, from the stored object; a documented recovery; a restore drill; an exit path.
• Candidate classes, none selected: an S3-compatible object store of another provider with versioning and Object Lock; offline write-once media in another place; a second git forge mirror (no immutability). Recommended shape: two copies of two classes.
• Chain of custody: a custody log (no credential), one row per copy and per verification, rows never edited.
• Procedures for the upload, the read-back by version id with the read identity, and the restore from the stored object only, offline, in a directory and user not used for the build; the archive carries the verifier, the trust anchor, the certificates and the git history, so no network and no original repository are needed; the OpenSSL version is the one dependency and the versions used at the build are recorded.
• Drill and cadence: the first drill is part of acceptance, by another person or at least another machine and account; the hash every six months, a full restore every twelve, and one before 2026-12-31 and one after the chain's end. States: NOT BACKED UP (today), UPLOADED (unverified), BACKED UP, BACKED UP (stale), BACKED UP (two classes).
• Eight decisions S1 to S8 for the owner (classification, classes, the concrete place and who may write and read, client-side encryption and key custody, retention and immutability, cadence, where the log lives, the DigiCert terms question); none is taken here.

Not claimed: that any copy exists beyond the repository and the temporary local archive; that any provider or account is approved; that the archive survives the listed failures; anything about the authenticity of a release.

Review round (2026-11-05): (1) The verifier needs more than OpenSSL. Taken from verify.sh itself and written into the plan: bash; openssl (3.0.13 used); git (2.43.0: init, fetch, bundle verify, cat-file, show); python3 with PyYAML (3.12.3, 6.0.1); GNU date -d, sha256sum, mktemp, cut, cat, cp, rm, printf, sed, env, dirname; find; cmp; tar and gzip; no network command (read in full). The earlier sentence that OpenSSL is the one dependency is removed. (2) The Git bundle restore is an explicit ordered procedure: archive hash, unpack, every file against ARCHIVE-VERIFY-MANIFEST.json, git init, git bundle verify, git fetch ... 'refs/*:refs/*', the three release commits reachable and the record hashes equal the manifest, then verify.sh --selftest from inside that repository. These eight commands were run once in a clean directory with a minimal PATH on the build machine as a dry run, not a restore drill from storage: archive hash OK, 18 of 18 files match, bundle verified, three commits reachable, v0.2.1 record hash equal, ALL CHECKS HOLD. The archive is not modified. (3) The reference must not live only in GitHub (the recorded hash, the custody log and the restore commands are also kept in an independent protected place, new decision S9; the restore commands are stored beside the archive as a separate small object with their own hash). The owner's positions on S1 to S8 are recorded in the plan; none selects a provider or approves an upload. New HEAD, so the gate check is needed again.