MINT CR2-2022: OCSP Stapling

[plughy2]

@kenji-acumen Opening this GitHub issue to discuss if NDcPP v3.0 should add support for OCSP stapling.

MINT, please feel free to add your comments whether NDcPP v3.0 should support this or not.

Reasons for adding support for OCSP stapling:

• For TLS client implementations that support OCSP stapling, the cost of an OCSP validation is reduced.
• The collaborative Protection Profile for Application Software as well as NIAP PPs support OCSP stapling.

Reasons for not adding support for OCSP stapling:

• OCSP stapling supports only one OCSP response at a time, which may not meet the FTP_ITC.1 requirement for TLS client connections where X.509 certificates are used to authenticate remote end points and revocation checking must support a certificate chain length of three. RFC 6961 - Multiple Certificate Status Request Extension - added support for sending multiple OCSP responses but appears to have limited widespread support.

• TLS 1.3 removed this limitation altogether. See https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.1). With TLS 1.3, a server can send multiple OCSP responses, i.e., one for each certificate in the certificate chain, which deprecates the need to support RFC 6961.

[kenji-lightship]

This captures the concerns I mentioned on the call. I do not believe OCSP Multi-Stapling (RFC 6961) is widely supported, so since it is already been obsoleted by RFC8446, I would not expect it to achieve wide support. I don't believe it is worth the effort to add OCSP multi-stapling.

As far as whether to add OCSP stapling, it comes down to whether the NDiTC is OK with only having end-entity certificates being revocation checked (i.e., not checking ICAs). I don't have a strong position either way.

If we add OCSP stapling, we will need to consider and clarify testing with TLSv1.2 vs. TLSv1.3. This is a complication the NIAP PPs don't currently address.