Feature request

With the update to enclaves, the security environment variables could also use some updates. To future proof variables. allowing for more exotic keystore URIs, like remote URL (https://...$TOKEN) or TPM devices (tpm://...$KEY), it would be advantageous to take the opportunity to name them more appropriately while generalizing across keystore types. E.g. integrating with more advanced secret management: https://www.vaultproject.io

The following renaming is proposed:

• ROS_SECURITY_ROOT_DIRECTORY -> ROS_SECURITY_KEYSTORE
• ROS_SECURITY_DIRECTORY_OVERRIDE -> ROS_SECURITY_ENCLAVE_OVERRIDE

Additionally, to abstract above directories or file paths, I'd also like to sagest that ROS_SECURITY_ENCLAVE_OVERRIDE takes instead a fully qualified enclave name, instead of a absolute file path to an enclave directory. The use of the env ROS_SECURITY_KEYSTORE would then consistently control keystore URI (currently a file system path) and always be used to resolve the context location, regardless if context name is overridden or not.

This could help guide users that secure ros2 nodes will only communicate with nodes that share a common source of trust, or common CA. If the user has multiple keystores on disk, they may be likely to use ROS_SECURITY_DIRECTORY_OVERRIDE to point to an entirely different keystore than the rest of the launched nodes, rendering potentially cryptic looking security handshake errors from Secure DDS vendor plugins given the empty overlap of trusted certificate authorities.

For users who know what they are doing, they can still set the ROS_SECURITY_KEYSTORE uniquely for each process if they do intend on separate processes having separate keystores.

https://github.com/ruffsl/ros2/blob/security_env/ros2.repos