create_generators flexibility

[BasileiosKal]

Currently we allow seeds with different scopes but it is not clear how a signature specific seed is going to be used since it is passed as a parameter to create_generators and not as input. Also i think this is a case that we want to reduce optionality (for example we don't want generator_seed = hash(all_messages)).

I think it's best to not allow "scoped seeds" but different create_generators operations. Each create_generators will accept a seed and a dst as a parameter and a count as input. If one wants signature specific generators they can use the count input but nothing else. This will be enough for "legacy support".

This also makes it easier to describe the requirements of the create_generators operations (rather than the requirements for the seed selection).

IMO there are 2 options:

1. Don't allow different create_generators or scoped_seeds: No changes are needed, expect to remove the text around "scoped seeds".
2. Allow different create_generators: In this case IMO we should:
   • Add a create_generators_operation parameter in the ciphersuites definition.
   • For the suites defined in the document give the create_generators_operation parameter the value of "create_generators with generator_seed=...".
   • Require every create_generators operation to also define a unique ID which will be added to the ciphersuite_id (like EXP_TAG for expand_message in h2c).
   • Add create_generators_operation as a parameter to Sign, Verify etc..
   • Add the requirements for defining a new create_generators_operation.

Obviously 1 is the simplest but the least flexible. It also is a "breaking change" with previous versions. So my preference will be 2 but I'm also very interested in others thoughts on the matter.

[BasileiosKal]

Discussed on the WG call of the 22nd of August. Will open a PR with the proposed updates.