But why would you want to do that? What problem does it solve? Just that you can connect without having a private key yourself? This doesn't sound very safe.
I have n clients, m servers.
On clients, i sign the lokal keypair with the CA key and log-in via certificate. The client-side certificate basically replaces the line in the server-side authorized_keys. The editing stays locally.
On servers, i register the CA key as "Certificates signed by this keypair are trustable", the authorized_keys file stays empty. No further editing required.
During normal daywork, the CA key sits unused and can be shut away.
Key Advantage: I don't need to edit anything on the countless servers anymore.
I think people really get into trouble with SSH certificates trying to reason about the properties of certificates versus SSH keys versus passwords. The format isn't the point; making the endpoint keys dynamic is. If you built a secure messaging system that propagated one-time-use SSH keys, it would address the same problem. Nobody will, because certificates are easier and already work, but you could.
Everybody knows the public key associated with that private key, so you can verify that the private key did sign this list of attributes.
An ssh keypair is an actual public/private keypair, but a certificate is just signed and encoded (but not encrypted) formatted data.
If an ssh daemon has knowledge of a public key used to sign a cert, and has been instructed to trust that cert, and all the dates are good, then the ssh daemon can accept that cert as proof of identity and allow a login.