The goal of this PR is to create a relatively-automated MasterKey, where versions and EPOCH times can be routinely increased. This PR will fix #4, and it will fix #1, with the exception of providing ways to change signature algorithms and KDF algorithms (unless I can get that sorted out).
There are several requirements for the MasterKey:
Every single generated key and key ID MUST expire. If they don't expire, there could exist a "MasterKey" that an attacker could use that will always be validated. The probability of this seems to be extremely low, but would be there nonetheless.
Versions need to expire as well as IDs. This will not apply to non-expiring keyless_ids, but for any expiring key ID, if the version is too old to have possibly been generated with a specific version, the key needs to be invalidated based on the version.
The goal of this PR is to create a relatively-automated MasterKey, where versions and EPOCH times can be routinely increased. This PR will fix #4, and it will fix #1, with the exception of providing ways to change signature algorithms and KDF algorithms (unless I can get that sorted out).
There are several requirements for the MasterKey:
keyless_id
s, but for any expiring key ID, if the version is too old to have possibly been generated with a specific version, the key needs to be invalidated based on the version.