[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poll: use of TLS channel bindings in SCRAM




--On Friday, May 29, 2009 10:59:17 PM +0200 Simon Josefsson <simon@xxxxxxxxxxxxx> wrote:

I've changed the first paragraph to:

	      <t>A default channel binding type agreement process for
		all SASL application protocols that do not provide
		their own channel binding type agreement is provided
		as follows.</t>

However this seems somewhat restrictive, since it may be read to suggest
that negotiation cannot happen at other levels.  But I can't come up
with better text.  Suggestions?

Until we define a negotiation strategy, there _are_ no other levels. Of course a user could choose a particular CB type, but I think the language we agreed on will handle that.


I'm glad you like it.  I'm not entirely happy with it: you can't parse
it using a var[=value] parser, you need to inspect the string character
by character in the beginning.  One alternative would be (compare with
the examples in the document):

I see a couple of problems with the grammar. One is that in the 'p' and 'y' cases, you get two consecutive commas if there is no authzid. The other is that in the 'n' case, you get no comma before the authzid, if there is one. I think it would be better to always have a comma after the [pny] field, and another after the a=authzid iff it is present.

I have no objection to the [py]= syntax you suggest; that might make parsing easier, and we're changing the format of that field anyway.

I see no reason to include a comma after the 'F' prefix.