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" <hlinn...@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.: >> >> SCRAM-SHA-256-PLUS tls-awesome tls-awesome2 tls-awesome3\0... >> > > I think we're going in circles.. Yeah, we could do that. Or they could be > listed as separate mechanisms: > > SCRAM-SHA-256-PLUS\0 > SCRAM-SHA-256-PLUS tls-awesome\0 > SCRAM-SHA-256-PLUS tls-awesome2\0 > SCRAM-SHA-256-PLUS tls-awesome3\0 > \0 > > One alternative is that you could list extra channel bindings that are > supported by all the mechanisms, as separate entries. So the list could be: > > binding tls-unique\0 > binding tls-awesome\0 > binding tls-awesome2\0 > binding tls-awesome3\0 > SCRAM-SHA-256-PLUS\0 > SCRAM-SHA-512-PLUS\0 > \0 > > 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. > > - Heikki > >
