Metadata API: implement verify in Key, store id in key

[jku]

This is a potential API improvement I'm considering (both ideas originally from @sechkova i think):

• Implement verify_signature() in Key class
• Store keyid in Key object

Implementing verify() in Key would make sense because:

• having both verify() and verify_with_threshold()/verify_delegate() in Metadata is tricky because former verifies a sig on itself, and latter would verifiy threshold of sigs on a delegated metadata)
• verify() is not actually usually needed by the API users -- they are only interested in threshold verification
• Asking key to verify a signature makes sense and makes the SSLib integration more a Key class implementation detail

The only reason against this is that now sign() and verify() are in different places -- I don't think this is a major issue, and I think the solution maybe to move sign() away from Metadata as well (not sure if we can implement a MetadataSigner based on SSLib.Signer?) -- this would make some sense because signing is not needed by client and may require specific dependencies.

Storing keyid with key makes sense since when keys are used (e.g. if we have Key.verify_signature()), the id is needed. This means from_dict() now has to take an extra argument

[sechkova]

Just linking here a request for revising the "key" representation in sslib: secure-systems-lab/securesystemslib#310 in case the ideas in the description come in handy.

[trishankatdatadog]

💯 💯

[jku]

Just linking here a request for revising the "key" representation in sslib: secure-systems-lab/securesystemslib#310 in case the ideas in the description come in handy.

I think a potential future development is moving Key (partly) to SSLib: it seems to fit there with Signer and Signature. Also, this change will further make the SSLib integration a Key implementation detail (now no other code needs to call format_metadata_to_key()) -- this seems to further point to same direction.

I think this change should be compatible with that long term plan -- I could see possibly tuf.api.metadata.Key deriving from securesystemslib.Key and just handling the "find the correct signature and serialize the data" parts itself and then calling parents verify_signature(sig, data)

This also seems to bring the "definition of what key is" more in line with SSLib and in-toto (while the in-toto spec doesn't include the id, the implementation apparently does so this is now a closer match)