Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move _get_keyid helper to Signer base class and use in implementations #557

Merged
merged 2 commits into from
Mar 31, 2023

Conversation

lukpueh
Copy link
Member

@lukpueh lukpueh commented Mar 31, 2023

Signer base class now provides a static _get_keyid method which may be used in the import_ or generate methods of Signer implementations.

This PR also changes GCPSigner in HSMSigner to use the new method instead of the legacy _get_keyid, which does overly complicated and intransparent mangling of the input data, and thus produces different hashes.

Note that keyid computation is not public API, and verification of existing signatures with existing keys is not affected. If this does disrupt existing users, who expect a certain default keyid for a give key, I'd rather annoy them now, when the signer API is still experimental.

This method can be used prior to creating a Key instance, in order
to generate a default keyid, which is a required Key argument.
Since this currently mostly happens in the import_ methods of
different Signer implementations, it feels right to implement this
on the Signer base class. But other places would be okay too.

Note that the computed keyids are different from
``securesystemslib.keys._get_keyid()``, which includes a legacy
field when producing the hash.

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
The import_ method of GCPSigner and HSMSigner used to assign
a default keyid to the imported key, computed with the legacy
_get_keyid function, which does overly complicated and
intransparent mangling of the input data.

This commit uses a new simple _get_keyid helper on the Signer base
class.

NOTE: keyid computation is not public API, and verification of
existing signatures with existing keys is not affected. If this
does disrupt existing users, who expect a certain value of a given
key, I'd rather annoy them now, where the signer API is still
experimental.

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
@lukpueh lukpueh marked this pull request as ready for review March 31, 2023 09:02
Copy link
Collaborator

@jku jku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I still hope we can move to free form keyids in the future -- but even in that case it probably makes sense to have a "default" that should just work for the cases where the application is not interested in doing the extra work of uniquely naming the keys.

@lukpueh
Copy link
Member Author

lukpueh commented Mar 31, 2023

I still hope we can move to free form keyids in the future -- but even in that case it probably makes sense to have a "default" that should just work for the cases where the application is not interested in doing the extra work of uniquely naming the keys.

Agreed. And I think the signer API already allows you to use free form keyids.

@lukpueh lukpueh merged commit 09e092e into secure-systems-lab:main Mar 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants