Prior to this change, only one interaction was supported by single OSCORE context. This resulted in invalid values for request_piv and request_kid fields when one than one interaction were active.
Example behavior: when the client subscribed for notifications, they only got proper values of the fields when no other communication was performed inbetween. If any request was received by the server, request_piv and request_kid fields were overwritten with new values, and next notifications used them instead of the values from the initial subscription request.
The changes introduced a dictionary-like structure to properly store, read and update valid values for multiple interactions. It was then integrated with the overall encryption and decryption flow.
Prior to this change, only one interaction was supported by single OSCORE context. This resulted in invalid values for
request_piv
andrequest_kid
fields when one than one interaction were active.Example behavior: when the client subscribed for notifications, they only got proper values of the fields when no other communication was performed inbetween. If any request was received by the server,
request_piv
andrequest_kid
fields were overwritten with new values, and next notifications used them instead of the values from the initial subscription request.The changes introduced a dictionary-like structure to properly store, read and update valid values for multiple interactions. It was then integrated with the overall encryption and decryption flow.