Hi Kevin, Drafts up until -07 used the language string K_S, server's public host key and/or certificatesand then prompted by a comment from Jeffrey Hutzelman I changed it in -08 to what you indicated below, in a desire for more precision in the specification.
I sent him another email after your post below to enquire about changing it back, and here's part of the reply I received:
The issue is that K_S must be the server's public host key, in the format dictated by the negotiated host key algorithm. Just randomly replacing it with a certificate (or a key in a different format) will cause interoperability problems. If Kevin wants to use certificates, he needs to define an SSH public key algorithm whose public key format includes or permits certificates; currently no such algorithms are in use (there are formats defined for keys signed using OpenPGP, but I don't know how widely deployed they are, and there are no formats defined for X.509 certs).
I'm willing to make a change in the draft to allow for the use of certificates, as it is the case that the key exchange method should transport the host public key / certificate in whatever format was decided for it.
I'd just like to have an idea in my mind of how an implementation might actually use certificates in an interoperable way in the context of ECDSA/SHA-2, which is presumably what you want when you say Suite B plans to require the use of certificates for both the client and the server. My interpretation is that, when using an ecdsa-sha2-* method for the public key algorithm, an implementation must encode keys in the format specified in the draft, which is as a raw point according to Section 3.1 of the draft. Do you intend for another public key algorithm to specify for the use of ECDSA/SHA-2 keys in X.509 or PGP or some other certificate format? Is it desired that such a specification appear in this draft as well? Or is there a reason that the existing framework of standards already covers it and I'm just not aware of it?
Douglas On 2009-Jun-18, at 5:43 AM, Igoe, Kevin M. wrote:
Douglas: I need to verify a small detail on the SSH_MSG_KEX_ECDH_REPLY messages. Suite B plans to be conservative and require the use of certificates for both the server (sent in the SSH_MSG_KEX_ECDH_REPLY) and client (sent in the SSH_MSG_USERAUTH_REQUEST).As described in section 7 of RFC 4252, SSH_MSG_USERAUTH_REQUEST supportsa "public key blob" for use in transporting the certificate: > byte SSH_MSG_USERAUTH_REQUEST > string user name in ISO-10646 UTF-8 encoding [RFC3629] > string service name in US-ASCII > string "publickey" > boolean FALSE > string public key algorithm name > string public key blob > > Public key algorithms are defined in the transport layer > specification [SSH-TRANS]. The 'public key blob' may contain > certificates. Your SSH_MSG_KEX_ECDH_REPLY message contains the field > byte SSH_MSG_KEX_ECDH_REPLY > string K_S, server's public host key octet string > string Q_S, server's ephemeral public key octet string > string the signature on the exchange hash > string K_S, server's public host key octet string I've been assuming that the K_S string can, like the "public key Blob" string, contain a certificate. Do you concur with that interpretaiion?