On Wed, 12 Jan 2022, Scott C Wang wrote: > Awesome! Thank you, Damien. > > > AFAIK clientData is > > prepared from origin, extensions and H(message), so there's not need > > to pass that explicitly. > > The trouble with not passing clientData is that the spec reserves > the right to append new keys to it in the future. To validate > the signature, the OpenSSH server has to be apprised of the > entire clientData blob returned from the webauthn API. Ergo, the > OpenSSH client does need to be passed the entire clientData blob > explicitly, as opposed to reconstructing it, lest there be extra keys. > (Chromium already randomly appends an extra "reminder" key to break > implementations that attempt such a construction. [0]) Sure, but OpenSSH is the thing requesting the signature to begin with and isn't going to requesting extra stuff. So AFAIK there's no need to pass clientData from OpenSSH to the signer. > > As far as communicating with the webauthn signer via the ssh-sk API, > > nothing in OpenSSH uses the extensions field and the existing > > application field could be used to pass origin. > > Are you referring to passing in, or passing back? Does "extensions" > refer to the authenticatorData attestedCredentialData and extensions > [0]? If so, then the SecurityKeyProvider will need to pass those > back to OpenSSH so that the server can include them in the hash > computation, even if it doesn't parse them. AFAIK extensions are the extra things that go in clientData, no? -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
