DDS-SECURITY 1.1 RTF Avatar
  1. OMG Issue

DDSSEC11 — Clarify the receiver-specific MACs described in the Table 57 decode operations

  • 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