Open falko-strenzke opened 4 months ago
...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).
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.