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

[email protected] (Niels Möller) wrote:
> Jeffrey Hutzelman <[email protected]> writes:
> 
> > 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.
> 
> Hmm. I think you're right. So then then the "algorithm" leaf would be
> the name being used in algorithm negotiation and the like, and the "key"
> leaf would be the key blob. The key blob typically starts with a string
> containing the algorithm identifier, but nothing but the ssh
> implementation is expected to care about that detail.

Ok.  But even if I don't know/care about the details; if I want to
configure a key, I need to know that the format my keygen program uses
is compatible with the format the server expects.


> So then the right choice is 1),
> 
> : 1)  Clarify that the leaf "key-data" contains:
> : 
> :          string    certificate or public key format identifier
> :          byte[n]   key/certificate data
> : 
> :     This allows for simple copy-and-paste from normal open ssh and
> :     rfc4716 files.

But Jeffrey Hutzelman wrote:

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

So if we introduce the clarification (1) above, aren't we doing the
same mistake as RFC 4716?

I am a bit confused by the terminology.  What is the difference
between "key", "key data", and "key blob"?



/martin