
.. _section-whats-new-750:

What's New in 7.5.0
===================

This section describes what's new in *Security Plugins* 7.5.0, compared to `7.4.0 
<https://community.rti.com/static/documentation/connext-dds/7.4.0/doc/manuals/connext_dds_secure/release_notes/whats_new/740/whats_new_740.html>`__.

*Connext* 7.5.0 is an early access release (EAR).
See `Connext Versions and Lifecycle <https://community.rti.com/connext-releases>`__ 
for more information on RTI's software release model.

For what's new in other products in the |CONNEXT| suite, see
those products' release notes on the `RTI Community Portal <https://community.rti.com/documentation>`__ 
or in your installation. 
Or start with `RTI Connext What's New 
<https://community.rti.com/static/documentation/connext-dds/7.5.0/doc/manuals/connext_dds_professional/whats_new/index.html>`__ 
for a launchpad to all products.

.. note::
   For backward compatibility information between 7.5.0 and previous releases, 
   see the *Migration Guide* on the `RTI Community Portal <https://community.rti.com/documentation>`__.

.. Release Notes from this point.

Key revisions now enabled in a manner compliant with the DDS Security specification
-----------------------------------------------------------------------------------
In release 7.3.0, the *Security Plugins* introduced a mechanism to
regenerate and redistribute the Key Material without needing to recreate
the involved *DomainParticipants* or lose liveliness. This mechanism
(described in `Limiting the Usage of Specific Key Material 
<https://community.rti.com/static/documentation/connext-dds/7.3.0/doc/manuals/connext_dds_secure/users_manual/p2_core/cryptography.html#limiting-the-usage-of-specific-key-material>`__) 
was enabled with the *DomainParticipant* property
``dds.participant.trust_plugins.key_revision_max_history_depth``.

In release 7.5.0, this RTI-specific property is now merely used to
configure a resource limit, while a new Governance Document Domain Rule, 
called ``enable_key_revision``, now controls enabling the mechanism. 
This Domain Rule is part of the `OMG DDS
Security 1.2 specification <https://www.omg.org/spec/DDS-SECURITY/>`__.

If you previously set the
``dds.participant.trust_plugins.key_revision_max_history_depth``
property to a value other than ``0`` in your *DomainParticipantQos*, now
you must also set the ``enable_key_revision`` Domain Rule to ``true`` in
your Governance Document (see the `Migration Guide 
<https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/migration_guide/index.html>`__ 
for an example of how to do this). Then you must re-sign the
Governance Document with the Permissions Certificate Authority.

See `enable_key_revision 
<https://community.rti.com/static/documentation/connext-dds/7.5.0/doc/manuals/connext_dds_secure/users_manual/p2_core/cryptography.html#enable-key-revision-domain-rule>`__ 
in the *RTI Security Plugins User's Manual* for more information.

.. Dynamic Participant Renewal, Revocation, and Expiration
.. [RTI Issue ID SEC-2562]


Support for kicking participants off a system that has non-RTI Participants
---------------------------------------------------------------------------
As described in
`Limiting the Usage of Specific Key Material 
<https://community.rti.com/static/documentation/connext-dds/7.3.0/doc/manuals/connext_dds_secure/users_manual/p2_core/cryptography.html#limiting-the-usage-of-specific-key-material>`__, 
the *Security Plugins* support a mechanism to regenerate and redistribute
Key Material without needing to recreate the involved *DomainParticipants*
or lose liveliness. This key regeneration and redistribution is
necessary to truly kick participants off the system. However, when the
*Security Plugins* 7.0.0 was released, the redistribution of Key Material
had not yet been standardized by the OMG DDS Security specification.

Now it has been standardized in the DDS Security 1.2 specification. 
This release uses the standard protocol for key redistribution when
communicating with non-RTI *DomainParticipants*. Note that the protocol
for key redistribution when communicating with RTI *DomainParticipants*
has not changed, so this feature does not impact backward wire
compatibility.

To further comply with the DDS Security 1.2 specification, the valid
range of values of
``dds.participant.trust_plugins.key_revision_max_history_depth`` has
changed from ``[7, 1000000]`` to ``[8, 1000000]``. This change impacts
backward configuration compatibility.

.. Dynamic Participant Renewal, Revocation, and Expiration
.. [RTI Issue ID SEC-2571]


Support for Online Certificate Status Protocol
----------------------------------------------
This release adds support for the Online Certificate Status Protocol (OCSP). If
the |DP|'s identity certificate's ``authorityInfoAccess`` extension
field contains an OCSP Responder URL, the |DP| will periodically validate
its identity status by contacting the OCSP Responder. If the status is valid,
the responder provides the |DP| with a stapling token. The stapling token is
a proof of identity validity that the |DP| shares with other |DPs|.

This a new mechanism for determining the validity of the certificate and offers
another (in addition to CRL) possibility for revoking the certificate before its
expiration.

See `Considerations when enabling OCSP
<https://community.rti.com/static/documentation/connext-dds/7.5.0/doc/manuals/connext_dds_secure/users_manual/p3_advanced/design_considerations.html#considerations-when-enabling-ocsp>`__
in the *RTI Security Plugins User's Manual* for more information.

.. Dynamic Participant Renewal, Revocation, and Expiration
.. [RTI Issue ID SEC-2528]


New Governance configuration for CRL and OCSP
---------------------------------------------
This release adds a new domain-level rule in the Governance document to govern
the use of identity credential validation mechanisms (currently CRL and OCSP) on
a domain level. The new configuration enables you to either mandate, disable or
leave as optional (by using the default ``AUTO`` value) the use of a certain
mechanism.
`You can set this rule <https://community.rti.com/static/documentation/connext-dds/7.5.0/doc/manuals/connext_dds_secure/users_manual/p2_core/authentication.html#identity-credential-authority-validation>`__
within the ``identity_credential_authority_validation`` tag under the existing
``domain_rule``.

.. Dynamic Participant Renewal, Revocation, and Expiration
.. [RTI Issue ID SEC-2553]


Improved compatibility of C++ applications using RTI Security Plugins SDK
-------------------------------------------------------------------------
This release improves compatibility between the *RTI Security Plugins SDK*
code and C++ applications. Before this change, if you tried to include
*Security Plugins SDK* functions from a C++ application, references may
not have been found due to name-mangling issues.

.. Security Plugins SDK
.. [RTI Issue ID SEC-2592]

Deprecations and Removals
-------------------------

HMAC-Only mode removed from Builtin Security Plugins
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*This change was made in release 7.4.0, but not documented at that time.*

The *Security Plugins* included the HMAC-Only mode in previous releases. 
This mode protected RTPS messages with a user-provided HMAC Key, 
while disabling all other security features (authentication, access control, 
and encryption). The 7.1.0 release of the *Security Plugins* deprecated 
the HMAC-Only mode in favor of the Lightweight Builtin Security Plugins. 

Starting with release 7.4.0, the Builtin Security Plugin's HMAC-Only 
mode is removed. Use the Lightweight Builtin Security Plugins instead. 
*RTI Routing Service* 7.3.0 can act as a bridge between legacy systems 
using HMAC-Only mode and modern systems using Pre-Shared Key Protection.

.. SEC-1932, SEC-2614 (task to add this)
