OpenSSH 5.4p1 introduced a novel, lightweight certificate format for user and host keys. These were designed to reuse SSH wire-encoding and signature primitives to minimise the additional attack surface exposed pre-auth. In particular, we are not comfortable with the complexity (syntactically or sematically) of X.509.
That's unfortunate, because it's what the rest of the world already has as its infrastructure. By not supporting it, you force people to choose between supporting your odd, proprietary, unproven certificate format or not getting to use certificates at all. Guess which one anyone with more than 5 machines is going to choose?
OpenSSH would be a lot more useful if it supported the same authentication mechanisms as the rest of the world.
signature key contains the CA key used to sign the certificate. The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained" certificates, where the signature key type is a certificate type itself are NOT supported. Note that it is possible for a RSA certificate key to be signed by a DSS CA key and vice-versa.
This seems like a serious shortcoming. Practically no one uses single-level certificate heirarchies any more; there's nearly always at least one intermediate CA for operational and security reasons. Taking out this feature makes the system less secure.
The name field identifies the constraint and the data field encodes
constraint-specific information (see below). All constraints are
"critical", if an implementation does not recognise a constraint
then the validating party should refuse to accept the certificate.
...
permit-X11-forwarding empty Flag indicating that X11 forwarding
should be permitted. X11 forwarding
will be refused if this constraint
is absent.
This is a poor combination, because it means that the server must understand all the things I am allowed to do, even if it doesn't implement them. And really, "permit foo" is not a constraint at all; it's the reverse of a constraint.
I recommend _both_ inverting the sense of the "permit-*" items _and_ allowing for non-critical extensions, which are often essential for extending a protocol in a meaningful way.
-- Jeff