5.3. What’s New in 7.5.0

This section describes what’s new in Security Plugins 7.5.0, compared to 7.4.0.

Connext 7.5.0 is an early access release (EAR). See Connext Versions and Lifecycle 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 or in your installation. Or start with RTI Connext What’s New 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.

5.3.1. 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) 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.

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 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 in the RTI Security Plugins User’s Manual for more information.

5.3.2. Support for kicking participants off a system that has non-RTI Participants

As described in 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.

5.3.3. Support for Online Certificate Status Protocol

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

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 in the RTI Security Plugins User’s Manual for more information.

5.3.4. 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 within the identity_credential_authority_validation tag under the existing domain_rule.

5.3.5. 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.

5.3.6. Deprecations and Removals

5.3.6.1. 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.