RFC: Unlock a sealed OpenBao with one admin and a phone passkey

[znerol2]

Status: Draft, for the project's RFC discussion category
Related issues: #864, #12, #396
Related RFC: the ESO Kubernetes-auth RFC (#851)
Related decisions: ADR-0009, ADR-0011, ADR-0028, ADR-0029, ADR-0050

Each repository citation reads dmfdeploy/dmfdeploy@1d47e09:<path>:<lines>,
where 1d47e09 is the umbrella origin/main revision I read. Appendix A
lists the external sources and what I read in each. Appendix B lists what I
could not confirm.

Summary

OpenBao starts sealed after every restart. A sealed OpenBao serves no
secrets, and nothing that needs them can start. In the current deployment,
unlocking needs the unlock key material to be reachable from the operator's
own machine, which fails when that machine or its route to the cluster is
missing.

This RFC proposes the Tier 2 flow that ADR-0029 accepts but defers. One admin,
who may not be technical, unlocks OpenBao after a cold boot without physical
access to the node. The admin opens an unlock page and confirms on a phone
with the phone's own sign-in check. The unlock key material is not stored on
the node.

This RFC covers the sandbox and open-source lane only. The goal is the most
security that is achievable without adding friction for admins. In this lane,
physical and local root access to the node is a known, accepted risk. Tier 2
does not try to stop an attacker who already has root on the node. What it
does give is that no unlock material rests on the node, so a stolen disk, a
stolen box or a one-time root login cannot unseal OpenBao without the
admin's phone. Once OpenBao is unsealed, root on the node can read secrets
in memory, and that risk stays documented.

The RFC describes three flows as properties that must hold: an online site
with a laptop and a QR code, an online site with a notification link on the
phone, and an offline portable kit. It describes an optional private mesh
layer. It states the properties for adding and removing devices, for audit,
for a periodic admin check-in and for the work after an unseal. Lanes with legal or regulatory obligations
are out of scope. It puts eleven choices to you as
decisions, each with a recommendation.

Background

ADR-0029 defines three tiers and calls Tier 2, "Operator unseal", the
recommended default
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0029-tiered-unseal-posture.md:19-29).
It marks the tiers as a direction, not a control. Every tier assumes a
high-availability OpenBao with Raft storage, and that baseline is not built
(same file, line 15). The live posture is the single-replica auto-unseal of
ADR-0011
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0011-auto-unseal-tradeoff.md:16-18).
ADR-0009 keeps the five-share recovery path as the disaster layer for every
tier
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0009-shamir-dr-model.md:23).

ADR-0029 also fixes four guardrails for any implementation
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0029-tiered-unseal-posture.md:31-36):
a one-time token for each cold boot, protection against a silent downgrade
to a lower tier, rate limiting with an audit record for every submission,
and no extra weaker factor on top of a passkey. The design plan adds the
unlock page and the passkey design
(dmfdeploy/dmfdeploy@1d47e09:docs/plans/dmf-unseal-posture-tiered-framework-plan.md:157-200, 285-353).
That plan is marked historical, so this RFC treats it as input.

Goals and non-goals

Goals:

• One admin unlocks OpenBao after a cold boot with a phone, without physical
  access to the node.
• The node holds no unlock material at rest.
• Every unlock attempt is rate limited, and audited whenever the local spool
  can write the record.
• The admin does not need to be technical.
• The design adds no friction for admins unless it buys protection that
  matters in this lane.

Non-goals:

• Lanes with legal or regulatory obligations. See "Out of scope" below.
• Choosing the implementation language, the page framework or the
  push-notification server. Those belong in the plan.
• Designing the work after an unseal. This RFC states its properties only.

Threat model

This RFC covers the sandbox and open-source lane. In this lane, physical and
local root access to the node is a known, accepted risk, because stopping it
would add friction for every admin and the lane's data does not justify
that.

What Tier 2 still gives:

• A stolen disk or a stolen box cannot unseal OpenBao. The node holds no
  unlock material at rest, not even in wrapped form (see property 3).
• A one-time root login cannot unseal OpenBao without the admin's device.
• A phishing page on another domain gets nothing. A passkey signs for one
  domain only (Appendix A).

Accepted:

• An attacker who has root on the node and stays there. The unlock page
  and the code that receives the shares run on the node, so such an attacker
  can change them and capture a later unlock. Stopping that needs a trusted
  client and an end-to-end boundary that root cannot change. That is a much
  larger design with real friction, and it is out of scope.
• Root on an unsealed node reads secrets in memory.
• Whoever holds an enrolled phone and passes its sign-in check. A
  per-device passphrase mixed into the wrapping key would narrow this
  (dmfdeploy/dmfdeploy@1d47e09:docs/plans/dmf-unseal-posture-tiered-framework-plan.md:246).
  It adds a step for every unlock, so the RFC does not require it.
• A coerced or malicious admin. One admin is the whole control here.

Design properties

This section states what must hold. It does not prescribe an implementation.

Properties that hold in every flow

1. The unlock page needs nothing from OpenBao. It starts before every
   other service. It does not depend on the console, on External Secrets
   Operator or on a console sign-in, because those need secrets that are
   still sealed.
2. The unlock page is reachable only on the private network. It is never
   published on the internet.
3. No unlock material rests on the node. Neither the plaintext nor the
   wrapped unlock shares or keys are stored on a Tier 2 node. That covers
   disks, backups, swap, crash dumps and logs. Unlock material exists on the
   node only in memory, for the length of one unlock. Off-node custody is
   one wrapped copy on each enrolled phone and the ADR-0009 recovery
   package. The WebAuthn PRF extension gives a passkey the output that wraps
   the copy (Appendix A).
4. Nothing sensitive is logged. The page never logs the passkey output,
   the unwrapped material or any token. It records whether a token was valid.
5. Every submission is rate limited and audited as far as the local spool
   can write it. See the audit property below.
6. The tier is signed and checked at boot. ADR-0029 requires the declared
   tier to be bound in git-tracked config, checked cryptographically at boot,
   and changed downward only through a signed, audited change
   (dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0029-tiered-unseal-posture.md:34).
   This RFC keeps that requirement as written.
7. The ADR-0011 automation quorum is retired before Tier 2 is declared.
   ADR-0029 says the automation file is deleted for Tiers 1 and 2
   (dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0029-tiered-unseal-posture.md:56).
   Declaring Tier 2 while the file still exists would declare a posture that
   differs from the real one. The migration also re-checks the ADR-0009
   five-share distribution.
8. Each credential belongs to one domain. A passkey is bound to a
   relying party ID, which must be the page's domain or a parent of it, and
   never an IP address (Appendix A). The page needs a stable host name, and
   the passkey is enrolled for it.

Properties of the unlock session

The same session shape serves every flow:

• The admin's phone opens the unlock page. In Flow A it gets there through a
  QR code that carries a session URL. In Flows B and C it gets there through
  a notification link or a saved page.
• The phone runs its own passkey assertion, unwraps its own copy of the key
  material locally, and submits it to the session. No other device sees key
  material. In particular the laptop in Flow A only shows the QR code.
• The session is bound to the cold boot that created it. It expires after a
  short time, it accepts one submission, and it cannot be replayed. Only a
  session that completed a passkey assertion for an enrolled credential, and
  that holds the wrapped copy, may submit.
• The session URL alone unlocks nothing. The submission needs the passkey
  assertion and the wrapped copy that only the phone holds.
• A passkey assertion proves possession of the credential and a
  user-verification result. It does not prove a specific physical device, and
  passkeys that sync between devices are allowed. What gates the unlock is
  possession of the wrapped copy that lives on the phone.

Device lifecycle: enrollment, removal and transfer

The properties below follow the steady-state design in the #864 discussion.

• Where enrollment happens. Only in the running console, behind its normal
  sign-in. The unlock page unlocks and never enrolls.
• Who approves. An already enrolled device approves, unwraps the key
  material on that device and wraps a copy for the new one. When no enrolled
  device is available, the ADR-0009 recovery package approves.
• One copy per device. Every enrolled device holds its own independently
  wrapped copy, and any one of them can unlock.
• Owner notification. The current owner is notified when a device is added.
• Audit. Every enrollment, removal and rekey is recorded with actor, role,
  request ID, reason, time and result, like an unlock.
• Removal and transfer end with a rekey. Deleting a passkey is not enough,
  because that device may still hold a working wrapped copy. A rekey makes
  every copy wrapped under the old key stop working. The new key is wrapped
  only for the retained devices.
• The recovery shares are reissued. After a rekey, the five ADR-0009
  disaster-recovery shares are reissued from the new key and their custody
  is verified again.
• An interrupted rekey is recoverable. The OpenBao rekey page documents
  -init (only when none is in progress), -status, -cancel (discards
  submitted keys and configuration) and a nonce that every submitted key must
  carry. It does not say how to resume an interrupted rekey, or whether the
  old keys stay valid until it completes (Appendix B). The plan must test
  both and write the procedure. The same page marks rekey as deprecated in
  favor of rotate-keys, so the plan also checks which command to use.

Flow A: online site, laptop and QR code

• The node tells the admin that it is sealed.
• The admin opens the unlock page on a laptop. The page shows a QR code that
  carries a single-use session URL.
• The phone scans the code and opens the session URL, which loads the unlock
  page on the phone. The phone asks for its sign-in check, unwraps locally and
  submits to the session.
• This is not the cross-device WebAuthn flow, so it needs no Bluetooth
  between the devices. The phone needs a network route to the unlock page.

Flow B: online site, notification link on the phone

• The notification carries a link to the unlock page.
• The admin opens the link on the phone and confirms there. The phone runs
  the same session as in Flow A, without the QR code.

Flow C: offline portable kit

The kit is the flypack of ADR-0050. That ADR is Proposed, and its Mode C
constraints bind no implementation today
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0050-flypack-mode-portable-offline-kit.md:6, 61).

• The kit runs its own self-hosted push-notification server, paired with the
  admin's phone at install.
• The phone is on the kit's local network, receives the notification there
  and opens the unlock page on itself.
• No internet, laptop or Bluetooth is needed.
• The phone must trust the kit's certificate, because WebAuthn needs a secure
  context (Appendix A). The certificate question below settles how.
• A notification may arrive late or not at all on some phones. The
  notification question below settles the fallback.
• ADR-0050 expects secrets sealed to a local TPM or HSM
  (dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0050-flypack-mode-portable-offline-kit.md:26).
  Unlock material sealed to the kit's own hardware is material at rest on the
  node, which conflicts with property 3. If the kit uses Tier 2, that
  constraint needs an amendment when the ADR is promoted. Nothing here changes
  the ADR while it is Proposed.

Optional private mesh layer

A self-hosted mesh VPN control server lets paired devices reach the unlock
page and the notifications from anywhere. It hides them from unpaired
devices.

• It is recommended at machine-room and VPS sites and optional on the kit.
• It does not replace the passkey. A device on the mesh still needs the
  passkey to unlock.
• Its keys live on the node. They grant network reach, not secrets.
• It starts without OpenBao, for the same reason as the unlock page.

Audit

ADR-0028 C5 requires actor, role, request id and reason on every
DMF-initiated automated action
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0028-identity-and-authority-chain.md:35).
ADR-0029 requires an audit record for every submission, sent to a write-once
target
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0029-tiered-unseal-posture.md:35).
The unlock page runs before the write-once target is reachable, so these
properties must hold:

• Records are written first to a local, bounded spool, before any network
  service is up.
• Records are delivered to the write-once target when it is reachable, and the
  spool is cleared only after delivery.
• A record of an authenticated action holds the actor (the enrolled admin
  that the credential belongs to), the role, a request ID and a reason. An
  automatic reason such as "cold-boot unlock" is enough. An unlock record also
  holds the verified time of the assertion, the credential identifier and the
  user-verification result. Device details that the phone reports about itself
  are labeled as claimed, not verified. The record never says "biometric",
  because the user-verification result does not say which method was used
  (Appendix A).
• A failed attempt by someone who has not authenticated records the source
  address and the time, with the actor marked unknown. It does not record an
  invented identity.
• Each record carries a hash of the previous record, so the spool shows
  accidental changes. The chain does not prove that no one edited it on
  purpose: anyone who can write the spool can rebuild it. Resisting root is
  out of scope in this lane.
• Each record carries a sequence number, so the next record that is written
  can show a gap. It shows a gap only while the counter itself survives.
• When the spool cannot write, the unlock still proceeds, and the record of
  that unlock can be lost. Some lost records may never be detectable. The
  gap shows when the next record is written, if the counter survived. If
  nothing can be written at all, the gap shows only once writing works
  again, and a restart before writing recovers can lose it for good. A
  refusal would turn a full spool into an outage and would add friction for
  the admin.
• This relaxes the ADR-0029 guardrail that requires an audit record for every
  submission, sent to a write-once target (line 35, cited above). Decision 5
  lists the amendment.

Periodic admin check-in

A regular check-in finds a lost phone or an admin who has left early, not at
the next cold boot. It applies to the portable kit and to long-running sites.
These properties must hold:

• Check-in period. Each unlock or check-in starts a period. The default is
  30 days, and the length is configurable. The deadline is stored durably, so
  it survives service and node restarts. Time while the node is powered off
  counts toward the period, and a restart alone never extends it.
• Same ceremony, no reseal. A check-in is the same passkey ceremony as an
  unlock, run while OpenBao is unsealed. It proves that at least one enrolled
  credential and its wrapped copy still work. It does not reseal anything.
• Departed devices are visible. The console lists each device's last
  check-in and warns about any device not seen within the period, so a
  departed admin's device shows up and can be removed. Any one device can
  still unlock.
• Early warnings. The console and the paired notification channel warn
  ahead of expiry, by default at 14, 7, 3 and 1 days, and the warning days
  are configurable. Each warning carries a one-tap check-in link.
• Expiry never interrupts running workloads. After expiry, running
  workloads keep running. Privileged changes are refused until an admin
  checks in. The recovery package path always works after expiry: it can
  check in and enroll a replacement device, and it leaves running workloads
  untouched. OpenBao seals at the next restart, as it does today. An
  immediate seal is rejected, because it would cause an outage during
  operation and a kit may be mid-event.
• Audit. Every check-in, warning and expiry is recorded like an unlock,
  under the same failure policy. A record may be lost when the spool cannot
  write, and a check-in is never blocked by the spool.
• Accepted risk. Root on the node can disable the timer. That is
  consistent with the accepted local-root risk of this lane.

After the unseal

After an unseal, a catch-up step runs before secret consumers retry. This RFC
states the properties and does not design the mechanism:

• No secret consumer retries a credential that may have expired before the
  credential is renewed.
• Consumers stay held until the catch-up succeeds.
• A failed catch-up leaves a clear path for the operator.

The reason is the login lockout. After a long power-off, the SecretID that
External Secrets Operator uses has expired. #396 records
that failed logins trip the lockout and that a new SecretID does not help
until the lockout ends. The OpenBao documentation gives the defaults: five
failed attempts, a 15-minute lockout, and a lockout that applies to the
userpass, LDAP and AppRole methods (Appendix A). The mechanism depends on
#851, which would remove the case for ESO, and on
#396, which covers the rotation and alerting around
AppRole credentials. It belongs in the plan that follows those two.

Out of scope: regulated lanes

Lanes with legal or regulatory obligations need their own changes later.
Examples are dual control across people, a specific authentication assurance
level and strict write-once audit delivery. This RFC does not design for
them. Tier 1 in ADR-0029 is the existing place for the multi-person case, and
it is also unbuilt.

Questions with options

Order: HA first or a single replica

ADR-0029 defines every tier on a high-availability OpenBao with Raft
(#12). Without it, every OpenBao pod restart seals the
single replica. An upgrade, a node drain or a crash then needs a phone unlock
and causes an outage until the admin acts.

HA keeps OpenBao serving while one node restarts. It does not remove the
unlock. The OpenBao seal documentation says that each node must be unsealed
with the threshold of shares, that partial unsealing is not distributed
across the cluster, and that a restart seals the node again (Appendix A). A
restarted node therefore needs the same phone unlock, and it must be unsealed
before the next node restarts. The same page's migration steps say to bring
back a downed standby before moving on to the others, to keep quorum with
Integrated Storage. A rolling upgrade is a sequence of restarts, each
followed by an unlock.

Options: build HA first, or allow Tier 2 on a single replica. The second
option conflicts with ADR-0029, which says the tiers are not selectable
without the Raft baseline. It needs an ADR-0029 amendment that names the
exception. It does not keep the baseline true. Recommendation: HA first
for any long-lived site, because it keeps OpenBao serving through a
single-node restart. The admin still unlocks each restarted node. Allow a
single replica in the sandbox lane through an explicit ADR-0029 amendment and
a visible warning.

Certificate trust offline

Online sites use a public certificate. An offline kit can also use one if the
kit gets it while online and can renew it, so offline does not always mean a
private authority. A kit that stays off for months may find the certificate
expired when it starts. The options:

1. A public certificate, provisioned while online. No trust change on the
   phone. It needs a renewal path and a plan for expiry during a long
   shutdown.
2. A private authority limited by name to the kit. The phone trusts it
   only for the kit's host name. Support for such limits on a user-installed
   authority is unverified on both phone platforms (Appendix B).
3. A private authority with no name limit. It is the fallback if option 2
   fails. A leaked signing key would let an attacker impersonate any site to
   that phone, so this is a security decision the operator must approve.

For options 2 and 3 the plan must settle how the authority is renewed and
removed, and how pairing installs it for a non-technical admin. Keeping the
private key off the kit protects it from an attacker with root on the kit,
but it adds a step to every renewal. Root on the kit is an accepted risk in
this lane. Recommendation: option 2 with the private key on the kit, so
renewal needs no admin action, tested on one iPhone and one Android phone.
Use option 1 where the kit has a renewal path. Do not use option 3 without
explicit approval.

Notifications on an offline phone

Whether an offline phone gets a timely alert from a notification server on
the kit's own network is an unconfirmed feasibility question on each phone
platform (Appendix B). Phones limit background work, and an offline kit may
not reach any outside service. Recommendation: treat the unlock page as
the source of truth, and tell the admin to save it to the phone's home screen
at pairing, so the bookmark is the fallback. Test on a real iPhone and a real
Android phone before the plan commits to the offline alert.

The one-time token

ADR-0029 requires a token for each cold boot, printed to the node console or
the SSH login message
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0029-tiered-unseal-posture.md:33).
Its purpose is to limit unlocking to people with legitimate infrastructure
access at boot. A non-technical admin without a console or SSH is the person
this RFC serves. Options:

• (a) The token arrives in the notification. The unlock page can reissue
  it after a passkey check. It proves that the holder receives the
  notification or holds an enrolled credential and passes its user
  verification. It does not prove a specific device, and it does not prove
  infrastructure access.
• (b) Drop the token for Tier 2. The passkey already proves possession of
  an enrolled credential, and the wrapped copy on the phone gates the unlock.
  The private network, the rate limit and the audit remain. This needs an ADR-0029 amendment for Tier 2. Tier 1 keeps the
  token.

Either choice weakens the original proof of infrastructure access, and the
amendment must say so. The path with no notification is an acceptance case
for either option: a late, lost or expired notification must not leave the
admin without a way to unlock. Recommendation: (b). Under (a) the token
comes from the same passkey, so it adds friction and a dead end without an
independent factor.

Sign-in policy for the unlock

WebAuthn's user-verification result can reflect a PIN or a biometric, and it
does not say which (Appendix A). ADR-0029's Tier 2 row specifies one phone
and one biometric event
(dmfdeploy/dmfdeploy@1d47e09:docs/decisions/0029-tiered-unseal-posture.md:24).
Accepting a device PIN conflicts with that wording, so this needs an ADR-0029
amendment. A biometric-only rule would need platform enforcement that I could
not confirm. Recommendation: amend the Tier 2 row to say user
verification by any method the platform offers, including a device PIN,
because that adds no friction. Record the result, and do not claim a
biometric in the audit or the documentation.

Appendix A: Sources and what I read

Claim	Source	What I read
Shamir is OpenBao's default seal, and its seal configuration lists no human-approval seal type	OpenBao 2.5.x seal configuration page, https://openbao.org/docs/2.5.x/configuration/seal/	The page overview and its sidebar.
bao operator unseal takes one key share, as an argument (not recommended, because it lands in shell history) or at a hidden prompt, with -reset and -migrate flags	OpenBao command reference, https://openbao.org/docs/commands/operator/unseal/	The whole page. It does not mention stdin.
-pgp-keys belongs to bao operator init, it encrypts the generated unseal keys, and the number of keys must match -key-shares unless -stored-shares is used	OpenBao command reference, https://openbao.org/docs/commands/operator/init/	The flag descriptions. The RFC does not use PGP: the passkey output wraps the key material.
Each node must be unsealed with the threshold of shares, partial unsealing is not distributed, a restart seals the node again, and a downed standby is brought back before the next one in a migration	OpenBao concepts page, https://openbao.org/docs/concepts/seal/	The seal concepts page text on unsealing, restart and the migration steps.
With a Shamir seal, unseal keys are supplied before or after a raft join	OpenBao command reference, https://openbao.org/docs/commands/operator/raft/	The join section.
rekey is zero downtime and needs a quorum of existing keys, -init only when none is in progress, -cancel discards submitted keys, a nonce goes with every key, and the command is deprecated in favor of rotate-keys	OpenBao command reference, https://openbao.org/docs/commands/operator/rekey/	The overview and flag descriptions. The page does not say how to resume an interrupted rekey or whether old keys stay valid until completion.
Lockout defaults to five failed attempts and a 15-minute lockout, applies to userpass, LDAP and AppRole, and stops validating credentials during the lockout	OpenBao concepts page, https://openbao.org/docs/concepts/user-lockout/	The page text. The order of the lockout check and validation is implied, not described.
The PRF extension returns outputs of a pseudo-random function tied to a credential, usable at registration and at authentication, and can derive a key that only the authenticator holder can recreate	MDN, https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/WebAuthn_extensions	The prf section. MDN says fewer authenticators support evaluating the PRF when a credential is created.
WebAuthn is available only in secure contexts (HTTPS), and a signature changes with the site's origin	MDN, https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API	The page overview.
The authenticator data in an assertion carries a user-presence flag and a user-verification flag, and the MDN summary does not say which method verified the user	MDN, https://developer.mozilla.org/en-US/docs/Web/API/AuthenticatorAssertionResponse/authenticatorData	The page summary. The flag layout is on a linked page that I did not read, and the W3C specification is the normative source.
The RP ID must be equal to or a registrable domain suffix of the origin's effective domain, and direct IP addresses are not allowed	W3C WebAuthn Level 3, https://www.w3.org/TR/webauthn-3/, section 5.1.3 (steps 7 and 8) and 5.1.3.1	Characters 130,000 to 230,000 of the page. Step 8 reads "a registrable domain suffix of and is not equal to"; section 5.1.3.1 reads "equal to or a registrable domain suffix". I cite the second form and flag the first in Appendix B.

Appendix B: Unconfirmed items

1. PRF on iOS Safari. A search summary of the Safari 18.0 release notes says
   they list WebAuthn PRF support. I did not open the notes' text. Test on
   the admin's device and operating system version.
2. PRF on Android Chrome. I found no primary source. Third-party pages
   disagree: one older page says Android does not support PRF, and newer
   ones say it does with the platform's default passkey store. Test on the
   admin's device.
3. User verification and PRF. I did not confirm that every targeted
   authenticator evaluates the PRF only after user verification, so the page
   asks for it and the enrollment test checks it. I also did not read the
   WebAuthn text on the user-verification flag and its methods.
4. Wrapped-copy durability on the phone. I did not verify how long a
   browser keeps the origin storage that holds the wrapped copy, or whether
   it can be evicted. The plan must test this, and the second enrolled device
   and the recovery package cover a lost copy.
5. Offline alert delivery. I did not confirm that an offline phone gets a
   timely alert from a notification server on the kit's own network, on
   either phone platform. I found no platform source I could check. Test on
   real devices, with the bookmark as the fallback.
6. Mesh names. I did not verify that the mesh layer provides names and
   certificates a passkey can use.
7. The RP ID rule in the specification. Two steps in section 5.1.3 word
   the rule differently. I did not resolve which applies to a host that
   equals the RP ID.
8. Name limits and private host names. I did not confirm that iOS or
   Android honor a name constraint on a user-installed certificate
   authority, or how private host names work as RP IDs.
9. Rekey interruption and key validity. The rekey page does not say how to
   resume an interrupted rekey, or whether the old keys stay valid until it
   completes.
10. The cross-device WebAuthn flow. This RFC does not use it, because the
    phone opens the unlock page through a session URL. I did not verify its
    internet need or whether PRF output survives it.

Decisions requested

1. Order and ADR-0029 invariants. Build HA OpenBao first for long-lived
   sites, because it keeps OpenBao serving through a single-node restart. The
   admin still unlocks each restarted node before the next one restarts. Allow a
   single replica in the sandbox lane through an ADR-0029 amendment that
   names the exception and a visible warning. Keep the signed, boot-checked
   tier and the audited downgrade as the ADR states them. Retire the ADR-0011
   automation quorum before Tier 2 is declared, and re-check the ADR-0009
   five-share distribution.
2. Certificate trust offline. Prefer a name-limited private authority with
   its key on the kit, so renewal needs no admin action, and a public
   certificate where the kit can renew one. Do not accept an unrestricted
   private authority without explicit approval.
3. Offline notifications. Treat the unlock page as the source of truth, and
   test on a real iPhone and a real Android phone before the plan commits to
   an offline alert.
4. The one-time token. Choose (a) the token in the notification with
   reissue after a passkey check, or (b) no token for Tier 2 with an
   ADR-0029 amendment. Recommended: (b). The no-notification path is an
   acceptance case either way.
5. Audit delivery. Write records to a local spool first, chain them and
   number them, and deliver them to the write-once target when reachable. If
   the spool cannot write, unseal anyway and accept that the record of that
   unlock can be lost, with the gap shown by the next written record. Amend
   the ADR-0029 guardrail that requires an audit record for every submission
   to a write-once target (line 35) to say this for the sandbox lane.
6. Device lifecycle. Approve the enrollment, removal and rekey properties
   above, including the reissue and re-verification of the five recovery
   shares after a rekey.
7. Unlock session. Approve the single design: the wrapped copy lives on the
   phone, the QR code carries a short-lived single-use session URL, and the
   phone unwraps locally and submits to the session, so no laptop sees key
   material.
8. Sign-in policy. Amend the ADR-0029 Tier 2 row from one biometric to the
   platform's user verification, including a device PIN. Record the result,
   and make no biometric claim.
9. Catch-up after unseal. Leave the mechanism to a later plan. Keep the
   properties above, with dependencies on RFC: Authenticate External Secrets Operator to OpenBao with Kubernetes auth #851 and
   AppRole SecretID rotation has no pre-expiry schedule or alert — every env silently fails at ~30 days #396.
10. Periodic admin check-in. Approve the check-in with these defaults: a
    30-day period that restarts at each unlock or check-in, warnings at 14,
    7, 3 and 1 days with a one-tap link, and on expiry running workloads
    keep running while privileged changes are refused until a check-in. The
    period and the warning days are configurable.
11. Next step. If you approve, I write the plan in docs/plans/ with
    tracking_issue pointing at Implement ADR-0029 Tier 2 operator unlock with a phone passkey #864, and I carry the
    confirmations in Appendix B into its first work package.

[znerol2]

Decisions (operator, 2026-11-07)

All eleven are approved as recommended:

1. HA OpenBao first for long-lived sites. A single replica is allowed in the sandbox lane through an ADR-0029 amendment with a visible warning. The signed, boot-checked tier and the audited downgrade stay. The ADR-0011 automation quorum is retired before Tier 2 is declared, and the ADR-0009 five-share distribution is re-checked.
2. A name-limited private certificate authority with its key on the kit, or a public certificate where the kit can renew one. No unrestricted private authority without explicit approval.
3. The unlock page is the source of truth. Offline alerts are tested on a real iPhone and a real Android phone before the plan commits to them.
4. Option (b): no per-boot token for Tier 2, through an ADR-0029 amendment.
5. Spool first, then delivery. A full spool never blocks an unseal, and a lost record is accepted. ADR-0029's audit guardrail is amended for the sandbox lane.
6. The device lifecycle properties, including the rekey and the reissue of the recovery shares.
7. The single unlock session design: the wrapped copy lives on the phone, the QR code carries a single-use session URL, and the phone unwraps the key.
8. The ADR-0029 Tier 2 row is amended to platform user verification, including a device PIN.
9. Catch-up after unseal is left to a later plan. It depends on RFC: Authenticate External Secrets Operator to OpenBao with Kubernetes auth #851 and AppRole SecretID rotation has no pre-expiry schedule or alert — every env silently fails at ~30 days #396.
10. Periodic admin check-in: a 30-day period, warnings at 14, 7, 3 and 1 days, and on expiry privileged changes wait while workloads keep running. The recovery package path always works.
11. Next step: a plan in docs/plans/ with tracking_issue: 864. Its first work package runs the real-device confirmations from Appendix B.

[znerol2]

Decisions, 2026-11-08: sandbox-lane posture

The operator changed the sandbox-lane posture on 2026-11-08. The plan records these as decisions 12 to 20.

1. No boot-time unlock. The sandbox lane auto-unseals on every boot, with no admin action and no time window. A time window can't be enforced against someone who holds the disk, because the node only has its own clock. Under ADR-0029 this is Tier 3, and the lane declares Tier 3, never Tier 2.
2. Recovery keys separate from the seal key. The lane uses an auto-unseal seal. Generate-root then asks for recovery keys, not the seal key, so material on the node can't mint a root token.
3. One device holds the authority. One enrolled admin device holds enough recovery key material to approve root token creation alone. A device is a phone, a laptop or tablet with a platform authenticator, or a hardware security key with a PIN. The minimum is two enrolled admin devices, and the ADR-0009 recovery package stays the last resort.
4. The seal key gets its own backup. Recovery keys can't unseal ("Recovery keys cannot decrypt the root key, and thus are not sufficient to unseal OpenBao if the Auto Unseal mechanism isn't working", OpenBao seal concepts). The seal key is encrypted to each enrolled admin device and stored with the Raft snapshots, and the recovery package holds a direct copy.
5. The device names the operation. Its screen says unseal, root token or restore. Every root token is single-use and short-lived, revoked after its one change, and audited at issue, use and revoke.
6. A lost device means rotation. Removing a lost or stolen device rotates the recovery keys and the seal key, and re-encrypts the copies for the remaining devices.
7. Synced passkeys by default. The risk is a takeover of the passkey sync account. That's a remote risk, which the accepted local-root risk doesn't cover. Encrypted copies sit on access-controlled storage, the approval surfaces are on the private network only, and every use is audited.
8. One-confirmation restore. After the loss of every copy of the seal key on the nodes, dmf-init restores the latest snapshot and asks one enrolled admin device to decrypt the seal key. The Kubernetes auth config is portable (in-cluster API address, the pod's local CA and token files, no pinned CA), so a restored snapshot works on a new cluster without a root-token write.
9. Push notifications optional. With no boot-time unlock, every remaining device ceremony starts with the admin at a screen. Push notifications become optional in the sandbox lane, including the portable kit's push server.

Lanes that need a boot-time unlock keep the Tier 2 design.