Should an x5c attestation always chain to the metadata service?

[chrismccaw]

Great library guys 👍 I'm doing some testing with MDS with a variety of authenticators. I can't find in the spec but must all x5c certificates (packed x5cband fido-u2f attestations) chain to the metadata service? For example, if I'm using MDS and authenticate with a packed x5c attestation however it does not exist in MDS it should fail?

Thanks

[bdewater]

tl;dr: it's really up to your requirements, the spec has no opinion on how you obtain the root of trust. From the current draft for Web Authentication level 2 states (6.5. Attestation):

It is expected that most authenticators will support a small number of attestation types and attestation statement formats, while Relying Parties will decide what attestation types are acceptable to them by policy. Relying Parties will also need to understand the characteristics of the authenticators that they trust, based on information they have about these authenticators. For example, the FIDO Metadata Service provides one way to access such information.

And during registration (7.1. Registering a New Credential):

20. If validation is successful, obtain a list of acceptable trust anchors (i.e. attestation root certificates) for that attestation type and attestation statement format fmt, from a trusted source or from policy. For example, the FIDO Metadata Service provides one way to obtain such information, using the aaguid in the attestedCredentialData in authData.
21. Assess the attestation trustworthiness using the outputs of the verification procedure in step 19, as follows:
    • If no attestation was provided, verify that None attestation is acceptable under Relying Party policy.
    • If self attestation was used, verify that self attestation is acceptable under Relying Party policy.
    • Otherwise, use the X.509 certificates returned as the attestation trust path from the verification procedure to verify that the attestation public key correctly chains up to an acceptable root certificate.

I've been meaning to update/correct the attestestation.md file from #280 and merge that to master but haven't made the time yet. It does point out correctly that there are four different formats and that handling each scenario is up to your specific requirements. If you can share what are trying to achieve with attestation I can give you a more specific answer.

[chrismccaw]

Ah, gotcha! Thanks for the info. That helps me! If I'm not mistaken, the conformance tests require the root of trust from metadata?

Since the tests verify revoking metadata leaf and intermediate certificate from the TOC, the Entry won't exist to fetch (F-4, F-5, F-6) In those tests there is only a leaf certificate in the x5c and since the TOC for those entries has been revoked there is no root to verify the chain.

[bdewater]

Yep, the metadata service conformance tests are a sort of utopic situation where one service has all the root certificates, while in practice you'll find it's a mix of MDS and three device-specific methods depending on your users.

Specifically for the metadata service conformance test API the documentation is a bit hidden - there's:

• a non-normative section in the FIDO 2.0 Server Requirements and Transport Binding Profile document that describes the requests/responses in more detail
• the FIDO 2.0 Metadata Service spec

• the FIDO 2.0 Metadata Statements spec

  The fact you have to cycle through all returned endpoints until you find a valid table of contents file I figured out by looking at a C# implementation. The rest was trial & error and searching/opening at https://github.com/fido-alliance/conformance-test-tools-resources/issues

I haven't looked at those specific tests for a while but based on your description that sounds about right :)

[chrismccaw]

That is Interesting. Good to know! I guess it all depends on your policy on the handling of authenticators. Determining what your security policy for the type of application you are using FIDO. For example, should all attestations chain to a root? Should MDS be used for that extra layer of registration verification? Do you periodically check registered attestations or perform that verification during authentication?

Android and TPM confuse me a little when it comes to MDS. I think MDS really only applies to packed and u2f as well. Android and TPM have their own special roots.

Have you gone to an interoperability event? I am assuming during that you would have to extra accept metadata statements outside of the TOC (since they aren't certified yet)?

[chrismccaw]

Closing as I got all the info I need. Thanks @bdewater