Thanks folks! This looks like it's exactly what I was looking for. As I'm pulling the thread on this, one word of warning on the fido_cred_authdata_ptr method. The following is mentioned libfido2 docs [1]: "The authenticator data returned by fido_cred_authdata_ptr() is a CBOR-encoded byte string, as obtained from the authenticator." This is a bit unfortunate since it's the CBOR-decoded data over which the attestation signature is computed (concatenated with the challenge hash). And of course you would also want to CBOR-decode the byte string before parsing the auth data structure. I just opened a question [2] on the libfido2 GH page to ask if there shouldn't be an API to return the CBOR-decoded data instead since really that's what you would want for any uses of the function. Basically, I think the openssh docs might also want to clarify that the "ssh-sk-attest-v01" structure similarly has "authenticator data" as a CBOR-encoded byte array (since customers would need to decode it to verify attestation), or else you may want to just CBOR-decode the output of fido_cred_authdata_ptr in sk-usbhid.c, at least until libfido2 (hopefully) follows up on my question and provides a convenience method for getting that decoded value directly. [1] https://developers.yubico.com/libfido2/Manuals/fido_cred_authdata_ptr.html [2] https://github.com/Yubico/libfido2/issues/212 On Mon, Sep 7, 2020 at 5:31 PM Damien Miller <djm@xxxxxxxxxxx> wrote: > On Mon, 7 Sep 2020, pedro martelletto wrote: > > > > I haven't tried to parse the attestation blob for FIDO2 devices, > > > so it's entirely possible that it doesn't work. > > > > > > We rely on libfido2 to obtain the attestation cert from the token, > > > so if it has functions that let us get at the rest of what we need > > > then it wouldn't be too much work to append/prepend that extra > > > information to the blob. > > > > > > Pedro, do you have any insight here? > > > > > > -d > > > > I agree with Ian -- we need to persist the contents of > > fido_cred_authdata_ptr(), or an external verifier won't be able to form a > > complete picture of what was signed. > > > > Alternatively, we could persist only the AAGUID and the signature > counter, and > > let the verifier reconstruct authdata. Since authdata isn't strictly > bounded > > (its last constituent part is a CBOR map of variable content and length), > > reconstructing it can get tricky. > > Thanks for the pointers - I think the attached patch should do it. > > -d > > > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
