[gnutls-devel] [RFC] Relaxing cipher suite (priority) string requirements

[Jouko Orava]

> It could be two different modes. One that you specify explicitly
> ciphersuites, and the other that is like now (level+ciphers,macs etc.).
>
> Does this make sense?

Absolutely, and that's also the reason I haven't yet tested the patches I
proposed earlier (making '+' optional, for example).

Here's the logic rules I've been considering.
I'm not entirely happy with it, and I think it needs further work.
It is quite possibly too complicated (for users).
(I do believe the implementation would be straightforward, though.)

	"!" <ciphersuite>
	"!" <protocol>
	"!" <certificate>
	"!" <compression>
	"!" <signature>
	"!" <cipher>
	"!" <mac>
	"!" <key exchange>
		Completely disallow (ban).
		Applies as if these were listed last in the string.

	"!" <level>
		Ban all cipher suites in <level>
		from the current priority set.
		(Other features of <level> are ignored.)

	"-" <ciphersuite>
	"-" <protocol>
	"-" <certificate>
	"-" <compression>
	"-" <signature>
	"-" "%" <option>
	"-" <cipher>
	"-" <mac>
	"-" <key exchange>
		Remove from the current priority set.
		Applies only to the left in the string,
		up to the last <level> encountered.

	"-" <level>
		Remove all cipher suites in <level> from
		the current priority set.
		(Other features of <level> are ignored.)

	<level>
	<ciphersuite>
	<protocol>
	<certificate>
	<compression>
	<signature>
	"%" <option>
		Add to current priority set.

	<cipher>
	<mac>
	<key exchange>
		Add to temporary priority lists.
		At the end of string, or at the next full cipher
		suite name (added, removed, or banned), the
		temporary lists will be converted to cipher suites,
		and added to the priority set.
		(Cipher suites that match any of the "!" bans will
		 not be added to the priority sets, of course.)

All strings are case sensitive.

Instead of "-ALL" suffixes, catch-alls could use an asterisk "*".
For example, any TLSv1 protocol could be "TLSv1.*".

"NONE" should include "no compression". Compression can be required
by explicitly banning or removing "no compression".

To distinguish between the existing parsing, this format would
require a start marker, for example "@" or "New".
Anything not accepted by the existing parser would be acceptable.
As it would be at the beginning of the string, it would be very easy to
factor out the common (splitting) code but keep the other parsing
separate, making for cleaner code without unnecessary repetition.

Thoughts? Comments? Better ideas?

Best regards,
  Jouko