On Fri, Jun 19, 2009 at 05:28:58PM -0400, Jeffrey Hutzelman wrote: > In particular, if you "require the use of certificates...", then at least > for the existing ssh-rsa and ssh-dsa public key algorithms, and for the > ECDSA algorithm specified in the present draft, you are requiring > noncompliance with the protocol specification. > > Now, this could be worked around by defining new public key algorithms > whose public key format allows the use of certificates. Some work was done > on this before the working group concluded, but it never went very far due > to lack of sufficient interest to get it done. Note that even if such new > algorithms were to be defined, either by the IETF or by another party, they > would likely not be as widely deployed as the current algorithms. +1 > Perhaps more importantly, requiring the use of certificates means requiring > a mode of operation that is inconsistent with the way people deploy and use > SSH in real life. Much use of SSH depends on the "leap of faith" model to > avoid the need for pre-established PKI, and a standard which prohibited > that mode of operation would make SSH considerably less useful for anyone > required to comply. I suggest considering these issues very carefully > before introducing such a requirement. Oh come on Jeff! This, from an author of RFC4462? I think SSHv2 extensions to allow the use of PKIX certificates for host and/or user authentication (and key transport!) would have their place. So too would use of PKIX certificates via PKU2U (hmm, where are we on that?) and the SSHv2 w/ GSS-API extensions (RFC4462). In fact, there's plenty of user interest in using SSHv2 w/ certs. In practice, however, a combination of PKINIT, RFC4462 and the Kerberos V GSS-API mechanism are good enough for a lot of the demand (i.e., PKIX for user certs, not so much for host certs). Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.