Calculate MIC like sending #163
Open
Conversation
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
- Move MIC calculation to after decryption/verification - Calculate MIC on first body part of multipart/signed messages - Ensures MIC is calculated on same data as sender
Owner
|
Thx - will check asap |
Author
|
One issue I have found with this is that between a partnership, if the sender does not use the defined values but instead sends new ones in the header the server will respond with the values defined in the partnership. For example, if a partnership A-B is defined with sign: sha-256 but the sender sends without signature then the server will accept the incoming request but it will calculate the MIC with headers as the partnership states that they use signature. The server responds with a signature and a wrong MIC. In my opinion the server should directly reject the request because the sender did not comply with the agreement but I may be wrong. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
In theory, MIC is calculated before signature and encryption. If the content is compressed before encryption then MIC should be calculated on the compressed object. I've tested both sending and receiving with mendelson.
Java is not my main language so please feel free to edit and fix. I tried to implement what would work in my use case but copying how the sending worked with callbacks. #140