It doesn’t, though that’s not really your question. Since as you observe
X.509 certificates, or signed keys in general, did not make it into the
SSH RFCs, anyone implementing them has to extend the protocol. SSH
provides easy mechanisms for doing this.
Various commercial SSH products, including VShell and Tectia (or
whatever they’re calling themselves today), have had X.509 certificate
support in both server and client authentication (transport key exchange
and userauth) for many years, mostly using identifier and format definitions
from this 2005 I-D:
http://www.snailbook.com/docs/x509.txt
(VShell at least still uses these; I haven’t looked at the others
recently.)
When the OpenSSH people got around to implementing certificates years
later, they did not use X.509; instead, they rolled their own
certificate format; you create an OpenSSH CA, generate and sign user
keys, etc. with OpenSSH tools such as ssh-keygen. This has always struck
me as a very odd choice. Most of the impetus for a PKI lies in dealing
with asymmetric keys when the number of users and servers grows
large. People in such as situation probably already have an X.509 PKI to
deal with other aspects of their systems which require it, such as web
and LDAP servers, code signing, etc. And so in exactly the situation in
which you would like to take advantage of your existing PKI, you can’t,
because OpenSSH won’t interoperate with it.
It is true that if all you want to secure is OpenSSH, then it’s somewhat
easier to use its key-handling tools than to set up an X.509-based CA --
but the latter is not *that* hard; you can make a simple one with
OpenSSL and nothing else.
You can read about the OpenSSH approach here:
http://api.libssh.org/rfc/PROTOCOL.certkeys
... which is a file included in the OpenSSH source.
--
Richard