You are proposing that, instead of using a standard PKI, where someone (goverment or not) controls a CA that signs certificates, would be simpler to just have a (big) list of government recognized public keys associated with the related person. In other words, a big searchable list of certificate contents. You claim that this would avoid "the difficult issue of trust on the common CAs (or their equivalents)"
First of all, to be sure you are checking the right and trusted list, the search server would need to be authenticated somehow (to fully avoid PKI, that is used in TLS/SSL, probably you would have to put the certificate of the server in your trust it and check out-of-bounds if it is valid). It is not clear how would you solve this in an scalable manner without using PKI. It is possible, of course, but not easier or simplier than the standard PKI trust challanges.
BTW, part of my master thesis work is about how a PKI could be to solve some of the problems of standard PKI, and we use online servers to provide certificate status and discuss many problems with standard PKIs. In many ways your proposal fits with ours, except it is not targeted on solving the trust issues of PKI, but other problems. Part of the work is available here: https://www.cdc.informatik.tu-darmstadt.de/reports/reports/TheNotaryBasedPKI.pdf
While NOT solving the trust issue, your proposal adds many other problems:
1) It is not offline verifiable. One may claim that this is not a problem nowadays, when everything is always online, and while not strictly true, I agree that for most applications there is no big advantage at the offline characteristics of x509 PKI (thats why we proposed NBPKI too)
2) For signature/verification, you need to be able to verify at any time in the future if a key binding was valid when the signature was done. For some scenarios that can take years and decades between the signature and the last needed verification. That means that even if the binding between person x key is lost, the server still needs to at any time in the future be able to give the key that was valid in a certain time in the past. So, the list only grows; That is not good because it wont scale whell, will not be efficient;
3) You have a single trust point to be attacked. Not good at all;
4) To solve all this problems is exaclty why PKI is how it is. Instead of a list, you have proofs of link between each key and each person. Those are small, and actually EASIER to validate (cost less computational power and resources). Those proofs have a presumed valididty usually based on how protected the private key is, and can be revoked if needed using a list of revoked certificates (that tends to be smaller than a list of valid ones, and can be made smaller using OCSP).
You mention the problem that is hard to trust in the common CAs. That is not strictly true, and can be solved by some means: Federated CAs, or TSL (Trusted Services List, used on Europe) or just have a national root CA as is done in Brazil that signs all other trusted CAs, so you need only to trust a single trust point. If thats the main reason to choose your proposal, I don´t see a real advantage between having a single national CA and your proposal. Other than that, PKI has so many advantages over your proposal on real usage scenarios, that explain why it is widelly used until now.
Having that said, PKI have its own problems, but most of them are exactly on the centralization of trust in FEW points, and may be solved by more decentralized approaches. Your porposal is going in the oposite direction, by proposing centralizing even more the trust in a single list.
