Certificate spec anomaly?

[Brian Candler]

I have had the following potential inconsistency pointed out to me, and 
I thought I'd raise it here.

On the one hand, OpenSSH by default doesn't allow authentication using a 
certificate with no principals[^1]. From sshd_config(5):

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

On the other hand, the spec at 
https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys?rev=1.19&content-type=text/x-cvsweb-markup 
says:

 > As a special case, a zero-length "valid principals" field means the 
certificate is valid for any principal of the specified type.

I think the behaviour of sshd is sane and sensible. A 
"super-certificate" which can impersonate any user (or any host[^2]) 
seems like a dangerous thing to me; especially since it's what you get 
by default if you omit the -n option to ssh-keygen -I.  There are other 
SSH CAs which may generate this sort of certificate if you don't request 
any principal (e.g. Hashicorp Vault).  Rejecting it seems the safer option.

I wonder if the protocol documentation is out of step, or if I've missed 
a subtlety?

What started this discussion[^3] was that in Go's implementation of ssh, 
validating a certificate skips the principal check if the certificate 
contains no principals - apparently in accordance with the spec.

https://cs.opensource.google/go/x/crypto/+/c86fa9a7:ssh/certs.go;l=401-413

Regards,

Brian.

[^1] Although I haven't tested it for a while, I was able to accept a 
principal-less certificate, by adding an entry to ~/.ssh/authorized_keys 
which specifies cert-authority without any principals="..." option.

AFAICT, this allows anyone with *any* user certificate signed by the CA 
to authenticate, with or without principals. That's clearly less than 
ideal, but at least it was configured explicitly on this account, and 
the attack surface is limited to that one particular account.

[^2] I haven't tested whether a host certificate without any principals 
is accepted by the ssh client.

[^3] https://github.com/uber/pam-ussh/issues/15#issuecomment-1250245686