Change keytype for newly generated ecdsa keys

[jku]

Current behavior:
generate_ecdsa_key() creates keys with keytype 'ecdsa'

Expected behavior:

Considering that the TUF spec defines the a "ecdsa-sha2-nistp256" keytype and not a "ecdsa" one we should probably use the more specific keytypes instead?

This should be an easy non-breaking change: set the keytype in generate_ecdsa_key() to "ecdsa-sha2-nistp256" or "ecdsa-sha2-nistp384" based on the scheme.

[jku]

cc @rdimitrov

[jku]

This still leads me to wonder what the practical advantage of changing this key type name was.

I understand that some people think keytypes are unneeded (and scheme should fully define the type/scheme)... but why keep making changes to key type then?

[lukpueh]

I'm still convinced that this is a specification bug. "ecdsa-sha2-nistp256" is not a key type. At least the hash algorithm is only relevant for signing. Unless we define "key type" as the information needed for signing/verifying. But then why have key type and scheme? My preferred fix would be to deprecate the key type field altogether. We really only need scheme.

Practical advantage is less ambiguity (in a very complex specification) and less data on the wire (granted, not that important).

I agree that changing key type of "ecdsa-sha2-nistp*" keys to ecdsa in securesystemslib alone is not a big win, and more likely an interoperability problem.

[jku]

oh yeah, you are right and I was confused (I thought the spec had changed):

• "ecdsa-sha2-nistp256" is one of the three keytypes that the spec actually defines, "ecdsa" is not one of them
• ecdsa keys created with securesystemslib have keytype "ecdsa" since PR Better distinguish between keytype and scheme for ECDSA keys #267

[lukpueh]

The way I read the spec, it also kind of offloads the definition of key types to the reference implementation.

[jku]

Sure, spec defines three keytypes and allows all implementers to define new ones. Using those implementation-defined keys is totally fine if interoperability is not a goal.

The issue is that a python-tuf repository user who decides to create ecdsa keys probably assumes they would be spec defined ecdsa keys... but they are not, they are implementation-defined keys. So the repository ends up spec compliant but likely not interoperable

[joshuagl]

I agree that this is a specification bug. I have created a PR theupdateframework/specification#272 to capture what appears to be the specs current intent and document the keytype as "ecdsa". I've also added key formats to the agenda for the TUF project meeting at KubeCon EU.

[lukpueh]

theupdateframework/specification#272 has been merged. @jku, can we close here?

[jku]

👍