Commit fd7138dd authored Sep 12, 2016 by Rob Percival Committed by Rich Salz Nov 15, 2016

Reword documentation for {SCT_CTX/CT_POLICY_EVAL_CTX}_set_time



Do not call the time "current", as a different time can be provided.
For example, a time slightly in the future, to provide tolerance for
CT logs with a clock that is running fast.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1554)
(cherry picked from commit 1871a5aa)

parent 9c9d1361

crypto/ct/ct_locl.h

+5 −4

Original line number	Diff line number	Diff line
		@@ -155,10 +155,11 @@ __owur int SCT_CTX_set1_issuer_pubkey(SCT_CTX sctx, X509_PUBKEY pubkey);
		__owur int SCT_CTX_set1_pubkey(SCT_CTX sctx, X509_PUBKEY pubkey);

		/*
		* Sets the current time, in milliseconds since the Unix epoch.
		* The timestamp of the SCT will be compared to this, to check that it was not
		* issued in the future. RFC6962 states that "TLS clients MUST reject SCTs whose
		* timestamp is in the future", so SCT verification will fail in this case.
		* Sets the time to evaluate the SCT against, in milliseconds since the Unix
		* epoch. If the SCT's timestamp is after this time, it will be interpreted as
		* having been issued in the future. RFC6962 states that "TLS clients MUST
		* reject SCTs whose timestamp is in the future", so an SCT will not validate
		* in this case.
		*/
		void SCT_CTX_set_time(SCT_CTX *sctx, uint64_t time_in_ms);

include/openssl/ct.h

+3 −3

Original line number	Diff line number	Diff line
		@@ -106,9 +106,9 @@ void CT_POLICY_EVAL_CTX_set_shared_CTLOG_STORE(CT_POLICY_EVAL_CTX *ctx,
		uint64_t CT_POLICY_EVAL_CTX_get_time(const CT_POLICY_EVAL_CTX *ctx);

		/*
		* Sets the current time, in milliseconds since the Unix epoch.
		* The timestamps of the SCTs will be compared to this, to check that they were
		* not issued in the future. RFC6962 states that "TLS clients MUST reject SCTs
		* Sets the time to evaluate SCTs against, in milliseconds since the Unix epoch.
		* If an SCT's timestamp is after this time, it will be interpreted as having
		* been issued in the future. RFC6962 states that "TLS clients MUST reject SCTs
		* whose timestamp is in the future", so an SCT will not validate in this case.
		*/
		void CT_POLICY_EVAL_CTX_set_time(CT_POLICY_EVAL_CTX *ctx, uint64_t time_in_ms);