Repository navigation
Metadata API: implement verify in Key, store id in key #1417
Description
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()andverify_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
Activity
sechkova commentedon May 27, 2021
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 commentedon May 27, 2021
💯 💯
jku commentedon May 28, 2021
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.Keyderiving fromsecuresystemslib.Keyand just handling the "find the correct signature and serialize the data" parts itself and then calling parentsverify_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)