My only desire would be to have a final spec and implement the full parser now, not have to change it in the future. We already know today all the requirements, so please pick one and I will follow it :)
On Apr 13, 2017 13:47, "Heikki Linnakangas" <hlinnaka@iki.fi> wrote:
On 04/13/2017 02:35 PM, Álvaro Hernández Tortosa wrote:
On 13/04/17 13:24, Heikki Linnakangas wrote:
Right, when we get channel binding, the server will list "SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms. And if we get channel binding using something else than tls-unique, then those will be added as extra mechanisms, too, e.g. "SCRAM-SHA-256-PLUS tls-awesome".
And how about supporting different SCRAM mechanisms with different possible channel bindings? Separate by space too? So given a field, is the first item the SCRAM mechanism, and all the remaning the channel binding methods? I.e.:
which would mean that those bindings are supported by all the mechanisms that follow. I think this would achieve the same thing as your proposed separate field, with the current proposed protocol.
But again, I'm 99% sure we won't need it, and we don't need to decide the exact syntax for channel bindings yet. We have the flexibility now, so we can cross the bridge when we get there.
