I get that, but you need to update the revocation list on every single server. At which point you've just undone the benefit of not having to manage `authorized_keys` on each server.
I would argue it's a lot easier to maintain a single CRL across your entire infrastructure (you can regularly update it to all hosts, easily monitor for non-matching versions through your monitoring tools, etc) than it is to maintain a customised authorised_keys file for each server or server group (n keys across m servers can be a lot of combinations, with no easy way to check correctness)
Sure, but wouldn't the complexity of managing distributed authorized_keys be significantly higher than propagating revokedkeys across a fleet of servers? You get the benefit of central management/administration with the benefit of distributed ssh keys. It's almost the best of both worlds.
It doesn't seem like it's more work, although you are right in that it's probably more user friendly as you don't have to wait for keys to propagate to various servers before you can login. We've previously used a cron script to pick up authorized_keys from a centrally published source, I guess that same infrastructure just moves to the CRL.
Thinking about it you make it a good point. How you do it is "central" but much less of single point of failure than something like LDAP. It would require a pretty contrived scenario to go undetected for an extended period that could be slightly more likely depending on how often you rotate keys. It would be nice if OpenSSH supported CRLs.
