MDS3 F-5 test case succeeds when it should fail

[sbweeden]

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

• [ ] 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?

FIDO Conformance Tools v1.7.17

What is the OS and the version are you running?

macOS Sonoma 14.2

For desktop tools

• [ X ] OSX
• [ ] Windows
• [ ] Linux

For UAF mobile tools

• [ ] iOS
• [ ] Android

Issue description

The final test case for Metadata Service Tests succeeds when it is supposed to fail. I don't believe the CRL is populated (at all).

The test case is: F-5 Send a valid ServerAuthenticatorAttestationResponse with FULL "packed" attestation for metadata from MDS3 who's metadata service leaf certificate is revoked, and check that serve returns an error

I captured an attestation result body, which showed a registration for AAGUID: BD794810-6113-4F57-A6B4-ECE5D1244AB2 I found the corresponding MDS3 server entry that contains this AAGUID (attached as e3145fb35e4349e9f0718b60a224616019a456c7722a0926520847b0c98d6672.jwt.txt). I looked into the JWT header, extracted x5c, and then produced PEM files for each of the two entries (x5c0.pem.txt and x5c1.pem.txt attached). x5c0.pem is the leaf certificate, and is signed by x5c1.pem which is the intermediate. The intermediate is signed by MDSROOT.crt.

The test case says the leaf certificate (i.e. x5c0.pem) is revoked. Looking at this cert in more detail we see:

• The certificate serial number is: 04:80:67:49:de:30:7b:bd:51:75:a2:6d:73:f5:f3
• The certificate extensions identify the following CRL distribution point: https://mds3.certinfra.fidoalliance.org/crl/MDSCA-1.crl
• Trying to retrieve that URL returns an empty response (i.e. no CRL at the provided distribution point)

If this leaf certificate is indeed revoked, then I believe a valid CRL containing its serial number should be retrievable from the CRL distribution point identified in the certificate.

[sbweeden]

Supplemental files. e3145fb35e4349e9f0718b60a224616019a456c7722a0926520847b0c98d6672.jwt.txt x5c0.pem.txt x5c1.pem.txt

[sbweeden]

Resolved - I needed to add a couple of Google CA's to the code which retrieves the CRL. It would be much better if the CRL was at a http URL, not https, since this often causes issues with CRL retrieval.