It's also a massive centralization of power. There have been numerous incidents in recent years, where someone became the subject of a viral Internet controversy, and their gmail account was mysteriously deleted with no explanation, only to be restored a day later, mysteriously with no explanation. Why wouldn't similar abuses occur with such an authentication system?
anyway nothing new here. these techniques have been deployed for ages. the simpler certificates supported natively by openssh are much better since they avoid x.509 complexity, unnecessary for such short lifetimes and extremely limited application profile.
you do hint at a good point though, the security posture of the CA and method of authenticating to the CA isn’t discussed. user/pass to the CA in many naive environments will reduce the ssh auth to that level.
It’s possible to generate private keys on a HSM like YubiKey to be a CA and perform signing of certs via a hardware function. Operations can make the difference; but given an offline SBC and 2+ YKs a robust, affordable, and friendly solution could be devised. A similar reference implementation would be IBM Hyperledger Fabric’s security w/ CA (the doc is good and team responsive).
Kerberos started out with symmetric keys. It's been a long time since I followed things, so that might have changed. Public keys would greatly simplify key distribution, of course.
We do something similar with HashiCorp Vault. People authenticate to Vault (backed by Active Directory) and if they have the proper permissions (based on AD group) they can ask Vault to issue an SSH certificate for a particular account on a specific server. This is working well; we no longer have accounts for everyone who needs access on every box and giving or removing access is as easy as changing group membership in AD.
So we delegate security to an alleged "trusted" third party that both the sysadmin and user have to trust.
Sounds like a massive increase in attack surface with questionable advantages.