If I'm not mistaken, all current key exchange algorithms (all derivatives of diffie hellman) only require digitalSignature, since the hostkey isn't actually used during the key agreement stage. Does that sound correct?
Yes, I believe that's currently true.
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.In that case, the original (abandoned) x509v3 draft included these: id-kp-ssh-server OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.2213.15.1.1 } id-kp-ssh-client OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.2213.15.1.2 } id-kp-ssh-clientHostbased OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.2213.15.1.3 } I don't recall how we came up with the oids...
1.3.6.1.4.1.2213 is the PEN assigned to Data Fellows. So presumably, someone employed by them who was working on this document allocated these numbers out of their arc.
Then we might do something like: > This key format has the following specific encoding: > > string "x509v3-ssh-dss" / "x509v3-ssh-rsa" / > "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2" > uint32 certificate-count > string certificate[1..certificate-count] > uint32 ocsp-response-count > string ocsp-response[0..ocsp-response-count] If I'm understanding the PKI correctly, ocsp-response-count should be at most certificate-count - 1 (once ocsp response for each issuing certificate in the chain.)
I'm not sure. I would not expect more OCSP responses than certificates, but it's unclear to me whether it's useful to provide for more than one. I suppose this is something we ought to ask the PKI experts about.
-- Jeff