webauthn signatures: SecurityKeyProvider, json parsing

[Damien Miller]

On Tue, 11 Jan 2022, Scott C Wang wrote:

> Greetings,
>
> I was recently exploring OpenSSH's support for security keys and
> webauthn signatures, and had the following questions.
>
> (1) Could you confirm that the client doesn't support creating
> signatures of type "webauthn-sk-ecdsa-sha2-nistp256 at openssh.com"?
> To me, it looked like SecurityKeyProvider implementers of sk-api.h
> aren't provided fields in the sk_sign_response struct in which to
> return the origin, clientData, and extensions signature fields,
> and sshsk_sign in ssh-sk.c cannot create signatures of type
> "webauthn-sk-ecdsa-sha2-nistp256 at openssh.com". What considerations
> would there be against augmenting sk-api.h with a webauthn signature
> type with fields for origin, clientData, and extensions, so that
> SecurityKeyProvider implementers can provide webauthn signatures?

What use for this do you have in mind?

It wouldn't be too hard to allocate a SSH_SK_* flag that indicates
that the data to be signed is a webauthn request and that the result
should be a webauthn signature, but I don't see how this would be used
in OpenSSH itself.

> (2) Am I correct to understand, from my reading of
> webauthn_check_prepare_hash in ssh-ecdsa-sk.c, that the server
> requires the webauthn signature's clientData field to begin with the
> type, challenge, and origin json fields, and ignores all fields after
> origin; and the hash is computed over the entire clientData blob? I'm
> asking to clarify since I notice Google Chromium [0] and the webauthn
> spec [1] warn that the json could be extended in the future, so they
> discourage verifiers from relying upon the order of the keys.

We worked with the webauthn team to avoid this. Strictly the
signed/verified data isn't JSON, but a JSON-compatible format that
strictly specifies the ordering of fields in a way to *not* require
a JSON parser in a signature verifer, as that would be a deal-breaker
for SSH use :)

> (3) I happened upon regress/unittests/sshsig/webauthn.html, which
> is very useful; however, the script hardcodes the relying party as
> "mindrot.org". I edited out that domain and hosted the site on my
> own domain to get this page to work. Is this page already hosted on
> mindrot.org, and if so, what's the path?

it's at https://www.mindrot.org/webauthn 

-d