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.