FIDO Flags and some other changes

[Reza Tavakoli]

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,