RFC : Follow up to PGP auth: what should be blocked

Nobody has claimed this yet.

Work is getting near merging state under https://github.com/linuxboot/heads/pull/2158

A user could still flash an evil-maid firmware unauthenticated to bypass authentication.

Up to now (before authentication keys being able to be restored on new smartcard received when lost) per https://github.com/linuxboot/heads/pull/2158

So attack surface is now:
- got to system info, capture commit id of good firmware
- flash new evil maid firmware
- not reseal secrets, got to recovery shell
- backup firmware, giving keyring, trustdb and config.user override
- create havoc if needed (DoS: wipe os install)
- create reproducible build for known good commit, reflash that rom
- on reboot, totp/hotp good, but havoc created

What do we want here? prevent flashing when user has gpg priv key backup (so lost usb dongle is not bricking access?) or should we stay more liberal vs more secured? @JonathonHall-Purism @nestire ?

Start by reading the linked pull request #2158 and tracing the attack sequence described here, especially unauthenticated firmware flashing and recovery-shell access. The issue needs a decision on whether backups of the GPG private key should block flashing or remain allowed; done means the authentication policy and resulting blocked actions are agreed.

Written by the indexing model from the issue text.