Re: drasft-green--secsh-ecc-08 support for certificates

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

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
--