Re: Publickey subsystem draft posted

[Simon Tatham <anakin%pobox.com@localhost>]

Joseph Galbraith  <galb-list%vandyke.com@localhost> wrote:
> The generalized message format is:
> 
> UINT32 length
> string type
> ... request specific data follows

Does the length include the 4 bytes of the length field itself? (I
don't care, but don't forget to state it either way :-)

> What if the "add" command were changed as follows?
> 
> 	string "add"
> 	string public-key algorithm
> 	string public-key blob
> 	uint32 attribute-count
> 		string attrib-name
> 		string attrib-value
> 		bool   mandatory
> 	repeated attribute-count times

Works for me. If anyone needs an attrib-value which is more complex
than a simple string, there's nothing to stop them treating the
string as a blob, and formatting the data inside the blob using
another layer of SSH data types, or indeed any other format they
feel like.

Is it worth defining what should happen if a user attempts to add a
key which is already present, but with different attributes? Should
the add operation fail, or succeed and alter the key setup?

>    If the server does not implement a mandatory attribute, it MUST fail
>    the add.  For the purposes of a mandatory attribute, storage of the
>    attribute is not sufficient, but requires that the server understand
>    and implement the intent of the attribute.

I particularly like that. It reminds me of the bits in PNG that
define what an editing program should do to chunk types it doesn't
recognise. Simple and effective.

> 	The comment field is useful so the user can identify the
> 	key without resorting to comparing it's fingerprint.

(As a vague aside: has anyone done a detailed study of what attacks
might be possible by people - malicious clients, servers, agents,
people, software, sysadmins or anyone else - substituting the
comment for one valid key on another? PuTTY's custom-designed SSH2
key format contains a passphrase-keyed MAC designed to make the
comment field tamper-evident, largely because I couldn't work out
whether there was a possibility of an attack or not, and could see
no reason not to be ultra-cautious. Anyone else had any thoughts on
the subject?)

>    "restrict"
[...]
> 	Currently defined restrictions are:
> 		"x11"
> 		"shell"
> 		"exec"
> 		"port-forward"
> 		"reverse-forward"

What about "subsystem"? Is that worth putting in as a separate one?
Or even "subsystem:foo", for any value of foo?

Actually, the latter might get messy, since subsystem names are
permitted to contain commas by my understanding. And in practice,
anyone restricting a key would be more likely to want to forbid _all
but_ specific subsystems rather than restricting particular ones.

Cheers,
Simon
-- 
Simon Tatham         "infinite loop _see_ loop, infinite"
<anakin%pobox.com@localhost>     - Index, Borland Pascal Language Guide