[Question] Canonical root 1→root 10 manual-transition procedure and immutable evidence

[seungchan2568]

Hello Sigstore community,

We are preparing a read-only, offline evidence review for the Sigstore TUF root
1→root 10 transition. We found the official installation requirement to begin
from root 10 and manually verify it against the root 1 public-ceremony context,
but the historical official sources below appear to be only partial candidates.
We do not want to infer an executable procedure from generic TUF rules or from
signing implementation history.

Could the root-signing maintainers/keyholders please point us to the canonical,
issuer-approved procedure and evidence source set? Please answer with official
immutable locators and evidence identities where available; a transient personal
or chat assertion is not sufficient for our review.

Candidate context (locator/provenance only; not root bytes or trust evidence):

• issue Bump actions/checkout from 4.0.0 to 4.1.0 #329: bug: python-tuf incompatibility because of hex-encoded ECDSA keys root-signing#329
• PR update github tokens #380: part 4: allow signing with multiple TUF format root-signing#380
  (merge d367c90da9f3842496419b103429badaaa7a3d7b)
• PR Update the codeql version from ancient to current #490: Update Root and Targets to version 5 root-signing#490
  (merge 991e36c6014571e5883f3c92a97ccb301a3f4aa0)
• PR Bump the actions group with 2 updates #508: Update python-tuf tests for v5 root root-signing#508
  (merge 629ccb6f53a759817b4b18247fd2d7308b77adef)
• PR move blog to workflow instead of branch-based publishing #617: cleanup: remove deadcode from hex public keys root-signing#617
  (merge 0496f2be0dfd3bc0078e0ee50e8dd642e8d0da27)
• issue #923: [V8 signing] Update key type to "ecdsa" root-signing#923
• PR #1323: Signing event: sign/migration root-signing#1323
  (merge 67d03664f9b4ab6f8dc85998ed3c453818ecadd8)
• docs path commit: sigstore/docs@8467db8
• docs requirement commit: sigstore/docs@53da8e2

Please address these five evidence groups separately:

1. Authoritative source set and scope

   • What canonical Sigstore issuer-approved URL(s), immutable revision/commit/blob
     or release identity, and procedure content hash govern root 1→root 10?
   • Does the source cover root 1→root 5, root 5→root 9, and root 9→root 10 as
     distinct transitions, and which portions are not ordinary sequential updates?

2. Exact inputs and custody

   • What are the exact root 1, root 5, root 9, and root 10 filenames, byte lengths,
     and content SHA-256 identities used by the manual procedure?
   • Which official custody path, independent digest/witness channel, receiver,
     and retention boundary bind those inputs without relying on a public locator?

3. Ordered manual algorithm and outcomes

   • Please publish or point to the exact ordered steps, including canonicalization,
     keyid derivation, role keyids, thresholds, signature-set selection, and
     predecessor/successor mapping.
   • What are the expected pass outputs, failure/rollback/exception rules, and
     evidence that distinguishes the backward-incompatible transition from a
     generic N→N+1 TUF update?

4. Independently qualified tool identity

   • Which parser, canonicalization, hash, signature/crypto, or equivalent tool is
     endorsed for this manual check? Please provide immutable version/build identity,
     provenance, and the source that qualifies it for this purpose.
   • Is the tool qualification independent of the byte-delivery and signing control
     plane, and what must be recorded to detect tool/input drift?

5. Transcript, review, and custody evidence

   • What immutable successful/failed transcript, reviewer decision, exception or
     rollback record, sender/receiver/witness identity, and custody handoff evidence
     are required and where is the canonical retention location?
   • Which facts are public, and which must remain out of a public request because
     they contain secrets, private keys, credentials, or personal data?

We will treat a response as transition evidence only when it identifies the
authoritative source(s) and supplies or points to immutable evidence for all five
groups. A partial official response that supplies at least one canonical immutable
locator or evidence item and explicitly leaves named gaps unresolved is still
useful for a later evidence preview, but does not qualify the transition or root
10. A response that explicitly confirms that no canonical procedure/evidence
exists is useful only as a bounded blocker confirmation and does not qualify root
10. A generic TUF explanation, an unpinned mutable link, a personal assertion, or
a chat-only answer without an immutable official publication will not be accepted
as transition evidence.

This is a request for clarification only. No root, metadata, key, target, artifact,
or ceremony bytes are attached or requested for this post, and no trust or release
qualification is being claimed.