Explicit handling of multiple non-notification responses from the same server to the same group request. The handling relies on the same rationale used for notifications, in order to detect replays and ensure ordering of responses from the same server. From a general point of view, this relates to the issue at https://github.com/core-wg/core-responses/issues/2
Improved presentation of the security properties ensured by Group OSCORE, by following more closely the parlance and structure used for OSCORE in RFC 8613.
Improved listing of operations defined for the group mode that are inherited by the pairwise mode.
Have "SHOULD" (not "MUST") for using the group mode to protect a request intended to multiple recipients. An exception is a Deterministic Request as defined in [1], which is always protected with the pairwise mode, even in the case where it is intended to multiple servers.
This PR is about the following points:
Explicit handling of multiple non-notification responses from the same server to the same group request. The handling relies on the same rationale used for notifications, in order to detect replays and ensure ordering of responses from the same server. From a general point of view, this relates to the issue at https://github.com/core-wg/core-responses/issues/2
Improved presentation of the security properties ensured by Group OSCORE, by following more closely the parlance and structure used for OSCORE in RFC 8613.
Improved listing of operations defined for the group mode that are inherited by the pairwise mode.
Have "SHOULD" (not "MUST") for using the group mode to protect a request intended to multiple recipients. An exception is a Deterministic Request as defined in [1], which is always protected with the pairwise mode, even in the case where it is intended to multiple servers.
Editorial fixes.
[1] https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/