User certificates with empty principals?

[Brian Candler]

I wonder if you could help clarify something for me.  There is a scary 
warning in ssh-keygen(1) about certificates with empty principals:

"By default, generated certificates are valid for all users or hosts"

However, this appears to be contradicted by sshd_config(5), where it says:

"The default [for AuthorizedPrincipalsFile] is none, i.e. not to use a 
principals file - in this case, the username of the user must appear in 
a certificate's principals list for it to be accepted."

and:

"Note that certificates that lack a list of principals will not be 
permitted for authentication using TrustedUserCAKeys."

I've been trying to identify when a user certificate with no principals 
can be used, and the only case I can find is when the cert-authority has 
been listed in ~/.ssh/authorized_keys without a principals="..." option 
being specified.  Is that the only case? Including all older versions of 
sshd?

The reason I'm concerned is I'm looking at Vault for issuing SSH certs, 
and I've found that even if you constrain an SSH role to issue certs for 
a certain set of principals, it still lets the user issue a cert with no 
principals.  I'm trying to convince myself whether or not that's safe.

I have tested the scenarios I can think of with openssh 8.2p1:

1. default configuration with no AuthorizedPrincipalsFile/Command

=> sshd rejects with: "Certificate lacks principal list"

2. AuthorizedPrincipalsFile containing "foo"

=> sshd rejects with: "Certificate does not contain an authorized principal"

3. empty AuthorizedPrincipalsFile

=> sshd rejects with: "Certificate does not contain an authorized principal"

So it seems OK, but in that case perhaps ssh-keygen(1) could be 
clarified.  As well as the warning given above, it contains an example 
of creating a user certificate without any principals:

            $ ssh-keygen -s /path/to/ca_key -I key_id /path/to/user_key.pub

To me it seems not very useful (or safe), if the only way you could use 
it is to allow logins with *any* certificate from this CA in 
~/.ssh/authorized_keys.

Thanks,

Brian.