Certificate Transparency: Correct month calculation.

net/cert/cert_policy_enforcer.cc

Index: net/cert/cert_policy_enforcer.cc
diff --git a/net/cert/cert_policy_enforcer.cc b/net/cert/cert_policy_enforcer.cc
index 680c2c6d1d792cdf4ef9bf6d9177222cb240e3b5..bd115c5e88a63ad6a1849ea64ddf5644c0a57ddd 100644
--- a/net/cert/cert_policy_enforcer.cc
+++ b/net/cert/cert_policy_enforcer.cc
@@ -52,10 +52,6 @@ uint32_t ApproximateMonthDifference(const base::Time& start,
   uint32_t month_diff = (exploded_expiry.year - exploded_start.year) * 12 +
                         (exploded_expiry.month - exploded_start.month);

[davidben, 2015/03/25 15:00:54]

This still isn't quite right, is it? A certificate valid from 2015-03-31 to
2015-04-01 would give 1 here, but, rounding down, it's 0.

(Also, doesn't really matter since code elsewhere will hopefully reject, but
this computation will underflow if end < start. Probably worth having this
method return 0.)

[Eran Messeri, 2015/03/25 18:27:28]

This is trickier than it seems, since the policy, as stated in month, does not
allow for consistent rounding up/rounding down of months - i.e., the code has to
know whether the validity period is exactly 15 months (or more) , so rounding up
is wrong in the case of 14 and a half months (as the issue pointed out). But the
code also has to know whether the validity period is exactly 27 months (or less)
have passed, so rounding down is wrong in the case of 27 and a half months.

I've resorted to returning, in addition to the number of rounded-down months, an
indicator of whether the last month counted is a full month.

 
-  // Add any remainder as a full month.
-  if (exploded_expiry.day_of_month > exploded_start.day_of_month)
-    ++month_diff;
-
   return month_diff;
 }