crypto/tls: implement OCSP Must-Staple

[nhooyr]

A bit over a year ago, someone created an issue to add support for RFC 7633 TLS Feature Extension into crypto/tls but it was closed by @agl because he felt it was premature and that OCSP stapling wasn't really supported as a client in Go (not sure if that has changed?).

See #13074

It's been more than a year so I'm creating this issue to see what he thinks of it now.

[odeke-em]

Another one for you s'il vous plait @agl.

[agl]

Firstly, there's nothing stopping you from using ExtraExtensions and Extensions to implement this if you wish in crypto/x509, the question is really whether OCSP stapling, must-staple etc should be wound throughout the code. Probably as both a client and server if we're going to do a good job of it.

Firefox supports must-staple now and Chrome has Expect-stable support. I think Cloudflare have it on blog.cloudflare.com.

So it's plausible, but a bigger job than can reasonably happen in the 1.10 cycle.

[ianlancetaylor]

Proposal accepted based on @agl's comment. Please go ahead and send in an implementation.

[FiloSottile]

Retitled to reflect that this is about implementing OCSP Must-Staple across crypto/tls and crypto/x509.

[divjotarora]

@FiloSottile @agl Until this is done, what are my options to perform OCSP verification in a client (non-HTTP client, if that matters). For my use case, I need to be able to determine whether or not the certificate presented by the server has a Must-Staple extension, the stapled response returned by the server, if any, and the OCSP responder endpoint for the certificate presented by the server.

I've seen two recommended options so far:

1. Use the VerifyPeerCertificate callback in the tls.Config. I like this idea because crypto/tls will abort the handshake and report a proper error if OCSP verification fails, but I cannot figure out how to access the server's stapled OCSP response.

2. Let the handshake complete normally and then use the tls.Conn.ConnectionState method to access the ConnectionState, which has the certificate chain presented by the server and the stapled OCSP response. I saw this approach in this talk. It could work, but it might report that the handshake has been successfully completed in server logs.

Any suggestions?