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