Skip to main content

3.3. Including the Signed Certificate Timestamp in the TLS Handshake

3.3. Including the Signed Certificate Timestamp in the TLS Handshake​

The SCT data corresponding to the end-entity certificate from at least one log must be included in the TLS handshake, either by using an X509v3 certificate extension as described below, by using a TLS extension (Section 7.4.1.4 of [RFC5246]) with type "signed_certificate_timestamp", or by using Online Certificate Status Protocol (OCSP) Stapling (also known as the "Certificate Status Request" TLS extension; see [RFC6066]), where the response includes an OCSP extension with OID 1.3.6.1.4.1.11129.2.4.5 (see [RFC2560]) and body:

    SignedCertificateTimestampList ::= OCTET STRING

At least one SCT MUST be included. Server operators MAY include more than one SCT.

Similarly, a certificate authority MAY submit a Precertificate to more than one log, and all obtained SCTs can be directly embedded in the final certificate, by encoding the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and inserting the resulting data in the TBSCertificate as an X.509v3 certificate extension (OID 1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, clients can reconstruct the original TBSCertificate to verify the SCT signature.

The contents of the ASN.1 OCTET STRING embedded in an OCSP extension or X509v3 certificate extension are as follows:

     opaque SerializedSCT<1..2^16-1>;

     struct {
         SerializedSCT sct_list <1..2^16-1>;
     } SignedCertificateTimestampList;

Here, "SerializedSCT" is an opaque byte string that contains the serialized TLS structure. This encoding ensures that TLS clients can decode each SCT individually (i.e., if there is a version upgrade, out-of-date clients can still parse old SCTs while skipping over new SCTs whose versions they don't understand).

Likewise, SCTs can be embedded in a TLS extension. See below for details.

TLS clients MUST implement all three mechanisms. Servers MUST implement at least one of the three mechanisms. Note that existing TLS servers can generally use the certificate extension mechanism without modification.

TLS servers should send SCTs from multiple logs in case one or more logs are not acceptable to the client (for example, if a log has been struck off for misbehavior or has had a key compromise).

Last updated on