Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt)

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Wed, 16 Jul 2003, Jeffrey Hutzelman wrote:

> On Tue, 1 Jul 2003, Joel N. Weber II wrote:
>
> > Looking at the January 2002 mailing list archive, it becomes clear
> > that while the public key types defined in the transport draft have
> > this encoding:
> >
> >      string   certificate or public key format identifier
> >      byte[n]  key/certificate data
> >
> > there is no requirement that public key types defined elsewhere will
> > have that encoding.  Perhaps the gsskeyex draft should explicitly say
> > that SSH_MSG_KEXGSS_HOSTKEY only works with ssh-dss and ssh-rsa keys,
> > or that it only works with types that start out with the type
> > identifier as a string.
>
> Hm..
> My interpretation of the description of public key algorithms in section
> 4.6 of the transport draft is that the encoding described above applies to
> _all_ public key types, not just the ones defined in that document.  In
> particular, the section you quoted contains general information describing
> the nature of public key algorithms and key and certificate formats.  The
> descriptions of specific algorithms defined in that document occur further
> down, and while they do describe key formats including the specific value
> of the format identifier to be used, this duplication is consistent with
> usage in these documents.

Actually, on further reflection, it doesn't matter.
The key transported in an SSH_MSG_KEXGSS_HOSTKEY message belongs to the
host key algorithm selected during algorithm negotiation.  So we already
know its type, and it doesn't matter whether the type is included in the
blob we transport or not.


Of course, this only helps when you are transporting a single host key of
the type selected during algorithm negotiation.  Fortunately, that is all
that gsskeyex currently does.  However, it doesn't help if what you want
to do is transport multiple host keys, or use keyex with one algorithm to
transport a key belonging to a second algorithm.

To address those issues, I would like to propose a protocol extension in
the form of a new host key algorithm, which could be called something like
'multi'.  The key format for this algorithm would consist of a list of one
or more { algorithm, key-data } tuples, and the format and semantics of
signatures would be identical to those for the first tuple in the list.
I haven't yet worked out all the details of how the algorithm negotiation
would work, but I think it's doable.

If there's interest in this, I'd be willing to work up a draft, either
as a working group item or for individual submission.

-- Jeff