Document runtime-confirmed CI signer selection and crypto reuse

docs/ci-validate-file-object.md

@@ -1,8 +1,9 @@
 # CiValidateFileObject: validation flag 0x00000020
 
-Issue #3 is **documented; kernel runtime verification is pending**. The probe
+Issue #3 is **documented; its TESTSIGNING-off runtime experiment is pending**.
-builds and its plumbing is covered by host tests, but those tests do not execute
+A related signer-selection experiment has now run successfully on Windows 11
-Windows Code Integrity. Do not close the runtime-testing portion on that basis.
+22631 with TESTSIGNING enabled (below). That run does not close the requested
+19041/19045 flag 0 versus 0x20 TESTSIGNING-off comparison.
 
 ## Meaning supported by the evidence
 
@@ -181,6 +182,41 @@ Self-signed acceptance must be reported explicitly, not confused with public-CA
 publisher trust. Do not use this flag as a new production default based only on
 one positive fixture.
 
+## Multiple signatures: a separate kernel experiment
+
+`0x20` is an accepted-root control, not a recovered "PE image" type flag.
+In the examined 22621.2792 and modern 26100 x64 bodies it leaves the
+preferred-signing-level search active. `PolicyInfo` can therefore describe a
+nested Microsoft signature even when the primary company signature also verifies.
+
+The first-success guard tests aggregate masks `0xE47FFF87` (22621.2792) and
+`0xE41FFF87` (modern 26100). `0x20` intersects neither; `0x80` intersects both.
+Compare flags `0x20` versus `0xA0`, requested signing level zero, on the same
+stable dual-signed file. Record the actual selected leaf/thumbprint, both policy
+statuses and signing time. Do not interpret status success alone as selection
+of the company certificate. First successful does not necessarily mean first
+listed: CI may reject the primary and continue.
+
+`0x80` has additional policy and fallback effects. It has not been published as
+a supported Domito constant or a production default. The companion research
+`SIGNATURE-SELECTION.md` provides the full static evidence and an alternative
+primary-signature path using `CiCheckSignedFile`.
+
+A user-run kernel probe on Windows 11 **10.0.22631 x64**, CI options **0x00080207**
+(TESTSIGNING enabled), confirms the selection difference for the exact dual-signed
+BthPS3 fixture: `0x20` returns Microsoft, while `0xA0` returns the Nefarius leaf
+`FF0CCF318FD8C14775023A0B52C28FFCCA59D7F7` and signing time
+**2026-10-02T18:32:01.000Z**. Direct primary SHA-256 `CiCheckSignedFile` returns
+the same Nefarius leaf, signer/timestamp policies and signing time. All three
+calls return STATUS_SUCCESS; all policy VerificationStatus fields also succeed.
+The file digest is identical across calls, before/after file hashes match, and
+TraceFmt reports 149 events with no losses, format errors or unknown formats.
+
+The companion `signature-selection/runtime-22631-bthps3.json` records exact
+trace hashes and the on-disk CI hash. This is one test-signing-enabled run;
+TESTSIGNING-off, other builds/policies and general signature enumeration remain
+unverified. `0xA0` does not mean "select any desired publisher".
+
 ## Checks available without the VM
 
 From an x64 Visual Studio developer shell:

docs/implementation-status.md

@@ -51,8 +51,10 @@ it should not be read as describing the corrected source unchanged.
 
 ## Requires the test VM or additional matching binaries
 
-Live kernel testing is not available yet. Extracted VM artifacts, host mocks,
+The first user-run kernel trace is available for Windows 11 22631 x64 with
-and compilation do not close these:
+TESTSIGNING enabled. It confirms the BthPS3 signer-selection comparison and
+primary-signature CI path below. That one run, extracted artifacts, host mocks
+and compilation do not close the remaining work:
 
 1. Run the paired `CiValidateFileObject` flag `0`/`0x20` probe on 19041/19045
    with TESTSIGNING off and a loadable signed test driver. Preserve complete
@@ -77,8 +79,14 @@ and compilation do not close these:
 5. Measure signing-time propagation, zero/sentinel values, timestamp expiry,
    revocation freshness/network policy and weak-crypto policy. Record OS policy,
    Secure Boot/HVCI/WDAC and exact files, not just a boolean result.
-6. Establish multiple/nested signature-selection behavior with a signed corpus;
+6. Extend the observed multiple/nested selection result beyond the first run.
-   extend supported PE gaps/overlays only after differential evidence.
+   On Windows 11 22631 x64 with TESTSIGNING enabled, `0x20` returns Microsoft;
+   `0xA0` and direct primary SHA-256 `CiCheckSignedFile` return Nefarius with the
+   same signing time and matching signer/timestamp policy observations. All
+   calls and policy statuses succeed, the file snapshots match, and no trace
+   events are lost. TESTSIGNING-off, general enumeration, full `0x80` semantics
+   and cross-build/policy behavior remain open. Extend supported PE gaps/overlays
+   only after differential evidence.
 7. Resolve page-hash allocation destruction, normalized-entry/truncation meaning,
    terminal-entry handling and cross-version layouts before publishing a general
    page-hash API. `CiFreePolicyInfo` is not an established destructor for it.

docs/mincrypt-contracts.md

@@ -158,6 +158,42 @@ later conversion failure. It is not owned by either policy object.
 Evidence: `MincryptFreePolicyInfo`, `MincryptCopyPolicyInfo`,
 `I_MincryptAddChainInfo`, `CiVerifyHashInCatalog`, and `CiGetCertPublisherName`.
 
+## Multiple signatures and selected results
+
+`CiValidateFileObject` returns one selected signature result and its timestamp
+policy. Those two policy outputs do not enumerate two file signatures. The
+output file digest and algorithm are not expected-certificate selectors.
+
+REA tracing of x64 CI 22621.2792 and the original 26100 sample found a
+flag-dependent distinction: ordinary `0x20` can continue nested-signature
+verification and retain a policy-preferred signing level. Adding `0x80` enters
+an early-exit path after the first successful full candidate verification.
+`0xA0` is therefore a concrete kernel experiment, not a proved stable
+"select primary signature" flag: `0x80` also affects other policy/fallback paths.
+An arbitrary signer index, expected-certificate predicate and continuation
+interface are not exposed by these examined wrappers.
+
+For the supplied BthPS3 fixture, host SignTool verifies a primary Nefarius
+SHA-256 signature and a nested Microsoft SHA-256 signature. On both examined CI
+builds, `CiCheckSignedFile` with the matching SHA-256 digest follows the primary
+signature directly. This gives a CI-based alternative worth testing without
+implementing RSA/ECDSA, chain or timestamp verification. A subsequent user-run
+probe on Windows 11 22631 x64 with TESTSIGNING enabled confirms that `0x20`
+returns Microsoft while `0xA0` and direct SHA-256 `CiCheckSignedFile` return the
+Nefarius leaf and its signing time. Every top-level and signer/timestamp policy
+status succeeds; the two company-signer routes have matching policy observations.
+The companion `signature-selection/runtime-22631-bthps3.json` retains exact
+fixture/trace identities. This does not establish TESTSIGNING-off or general
+cross-build behavior. A different layout may still require bounded signature
+framing/enumeration.
+
+The companion CodeIntegrity-RE `SIGNATURE-SELECTION.md` retains fixture hashes,
+56 procedure bodies, assembly, flag side effects and the kernel test plan.
+The 23H2 batch is
+`ev_049bd7d3aa492a9e3e4d8fcbf365ae00a6057751b26f93f3c1663c9436952ff7`;
+its primary-selection helper is in
+`ev_c867c73ca7eae7e4fbca2f44c6f6fb5904fb00459d0b84f2da8294b5b05a3866`.
+
 ## Digest-based verification inputs
 
 `CiCheckSignedFile` consumes a caller-computed file digest. It does not reopen