# Remozio plan review: revision 21

**Scope.** I reviewed the complete revision 21 against the round 14 disposition. I paid most attention to the new restored-trust gate in §16 and how it interacts with §§3, 5, 12, 17 and 18. No earlier convergence is assumed for this revision.

The Opus 1 correction works as intended. §16 *Feasibility gate: restored trust state* now covers:
- floors, policy revisions and installed generations;
- lifecycle epochs and control replay state;
- atomic witness commits;
- recovery that cannot simply accept an old signed snapshot.

It also keeps offline and LAN operation and adds no recurring prompt. Two gaps remain around the same backup and migration scenario.

## Finding 1 (Medium): Mac authority key custody is unspecified, so a backup or migration clone can mint trusted requests and credential recipients

**References:** §3 *Root authority and retained state*, §3 *Key custody and pre-login transport*, §7 *Credential enrollment and release*, §16 *Feasibility gate: restored trust state*.

**What the plan says.** §3 requires adapter receiving keys to be non-exportable. It also says the file fallback "does not apply to credential-receiving or authority keys." It never states the required custody of the Mac authority private key, or whether that key may appear in backups or migrations. The §16 gate adds a non-migrating installation key, but only as a rollback witness.

**Failure scenario.** Suppose the authority key sits in ordinary root-only storage. It would then be included in Time Machine or Migration Assistant copies.
1. An attacker restores that copy on a Mac they control. They are root there, so the §16 continuity checks never run.
2. They now hold the key that phones pin as the Mac authority.
3. They can issue authority-signed 1Password unlock requests and certify their own adapter receiving key.
4. The enrolled phone verifies both correctly. After the user completes one biometric, the phone releases the credential package to the attacker's key.

This is not a root compromise of the protected Mac. §16 explicitly treats backup and migration as in scope, yet it only prevents the clone from acting locally. It does not prevent the clone from impersonating the authority to phones.

**Minimal correction.**
- Require the authority key, and any key that certifies credential recipients, to be non-exportable and device-bound: Secure Enclave or a this-device-only keychain item.
- Otherwise, record an explicit custody blocker in the key-custody deliverable.
- On migration, rotate the authority key through the existing independent administrator recovery, which the plan already requires when continuity fails.

**UX note (needs user consultation).** This adds no step to normal approvals. It does mean every Mac migration requires authority re-establishment with the phone, which could involve a phone biometric. That cost should be disclosed to the user rather than silently adopted.

## Finding 2 (Low): Audit sequence and cursor behavior after a restore is undefined

**References:** §12 *Sync and offline cache*, §12 *Retention and replay safety*, §16 *Feasibility gate: restored trust state*.

**What the plan says.** Phones resume sync from an authenticated per-Mac sequence cursor and flag "missing or changed records." The trust-generation commitment deliberately excludes audit history.

**Failure scenario.** After a legitimate restore and administrator recovery, the Mac reissues sequence numbers the phone has already cached, now with different content. Each phone then does one of two things:
- permanently reports tampering for a legitimate restore; or
- stalls, because its cursor is ahead of the Mac's journal.

A malicious restore, by contrast, would look identical to this benign case.

**Minimal correction.**
- Give the journal an epoch bound to the trust generation.
- Have recovery start a new epoch.
- Have phones show an explicit "history discontinuity after Mac restore" marker, keeping cached records rather than overwriting them.

**UX impact:** none.

## Items reviewed without new findings

These areas are either consistent or already covered by defined feasibility gates with consultation paths:
- scope and key separation for decision-key, routing and scheduling purposes;
- relay and gateway non-authority;
- token-possession binding;
- update drain and quiescence;
- floor commit and the activation boundary;
- the mixed-version contract selection rule;
- the Update installing resubmission rule;
- restart recapture.

The idle threshold and retention duration remain deferred preferences, as stated.

**Implementation verification limits:**
- Platform proof of the witness, protected placement and generation-scoped key access remains open.
- Push delivery under Doze remains open.
- The one-biometric CryptoObject spike remains open.
- AX fixture behavior for 1Password and Little Snitch remains open.

**SUBSTANTIVE FINDINGS REMAIN**