Report spec violations in FIDO Metadata

[infinisil]

While implementing the parsing of the structures from the FIDO Metadata Service and the FIDO Metadata Statements, some spec violations were found when tested using the BLOB from downloaded from https://mds.fidoalliance.org/. We should report these violations so that they get fixed. The email to reach out to is certification@fidoalliance.org, see also https://fidoalliance.org/metadata/.

Here are the violations we currently know about. Note that this is based on the BLOB payload in https://github.com/tweag/haskell-fido2/blob/0175bb0d0cd941318d2db4b49082ef0a499a85d4/tests/golden-metadata/big/payload.json, which might be outdated.

• In the Metadata Statement for the "Hideez Key U2F SDK", the attestationRootCertificates field contains a certificate with a newline at the beginning, which is not compliant because the spec of that field says:

  Each array element is a base64-encoded (section 4 of [RFC4648]), DER-encoded [ITU-X690-2008] PKIX certificate value.

  Current workaround is to strip empty spaces when decoding any certificates. https://github.com/tweag/haskell-fido2/blob/0175bb0d0cd941318d2db4b49082ef0a499a85d4/tests/golden-metadata/big/payload.json#L3765

• In the Metadata Statement for the "Hideez Key FIDO2 SDK" and "Hideez Key U2F SDK", the icon field contains an invalid base64 encoded value without the necessary padding of a single = at the end, the base64 string has length 8039, which is not divisible by 4.

  Current workaround is to use lenient base64 decoding that doesn't require padding. https://github.com/tweag/haskell-fido2/blob/0175bb0d0cd941318d2db4b49082ef0a499a85d4/tests/golden-metadata/big/payload.json#L571 https://github.com/tweag/haskell-fido2/blob/0175bb0d0cd941318d2db4b49082ef0a499a85d4/tests/golden-metadata/big/payload.json#L3774

• In the Metadata Statement for the "PixelPin - Picture Login", the minComplexity field of the paDesc has a value of 34359738368, which does not fit into an unsigned long, which can fit a maximum of 4294967295.

  Current workaround is to use an unsigned long long instead. https://github.com/tweag/haskell-fido2/blob/0175bb0d0cd941318d2db4b49082ef0a499a85d4/tests/golden-metadata/big/payload.json#L4462

• The Metadata Statement specification declares AuthenticatorGetInfo as such:

  dictionary AuthenticatorGetInfo {
    DOMString members...;
  };
  

  which would indicate that the values of the dictionary should all be strings, which is however not the case in the BLOB.

  Current workaround is to allow arbitrary JSON values instead. An example of a non-string value is https://github.com/tweag/haskell-fido2/blob/0175bb0d0cd941318d2db4b49082ef0a499a85d4/tests/golden-metadata/big/payload.json#L117-L122

[sumo]

Seeing this issue with the latest MDS, with Security Key NFC by Yubico. The attestationCertificateKeyIdentifiers is not a valid SHA1 hash as it is missing two digits. With data that varies in quality is this a motivation to continue parsing the MDS but ignore (and log) bad entries? Don't know the implications of this but given the current situation of needing to fix out of band, this might be more resilient.

[sumo]

What's the best way to workaround this till it is updated in the MDS? Load the registry from a modified payload (using out of band process to verify MDS blob)?

[infinisil]

I agree that it should at least be possible to ignore the errors. I don't have time myself to implement this but if somebody else does I could help them to navigate the code base.

As an alternative workaround, if you have access to older versions of the blob, load the latest one that's not invalid.

[sumo]

Sounds good, will send a PR soon.

…

________________________________ From: Silvan Mosberger ***@***.***> Sent: Tuesday, March 7, 2023 11:46:28 PM To: tweag/webauthn ***@***.***> Cc: Sumit Raja ***@***.***>; Comment ***@***.***> Subject: Re: [tweag/webauthn] Report spec violations in FIDO Metadata (Issue #68) I agree that it should at least be possible to ignore the errors. I don't have time myself to implement this but if somebody else does I could help them to navigate the code base. As an alternative workaround, if you have access to older versions of the blob, load the latest one that's not invalid. — Reply to this email directly, view it on GitHub<#68 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AACJYQGFGPKCJBY46SJORCDW24U2JANCNFSM5KBYEK5Q>. You are receiving this because you commented.Message ID: ***@***.***>