Add support for SCTs over TLS extension and OCSP stapling

[mattmook]

Research into server-side adoption of certificate transparency shows that X.509v3 extensions are currently the most popular way to retrieve SCTs.

However to adhere to Certificate Transparency spec and Certificate Transparency v2 spec the library needs to add support for retrieving these over TLS extensions and OCSP stapling. "TLS clients MUST implement all three mechanisms."

There is substantial use of the TLS extension (for example, Google domains typically serve SCTs via TLS extension rather than x.509v3 extension).

The same research shows how this can be implemented in pure Java with no native libraries.

See Server-side Adoption of Certificate Transparency

As part of this work DefaultPolicy will need to be updated to accommodate this.

If the SCTs were provided by TLS extensions or OCSP stapling then we only require two valid entries (Chrome forces 2 because of diversity rules), otherwise embedded SCTs continue to be checked as they are currently.

Certificate Transparency in Chrome Apple's Certificate Transparency policy See Chromium source CheckCTPolicyCompliance

[mattmook]

Interesting article about CT checks using Conscrypt - https://techblog.bozho.net/certificate-transparency-verification-in-java/

[mattmook]

Examples of SCT delivered via a TLS extension or OCSP response?

[MartinStyk]

Hi @mattmook, what is the status of this issue, please? Will OCSP stapling verification be supported on Android?

Are you aware of any working OCSP stapling implementation or library for Android clients, please? Thank you, kudos for a nice library! 🙌