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

[Jeffrey Hutzelman <[e-mail]>]

--On Friday, June 19, 2009 09:12:56 AM +1000 Douglas Stebila 
<[e-mail]> wrote:

>> > Public key algorithms are defined in the transport layer
>> > specification [SSH-TRANS]. The 'public key blob' may contain
>> > certificates.

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

I'm concerned you might be misinterpreting the language in the transport 
and userauth documents.  When the userauth document says "The 'public key 
block' may contain certificates", it doesn't mean that it is permissible to 
send a certificate instead of a public key.  What it means is that for some 
SSH public key algorithms, the specified public key format may include or 
permit use of a certificate.  Implementations of key-exchange methods and 
public-key userauth must send public keys in the format specified for the 
SSH public key algorithm in use; anything else is not in compliance with 
the protocol and will not interoperate.

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.

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.

-- Jeff