Incomplete attestation data for FIDO2 SKs?

Ian Haken ihaken at
Wed Sep 9 03:54:07 AEST 2020

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.


On Mon, Sep 7, 2020 at 5:31 PM Damien Miller <djm at> 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

More information about the openssh-unix-dev mailing list