To validate the signature on an electronic passport you need the issuing country's CSCA certificate. States distribute these in bulk as a "Master List" - a CMS SignedData wrapping a SEQUENCE OF Certificate, specified in ICAO Doc 9303 Part 12. The format is not hard. What surprised me is how little public tooling just opens the file and hands you the certificates; most eMRTD code buries the parse inside a larger verification stack.
So I wrote the parse on its own. Then I ran it against a real Master List and six of the 581 entries failed:
Live, government-issued CAs carrying trailing bytes in the signature AlgorithmIdentifier that the Rust ASN.1 parser in `cryptography` treats as ExtraData. Austria, the UAE and Japan are not edge cases you get to skip: drop them silently and passports from those states fail with "unknown issuer" instead of a real error - which is genuinely unpleasant to debug, because the trust store looks fine and the count looks plausible.
So the default path falls back to `openssl x509` for anything the strict parser refuses, and the manifest records which parser produced each row, so the gap is visible rather than silent. --strict turns the fallback off if you want to see what a strict parser alone gives you.
It handles only public trust anchors - the certificates states publish precisely so that anyone can validate the documents they issue. No private keys, no chip communication, no passport data.
I have not torn those six apart byte by byte yet; my guess is a redundant explicit NULL or a PSS parameter block. Would be glad to hear from anyone who has hit the same six, or a different set from a newer Master List.
Interesting but would be better if you didn't copy/paste AI generated text here. Also, the link seems to go to a tool and the "Python doesn't parse 6 certificates" is only a sidenote to the repo's main purpose. Either focus on one or the other, don't mix the 2. Your comment I'm replying to here mixes the 2 as well. The default path and open SSL fallback is irrelevant to the invalidity finding.
Author here. Some background on why this exists.
To validate the signature on an electronic passport you need the issuing country's CSCA certificate. States distribute these in bulk as a "Master List" - a CMS SignedData wrapping a SEQUENCE OF Certificate, specified in ICAO Doc 9303 Part 12. The format is not hard. What surprised me is how little public tooling just opens the file and hands you the certificates; most eMRTD code buries the parse inside a larger verification stack.
So I wrote the parse on its own. Then I ran it against a real Master List and six of the 581 entries failed:
They are not junk. OpenSSL reads every one of them: Live, government-issued CAs carrying trailing bytes in the signature AlgorithmIdentifier that the Rust ASN.1 parser in `cryptography` treats as ExtraData. Austria, the UAE and Japan are not edge cases you get to skip: drop them silently and passports from those states fail with "unknown issuer" instead of a real error - which is genuinely unpleasant to debug, because the trust store looks fine and the count looks plausible.So the default path falls back to `openssl x509` for anything the strict parser refuses, and the manifest records which parser produced each row, so the gap is visible rather than silent. --strict turns the fallback off if you want to see what a strict parser alone gives you.
It handles only public trust anchors - the certificates states publish precisely so that anyone can validate the documents they issue. No private keys, no chip communication, no passport data.
I have not torn those six apart byte by byte yet; my guess is a redundant explicit NULL or a PSS parameter block. Would be glad to hear from anyone who has hit the same six, or a different set from a newer Master List.
Interesting but would be better if you didn't copy/paste AI generated text here. Also, the link seems to go to a tool and the "Python doesn't parse 6 certificates" is only a sidenote to the repo's main purpose. Either focus on one or the other, don't mix the 2. Your comment I'm replying to here mixes the 2 as well. The default path and open SSL fallback is irrelevant to the invalidity finding.