Dynamic Participant Renewal, Revocation, and Expiration
=======================================================

.. Release Notes from this point.

:critical:`[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]

:major:`[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]

:major:`[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]


.. include:: ../../../../../connext_doc.1.0/srcDoc/release_notes/whats_fixed/disregard_if_7xbug.txt


