Language change around SCTs with timestamp in the future.

rfc6962-bis.xml

@@ -1297,7 +1297,7 @@ but it is expected there will be a variety.
           TODO: What should the TLS client communicate in the extension_data? Version(s) of CT that it supports? Certain types of TransItem that it can handle? Whether or not it wants to gossip?
         </t>
         <t>
-          In addition to normal validation of the certificate and its chain, TLS clients SHOULD validate each supplied SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key. TLS clients MUST reject SCTs whose timestamp is in the future.
+          In addition to normal validation of the certificate and its chain, TLS clients SHOULD validate each supplied SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key. TLS clients MUST NOT consider SCTs whose timestamp is in the future as valid.
         </t>
         <t>
           TLS clients SHOULD also validate each supplied inclusion proof (see <xref target="verify_inclusion"/>), in order to audit the log. If no inclusion proof was supplied by the TLS server, the TLS client MAY request one directly from the corresponding log using <spanx style="verb">get-proof-by-hash</spanx> (<xref target="get-proof-by-hash"/>) or <spanx style="verb">get-all-by-hash</spanx> (<xref target="get-all-by-hash"/>), and then validate it.