Firstly, this topic is in no way meant to insult anyone's intelligence. Nuances of interpretation can be a real gray/grey area. In case anyone is confused about this incident, I want to provide a simple, brief explanation of the math. Again, if this seems obvious, it means that you already interpreted things the "right" way.
The key lies in the terms "not before" and "not after" along with the one-second granularity of digitally accounting for time. Many of us are perhaps more used to the terms "begins at" and "expires at". When accounting by the second, "not before" and "begins at" noon have the same meaning. When the clock transitions from 11:59:59 AM to 12:00:00 PM, the period starts. However, "not after" and "expires at" one do not have the same meaning. When the clock transitions from 12:59:59 PM to 1:00:00 PM, the period has "expired at one" and thus the period lasted one hour. However, when the clock transitions from 12:59:59 PM to 1:00:00 PM, the time is still "valid" within the period because the time is invalid "after" 1:00:00 PM. Since we are using digital time granularity, the period expires at 1:00:01 PM, which is the first granular unit of time meeting the condition of being "after" one. Thus, the period lasted for one hour and one second.
Personally, I wouldn't care if the certificates were 90 days and 43 199 seconds valid. If the CPS says "90 days", I would say you could round it to a whole day.
Personally, I think this is a whole big bunch of nitpicking. In practice, there's effectively no big deal here.
Of course, since the notBefore date is set to an hour before the certificate is requested, actual certificate lifetime has been 90 days minus one hour (plus one second) from the request time. It's just that it's the notBefore-through-notAfter time that all the Official Standards are looking at.
Agreed, though of course CAs are held to an extremely high standard (as they generally should be) about nitpicking all the standards that apply. Though this may be one of the times that the standards are more buggy than the implementations.
While I certainly agree that this should be considered an "incident" until proven it's not, some of the discussion in the Mozilla bugs is that this nitpicking about things that violate a CPS but don't violate the industry standards will end up encouraging CAs to be extremely vague in their CPS wherever possible, which might not really be the desired result.
That just depends on what you consider the "lifetime" of a certificate: the technical meaning by calculating the time between notBefore and notAfter (with our without the second ) or the practical meaning: i.e., how long it's still valid since issuance?
Ironically, this all comes down to analog versus digital time accounting. Milton Erickson, considered by many to be the father of modern hypnotherapy, spent a great deal of effort "dedigitizing" patients' "conditions". How far is too far? Where is the "line" (digital cutoff point / threshold) for one behavior versus another. He once mapped a guy's route home from work in a horribly convoluted path just to test "how close" the guy could get to a bar without walking inside for a drink. Can't say "no" to a cigarette, huh? Let me keep handing you one after another until you can say "no"... or you catch on fire trying to hold them all...
RFC5280 only specifies that the notbefore/notafter times are stored as integer seconds, it does not mandate that the comparison should be done using the current system date truncated to whole seconds. In fact, it's logical that it's done using all the available precision, and in that case, this bug is not a bug actually, since the current notbefore/notafter dates specify exactly 90 days, and any implementation that allow the usage for 90days1second should be fixed.
Integer seconds are digital time accounting. Since the certificate stores its time in this format, the comparison between notafter and notbefore will necessarily be in whole=integer seconds, so I'm not exactly sure where the difference is here. How does the current system date come into play?
That's the problem. The specification/intention comes from the math, not the other way around.
Mathematically, comparisons between integers and real or even transcendental numbers are well-defined.
We can say that 3 is smaller than 3.01, or that 3 is smaller than pi.
Computer systems (to my knowledge) always keep the time with better than 1 second precision, as evidenced by for example the gettimeofday() POSIX system call that provides microsecond granularity.
This call was even obsoleted in POSIX.1-2008 in favor of clock_gettime(), that provides nanosecond precision.
So any implementation should be able to compare the notAfter (integer) with the current system time (integer seconds + integer nanoseconds), and would come to a conclusion that the cert is invalid at 1:00:00.000000001 - a mere nanosecond after the intended expiration.
This nanosecond error will likely be even less in the future as better timekeeping becomes available.
That RFC refers to the ASN.1 type of UTCTime and GeneralizedTime . One must verify the time canonicalization method defined by ASN.1, such as how to deduce from the semi-continuous time (very high precision) to the full second resolution time. Is it rounding, truncating or some other method?
The defined method itself is not so important for our case. What is important to know, is the time canonicalization well defined in ASN.1?
The problem though, as I see it, is not the comparison of notafter (integer) with the current system time (?). The problem, as I see it, is the comparison of notafter (integer) with notbefore (integer) while mathematically operating in the same numerical domain. Since the timestamps of notbefore and notafter are integers, the same would hold true of any valid timestamp within that numerical domain. Hence, I don't believe smaller granules of time can be considered here. Otherwise, we could simply take the lower limit as the granule size approaches zero (i.e. just keep cutting the granule) until we're left with "not after" = "expires at".
This is a foundational problem similar to what happens in the legal realm where well established tenets (math and semantics here) are leveraged so copiously that they overshadow underlying assumptions (the nature of the operands here) that are not necessarily well established.
Wouldn't crl (http://x1.c.lencr.org/) have same problem as certs CSP it follows same RFC5280 and CSP 3.3 still mantion its lifetime as 30 days? @lestaff
) or the practical meaning: i.e., how long it's still valid since issuance?
