This is completely the wrong place for this, but you don't list an email address and I don't want a Twitter account
In Dispatch #4 you complain (speaking of FIDO for OpenSSH) that "As far as I can tell, that’s true when the key handle is indeed an encrypted private key, but there’s nothing in the spec requiring that". In the WebAuthn spec. which I've actually read unlike the various other specifications, there are two alternatives offered:
1. At least 16 bytes that include at least 100 bits of entropy, OR
2. The public key credential source, without its Credential ID or mutable items, encrypted so only its managing authenticator can decrypt it. This form allows the authenticator to be nearly stateless, by having the Relying Party store any necessary state.
(The Reply-To of the Dispatches goes to my inbox!)
Nice! Both 1 and 2 should provide the security properties. Now I do wonder how the WebAuthn spec reflects the ecosystem of tokens compatible with OpenSSH. Honestly, I don't even know if OpenSSH implements WebAuthn or there's a different umbrella spec?
I can't imagine there's actually a meaningful market for products that implement the hardware protocols described in FIDO (which use byte conservative CBOR because it's imagined that you'd try to run them over some ratty wireless protocol with no bandwidth) but aren't intended to be used with WebAuthn (which is full of JSON mapped to that CBOR because it's imagined you're a full fat modern web site displayed on a modern graphical web browser like Chromium or Firefox) but they are separate.
But OpenSSH doesn't need WebAuthn it just needs FIDO.
You'd presumably hate both specifications, because they drag in (and rely upon) registries for a bunch of technically unnecessary stuff and not even for the practical engineering reason I've excused in my sister posts to this thread. It's pure politics, you need everybody on the bus and so if they insist upon stupid ideas A, B and C between them then your options are veto A, B and C and nobody goes on the bus so the exercise was futile or you allow A, B and C with your face buried in your hands and plan for the inevitable negative security consequences.
Microsoft really wanted to do RSA for example. So, even though you wouldn't do RSA and I'm sure none of the Google people working on this love it either, the WebAuthn specification makes RSA an option and Microsoft shipped code that does RSA with WebAuthn.
I believe agl wanted the standards to rip out U2F's counters. Some security people love counters (does somebody have a war story where counters actually saved the day? I want to hear that war story) but others wanted them and so they are still in FIDO2/ WebAuthn even though they're a potential privacy hazard.
In Dispatch #4 you complain (speaking of FIDO for OpenSSH) that "As far as I can tell, that’s true when the key handle is indeed an encrypted private key, but there’s nothing in the spec requiring that". In the WebAuthn spec. which I've actually read unlike the various other specifications, there are two alternatives offered:
1. At least 16 bytes that include at least 100 bits of entropy, OR
2. The public key credential source, without its Credential ID or mutable items, encrypted so only its managing authenticator can decrypt it. This form allows the authenticator to be nearly stateless, by having the Relying Party store any necessary state.