o Do we want to require processing of (or give guidance with regards to) any extensions, such as BasicConstraints, KeyUsage, and SubjectAltName? o Do we need language about respecting critical extensions or rejecting the certificate?
We probably should require that KeyUsage include one or more of digitalSignature, keyEncipherment, and/or keyAgreement, depending on the requirements of the key exchange algorithm in use.
I don't think we need specific language detailing how to validate certificates, beyond "MUST comply with RFC5280".
o Do we want to define any extended key usage key purpose ids?
IMHO we should, because defining an EKU key purpose ID is the only way to allow issuance of a certificate that can be used _only_ for SSH, and not for any other application.
o When we were working on x509v3 before, people seemed to want to include revocation data as well as chain data; I was never quite sure whether this was really needed or if it was gold plating, so to speak.
For most protocols, including an OCSP response alongside a certificate is an optimization, because it allows the recipient to verify that the certificate is valid without independently contacting an OCSP server. This is particularly interesting when the party that includes the OCSP response uses its certificate frequently in a short period of time, because it can cache and reuse the OCSP response for as long as it is valid, reducing load on OCSP servers.
For SSH, this capability might be valuable chiefly because it would permit clients to provide OCSP responses to SSH servers living in restricted networks or under other constraints which might prevent them from contacting the OCSP server directly.
o We should require the first certificate in a chain to use the correct type of key (i.e., it must have a rsa key if it is a "x509v3-ssh-rsa".)
We could go a step further, and require that all certificates in the chain use key types corresponding to algorithms that were advertised by the side that will verify the certificate. This would put SSH years ahead of virtually every other certificate-using protocol, in that we would actually have a means of negotiating which algorithms to use not only in end-entity certificates but in all certificates relied on for a particular session. On the other hand, it's not clear how much value that capability has in practice.
-- Jeff