Automatic FIDO2 key negotiation (request for comments)

[Jordan J]

> Right, this was an deliberate decision. Another motivating factor
> was being able to use existing non-OpenSSH SSH tooling and workflows
> with only small changes.

Hopefully with extensions this can keep that benefit!

> I'm not keen on making the public keys contain the key handle. IMO
> being able to offer some protection of the key handle on disk by
> setting a password on the key is valuable and we'd lose that if
> everything were public by default.
> [snip]
> If you do this, then you don't need step #1 at all: the server
> could send the key handles registered for a user at the start
> of userauth and the client could proceed to match them against their
> available hardware authenticators and return a signature using one.

I was thinking putting the key_handle in the public key is potentially
an easy way to inform the server of the key handles using the existing
add authorized key flow; but I can understand the desire to be able to
password it. As the private key contains the public key as well as the
key handle, is there any reason we couldn't allow people to upload the
(not passworded) private key file to authorized_keys as a way of
specifying both? It's useless without the hardware key anyway. That
also provides a way for the user to choose if they want to avail of
the feature by which key file they upload and do so on a per-key basis
if they choose. It's a very subtle way of enabling a feature though
that people probably wouldn't intuit so it'd need to be clearly
documented - but that shouldn't be an issue.

I'm trying to avoid something that would add new configuration files
if it's not necessary, but a seperate file for a list of key handles
the user wants to advertise is also an option of course.