5.1 Security Considerations for Implementers

The COMQC does not define any specific means by which the contents of a message have to be encrypted. COMQC messages, as defined in this specification, are transmitted in plain text. They are also not numbered, time stamped, or otherwise identified. If implementers of this specification require properties such as confidentiality or nonrepudiation, they have to use functionality provided by the underlying transport to achieve the desired result.

The protocol also does not define how to validate and set up the security properties that were transmitted as part of the message beyond what is defined in [MS-COM] section 2.2.3.2. It is the responsibility of the implementer of this protocol to build the security infrastructure, since the protocol does not provide feedback to the client regarding how to communicate security violations.

Many fields of a COMQC message are of variable length. Implementers have to exercise caution when accessing memory based on the size fields in the message because the protocol does not specify any validation fields such as checksums.

This protocol does not define ways to detect or prevent replays of messages. As a matter of fact, due to the use of this protocol in scenarios of limited or unreliable connectivity, multiple transmission attempts by the underlying transport can occur. This protocol itself does not define any retry mechanisms and relies on MSMQ to retransmit the messages in case of failures and to ensure the messages are delivered only once.