Address inconsistency between docs and OEM factory reset User GPG PIN minimum length requirement

[UndeadDevel]

Addresses part of #1645:

Lowers the User GPG PIN minimum length to 6 to be consistent with NitroKey app / docs and default PIN length (Admin GPG PIN minimum length is still 8).

[tlaurion]

@UndeadDevel no problem with changing the pins lengthts. I have no problem changing the default to setting custom PIN as well, but that is for those enforcing OEM factory reset prior of shipping, which is oem-factory-reset main use case, otherwise should be considered under #1521 bigger discussions.

@daringer @JonathonHall-Purism

[UndeadDevel]

As requested by @tlaurion here this PR now only addresses the inconsistency between the docs / NK app and Heads OEM factory reset minimum User PIN length requirement.

[tlaurion]

@UndeadDevel, I’ve realized that the user experience (UX) for the OEM factory reset limits PIN/password/passphrase lengths to a minimum of 8 characters and remembered why. This isn’t due to misreading of smartcard/GPG docs but because a comprehensive re-ownership process shouldn’t rely on a PIN, especially not one shorter than 8 characters. And because in default settings, if choosing a single passphrase for TPM/GPG/DRK, it shouldn't be of 6 characters even if software permits it.

When users opt for default settings, this 8-character minimum isn’t enforced. The GPG factory reset defaults to a user PIN of ‘123456’ (6 characters) and an admin PIN of ‘12345678’ (8 characters).

While you might prefer PIN sizes to align with GPG/OpenPGP smartcard documentation, we’re focusing on users who reject these defaults on first use. We encourage users to choose passwords or, ideally, passphrases, which are more secure according to the documentation: Configuring Keys.

A single PIN/password could not meet the security needs of a LUKS Disk Recovery Key passphrase with earlier version of LUKsv1. I mean today you could use a PIN of 6 digits for LUKSv2, but I still won't vet to go that way and would actually get rid of the word PIN if it was possible, but that is what gpg uses, so the wording tries to push users into choosing passphrase, not password and even less PIN. PIN refers to a numeric code. But under GPG/OpenPGP smartcard its a bit different since 3 attempts is permitted prior of locking that user/admin. Still no reason to use a "PIN" to me, where a 2 words EFF short list would be way better http://www.highprogrammer.com/alan/diceware/ even for a single shared passphrase for all secrets if never disclosed.

Conclusion:
We won’t be merging the PIN size changes and I hope the reasoning is clear. You can appeal of my decision and I could, with good arguments, accept to change the minimal size to 6 alone as said in the issue, but other stakeholders would need to agree with that as well.

If passphrases were aotomatically generated, they should be random and meet the minimum word requirements as suggested in the documentation. They could be shared with the user via a QR code or, ideally, not shared at all except for the Disk Recovery Key (DRK) passphrase necessary for re-ownership. Other secrets are "non need to know" and would force the user to do a re-ownership upon reception of hardware and remove accountability on the OEM at that point in time for any leak that could happen, also including reencryption of disk. My personal recommendation is to only share the DRK passphrase with the customer, if that is not of course PleaseChangeMe. Whether the OEM decides to generate and store additional secrets is up to them. However, shipping devices with a shared passphrase for all secrets should motivate users to take ownership ASAP. If Heads prompts users to change default PINs at each boot with devices shipped seperately, that's also good to me: we expect users to follow this guidance.

TLDR:
The decision to set these design parameters was to simplify the code. The terminology around PINs, passwords, and passphrases can be confusing, which is why we use ‘password’ in the UX. The system tolerates a minimum of 8 characters for a PIN, even though the default is 6. This doesn’t affect the DRK passphrase.

Next Steps:
I concur with your previous comment. We’ll consider modifying the OEM factory reset once upstream bugs are resolved and we can assess the expected behavior vs desired. Personally, I’d prefer to eliminate the term ‘PIN’ altogether, but we can't because used by gpg toolstack. If we adopt passphrases using diceware, even with the EFF small wordlist, the minimum passphrase length would average more than 8 characters anyway, making it more secure and easier to remember than a numeric PIN.

[UndeadDevel]

@tlaurion I just noticed that I changed the wrong limit in the PR; fixed with the last commit.

I do disagree with your reasoning, because much of it, it seems to me, does not apply here: this PR does not change the limit for the unified password (what you referenced as "single passphrase for TPM/GPG/DRK"), but only for the User GPG PIN. The USB Security Dongle enforces a 3-try limit before it locks the ability to enter more User PINs; in this case the user or attacker need to enter the Admin PIN (still at 8 characters) to unlock the User PIN again...though here, as well, the dongle enforces a 3-try limit.

So I think there is a misunderstanding here. I simply want Heads to be in line with the documentation and your entire reasoning, while perfectly valid for the "single passphrase" or TPM DUK or LUKS DRK or TPM Owner passphrase, is invalid here because of how the USB Security Dongles work; one could argue that it's tangentially valid for the Admin GPG PIN, because the new(ish) mechanism with USB sticks as GPG vaults for Heads sets the LUKS vault volume key passphrase to the Admin GPG PIN, but even that argument is irrelevant for the User GPG PIN, which is the only thing this PR affects.

So, I request you review your decision, please.

[tlaurion]

As requested by @tlaurion here this PR now only addresses the inconsistency between the docs / NK app and Heads OEM factory reset minimum User PIN length requirement.

Sorry I missed this comment. Agreed. This simple change makes total sense.

Tested and then reviewed

The commit log trace is not so clean, but I encourage external contributions and therefore the final changeset on one single file applied shows the exact reasoning leading to the final change, which I love.

Thanks for spotting the discrepency and fixing it in the proper way. Based on those bases, I merge since its a minimal change and I can hear @JonathonHall-Purism in my mind saying this is good enough. If otherwise, sorry, I need things to go forward.

[tlaurion]

LGTM! Merging!