4.2. Dynamic Participant Renewal, Revocation, and Expiration

4.2.1. [Critical] Unexpected loss of keyed data when Persistence Service enabled Key Revision History

Consider the following scenario:

  • You are using Persistence Service.

  • You are setting the Persistence Service DomainParticipant property dds.participant.trust_plugins.key_revision_max_history_depth to a non-zero value.

  • You are using a keyed data type.

  • You trigger enough key regenerations (e.g., by changing the Certificate Revocation List or the Subject Name Whitelist) to reach the key_revision_max_history_depth limit.

In this scenario, Persistence Service incorrectly failed to re-encode the historical samples of the keyed data type that were encoded with the oldest key revision; as a result, those samples were unexpectedly lost to newly discovered DataReaders. The following error message occurred during the failed re-encoding:

attempt to decrypt empty input

[RTI Issue ID SEC-2906]

4.2.2. [Major] RTI Security Plugins were not compatible with monotonic clock

The RTI Security Plugins DomainParticipant’s identity certificate (OCSP included) and permissions document expirations did not work properly when the internal clock (dds.clock.internal_clock property) was set to “monotonic”. This issue affected both local and remote artifacts. It caused DomainParticipants to not react to their expiration; that is, users were not notified about the expiration, and remote DomainParticipants with expired artifacts were not banished.

Expirations are now tracked regardless of the Connext clock settings, provided that the host system clock is set to the correct time and date.

[RTI Issue ID SEC-2813]

4.2.3. [Major] Authentication failures when discovering a DomainParticipant and simultaneously updating the local Permissions Document *

You may have faced authentication errors when discovering remote DomainParticipants right after updating the local Permissions Document:

ERROR [PARSE MESSAGE|[...]{Entity=DR,MessageKind=DATA}|RECEIVE FROM [...]|RECEIVE SAMPLE|PROCESS HANDSHAKE|GET SECURITY STATE|LC:Security] RTI_Security_AccessControl_validate_remote_permissions:{"DDS:Security:LogTopicV2":{[...], "x":[{"DDS":[{"domain_id":[...]},{"guid":[...]},{"plugin_class":"DDS:Access:Permissions"},{"plugin_method":"RTI_Security_AccessControl_validate_remote_permissions"}]}],"m":"failed to validate remote permissions"}}

These errors would last until authentication timeout (dds.participant.trust_plugins.authentication_timeout.sec property value), after which the re-authentication would succeed.

[RTI Issue ID SEC-2863]



* This bug does not affect you if you are upgrading from 7.3.x or earlier.