-
Key: DDSSEC11-58
-
Status: closed
-
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
-
Summary:
In Table 57, the language in decode_rtps_message and decode_datawriter_submessage should be made more consistent with the language in decode_datareader_submessage. For example, decode_datawriter_submessage mentions receiver_specific_mac_key_id and master_receiver_specific_mac_key, but those terms are not mentioned anywhere else in the specification.
Proposal:
decode_datareader_submessage: "receiver_specific key_id" is missing an underscore. It should be "receiver_specific_key_id".
decode_datawriter_submessage: "receiver_specific_mac_key_id" and "receiver_mac_key_id" should be "receiver_specific_key_id". "master_receiver_specific_mac_key" should be "receiver_specific_macs".
decode_rtps_message: "RemoteParticipant2ParticopantKeyMaterial" should be "RemoteParticipant2ParticipantKeyMaterial". "containe" should be "contained". Add "If the RemoteParticipant2ParticipantKeyMaterial specified a receiver_specific_key_id different from zero, then the operation shall check that the received SecureRTPSPostfixSubMsg contains a non-zero length receiver_specific_macs element containing the receiver_specific_key_id that is associated with local and remote CryptoHandles and use it to verify the submesage. If the receiver_specific_key_id is missing or the verification fails, the operation shall fail with an exception."
-
Reported: DDS-SECURITY 1.0 — Tue, 7 Mar 2017 14:25 GMT
-
Disposition: Resolved — DDS-SECURITY 1.1
-
Disposition Summary:
Changes to Table 57
Perform the changes proposed in the issue description.
-
Updated: Tue, 19 Dec 2017 20:03 GMT
DDSSEC11 — Clarify the receiver-specific MACs described in the Table 57 decode operations
- Key: DDSSEC11-58
- OMG Task Force: DDS Security 1.1 RTF