Re: Publickey subsystem draft posted

["Brent McClure" <mcclure%swcp.com@localhost>]

Darren, Sorry for the delay responding to your comments.

> In the introduction you say:
> 
>    This protocol requires that the user be able to authenticate in some
>    fashion before it can be used. If password authentication is used,
>    servers SHOULD provide a configuration option to disable the use of
>    password authentication after the first public key is added.
> 
> 
> While I support the intent of this the functionality seems like it would
> actually be more appropriate for one of the core drafts rather than this one.

It seems to me that the core drafts are pretty well closed up at this point.
I'm not sure yet if I understand completely why some language like this
would be inappropriate in this document. I'd be happy to see it changed
to "MAY provide a configuration option...". I could also see rephrasing it
to not specifically mention password authentication. Otherwise this 
seems pretty innocuous.

> 
> 
>   3.2 Adding a public key
> 
>    If the client wishes to add a public key, the client sends:
> 
>    string    "add"
>    string    comment
>    string    public-key algorithm name
>    string    public-key blob
> 
>    The server MUST attempt to store the public key for the user in the
>    appropriate location so the public key can be used for subsequent
>    public-key authentications.
> 
>    The comment field contains user-specified text about the public key
>    and MAY be empty.
> 
> 
> I'd like to see text added to say that the server is not supposed to
> interpret the comment in any way and is NOT required to preserve it for
> subsequent return in a list command.

Sounds good. But, I do think it would be nice to have a statement that indicates 
that returning the comment in a list would be helpful to users trying to
distinguish keys from each other in a listing (other than by looking at fingerprints).

> 
>  3.4 Listing public keys
> 
>    If the client wishes to list the known public keys, the client sends:
> 
>    string    "list"
> 
>    The server will respond with zero or more of the following responses:
> 
>    string    "publickey"
>    string    comment
>    string    public-key algorithm name
>    string    public-key blob
> 
>    The comment field contains user-specified text about the public key
>    and MAY be empty.
> 
>    Following the last "publickey" response, a status packet MUST be
>    sent.
> 
>    An implementation MAY choose not to support this request.
> 
> How long is the client supposed to wait for the server to send the
> status packet to say it is done ?

On one hand I'd say that how long a client decides to wait could
be implementation dependent. I suppose some implementations might
simply hang until the status packet comes through assuming that 
a user would cancel or interrupt the whole thing...

I see your point though. I believe one of the reasons we chose to 
have a bunch of 'list' responses followed by a 'status' response
was that we found it easy to parse.

> 
> I would have expected the server to send a packed more like this:
> 
> string "publickey-list"
> uint32 number of following public keys
> string comment
> string public-key algorithm name
> string public-key blob
> .... and so on upto uint32 number of keys
> 
> OR something like
> 
> string "publickey-list"
> uint32 number of following public keys
> 
> then send the publickeys in the packet format you defined in 3.4
> 
> Telling the client how many keys are comming would probably be helpful
> for implementers building a UI to display this info.

--Brent