DDSSEC11 — Additional typos/inconsistencies

Several inconsistencies remain in the document:

The document uses the terms " MasterReaderSpecificKey" and "MasterReceiverSpecificKey" to refer to the same key. Should rename one of the two. It would be better to keep MasterReceiverSpecificKey to be consistent with the name used for other keys, such as, SessionReceiverSpecificKey.

Section 9.5.3.3.4.2 second paragraph starts: "Note that the built cipher operations..." The "built" word should be removed.

The word: "operationg" is mis-spelled 5 times. Should be replaced with "operating"

The words "AES-GMAC operation" appear 3 times in the spec. The more correct term would be "AES-GMAC transformation"

Section 9.5.3.3.5 mentions a CryptographicSessionHandle three times. This is undefined. This really refers to the appropriate crypto handle (ParticipantCryptoHandle, DatawriterCryptoHandle, or DatawriterCryptoHandle).

To fix this replace the first occurrence of "CryptographicSessionHandle" with "crypto handle (ParticipantCryptoHandle, DatawriterCryptoHandle, or DatawriterCryptoHandle)" and the remaining two occurences with "crypto handle"

The IDL in the specification is still not using IDL 4.1 format. The following changes should be applied:
@Extensibility (EXTENSIBLE_EXTENSIBILITY) -> @extensibility (APPENDABLE)
@Extensibility (MUTABLE_EXTENSIBILITY) -> @extensibility (MUTABLE)

Paragraph in section 9.4.1.2.4.6 (RTPS Protection Kind element) is in the wrong section
The paragraph:

This setting controls the contents of the ParticipantSecurityAttributes returned by the AccessControl::get_participant_sec_attributes operation on the DomainParticipant. Specifically the is_liveliness_protected attribute in the ParticipantSecurityAttributes shall be set to FALSE if and only if the value of the <liveliness_protection_kind> element is NONE.

The numbered items in section 9.4.1.2.4 (Domain Rules) are missing one item. A new item numbered shown below should be inserted ahead of the current 6 (Topic Access Rules Section, containing topic rules).
6. RTPS Protection Kind Element

Provide the means to force strict parsing/formatting of the Governance file. See comments on DDSSEC11-114.

The resolution of DDSSEC11-114 only addressed the strict formatting of the permissions file, not the governance file. To address the latter the AccessControl plugin should have an additional property "dds.sec.access.enable_strict_governance_formatting" with possible values "true" or "false". This property shuld be added ton 9.4.1(Configuration), Table 48 (Properties used to configure the builtin AccessControl plugin).

The text in the newly added (by DDSSEC11-114) sections 9.4.1.2.5.9 Unknown elements in the domain rules and 9.4.1.2.5.9 Unknown elements in the topic rules would also need to change to say that this configured in the plugin, not controlled by the <enable_strict_permission_formatting>.element in the Governance file.

In sections 9.4.1.2.5.9 (Unknown elements in the domain rules) and 9.4.1.2.6.8 (Unknown elements in the topic rules) the last paragraph in the section (see below) is wrong and should mention a configuration of the plugin instead:

As specified in 9.4.1.2.5.7, unknown elements are only allowed if the governance file has set the Enable Strict Permissions Formatting element to FALSE.

In 8.5.1.9.3 last paragraph, change receiving_datawriter_crypto_list.length with Length(receiving_datawriter_crypto_list)

In section 7.4.1.5 after table 13 add IDL representation of the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData

        @extensibility(MUTABLE)
        struct PublicationBuiltinTopicDataSecure  :  DDS::PublicationBuiltinTopicData {
	    @id(0x1003)  DataTags data_tags;
        };

        @extensibility(MUTABLE)
        struct SubscriptionBuiltinTopicDataSecure  :  DDS::SubscriptionBuiltinTopicData {
	    @id(0x1003)  DataTags data_tags;
        };

In many of the tables there are "out" parameters, such as the exception that are not marked as such. They should be corrected.

DDSSEC11-17 added enable_liveliness_protection but the XSD was not updated accordingly. To correct, in
in section 9.4.1.2.3 "Domain Governance document format" in the Governance XSD under, under<xs:complexType name="TopicRule">, change from:

            <xs:element name="enable_discovery_protection" type="xs:boolean" />

To:

            <xs:element name="enable_discovery_protection" type="xs:boolean" />
            <xs:element name="enable_liveliness_protection" type="xs:boolean" />

Also make that change to machine readable Governance XSD file

Already applied
Issue 88 changed all the BuiltinTopicKey_t to be GUID_t. However it missed some changes, partially because the resolution of Issue#21 added some parameters that thought have also been renamed by 88. As a consequence the following additional changes are needed:

• Global replace of remote_participant_key with remote_participant_guid in the specification document
• Global replace of local_participant_key with local_participant_guid in the specification document
• Global replace of "local participant_key" with local_participant_guid in the specification document
• Global replace of participant_key with participant_guid in the specification document

• Replace replace of BuiltinTopicKey_t with GUID_t in the machine readable IDL dds_security_pugin_spis.idl operation validate_remote_identity
• Global replace of remote_participant_key with remote_participant_guid in the machine readable IDL dds_security_pugin_spis.idl

Address identified typos and inconsistencies

Apply the changes suggested in the issue description.