Add support for Certificate Revocation List files.

[clalancette]

At least Fast-RTPS and CycloneDDS support Certificate
Revocation Lists, so add it as one of the possible files
in the enclave. Note that it is an optional file; if
an enclave doesn't have it, then the key will be missing
from the returned map.

Signed-off-by: Chris Lalancette clalancette@openrobotics.org

Besides the maintainers of this package, also pinging @ruffsl , @mikaelarguedas , and @SidFaber . The addition of this file is essentially expanding the on-disk "API" of an SROS2 security enclave to include the crl.pem file, so I'd appreciate any feedback that you may have.

[clalancette]

CI:

• Linux
• Linux-aarch64
• macOS
• Windows

[ruffsl]

From the secure DDS spec:

If the property ocsp_status is present, the operation shall verify that the OCSP
response included in the property corresponds to the identity in the c.id property.
The operation shall use the OCSP response to verify the status of the
IdentityCredential. If that status is good and the validity interval has not
been exceeded it shall accept that as proof that the IdentityCredential is still valid.
If the status is revoked, the operation shall fail and return ValidationResult_Fail. If
the status is different from the aforementioned ones it shall behave as if the
ocsp_status property was not present.
If the property ocsp_status is not present, the operation shall use its own means to
determine the status of the IdentityCredential. This may performing an
OCSP query or consulting a CRL list. The specific behavior is implementation
specific.

Is there a consensus among the DDS vendors on how the CRL list is to be encoded, or how enabling it's configuration as implemented?

[clalancette]

Is there a consensus among the DDS vendors on how the CRL list is to be encoded, or how enabling it's configuration as implemented?

For the encoding, both open-source implementations (CycloneDDS and Fast-DDS) rely on OpenSSL (and more specifically, X509_STORE_add_crl) to make CRLs work. That means that they both expect the CRL to be of the form:

-----BEGIN X509 CRL-----
MIHTMHoCAQEwCgYIKoZIzj0EAwIwEjEQMA4GA1UEAwwHc3JvczJDQRcNMjEwNjA3
...
-----END X509 CRL-----

(it is unclear whether or how Connext implements CRLs; maybe @asorbini can comment?)

As far as how to enable CRLs, that is done differently per DDS implementation:

• For CycloneDDS, the CRL is specified by setting org.eclipse.cyclonedds.sec.auth.crl on the property QoS. Alternatively, CycloneDDS also supports setting it in a configuration file during startup.
• For Fast-DDS, the CRL is specified by setting dds.sec.auth.builtin.PKI-DH.identity_crl on the property QoS. Alternatively, I believe Fast-DDS also supports setting it in a configuration file during startup.

[clalancette]

CI:

• Linux
• Linux-aarch64
• macOS
• Windows

[clalancette]

CI is green, and this has been approved. I'm going to go ahead and merge this now; if there are any further questions about how this fits into an enclave, we can do follow-ups to make changes.

[asorbini]

(it is unclear whether or how Connext implements CRLs; maybe @asorbini can comment?)

@clalancette apologies for the late reply. Connext has supported CRLs for several versions, although I'm not sure about 5.3.1.

I also don't recall the exact CRL format, but I suspect it is the same as other implementation, since our default security plugins also rely on OpenSSL. The documentation for the authentication.crl mentions "PEM format", which is I think what you are referring to.

You can find some more information about CRL support here

I'll look for an authoritative answer on the exact version and format and get back to you.

[clalancette]

I'll look for an authoritative answer on the exact version and format and get back to you.

Perfect, thanks @asorbini !