-
Key: DDSSEC13-56
-
Status: open
-
Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
-
Summary:
8.5.1.9.4 (4th pgh) describes that encode_rtps_message may determine that no encoding is necessary. This is currently an awkward fit with the common API design of returning a boolean and "setting" or "not setting" an exception struct. What does "not setting" the exception struct mean in practice? How does an implementation portably handle this?
It would be better to have an enum or integer return type so that the plugin can more directly influence the implementation's control flow, with distinct return values for OK_ENCODED, OK_NOT_ENCODED, ERROR, possibly others.
A similar issue occurs with decode_rtps_message (8.5.1.9.5). Because key exchange happens asynchronously with respect to encoded message transmission, the plugin may not be able to decode a given message. Simply "returning an exception" in this case is not ideal since the calling code should probably log this exception and it may raise alarms.
Extending this idea of enum (or integer constants) return types instead of boolean to other CryptoTransform operations may also be useful. For example, the other encode operations could return a OK_NOT_ENCODED instead of copying data.
-
Reported: DDS-SECURITY 1.1 — Tue, 17 Sep 2019 21:53 GMT
-
Updated: Fri, 21 Jun 2024 22:35 GMT
DDSSEC13 — encode_rtps_message/decode_rtps_message error and status reporting
- Key: DDSSEC13-56
- OMG Task Force: DDS Security 1.3 RTF