The specification actively does not require implementations to support specific keytypes, and only recommends supporting three specific keytypes. This is understandable but creates a situation where
- understanding which keytypes are supported by which implementations is difficult: this makes integrating TUF more difficult
- compatibility mistakes are easy to make when new keytypes are added or existing ones are modified (this has already happened several times)
There should be a list of keytypes that are either "recommended" (or in other words already commonly supported or clearly getting there), or "candidates" (keytypes that are either still experimental or have not been commonly supported yet). At least the former list should be tested in tuf-conformance. Even the former list should probably not be integrated into the spec. The lists don't need to live in a TAP either but I'm filing an issue here to say that a TAP could be a possible path forward.
Initial "Established Keytypes" proposal
As a starting point I would suggest this as the "Established Keytypes":
- ecdsa: ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521
- ed25519: ed25519
- rsa: rsassa-pss-sha256, rsassa-pss-sha384, rsassa-pss-sha512, rsa-pkcs1v15-sha256, rsa-pkcs1v15-sha384, rsa-pkcs1v15-sha512
These are the spec defined keytypes with slightly expanded scheme options.
Candidate Keytypes
I'd like this list to document the keytypes that are not yet commonly supported but have potential to develop. The bar to add things to this list should be quite low -- the idea is to point other developers to already existing keytype definitions if they are considering adding new experimental ones to their implementations
- sigstore: Fulcio
- sphincs: sphincs-shake-128s
- mldsa
- No implementation exists but Sigstore project is currently evaluating PQC options
- It's noteworthy that TUF use case would likely benefit from also having the prehashed algorithm variant (to enable signing with cloud KMS and harware keys) but those are lagging behind the pure variant
The specification actively does not require implementations to support specific keytypes, and only recommends supporting three specific keytypes. This is understandable but creates a situation where
There should be a list of keytypes that are either "recommended" (or in other words already commonly supported or clearly getting there), or "candidates" (keytypes that are either still experimental or have not been commonly supported yet). At least the former list should be tested in tuf-conformance. Even the former list should probably not be integrated into the spec. The lists don't need to live in a TAP either but I'm filing an issue here to say that a TAP could be a possible path forward.
Initial "Established Keytypes" proposal
As a starting point I would suggest this as the "Established Keytypes":
These are the spec defined keytypes with slightly expanded scheme options.
Candidate Keytypes
I'd like this list to document the keytypes that are not yet commonly supported but have potential to develop. The bar to add things to this list should be quite low -- the idea is to point other developers to already existing keytype definitions if they are considering adding new experimental ones to their implementations