On Mon, Sep 19, 2022 at 8:05 PM Damien Miller <djm@xxxxxxxxxxx> wrote: > > On Mon, 19 Sep 2022, Carlos Cabanero wrote: > > > Between sshconnect2.c:sign_and_send_pubkey() and identity_sign(), > > there is a call to key_sig_algorithm and its output is used for > > SSH2_MSG_USERAUTH, and so on... key_sig_algorithm makes use of > > sshkey:sshkey_ssh_name_from_type_nid. The issue there is that webauthn > > and sk both are declared as the same type: KEY_ECDSA_SK. > > > > At the moment webauthn-sk is considered just a signature only type, > > per sshkey:keytypes, and per your "experiment", the pubkey type is > > made sk-ecdsa. But, trying to force things, if you create the pubkey > > as webauthn-sk-ecdsa, sshd will log you in if you add webkey-sk-ecdsa > > as an Allowed Pubkey Method. > > > > As you said, it is a violation that the key and signature are > > different, but could a case be made to grant webauthn-sk-ecdsa the > > full "key type" status? At the end of the day, it is not fully true > > that KEY_ECDSA_SK and Webauthn represent the same type of key, even if > > until now things have been "forced" to fit that way. > > Well, this is similar to what I suggested wrt having the agent send the > keys back as "webauthn-sk-ecdsa-sha2-nistp256" but a little more > officially :) > > There are two ways to do this. One is keeping the key type id > as KEY_ECDSA_SK and adding a key->flags entry to indicate that it's > webauthn-only. Another is a whole separate key type. > > At the moment, adding a new key type means a lot of duplicated > boilerplate code. I have some WIP changes to reduce this[1], but even > after they land it there is so much overlap with regular ecdsa-sk keys > it probably makes more sense to go the other way. > > -d > > [1] https://github.com/djmdjm/openssh-wip/pull/10/commits Ahhh I think I see now. Using key->flags we could indicate that it is webauthn only, but as you mentioned in your first message, we would also need some way for the agent to communicate that when listing, or to make it fallback to a webauthn-signature at one point, correct? Now that I have an idea of the scope I think it is doable, but we will definitely not make it for v1. We will launch as-is to see what adoption we get, and if we get requests to add forwarding capabilities at least we know there could be a way. Hopefully we can contribute that to the project :) _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
