JEP draft: Certificate Transparency

Summary

Support Certificate Transparency (CT) in JSSE as specified in RFC 6962 and section 4.4.2.1 of RFC 8446.

Success Metrics

The success metrics for the CT feature are different for the client and server:

• client: The JSSE client must be able to receive and validate Signed Certificate Timestamps (SCTs) from all three forms of delivery: Embedded SCTs in a TLS server certificate, SCTs placed in the signed_certificate_timestamp TLS extension, and inclusion of SCTs in stapled OCSP responses. Validation must include both positive and negative tests.
• server: The server must be able to accept requests from clients that support CT and deliver SCTs through either a TLS server certificate, a stapled OCSP response, or a TLS extension.

Motivation

Certificate Transparency is a solution to the challenge of detecting misissued certificates. Certificate chains are appended to public logs. These logs may be audited by certificate owners to ensure any subsequent certificates logged within their domains of interest are legitimate. RFC 6962 describes the use of the CT solution for TLS server certificates issued by public CAs.

As of today most browsers have implemented CT support and most TLS libraries have at least client-side support for SCT validation and some have server-side support as well. The validation of SCT data during the TLS handshake is a useful security feature for TLS and JSSE should implement it to achieve parity with these other TLS implementations.

Description

This feature will be provided in the SunJSSE TLS implementation. The tasks for implementing CT support will be different for client-side and server-side roles:

Client-side:

The JSSE client must be able to accept SCTs from all three methods as outlined in the specification. These are:

1. from a signed certificate timestamp list extension embedded in the X.509 TLS server certificate.
2. from a signed certificate timestamp list extension in a stapled OCSP response. This method of delivery requires that OCSP stapling is active for the TLS handshake (see JEP 249 for more information on OCSP stapling)
3. from a TLS extension that is asserted in the ClientHello message and delivered to the client either via the ServerHello (for TLS versions <= TLSv1.2) or in the Certificate message (TLSv1.3).

SCTs may be delivered through more than one source and will be collected before verifying signatures on the timestamps. The criteria for passing the SCT check (e.g. number of required valid/trusted SCTs, etc.) is TBD. If a client does not meet the minimum threshold for a passing SCT check a TLS alert will be issued and the connection closed. We may choose to bypass SCT checks if older TLS certificates before a certain cutoff date are presented by the server. Whether to allow a bypass or not, and the cutoff date for this kind of bypass are both TBD. We may also choose to bypass SCT checking requirements for non-public CAs.

Storage/Loading of trusted logs: Logs are untrusted by default and typically provide RSA or ECC keys used to perform the signatures on SCTs. These keys would need to be known to the client and a mechanism for storage of the keys needs to be determined. This may happen through extensions to the Keystore class, the X509ExtendedTrustManager class, or some other approach. This is currently TBD.

Finally, the client can have the entire feature enabled or disabled via the jdk.tls.client.enableCertTransparency System property. By default this will be true for the client.

Server-side:

JSSE Servers automatically have support for SCT delivery via X.509 certificates, and this method requires no changes to JSSE. Likewise, OCSP stapling support exists on the server and therefore no changes are required for SCT delivery via stapled OCSP responses. We may choose to support the signed_certificate_timestamp TLS extension on the server side. This would require changes to the handshaker code for the consumption of the extension in the ClientHello, and the extension's placement into either the ServerHello message (versions <= TLSv1.2) or the Server Certificate message (TLSv1.3). We will also need to investigate a method for caching SCTs so they can be retrieved efficiently on an as-needed basis. Finally we will have the jdk.tls.server.enableCertTransparency System property, true by default, that can enable or disable support for the TLS extension. Disabling it will not prevent SCT delivery via OCSP stapling or via X.509 certificate presentation to the client.

Testing

Extensive testing should be done to ensure the feature works properly. Some of the types of tests to be performed are listed below:

Client-side

• Verification of proper operation with the feature enabled:
  • Assertion of the signed_certificate_timestamp extension in the client hello message
  • Completion of handshake when valid SCT timestamps are provided
  • Alert/Closure of the handshake if SCT validity checks fail
  • Test connection with no SCT data provided at all (should fail).
  • Test loading/caching of trusted CT logs
  • Test proper collection of SCTS from the following sources:
    • X.509v3 certificate
    • Stapled OCSP responses
    • TLS Server Hello extension data
• With the feature disabled does the client omit the signed_certificate_timestamp from the ClientHello
• With the feature disabled does the client alert if signed_certificate_timestamp is asserted in the ServerHello message? (TLS 1.2 and earlier)

Server-side

• If the TLS Extension delivery feature is implemented:
  • Test ServerHello - should only assert signed_certificate_timestamp if the client asserts it (TLS 1.2 and earlier)
  • Test caching/loading of SCT data - is the data properly encoded in the ServerHello?
  • For TLS 1.3, are the SCTs provided in the Server Certificate message?

Risks and Assumptions

Certificate Transparency Version 2.0 is a revised and improved CT solution. This is still in draft but is far along in the process. It is assumed that this will not quite reach standardization by the time this JEP is completed. CT v2.0 design and requirements should be considered when designing classes and interfaces for this JEP.

Non Goals

Some items pertaining to Certificate Transparency go beyond the scope of the JSSE client and server and will not be addressed as part of this JEP.

• Implementation of a CT log monitor
• Implementation of a CT log server