Re: SSH keys - draft-ietf-netmod-system-mgmt

On Wed, 2014-04-30 at 19:50 +0200, Juergen Schoenwaelder wrote:
> On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote:
> > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote:
> > > >     However, if we also keep the leaf algorithm, we need to specify
> > > >     what happens if the leaf algorithm has a value that is different
> > > >     from the value embedded in the key blob.
> > > 
> > > Right, eliminating this redundancy makes things simpler.
> > 
> > It would, except you can't eliminate it.  The second copy of the
> > algorithm name is part of the key data format for _certain public key
> > algorithms_, but not necessarily for all of them.
> > 
> 
> Hm. Are you saying RFC 4716 is broken or only applicable to certain
> subset of public key algorithms? In which case would the public key
> not follow [RFC4253], Section 6.6:
> 
>          string    certificate or public key format identifier
>          byte[n]   key/certificate data
> 
> I am just trying to understand this.

Section 6.6 is actually quite specific on this:

   The key type MUST always be explicitly known (from algorithm
   negotiation or some other source).  It is not normally included in
   the key blob.


It then goes on to define two key types ("ssh-dss" and "ssh-rsa") which
each begin with a fixed string that is the same as the key type name,
and two more which are unfortunately rather vague, but which I don't
think are commonly used.

I seem to recall this being an issue in the past, because someone made
an assumption that keys would always be self-describing when in fact
they were not.  Unfortunately, I no longer remember the exact
circumstances.  But yes, I believe RFC4716 is broken, because it relies
on the encoding described above, rather than being consistent with the
requirement "The key type MUST always be explicitly known."


IMHO, things that are not implementations of SSH should not need to be
aware of SSH's encoding or of the details of particular public key
formats.  They should treat the opaque key data as opaque, and separate
from the key type.

-- Jeff