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

Implementation of draft-ietf-openpgp-replacementkey #2254

Open
falko-strenzke opened this issue Jul 29, 2024 · 1 comment
Open

Implementation of draft-ietf-openpgp-replacementkey #2254

falko-strenzke opened this issue Jul 29, 2024 · 1 comment

Comments

@falko-strenzke
Copy link
Contributor

In our project we are considering the implementation of draft-ietf-openpgp-replacementkey. I would like to hear from the RNP maintainers whether the implementation of this draft would be relevant to RNP from their perspective. RNP could support an application in parsing the Replacement Key Subpacket and evaluating whether for a pair of two keys trust can be transferred based on the their Replacement Key Subpacket. However, RNP does not – as far as I understand – implement key server lookups, thus the task of retrieving the replacement key would be left to the application.

@ni4 @TJ-91

@kaie I would also be interested to hear whether Thunderbird would make use of this extension if it were implemented in RNP.

@ni4
Copy link
Contributor

ni4 commented Jul 29, 2024

...whether the implementation of this draft would be relevant to RNP from their perspective

For me this draft seem to be in a quite early stage, and I don't think we should implement support directly for it, at least right now. However, we could add API which would allow to enumerate and retrieve all the signature subpackets, including not yet supported ones, and allow library user to deal with those in the way they wish. This would be more universal approach for all the current and future extensions.

However, RNP does not – as far as I understand – implement key server lookups, thus the task of retrieving the replacement key would be left to the application.

Yeah, implementing server lookups on library level would be an overkill for RNP purpose (and bring us few more layers of dependency hell).

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

No branches or pull requests

2 participants