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

On Wed, Apr 30, 2014 at 02:14:19PM -0400, Jeffrey Hutzelman wrote:
> 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.

Well, but the text in section 6.6 also says this (right after the text
you quoted):

:   Certificates and public keys are encoded as follows:
:
:      string    certificate or public key format identifier
:      byte[n]   key/certificate data

This text does not look conditional and perhaps this is where the
confusion comes from? For me, as a reader who has no prior involvement
in this, these two paragraphs look a bit like a contradiction...

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

OK. I am happy to follow you advice to keep the algorithm type leaf.
 
> 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.

Yes, I think we agree. I do not expect a NETCONF server to try to
validate whether the key blob is valid.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>