With PQC emerging ecosystems must work on enablement, and hybrid modes can be an valid approach.
I'm proposing (a non standard configuration) AllowedSignatureScheme: comma-separated list for the config struct.
This would enable a mode of operation where a TUF repository can be dual signed with classical and PQC. During verification the tuf client can be set to only verify signatures made with key using the allowed scheme.
This would greatly simplify operation for ecosystems that are in the migration process without requiring two separate TUF repositories which can be quite an overhead to operate.
The consequence would be that each delegate (root, targets, snapshot, timestamp etc) would 2x the keys configured. For e.g. ML-DSA this would mean that the file size would grow with roughly 5.3kB (2kB public key and 3.3kB signature) per delegate. In practice this would not be that bad, as most client caches previous versions of seen metadata, the difference would primarily be for the timestamp.
With PQC emerging ecosystems must work on enablement, and hybrid modes can be an valid approach.
I'm proposing (a non standard configuration)
AllowedSignatureScheme: comma-separated listfor the config struct.This would enable a mode of operation where a TUF repository can be dual signed with classical and PQC. During verification the tuf client can be set to only verify signatures made with key using the allowed scheme.
This would greatly simplify operation for ecosystems that are in the migration process without requiring two separate TUF repositories which can be quite an overhead to operate.
The consequence would be that each delegate (root, targets, snapshot, timestamp etc) would 2x the keys configured. For e.g. ML-DSA this would mean that the file size would grow with roughly 5.3kB (2kB public key and 3.3kB signature) per delegate. In practice this would not be that bad, as most client caches previous versions of seen metadata, the difference would primarily be for the timestamp.