[root v12] yubikey updates

[jku]

(I'm using the "root v11" label to make sure this gets discussed but I don't think we need to rush with this.)

I believe ysa-2024-03 affects some or all yubikeys used in sigstore root-signing. An attacker could duplicate elliptic curve signing keys on these yubikeys. The factors that makes this less severe are

• attacker needs the PIN
• attacker needs physical possession of the yubikey
• attacker needs specialized equipment

My opinion is that we should phase out current keys but that it is not critical to do it right now. Potential fixes that can be done during a root signing event:

• Switch to a non-affected algorithm (ed25519 or RSA) -- knowing that this could affect client compatibility
• Switch to yubikeys with firmware >= 5.7.0 -- this seems like the better choice

Issues to keep in mind:

• tuf-on-ci root key rotation may need a bit of work if threshold of keys change at once (but the signer identities remain same): this is a tricky case where signatures from both old and new keys are required test root key rotation when threshold of keys rotate theupdateframework/tuf-on-ci#505 and likely has not been fully implemented for this specific case
• An alternative may be to only change less than threshold keys at a time

[haydentherapper]

Agreed that this does not seem critical to address immediately, though if possible it would be nice to distribute updated Yubikeys before the signing event. Should we ping keyholders to see if they have access to a newer key, or ask them now to obtain one?

I'd prefer to continue to use ECDSA. I recall some issues supporting Ed25519 for the Ruby ecosystem, and RSA significantly increases the size of metadata.

Does tuf-on-ci check firmware versions (I assume from device attestations) for Yubikeys, or is this a feature we should add? Do you think there is value in copying device attestations into either the repo or the root.json file?