Add support for simplified component binding signature history evaluation#2262
Draft
vanitasvitae wants to merge 3 commits intobcgit:mainfrom
Draft
Add support for simplified component binding signature history evaluation#2262vanitasvitae wants to merge 3 commits intobcgit:mainfrom
vanitasvitae wants to merge 3 commits intobcgit:mainfrom
Conversation
…reation time from SignatureParameters This fixes OpenPGPMessageGenerator not applying custom signature creation times for message signatures
…tion Historically, OpenPGP implementations check the full signature history of a component key, when evaluating its validity. E.g. if a message signature was created at t1, signing key binding signatures at t2 are ignored, since they are not yet effective. Instead, binding signatures from t1 or earlier (t0) are checked. Now, there are multiple reasons why a certificate holder might want to clean older key signatures from their certificate. Most notably, PQC signatures are rather large in size, so cleaning historic signatures from time to time in order to maintain a reasonable certificate size is sensible. Unfortunately, with the current binding signature evluation model, this might lead to historic document signatures or third-party certifications to break, as the binding from t1 or t0 might no longer be there. Therefore, it is desirable to implement a different component binding signature evaluation model which prevents such 'temporal holes'. Such a model is described and proposed in https://mailarchive.ietf.org/arch/msg/openpgp/kA4YtiP3j8LJUift1_D0mWIHVV0/ This PR compartmentalizes the signature validity period evaluation into a delegate (ComponentSignatureEvaluator) and allows the user to swap out the classic implementation with a custom implementation that implements the simplified validity check logic. This can be done via the OpenPGPPolicy class.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Historically, when checking if a signature or component is valid at a given point in time, OpenPGP implementations reject signatures created after the reference time.
E.g. if a message signature was created at t1, signing key binding signatures at t2 are ignored, since they are not yet effective. Instead, binding signatures from t1 or earlier (t0) are checked.
Now, there are multiple reasons why a certificate holder might want to clean older key signatures
from their certificate.
Most notably, PQC signatures are rather large in size, so cleaning historic signatures from time to time in order to maintain a reasonable certificate size is sensible.
Unfortunately, with the current binding signature evaluation model, this might lead to historic document signatures or third-party certifications to break, as the binding from t1 or t0 might no longer be present on the cert.
Therefore, it is desirable to implement a different component binding signature evaluation model which prevents such 'temporal holes'.
Such a model is described and proposed in this mailing list post.
This PR compartmentalizes the signature validity period evaluation into a delegate (
ComponentSignatureEvaluator) and allows the user to swap out the classic implementation with a custom implementation that implements the simplified validity check logic.This can be done via the OpenPGPPolicy class.
This PR is still WIP, as I'm not yet fully satisfied with my naming conventions. Also, I want to add more tests to ensure proper functionality.
Contains #2261