crypto/x509: support SCT/OCSP passthrough when using platform verifiers

[rolandshoemaker]

During TLS handshakes, in particular, additional inputs to verification can be sent alongside the certificate chain, typically a set of SCTs and/or a stapled OCSP response, that can be used to resolve additional trust constraints on the chain. The native Go verifier currently has no support for these additional inputs, but when platform verifiers are used (on Windows and macOS) these inputs could be utilized.

#51991 is an example of when ignoring these additional inputs (in particular SCTs) causes verification failures when using a platform verifier, because the platform applies additional restrictions on verification which require the inputs to resolve.

I propose that we add fields to x509.VerifyOptions that allow passing through these inputs to Certificate.Verify. These will be explicitly documented to only be considered when using platform verifiers, but at some point in the future we may want to add additional functionality to the native verifier to consider them (in particular OCSP responses). Once these fields are added the TLS implementation can be configured to pass through any additional inputs passed during the handshake.

type VerifyOptions struct {
	...

	// SignedCertificateTimestamps is a list of DER encoded SCTs for the
	// certificate to be verified. These SCTs are only considered if a platform
	// verifier is being used for verification. When using the native Go
	// verifier, SCTList is curently ignored.
	SignedCertificateTimestamps [][]byte

	// OCSPResponse is a DER encoded OCSPResponse, containing an OCSP response
	// for the certiifcate to be verified. The response is only considered if a
	// platform verifier is being used for verification. When using the native
	// Go verifier, OCSPResponse is currently ignored.
	OCSPResponse []byte
}

cc @FiloSottile

[FiloSottile]

I would hedge on not using them with the Go verifier as we might start doing that later. So maybe "is currently ignored".

Let's use the names and types from tls.ConnectionState so callbacks can easily pass them through.

type ConnectionState struct {
	// SignedCertificateTimestamps is a list of SCTs provided by the peer
	// through the TLS handshake for the leaf certificate, if any.
	SignedCertificateTimestamps [][]byte

	// OCSPResponse is a stapled Online Certificate Status Protocol (OCSP)
	// response provided by the peer for the leaf certificate, if any.
	OCSPResponse []byte

[rolandshoemaker]

Agreed, updated to match.

[FiloSottile]

LGTM, although note that Chrome is asking the community for feedback around deprecating SCT delivery via TLS extensions. https://groups.google.com/a/chromium.org/g/ct-policy/c/WX6iZt7uJBs

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Have all concerns about this proposal been addressed?

[rolandshoemaker]

I believe so, there is some movement in Chrome-land to possibly deprecate the SCT transmission methods, but there was enough pushback that it seems unlikely to go anywhere anytime soon. I think myself and Filippo are in agreement that it makes sense to add the functionality for now.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group