Include the period as part of the KES signing key

[iquerejeta]

Currently, KES signing keys do not contain the period to which they are evolved. This means there is no way to know in which evolution a key is at. This is particularly problematic while designing the KES agent as we will have more than one process/machine handling key evolutions which might not be in sync. It is therefore important to allow the key handlers to understand at which evolution a particular key is at. To that end we should change from the current KES sk design:

data SignKeyKES (SumKES h d) =
           SignKeySumKES !(SignKeyKES d)
                         !Seed
                         !(VerKeyKES d)
                         !(VerKeyKES d)
        deriving Generic

to a different data structure that contains the period. However, we might not want to include the period in such a way that it is redundant for each layer of the key (this is because a Sum6KES sign key is formed by a Sum5KES, and so on).

[dcoutts]

This would have an impact in a number of areas.

I think we should clarify our KES agent design first, and then see if it would need this. I'm sure it will need to track the evolution number, but it may not need to do so within the KES key, but perhaps paired up with the KES key.

[tdammers]

I think pairing up is the way to go here, something like:

data SignKeyWithPeriodKES k =
    SignKeyWithPeriodKES { sk :: !(SignKeyKES k), period :: !KESPeriod }

This has next to no disadvantages compared to integrating the period with the key, but a lot of advantages, most notably, with this approach we can gradually migrate parts of the codebase to the new data type by adding or removing the period at API boundaries, while maintaining API compatibility on the other side.

[tdammers]

Implementation on the tdammers/kes-agent-requirements branch (3bd4a04)