The original text reads:
The RTPS protocol version 2.5 defines the following special values.
PROTOCOLVERSION_1_0
PROTOCOLVERSION_1_1
PROTOCOLVERSION_1_0 PROTOCOLVERSION_1_1
PROTOCOLVERSION_2_1
PROTOCOLVERSION_2_2
PROTOCOLVERSION_2_2
PROTOCOLVERSION_2_4

Two PROTOCOLVERSION_2_2 appeared
I think it should be PROTOCOLVERSION_2_3

In Clause 7.2.2, the term "network topology description" seems odd. The text should probably refer to the deployment configuration model.

In Table 7.19, "DataFrameSpecification Definition", the second bullet point should only refer to UDP/IP, not "TCP/IP".

In Clause 8.2.2 should clarify that endpoints in the context of DDS entities refer to DataReaders and DataWriters, the term may confuse readers coming from different backgrounds.

In Clause B.1.2, the clarification on manual configurations that need to calculate a schedule should probably mention they need to calculate whether the requirements can be met (schedule may be a confusing term in that context).

In B.2.1.1, "Square Stream Configuration", the destination-mac-address in the status response should be "01-00-5E-7F-FF-01" (given the destination multicast IP address).

In B.2.1.2, "Triangle Stream Configuration", the destination-mac-address in the status response should be "01-00-5E-7F-FF-02" (given the destination multicast IP address).

IEEE 802.1Q has recently (as of 2022) incorporated several specifications that have been developed in parallel. That is the case of 802.1Qcc, which this specification heavily relies on, and 802.1Qcr. This is part of the regular process of IEEE.

At the time of publication of the revised submission, 802.1Q-2022 was being voted and finalized, so the Beta 1 version of DDS-TSN points to 802.1Q-2018, 802.1Qcc, and 802.1Qcr. We should update these references and point to 802.1Q-2022, which now includes both Qcc and Qcr.

The specification does not state what to do when Permissions and Governance files contain "extra elements" that are not valid according to the XSD.

This is expected to occur both as a result of vendor extensions as well as due to additions in future versions of DDS Security.

Allowing these extensions/additions without breaking compatibility is important. So the spec should be clear in that they are allowed and also provide rules/guidelines on them.

Some possibilities:

• Simply state that elements that are not expected/understood should be ignored
• Same as above but provide some structure for those elements. E.g. specify that they must have a "vendorId" attribute (used to avoid collisions) and a "mustUnderstand" attribute used to force failure in some cases.
• Define an "extensions" element that has known structure (e.g. name/value pairs) which is the one used for the extensions.
• Others to be proposed.

Common approaches are described here: http://www.ibm.com/developerworks/library/x-xtendschema/
This document also discusses various approaches: https://www.xml.com/pub/a/2004/10/27/extend.html

The operations
check_create_participant
check_create_datawriter
check_create_datareader
check_remote_participant
check_remote_datawriter
check_remote_datareader
check_local_datawriter_match
check_local_datareader_match

Should be called when the Qos (or the discovery XXXBuiltinTopicData) change for the one of the involved entities.

This should be added to the proper 8.4.2.9.x sections.

Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

@Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};
};@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};
};@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places. The correct IDL would be:

@Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};

@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};

@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};

@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

The check_remote_participant row of Table 63 contains the text:

If the Permissions document contains a Grant for the remote
DomainParticipant and the Grant contains an allow rule on the
DomainParticipant domain_id, then the operation shall succeed and
return TRUE.

It seems like the intent is to ensure that there is some possible Action that this participant can do in the domain. That should take into account a <default>ALLOW</default> permission.

In general the <default> XML element seems to be not fully/consistently described in the section for Built-In Access Control. The xsd says it must be present, but section 9.4.1.3.2.3 says it may not be.

In 7.3.5 (Immutability of Publisher Partition Qos in combination with non-volatile...)

The criteria (1) is not consistent with the goal stated at the end of the section about "prevents data that was published while the DataWriter had associated a set of Partitions from being sent to DataReaders that were not matching before the Partition change and match after the Partition is changed."

To accomplish this criteria (1) should be re-stated to say this impacts if the Topic associated with the DataWriter has TopicSecurityAttributes with is_read_protected set to TRUE.

In the definition of the various Handshake Tokens, certain property values are specified with literal strings in the spec (such as "RSASSA-PSA-SHA256"). Since these are inserted into binary_properties, the spec should describe the encoding: is there a length prefix (like CDR string?), is there a trailing nul (like CDR string?), assume the encoding is ASCII but it would be good to specify this.

The syntax in DDS-XML containes places where an object references another object. This is done normally using an attribute with type elementNameReference defined in http://www.omg.org/spec/DDS-XML/20170301/dds-xml_domain_definitions_nonamespace.xsd

However the specification does not deny any rules/constraints on the references themselves. In fact those references must follow a precise syntax to uniquely select an element which require a full path down the containment hierarchy down to the selected element.

The specification should define this and provide some examples.

Section 7.3.7.3 defines CryptoHeader as inheriting from CryptoTransformIdentifier. However CryptoHeader is APPENDABLE and CryptoTransformIdentifier is FINAL.

This does not seem possible according to XTYPES.

Other places of the spec (section 9.5.2.3 "DDS:Crypto:AES-GCM-GMAC CryptoHeader") define it as final.

In 9.4.1.3.2 Grant Section, the spec states:

"A permissions [sic, should be grant] Section with a subject name that does not match the subject name given in the corresponding Authorization certificate shall be ignored."

It is not clear what algorithm should be applied to determine if two subject_names "match"; and this has interoperability implications.

A 'simple' approach would be a simple string comparison.

A 'complex' approach would be to do the following:

1) parse each subject_name as a series of name=value pairs,
2) check that all name's exist in each subject_name
3) check that for each name, the corresponding 'value' matches, using regex (for example fnmatch(), or similar) processing.

The more complex approach might be beneficial, because it could support using a 'wildcard' Common Name. For example, in the permissions file, use a Subject Name like this:

      <subject_name>/C=US/ST=CO/O=Twin Oaks Computing/CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com</subject_name>

Then, the Identity Cert's could be constructed with a more specific Subject Name, like "CN=participant1.twinoakscomputing.com", and it would match.

The check_create_participant entry of "Table 63 - Actions undertaken..." in the case where is_access_protected is true and all topic entries in Governance have enable_read_access_control and enable_write_access_control both true specifies that check_create_participant returns false. Thus the participant can't be created and this configuration won't be usable.

If the intent of enable_read/write_access_control is to defer to the Permissions document to determine both readability and write-ability of this participant (for the given topic) it would seem like this case should be supported and allowed by check_create_participant.

As part of resolving this issue we should also address DDSSEC12-85, meaning state whether a <default> clause should always be present.

The Authentication Plugin Model specifies a state machine to be implemented by the DDS middleware to manage the authentication of the remote Participants. The implementation of this state machine is complex because:

• It is not specified when to call validate_remote_identity (for each received SPDP or only for the first received SPDP from a newly discovered Participant? What if a malicious Participant send a SPDP at first, usurping the GUID of a legit Participant?)
• The handshake could be initiated from both sides at nearly the same time (nothing forbid this in §8.3)
• There is no indication in the specification to tell how parallel handshakes between 2 Participants should interact
• It is difficult to determine at which sense a received message belongs
• In §8.3.2.8.1 it's specified that "The DDS security implementation shall pass to the AuthenticationPlugin any message received by the BuiltinParticipantStatelessMessageReader...". But there are states in the state machine where it's not specified how to pass those messages (e.g. when validate_remote_identity has not been called yet, and the state machine is not initialized)

This results in quite complex code, and this is a weakness in a mechanism which needs to be very strong.

Anyway, the state machine in the middleware is redundant with the one needed in the plugin. In addition, it has to deal with events where it doesn't know what is really going on. Only the plugin has the real information. Therefore, we think this middleware state machine is useless, add extra complexity which makes the authentication less robust, and consumes a lot of resources.

Instead, we suggest to remove it and to change the mechanism to the following:

• remove all the "_handshake" methods on the Authentication Plugin
• add a treat_message method to the authentication plugin to handle any incoming authentication ParticipantStatelessMessage
• add a send_message method to the authentication listener interface to tell the middleware to send an authentication ParticipantStatelessMessage
• add a validated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is authenticated
• add a invalidated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is not authenticated
• once the authentication is initialised with validate_remote_identity, all the state machine is managed directly by the plugin which sends the appropriate messages and is given the received ones, until its decision is given to the DDS middleware through the authentication listener.

This will provide the necessary functionality in a much simple, efficient and robust manner.

The DDS Security version 1.1 specification mentions:

If the Participant Private Key is a RSA key, then:

The value of the c.dsign_algo property shall be “RSASSA-PSS-SHA256”.
The digital signature shall be computed using the RSASSA-PSS algorithm specified in PKCS #1 (IETF 3447) RSA Cryptography Specifications Version 2.1 [44], using SHA256 as hash function, and MGF1 with SHA256 (mgf1sha256) as mask generation function.
This RFC is the one aforementioned. It states:

This encoding method is parameterized by the choice of hash function, mask generation function, and salt length. These options should be fixed for a given RSA key, except that the salt length can be variable (see [31] for discussion). Suggested hash and mask generation functions are given in Appendix B.

In the appendix, we can see an example where the salt length is the same as the hash length:

RSASSA-PSS-params ::= SEQUENCE
Unknown macro:
Unknown macro:

However, the salt length doesn't have to be the hash length. The WolfSSL and OpenSSL crypto libraries support several options (Openssl doc here and WolfSSL doc here). Our current approach is to use OpenSSL's default option: "maximum permissible value" (pkcsBlockLen - hLen - 2) when signing and auto (detect salt length from the signature) when verifying.

proposed solution
The specification should mention the salt length used when generating the signature. Otherwise, it should say that auto must be used when verifying the signature. This would allow interoperability (WolfSSL for example doesn't use auto by default).

Section 8.2.1 Message Module says:

To provide a deterministic behavior and a deterministic message size, DataWriters associated with an TsnTalker in the Deployment configuration (see subclause 7.2.3.1) may need to limit their RTPS Message exchange to RTPS Messages that include the following RTPS Submessages:
• InfoTimestamp
• Data
• DataFrag

This should be expanded to include the RTPS HeaderExtension as well as GAP.

Later in the section there is an explanation of why GAP may not be needed:

RTPS Submessages responsible for achieving reliability or in-order delivery, such as Gap, AckNack, NackFrag; as well as the rest of Interpreter Submessages, may be sent as part of “Best Effort” Streams. However, given the guarantees of the underlying TSN system, this sort of traffic may be unnecessary for TSN-enabled DataReaders and DataWriters. Also, retransmissions and other types of aperiodic traffic may fail to meet the schedule and configuration of the TSN Streams associated with the delivery of time-critical data.

However GAP is not just for reliability or in-order delivery. It is also used in best-efforts in situation where a sample is not relevant to a reader (e.g. because of writer-side content filtering), even if the sample is sent best-efforts.
Gaps are needed to distinguish lost samples from samples that are intentionally-skipped. If the gap is not present, the reader side will interpret non sequential sequence numbers as sample loss, impacting status variables in in the DataReader.

The specification does not address whether DDS-Security can be deployed on top of TSN.
The logical assumption would be yes, but then the use of the RTPS sub-messages introduced by DDS security (e.g. SRTPS_PREFIX) should be mentioned.

An implementation of the built-in Cryptography plugin is not compatible with the local implementation of the built-in Authentication, unless it uses/understands the same type of SharedSecretHandle. (SharedSecretHandle is the interface defined at the architecture level.) Therefore, the two built-in plugins are tied together and you cannot replace one or another with any other implementation of the same built-in plugin.
It is possible to make them independent in two possible ways (at least):

1. Define a BuiltinSharedSecretHandle that extends SharedSecretHandle interface, and has 3 methods like this:
   • octet[] getChallenge1(): returns challenge1 from the authentication handshake
   • octet[] getChallenge2(): returns challenge2 from the authentication handshake
   • octet[] getSharedSecret(): returns the shared secret from the authentication handshake
2. OR define a new type of Token (IDL structure) - e.g. HandshakeResultToken - for the final output of the Authentication handshake like this:
   • class_id DDS:Auth:PKI-DH:1.0+Result
   • binary_properties: challenge1, challenge2, SharedSecret

In both cases, it would change the specs of the methods get_shared_secret() and return_shared_handle() of the Authentication plugin, section 9.3.3.

The following two sections in DDS-Security 1.1 affect future versions of DDSI-RTPS.

The DDSI-RTPS should include language that makes sure future versions do not conflict with what DDS-Security and future revisions thereof may do.

Specifically the following two sections of DDS-Security 1.1 should be taken into consideration

7.3.6.1 Change to the RTPS minor version number
Implementations of this specification shall set the RTPS protocol version number present in the RTPS Header. The RTPS Major version number shall be set to 2 and the RTPS Minor version number shall be set to 3. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

7.4.1.3 Reserved RTPS parameter IDs
This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range:
0x1000 to 0x1FFF and 0x5000 to 0x5FFF. The second interval covers the same range of parametersID, except they have the must-understand bit set. This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

It is not clear whether the Permissions XSD allows to express all kinds of wildcard permissions. Just to make sure we cover all cases, we should give examples of permissions XML that grant only...

1. all permissions to any domain? ("all permissions" = join, pub/sub/relay to any topic/partition/data_tag, etc.)
2. all permissions to a specific domain, e.g. domain 0?
3. all permissions to all topics of domain 0? ("all permissions" = pub/sub/relay, etc.)
4. all permissions to all partitions of domain 0?
5. all permissions to a specific topic, e.g. "Circle1", of domain 0?
6. all permissions to a specific partition, e.g. "P1", of domain 0?
7. the permission to publish to any topic of domain 0? (but not subscribe/relay)
8. the permission to publish to any partition of domain 0? (but not subscribe/relay)

Such examples would be very useful in the spec as well.

There are some issues with the UML model that should be improved. This came from the AB review of the RTF 1 report:

● SubmessageKind should be an Enumeration not a Class. And it’s missing its Literals. Tables 4,5 indicate Literals would include SEC_BODY, SEC_PREFIX, SEC_POSTFIX, SRTPS_PREFIX, SRTPS_POSTFIX
● SubmessageFlag is totally underspecified but probably should not be a PrimitiveType
● Likewise CryptoState. In fact there are far too many PrimitiveTypes, none of them documented, which should probably be Strings.

The specification contains full copies of the machine readable XSD files:

• DDS Security Access Control Permissions XSD
• DDS Security Access Control Governance XSD

This causes problems as updates may not always be done consistently.

Therefore it would be better if the specification removed this duplication and just referenced the external machine-readable files.

The specification depends on many other standards that appear referenced thought the specification and in Annex A (References) but do not appear in Section 3.

Section 3 should be expanded to include the subset of those references that are used for normative behavior. [46], [47], and [52] are clear examples of references that should be moved to Section 3.

The machine-readable files have comments that trace their changes to the Jira issues that caused them. This hurts the use of the specification so they should be removed.

The authentication handshake requires participants to exchange their permission files. This is done as clear text.

Visibility into the permissions file leaks information as to what the system Topic names are as well as what the application publishes and subscribes. This can be sensitive for some systems.

Aside form this sending this document is potentially expensive as the knowledge could be available on a separate channel.

The RTF should look share this information only with authenticated participants and possibly also avoid sending it if it is already known to the peer participant.

Related this is the fact that permissions are "monolithic" of you need to add a permission to a Participant you need to create and sign a new document. Would be nice to have some way to grant/propagate incremental permissions. E.g. something that could be bundled into the propagation of the Endpoint discovery data itself.

The Security plugin model supports being able to control access to each DDS Topic instance (instead of just controlling access to the DDS Topic). However the builtin plugin permission files do not provide a way to configure these permissions.

This is important for many DDS-Security use-cases where each instance represents a different object and needs to separately indicate who has access to it. For example imaging a "CarPosition" topic that is used to publish the position of cars. Someone may be given permission to suscribe or publish its own car position, but not other cars. Likewise a manufactured or insurance company may be given permissions to the cars that they manage but not others.

The permissions document allow and deny rules contain a section for matching the data tags of the DataReader/DataWriter. The match is based on an exact match of the tag-name and tag-value.

For consistency with the way we match the permissions for Topic and Partitions we should also allow an expression for the tag-value portion. This is only for the permission rule itself. Not for the DataTag QosPolicy.

So to match the rule the DataTag name in the Qos must exactly match the name in the permissions document (no expressions here) and the DataTag value in the Qos should match (using fnmatch) the expression in the permissions document.

Normative IDL has no parameter handshake_message_in (from Table 23). It would be possible to use handshake_message_out to serve the purposes of "in" since it's an inout parameter in IDL, but is that the intention here?

In 7.2.3.1, DataHolder is a struct annotated with @extensibility(APPENDABLE) and no optional fields.
However in ptc/17-09-26 (normative IDL), DataHolder has no @extensibility annotation and two optional fields.

At end of 2nd to last para document has (matching the errata):

"sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid."

It should probably be

"sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid set to zero.”

The UML diagrams in the specification use UML stereotypes, such as <<discovery>>. However these are not documented anywhere in the specification nor do they appear in the XMI.

Also the diagrams are non-standard UML in that they show superclasses in the top right corner. See for example Figure 10.

These issues should be corrected.

Table 32 (8.4.2.9) has a topic_name parameter for both get_datawriter_sec_attributes and get_datareader_sec_attributes, however this parameter is not present in the normative IDL.

In the normative IDL interface CryptoTransform, the decode_datawriter_submessage operation uses the "in" parameter passing mode for SecurityException – should be "out" or "inout".

In the normative IDL, the type of the 2nd parameter for set_permissions_credential_and_token is listed as PermissionsCredential but should PermissionsCredentialToken.

The normative IDL doesn't have SecureSubmessageCategory_t, but it does have SecureSumessageCategory_t which appears to be a typo.

Section 7.4.3.2:

The data type associated with these endpoints is ParticipantStatelessMessage defined
below (see also 7.2.5):
typedef ParticipantStatelessMessage ParticipantGenericMessage;

Two issues:
a. I don't see how this relates to 7.2.5, should that be 7.2.6?
b. The typedef is backwards. Typedef declares a new name (second) from an existing type (first).

2nd parameter to get_topic_sec_attributes has type "String", should be "string".

SubscriptionBuiltinTopicDataSecure should inherit from SubscriptionBuiltinTopicData in the local module, not the one in the DDS:: module.

DDS::Security::LongLongSeq is not used so it should be removed from the normative IDL.

Section 7.2.5 changes QoS in ways that break RTPS compatibility, however minor modifications can fix this.

Because the mapping for PropertyQosPolicy in Table 10 (is this an implied entry in Table 12 as well?) conflicts with RTPS's definition of PID 0x59, the Binary Property values may not be sent on the wire. Note that RTPS has no concept of appendable extensibility, and requires backwards compatibility for all 2.x versions.

We can represent this restriction on PropertyQosPolicy in IDL4:

@extensibility(FINAL)
struct PropertyQosPolicy {
  PropertySeq value;

  @non-serialized
  BinaryPropertySeq binary_value;
};

The practical effect of this change is that any BinaryProperty entry with propagate == TRUE is not actually propagated inside PropertyQosPolicy. However a search through the specification indicates that there is no requirement for this, at least for built-in plugins. Any other plugins are necessarily vendor specific so those are not necessarily restricted from using an appendable policy, as long as they are aware of the compatibility issues (for allow_unauthenticated_participants == TRUE).

Also, for consistency the Tag and DataTags structs could be made @extensibility(FINAL). This is not as important since only Security-aware implementations will know about DataTagQosPolicy.

The rows in Table 61 is_submessage_encrypted and is_payload_encrypted each have paragraphs starting "If is_*_encrypted is FALSE..." and including "GCM authenticated encryption", which should be "GMAC authentication transformation" like the corresponding rows of Table 59.

In Table 30, the entry for is_payload_protected says "If is_payload_protected is FALSE, then the CryptoKeyFactory, KeyExchange and CryptoTransform operations are called only if is_payload_protected is TRUE", but the last phrase should be "only if is_submessage_protected is TRUE".

In section 8.8.2.2, it's established that the BuiltinParticipantStatelessMessage built-in endpoints are used for exchanging the "authentication handshake" messages. This makes sense based on how those built-in endpoints are defined in 7.4.3 and how they're used in some parts of 8.3.2.9 and .11.

However there are parts of 8.3.2.11 and 8.8.2 that describe this handshake using the names BuiltinParticipantMessageWriter / Reader (note the absence of "Stateless"). The name BuiltinParticipantMessageWriter is defined by the RTPS spec as the endpoint used to implement the participant scoped liveliness (see RTPS 2.2 section 8.4.13.2).

If the crypto plugin transforms the payload but the layers containing the payload (submessage or message) are not transformed, the resulting Data/Frag submessage contains no indication that its payload has a nonstandard format.
Since this spec is essentially defining a new minor version of RTPS (along with RTPS RTF process concurrent to this), one of the reserved flags in the submessage header of Data/Frag can be defined as FLAG_S meaning that the format of the SerializedPayload submessage element is defined by the security spec.

The last paragraph of 7.4.2 indicates that TopicSecurityAttributes::is_liveliness_protected is used to determine if a liveliness message should be sent using the new DCPSParticipantMessageSecure builtin endpoint or the old DCPSParticipantMessage builtin endpoint.

However it is not clear which topic's TopicSecurityAttributes are to be used. The liveliness message essentially belongs to the participant and not any given topic (see RTPS v2.2 8.4.13.5). Should the security spec use ParticipantSecurityAttributes here instead?

9.4.1.2.6.4 describes Enable Read Access Control, however the bullet list within this section uses the xml tag <enable_write_access_control> (twice), it should be <enable_read_access_control>.

Operation: get_datarwriter_sec_attributes
should be
Operation: get_datawriter_sec_attributes

In the Table 70 row for register_local_datareader, the ReaderKeyMaterial is created based on Data Protection Kind. This should be Metadata Protection Kind because the ReaderKeyMaterial signs/encrypts submessages and not data payloads.

The term CryptoKeyTransform is used 3 times (section name of 9.5.3.3, text of 9.5.3.3.1, caption of Table 72). These should be CryptoTransform.

Section 7.4.4.2 "TopicSecurityAtributes" should be "Attributes"

Section 8.8.9.1, 8.8.9.2, and 8.8.9.3 "cripto" should be "crypto"

Section 8.8.3 "best-efforts" should be "best-effort"

Section 8.8.4 "simultanepusly" should be "simultaneously"

Table 63 caption: "bulitin" should be "built-in"

Section 9.5 "BEST_EFFORTS" should be "BEST_EFFORT"

Section 9.5.2.3 "indentifier" should be "identifier"

Section 9.5.3.1 "ciphetext' should be "ciphertext"

Normative IDL parameter 1 of create_local_data_crypto_tokens "cryto" should be "crypto"

Section 7.4.1.3 'Reserved RTPS parameter IDs' reserves the whole 0x1000 to 0x1FFF (plus 0x5000 to 0x5FFF for must-understand) . That is 2 x 4096 PIDs. In reality DDS security only uses 6 PIDs... So this is a bit too much of a land grab.

It would be better to be more conservative and reserve a smaller range which can then be expanded as needed.

RTPS version 2.4 states that the reserved range for DDS security is 0x1000 to 0x10FF and 0x5000 to 0x50FF.

Section 7.4.1.3 should be updated to reflect this reduced range.

There are a few cross-references that don't resolve, resulting in the text "see 0" or "in subclause 0" in the spec:

• Table 30 plugin_endpoint_attributes column 3 contains "found in 0"
• Table 52 get_authenticated_peer_credential_token contains "See section 0"
• 9.4.1.2.6.7 right before the bullet list
• Table 63 validate_remote_permissions
• 9.5.3.3.4.1 final paragraph has "subclause 0"

In CryptoKeyFactory, all operations other than the unregister_* ones return handles. But the descriptions of register_matched_remote_participant and register_local_datawriter (8.5.1.7.2-3) end with "operation returns false". That should be "operation returns HandleNIL".

In Table 48 (9.3.2.4), "properties" should be "binary_properties" so that the property future_challenge is treated as binary, matching Table 49's challenge1.

In the normative IDL, the struct ParticipantSecurityAttributes's field plugin_participant_attributes has type ParticipantSecurityAttributesMask but it should have type PluginParticipantSecurityAttributesMask

Section 9.3.1.3 (Identity Certificate) indicates it is possible to use certificate chains.

However the language of this section is confusing because an X.509 v3 Certificate does not contain a chain. It is a single certificate. What can contain a chain of certificates is a file. E.g. the standard "PEM" file format referenced in Table 44 can contain a certificate chain.

To clarify this the following modifications are suggested:
(1) In table 44, row for "identity_certificate" change from:
"URI to a X509 certificate signed by the IdentityCA in PEM format"...
To
"URI to a X509 certificate (or certificate chain) signed by the IdentityCA, either as the root CA or as an intermediate CA, in PEM format"

(2) In section 9.3.1.3 change from:
"An X.509 v3 Certificate [39] that chains up to the Identity CA (see 9.3.1.1)."
To:
"A X.509 v3 Certificate chain [39] that is signed by the Identity CA (see 9.3.1.1) either as the root or as an intermediate CA in the chain"

(3) In section 9.3
In bullet 3. Clarify it may not be a single X.509 rather it can be a chain.

(4) In table 49, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

(5) In table 50, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

(5) In table 52, field "validate_local_identity" indicate this is not a single certificate but a certificate chain.

(6) In Table 53 IdentityCertificate is undefined. Maybe it should be "identity_certificate" and refer to the property defined in Table 44.