PITCH: Update config to support an allowlist of signing algorithms.

[kommendorkapten]

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.

[JustinCappos]

Usually, the root file or map file is where you'd list the allowed algos. (This is probably obvious, but I just wanted to check.)

We were discussing making a formal cryptoagility TAP to explain this, but I think this was deferred when Marina graduated.

[jku]

These seem to be the critical points:

each delegate (root, targets, snapshot, timestamp etc) would [have] 2x the keys configured.

During verification the tuf client can be set to only verify signatures made with key using the allowed scheme.

The issue is that if any verifying TUF client uses this repo and

• does support all of the key types
• is not configured with AllowedSignatureScheme (or does not have that configuration option)

then the security model has changed: now I only need to compromise N/2 keyholders instead of N keyholders (because each keyholder now has two keys from the perspective of this client). It feels risky to assume this never happens

[kommendorkapten]

then the security model has changed: now I only need to compromise N/2 keyholders instead of N keyholders (because each keyholder now has two keys from the perspective of this client). It feels risky to assume this never happens

That is a good point. As the repo still behaves as regular TUF repository such polices can't be guaranteed to be in place.

[mnm678]

You can roughly support a transition today by doubling the required threshold and signing with both key types (though this isn't perfect).

One solution (which I haven't totally thought through) could be to define a key type that is compatible with our signature API, but internally signs with both a classic and PQC key. This could keep the logic for the signature scheme abstracted from the rest of the implementation, but still allow a transition period.

[jku]

You can roughly support a transition today by doubling the required threshold and signing with both key types (though this isn't perfect).

This only works if you assume all verifying clients already support both keytypes. I think the problem @kommendorkapten is trying to solve is that PQC support is likely to arrive very unevenly:

• Conservative open source crypto projects (say python cryptography) are unlikely to support PQC very soon and responsible TUF implementations should rely on those conservative crypto projects
• Some individual deployments will still want to try the new stuff early on

So we just have to live with the fact that some clients will not support some key types for a long time.

One solution (which I haven't totally thought through) could be to define a key type that is compatible with our signature API, but internally signs with both a classic and PQC key

That's a novel idea...

• this requires a new TUF keytype
• You'd need the key definition to be something like "verification implementation must choose one of the internal key types and must disregard the other key type" -- the implementations that support PQC could use that, others just use the classic key
• this still has the downside of needing every verifying client to support the new keytype before it can be used by the repository -- as an upside implementing the initial "classic-key-only" version of the keytype would not be tricky

This could work but feels like abuse of the keytype idea.

[kommendorkapten]

So we just have to live with the fact that some clients will not support some key types for a long time.

Right, this is what I'm thinking about. A simple solution is to just run with two tuf repositories that serve the same content, but with different key types (still same key custodians). There is quite a bit of overhead here and possibly less than optimal ux as each client need to manage two tuf roots.

It's an interesting idea of creating a new key-type, but I fear this will put us on a path where we need to wait for a wide client support before we can roll it out. Solving this in a non-breaking way is thus the preferred method.

Another option could be to push the complexity to the TUF repository automation, such as TUF-on-CI.

To avoid managing multiple repositories, we could let the repository server "two views" of the same metadata. The automation would need to know that, and so understand how to deal with the different key ids for the different view. Then during publish it's all compiled and published:

• tuf.example.com/ <- this is the classic crypto metadata
• tuf.example.com/pq <- this is the same metadata but signed with PQC
• tuf.example.com/targets <- targets are the same

For this to work, the ecosystem must agree on what the path is for the "alternative view", I used use pq in the example above. If a client can be initialized in PQC mode, it would then load the PQC root.json then configure the metadata endpoint to match the exported view.

This puts much more pressure on the repository management, but makes it much simpler for the clients to adopt, and is not a breaking change. I think this is preferable as breaking clients is worse as it hinders adoption.

The core metadata will be the same for both views, only the keys and roles will be different as they need to match the expected keys from both classic and PQC.

[jku]

To avoid managing multiple repositories, we could let the repository server "two views" of the same metadata.

So far this has been the only solution to breaking changes in TUF repos that seems viable -- so a solution to this would solve some other problems as well... The complexity of signing really, really makes me not want to touch this option but I agree it seems like the only path that doesn't require unreasonable amounts of co-operation from users

[kommendorkapten]

The complexity of signing really, really makes me not want to touch this option but I agree it seems like the only path that doesn't require unreasonable amounts of co-operation from users

Agreed, this opens up for a lot more failure modes.

[JustinCappos]

Right. The versioning TAP <https://github.com/theupdateframework/taps/blob/master/tap14.md> is meant to handle cases like this. Anyways, I hope we can talk in the community meeting (in 15 mins!) and put notes here.

…

On Wed, Mar 4, 2026 at 4:57 AM Fredrik Skogman ***@***.***> wrote: *kommendorkapten* left a comment (theupdateframework/go-tuf#723) <#723 (comment)> The complexity of signing really, really makes me not want to touch this option but I agree it seems like the only path that doesn't require unreasonable amounts of co-operation from users Agreed, this opens up for a lot more failure modes. — Reply to this email directly, view it on GitHub <#723 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD7XM7Y3SMDG33ODYKL4O74YDAVCNFSM6AAAAACWFPQOL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSOJWGQ2TQNJQGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[kommendorkapten]

Thanks for the link to the versioning tamp @JustinCappos , however I don't think it's fully compatible with our goals as it focuses on TUF specification versions, where the client can upgrade to a newer version. We are primarily trying to expose two identical metadata views, only signed with different signature algorithms. Trying to mimic that via supported_versions feels a bit off.

I've been busy lately will try to attend the next community meeting and we can discuss this further if desired.