An implementation claiming conformance to this document shall support the status_request_v2 [sic] extension according to RFC 6066.
Note that this does not necessarily require support of OCSP interaction with an OCSP responder.
======
The problem is that if the implementer has no intention of supporting communication with an OCSP responder, then there are two possible responses that a TLS 1.2 Server can have if a TLS 1.2 Client has made an OCSP stapling status_request:
1. The TLS 1.2 Server can completely ignore the status_request and not even transmit a CertificateStatus message back to the TLS 1.2 Client.
2. The TLS 1.2 Server return a CertificateStatus message with status_request extension with empty extension_data in its extended ServerHello message.
Currently product implementers have the ability to implement either response. However, from a testing perspective there is no way to tell if the TLS 1.2 Server "supports the status_request extension" if the TLS 1.2 Server reacts using method 1. I.e., it's indistinguishable from simply not support the status_request extension at all.
This would seem to point towards a need for a TLS 1.2 Server to react using method 2. However, the current standard does not mandate this.
Proposal
Either mandate method 2 or remove the mandate to support the status_request extension (RFC 6066).
Discussion
Created
Status
To capture the described point proposal 2 has been accepted as future improvement to clarify the reaction of a server not willing to contact an OCSP responder. As IEC 62351-3 mandates support of the extension, a client could implicitly derive that if it does not get the information from the server, the server may have no possibility to provide the information. The further procedure on the client side without having revocation information is described.
In the future enhancement, the sentence "An implementation claiming conformance to this document shall support the status_request_v2 extension according to RFC 6066." need to be corrected to state "status_request" only.
08 Jan 25
Approval (Future Improvement)
OK for me
27 Aug 24
Discussion (red)
Proposal for Approval (Editorial)
26 Aug 24
Discussion (red)
I agree with the comments provided by Steffen Fries. If the implementation is compliant with the document it must support the extension and should then respond with empty data.
27 Jun 24
Accepted
In general if the server is IEC 62351-3 compliant, it shall support the extension.
To be unambiguous in the response, the server should react as proposed in method 2 returning a CertificateStatus message with empty extension_data.
Note that the sentence "An implementation claiming conformance to this document shall support the status_request_v2
extension according to RFC 6066." need to be corrected to state "status_request" only. v2 refers to multi stapling of OCSP responses and is handled in a separate sub clause.