On Sep 12, 2016, at 12:14 PM, denis bider (Bitvise) <ietf-ssh3%denisbider.com@localhost> wrote:
[Ron] Thanks, Denis. I have looked at that RFC, and have thought about adding support for both those and the OpenSSH variants. For deployments where this is already a good X.509-based public key infrastructure in place, I can definitely see the value in being able to use a common set of certificate authorities for both SSL/TLS and SSH. That said, there are some challenges with supporting RFC 6187: - Parsing X.509 certificates is extremely complex, and validating a certificate chain is even more so. If you want to do it right, you need to bring in a bunch of additional crypto infrastructure, like support for CRLs and OCSP. - The RFC provides a recommendation for how to validate server names when certificates are used for host authentication, but for user authentication it simply says "the mapping between certificates and user names is left as an implementation and configuration issue for implementers and system administrators.” It also really doesn’t provide any guidance about how to specify the list of trusted root CAs for either user or host authentication. - While the RFC does provide a way to indicate if an X.509 certificate can be used for user or host authentication, it doesn’t currently define any way to put restrictions on when a user can use a particular certificate or what they can do when they authenticate with a particular certificate. This would not be difficult to do in X.509, but I haven’t seen a proposed spec for encoding any such restrictions. OpenSSH certificates addresses these points pretty well: - All parsing is done using the same mechanism used for parsing other SSH packets, just like OpenSSH-format keys. There’s no need to pull in an ASN.1 parser or deal with the large number of OID values that need to be understood to properly parse X.509 certificates. - Specifying the list of trusted CAs and revoked certificates is done as a natural extension of the existing authorized_keys and known_hosts file formats. - OpenSSH provides very rich ways of limiting when certificates can be used and what actions can be taken by a user presenting a certificate. This can be done in either the authorized_keys file on the host deciding whether to accept a certificate or in the certificate itself, such that the limitations automatically apply to all hosts the certificate is accepted on. There are some ways in which OpenSSH is behind, though: - There’s no support for certificate chaining. It only supports direct signing of keys by a root CA, with no intermediate CAs. For many organizations, I imagine this would be a show-stopper. - While it can support the equivalent of CRLs for revocation, there’s currently nothing in OpenSSH equivalent to OCSP for real-time revocation checking. If you’re interested, more info on OpenSSH certificates can be found at http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.certkeys?rev=1.10&content-type=text/plain. -- Ron Frederick |