cert-authority handling in authorized_keys broken

[Kegan Myers]

I recently installed a machine that has a newer version of OpenSSH 
server on it, and suddenly my certificates are being rejected. I have 
been using a principal-less self-created PKI for years. That field 
seemed superfluous for my use case of putting the CA in authorized_keys 
(and not specifying principals= on that line either), as this was solely 
for me on my machines/accounts. If I issued the cert (usually to a new 
key or new device), I wanted it to just work wherever host I was 
connecting to, and just drop it in the authorized_keys of "ubuntu", 
"ec2-user", or even "root" in some cases.

It seemed like omitting the principal achieved exactly my goals and 
worked perfectly fine. Documentation for how principals, and even certs 
themselves seemed thin on the ground, so I was satisfied that using an 
empty list was intended as a permissive wildcard. Even now the 
ssh-keygen documentation mentions that a certificate includes "zero or 
more principal (user or host) names" and only mentions wildcard 
characters as being allowed for host keys.

Regardless, it was very surprising to suddenly have to debug a 
"Permission denied" and see "Refusing certificate ...: Certificate lacks 
principal list" in the server logs when trying to figure out what I had 
done wrong. Previous discussion on this 
(https://marc.info/?i=aSa3qSYgLlIRPs7m%20()%20wanda) identified exactly 
how I was using this feature, but opted to reject all such certificates 
to prevent other bad uses. The solutions to this regression I see are 
either a way to opt in to old behavior 
(AllowEmptyUserCertificatePrincipals or similar) or to only enforce 
principals being non-empty if some downstream check wants to validate 
principals, though I am open to any suggestions as I am certainly less 
familiar with the code base and how feasible those ideas are than others 
on this list.

Best wishes,
Kegan