> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
