TLS 1.3: support for status_request extension in CertificateRequest messages

[Jamil Nimeh]

It wasn't implemented primarily for time considerations during the 
initial TLS 1.3 implementation.  I had planned to go back at some point 
and add support for it.  It's the wrong thing to have an alert thrown by 
the client if the extension is present, since it's legal to have in TLS 
1.3.  Our client should have just omitted the response in-band but 
continued with the handshake.

If you want to take a swing at it, go for it.  I'd be happy to be a 
reviewer for it.

I agree about the empty nature of the extension...it seems like if and 
endpoint - server or client - is initiating status_request, then you 
might want to put responder IDs or other OCSP extensions in it, just as 
you would in the CH.  But I don't see anything yet in the errata 
relating to this.  It's probably best to just go right along with the 
spec.  I think that was what the Go folks were doing.

--Jamil

On 12/16/2019 8:19 AM, Martin Balao wrote:
> Hi all,
>
> Looks to me that OpenJDK's TLS 1.3 implementation is not supporting
> status_request extension in CertificateRequest messages [1]. This is
> specified in RFC 8446 at section "4.4.2.1. OCSP Status and
> SCT Extensions" [2]:
>
> "A server MAY request that a client present an OCSP response with its
> certificate by sending an empty "status_request" extension in its
> CertificateRequest message.  If the client opts to send an OCSP
> response, the body of its "status_request" extension MUST be a
> CertificateStatus structure as defined in [RFC6066]."
>
> Note: It's unclear to me why the RFC 8446 requires the status_request
> extension to be empty when available in the CertificateRequest the
> server sends to the client. Would have made more sense to me if the
> extension where the same than in a ClientHello message.
>
> A compatibility issue has been raised by golang people here [3].
>
> My questions are:
>
>   1) is there a reason why this was not implemented?
>
>   2) in case there is not, is this on your roadmap or would you be
> interested in a fix proposal?
>
> Apologies if this has been discussed already, but couldn't find anything
> on this list.
>
> Thanks,
> Martin.-
>
> --
> [1] -
> https://hg.openjdk.java.net/jdk/jdk/file/de152e6a99a5/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#l98
> [2] - https://tools.ietf.org/html/rfc8446#section-4.4.2.1
> [3] - https://github.com/golang/go/issues/35722
>