Hello, I just want to share my ideas about few things related to fido keys: 1. Right now, we specify flags like "no-touch-required" and "verify-required" during key generation, but I think this information should not be attached to keys at generation times, especially because servers most accept our keys based on their configurations: for example, one server may have "no-touch-required" on it's "authorized_key" file and another one doesn't. But we cannot change "no-touch-required" on every login since it's permanently attached to its private key. Also, keys created with "verify-required" need to have "verify_required" on the server config or they will be rejected, and if we add "verify-required" to keys which do not have this flag, they'll become useless. My purpose is, these options should be configured on ssh configs, so for each server, we can specify them as it should be(or select a default with "Host *"). What do you think? 2. Another thing I wanted to share is, with "verify-required", you ask for the pin before starting sk module, I think it's not a good idea since some modules do not read pin (for example mine, which is using Windows Hello, and it needs to ask for the pin on it's UI) And in future, when you want to add support for biometric verification, this should be changed. 3. "-O user" option only set key_id in sk-usbhid.c, you hardcoded name and display_name to "openssh", this can make key management hard, most of key managers app(like YubiKey manager) only shows the name of the resident key, and refuse to delete keys when there are two with the same name, an easy fix is to set name and display name to the one requested in "user" option (and fallback to "openssh" when the user is not configuring any name since they can't be empty) 4. In the next version of libfido2, a new function named fido_cred_authdata_raw_ptr will be added which is same as fido_cred_authdata_ptr but its output is not CBOR encoded. I think it's a better fit for storing attested data. Thanks for reading this. Regards, _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
