DDSSEC11 — OCSP stapling to enhance certificate status checking during handshake

Similarly to TLS OCSP stapling (RFC 6066, §8, improved by RFC 6961), OCSP stapling consists to send the certificate status (OCSP response) in the handshake message, saving roundtrips and resources. This would enhance handshake performance and energy saving in DDS security

This requires to add a new (optional) binary property like c.status to HandshakeRequestMessageToken and HandshakeReplyMessageToken and value is a DER-encoded OCSP response (using the ASN.1 type OCSPResponse defined in RFC2560) that provides the status of the certificate in c.id property. Then begin_handshake_reply() and process_handshake() should honor this property if present.

This issues has been merged with DDSSEC11-110. So the resolution to this issue should also address the certificate expiration issue raised in DDSSEC11-100.

Add support for OCSP stapling

The issue is addressed by adding two features:
(1) The DomainParticipant will be able to attach (staple) the OCSP response during the Authentication Protocol, as an extra field in the Tokens that are exchanged. This ca be used to ensure freshness at the time the authentication occurs.

(2) The DomainParticipant will be able to include the OCSP response in its ParticipantBultinTopicDataSecure. This would help ensure freshness after authentication completed.

Details of the configuration for the freshness limits and handling of expired certificates are left to the implementors.