openssh unix dev - Jan 2022 - webauthn signatures: SecurityKeyProvider, json parsing

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?

(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.

(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?

Thanks for your patience with my questions,


Scott C Wang

[0] https://goo.gl/yabPex
[1] https://w3c.github.io/webauthn/#dictdef-collectedclientdata

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