Issue #178: Describe how to validate an SCT

draft-ietf-trans-rfc6962-bis.md

@@ -1674,9 +1674,21 @@ and v2 SCTs to co-exist in a certificate (See {{v1_coexistence}}).
 In addition to normal validation of the server certificate and its chain, TLS
 clients SHOULD validate each received SCT for which they have the corresponding
 log's parameters. To validate an SCT, a TLS client computes the signature input
-from the SCT data and the server certificate, and then verifies the signature
-using the corresponding log's public key. TLS clients MUST NOT consider valid
-any SCT whose timestamp is in the future.
+by constructing a `TransItem` of type `x509_entry_v2` or `precert_entry_v2`,
+depending on the SCT's `TransItem` type. The `TimestampedCertificateEntryDataV2`
+structure is constructed in the following manner:
+
+* `timestamp` is copied from the SCT.
+* `tbs_certificate` is the reconstructed TBSCertificate portion of the server
+   certificate, as described in {{reconstructing_tbscertificate}}.
+* `issuer_key_hash` is computed as described in {{tree_leaves}}.
+* `sct_extensions` is copied from the SCT.
+
+The SCT's `signature` is then verified using the public key of the corresponding
+log, which is identified by the `log_id`. The required signature algorithm is
+one of the log's parameters.
+
+TLS clients MUST NOT consider valid any SCT whose timestamp is in the future.
 
 ### Validating inclusion proofs    {#validating_inclusion_proofs}