By default, allow SCT timestamps to be up to 5 minutes in the future

As requested in
https://github.com/openssl/openssl/pull/1554#issuecomment-246371575.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1554)

crypto/ct/ct_policy.c

@@ -17,6 +17,12 @@
 
 #include "ct_locl.h"
 
+// Number of seconds in the future that an SCT timestamp can be, by default,
+// without being considered invalid. This is added to time() when setting a
+// default value for CT_POLICY_EVAL_CTX.epoch_time_in_ms.
+// It can be overridden by calling CT_POLICY_EVAL_CTX_set_time().
+static const time_t SCT_CLOCK_DRIFT_TOLERANCE = 300;
+
 CT_POLICY_EVAL_CTX *CT_POLICY_EVAL_CTX_new(void)
 {
     CT_POLICY_EVAL_CTX *ctx = OPENSSL_zalloc(sizeof(CT_POLICY_EVAL_CTX));
@@ -27,7 +33,7 @@ CT_POLICY_EVAL_CTX *CT_POLICY_EVAL_CTX_new(void)
     }
 
     // time(NULL) shouldn't ever fail, so don't bother checking for -1.
-    ctx->epoch_time_in_ms = time(NULL) * 1000;
+    ctx->epoch_time_in_ms = (time(NULL) + SCT_CLOCK_DRIFT_TOLERANCE) * 1000;
     return ctx;
 }
 

doc/man3/CT_POLICY_EVAL_CTX_new.pod

@@ -68,8 +68,8 @@ CT_POLICY_EVAL_CTX.
 
 The SCT timestamp will be compared to this time to check whether the SCT was
 issued in the future. RFC6962 states that "TLS clients MUST reject SCTs whose
-timestamp is in the future". By default, this will be set to the
-current time (obtained by calling time()) if possible.
+timestamp is in the future". By default, this will be set to 5 minutes in the
+future (e.g. (time() + 300) * 1000), to allow for clock drift.
 
 The time should be in milliseconds since the Unix epoch.