OCSP stapling to enhance certificate status checking during handshake
Source: THALES ( Cyril Dangerville)
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.
Reported: DDS-SECURITY 1.0 — Mon, 22 May 2017 06:40 GMT
Disposition: Resolved — DDS-SECURITY 1.1
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.
Updated: Thu, 11 Mar 2021 20:10 GMT
- Figure21_DDSSecurity-Participant_i82.emf 75 kB ()
- Figure3_Tokens_i82.emf 74 kB ()
- Figure8_Authentication_i82.emf 121 kB ()
- dds_security_plugins_spis_ballot5_i33_i66_i16_i106_i137_i3_i82.idl 35 kB ()