Mandatory vs optional ssh_pubkey_type and ssh_pubkey AVPs

[haussli]

Given the solution to PR #6 is the inability to mix mandatory and optional AVPs of the same name in a T+ session, does the language about a mandatory vs optional for ssh_pubkey_type and ssh_pubkey AVPs need to change in S5.2 step 1 & 4?

There may be other areas of S5 that need to be addressed.

[dcmgashcisco]

I think yes. Otherwise we are going to have different behaviours for the Extended Authentication args and the old author and acct args.

I guess the challenge is, this will mean that the ssh_pubkey_type is no longer exactly the same as in the SSH RFCs?

[haussli]

If a client can not mix mandatory and optional when requesting keys by ssh_pubkey_type, what remedy does it have? I think that the only thing that it can do is start a new T+ session for each (mandatory and optional).

Logically, if a client requests 2 mandatory types and the server does not have one of them, the server must reply with an error indicating this. It seems more likely for the client to only want one or the other, so it can use two sessions? And, frankly, it seems more likely for the client to ask for "any key type matching that the client supports".

[haussli]

Cleaned-up the language to address this in 68190ef723.