MDS3 negative tests (F-2 to F-5) fails due wrongly provided Metadata Statements

[glacuesta-sa]

By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.

If you have privacy concerns, please email conformance-tools@fidoalliance.org

FIRST PRE CHECK

• [x] I SOLEMNLY SWEAR THAT I HAVE SEARCHED DOCUMENTATION AND WAS NOT ABLE TO RESOLVE MY ISSUE

What protocol are you implementing?

• [x] FIDO2 Server
• [ ] CTAP2.0
• [ ] CTAP2.1
• [ ] UAF 1.1
• [ ] U2F 1.1
• [ ] U2F 1.2

NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.

What is your implementation class?

• [ ] Security Key / FIDO2 / U2F authenticators
• [x] Server
• [ ] UAF Client-ASM-Authenticator combo
• [ ] UAF Client
• [ ] UAF ASM-Authenticator

If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org

What is the version of the tool are you using?

v1.6.39 NEW FIDO2 Server - MDS3 (EXPERIMENTAL)

What is the OS and the version are you running?

For desktop tools

• [ ] OSX
• [x] Windows
• [ ] Linux

For UAF mobile tools

• [ ] iOS
• [ ] Android

Issue description

During Metadata Service Tests (MDS3) negative tests the server receives the same Metadata Statement for the tests, its repeated and each case asks for a different condition, which makes repeatability of the mocked data absurd.

I registered my endpoint_url at https://mds3.certinfra.fidoalliance.org/, parsed the Metadata Statements provided in the endpoints and provided them to my service.

Looking at the tools code, the MetadataStatement for each case is requested from https://mds3.certinfra.fidoalliance.org/getTestMetadata with the following body: { "endpoint": "{{endpoint_url}}", "testcase": {{test_case}} }

The test_case options are: fido2_good (P-1) fido2_badReports (F-1) fido2_badSignature (F-2) fido2_badCertificateChain (F-3) fido2_intermediateCertificateRevoked (F-4) fido2_subjectCertificateRevoked (F-5)

Looking at the results from fido2_good and fido2_badReports, the only field that changes (ignoring aaguid and aaguid-related fields) is statusReports.status. In fido2_badReports the status is an Undesired State as it is needed to pass the test successfully.

For the rest of the cases, it is the same structure, the only thing that changes is the aaguid-related fields for obvious reasons:

Should that be happening?

[glacuesta-sa]

Server-ServerAuthenticatorAttestationResponse-Resp-B Test server processing "android-safetynet" attestation P-1 Send a valid ServerAuthenticatorAttestationResponse with "android-safetynet" attestation, and check that server succeeds

Something similar is happening as well with android-safetynet P-1 test case. During the validation for "attest.android.com" in attCert.DNSNames, that array is empty though the "attest.android.com" is present in, for example, attCert.Subject.Names. This causes the test to fail as there should be and element "attest.android.com" in that array for the test to pass successfully.

If it is needed I could open a separate new issue for this.

[yackermann]

This has now been resolved