Currently, the sros2 api makes subprocess calls to the systems OpenSSL CLI for generating public/private x509 key pairs and signing for SMIME. This is a bit hacky, as it relies upon the OpenSSL CLI to be consistent across runtime targets, making it quite fragile should the CLI or implicit defaults change. Instead, we should seek to use a proper cryptography library API so we may have finer control over key material provisioning and error handling for the user.

For example, users wishing to use Connext for DDS Security must swap the environment to point to a version of OpenSSL shipped by RTI. As RTI’s OpenSSL installer does not fully configure the CLI, as it does instead for the shared library, nor does the install respect the system config defaults for OpenSSL; this results in warnings produced by the RTI OpenSSL CLI binary that are susiquentl silenced by sros2 use of subprocess, obscuring potential errors or deviating crypto settings.

Background

cryptography is a package which provides cryptographic recipes and primitives to Python developers. Our goal is for it to be your "cryptographic standard library". cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, message digests, and key derivation functions.
https://cryptography.io

By far, my favorite python library for this is cryptography, which has a pythonic API, excellent documentation, and readily available for most targets. This what I also used back for SROS1 when developing its keyserver:
https://github.com/ros/ros_comm/blob/f95b4a5de2acb4fb53f0e9a4cff47dcef928eac5/tools/rosgraph/src/rosgraph/key_helper.py

Progress

While sros2 CLI was still in its early stages, I previously prototyped a more advanced keystore workspace tool called Keymint, again using the python cryptography library:

https://github.com/keymint/keymint_keymake/tree/adc38e07ce5f16d6ba4b36294d7d2e8a361153f0/keymint_keymake/pki

This allowed me to abstract a bit more allowing users to finally configure the asymmetric key algorithm/size/format, CA hierarchy, period of validity and expiration, file protection, etc. I’d like to port over most of these features directly into sros2, but would like to just start by swapping out the subprocess calls and establishing cryptography as a primary depency.

The only road bump is foresee is that of supporting SMIME signatures when notarizing DDS Security governance and permission documents. As of writing, the cryptography library doesn’t yet seem to have a simple API for producing smime signature. This has been an open ticket for a while:

pyca/cryptography#1621

For Keyment, I worked out out this by using M2Crypto for this one purpose instead, allow me to replicate the same valid SMIME signatures in pure-ish python. However M2Crypto isn’t as simple to install (this may have improved since I last checked a year ago), and its API is more like OpenSSL (think: giant hairball):

https://github.com/keymint/keymint_keymake/blob/adc38e07ce5f16d6ba4b36294d7d2e8a361153f0/keymint_keymake/smime/sign.py

Still, I think we can avoid M2Crypto as a dependency if we temporarily drop down a little into the backend API and add some wrappers around the lowevel interfaces for SMIME signing:

https://stackoverflow.com/questions/52780716/signing-s-mime-content-from-python