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

Jeffrey Hutzelman <[email protected]>
Newsgroups gmane.ietf.secsh
Message-ID <[email protected]>
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.

The right thing here is to leave it as defined - the "algorithm" is a
string naming the public key algorithm, and the "key-data" is an
_opaque_ base64 blob.  The fact that for certain kinds of keys the
opaque blob happens to contain a copy of the algorithm name is
irrelevant.

As for what happens when they're different -- it doesn't work!  If you
say you're providing a key for one algorithm and actually provide key
data for a different one, it's simply not going to work.  You could
check when setting a key that the provided key data is valid for the
specified algorithm, but I would very strongly recommend against that.
Doing so requires that whatever's doing the validation understand all
possible key algorithms, which is impossible, since public key algorithm
names are a vendor-extensible namespace.


> I think it would make more sense to have a name that reflects the
> *purpose* of the list of keys, rather than just the data type. E.g., if
> it's authorization keys for logging in to the users account, it could be
> "authorized-ssh-keys" or something like that.

Yes.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.