Comment by gpm | Hacker News Reader

Comment by gpm | Hacker News Reader

> Grzegorz Prusak

> Comment 5 • 6 hours ago

> I do not understand the math behind the mentioned problem.

> Is either the RFC or BR really specifying a DATE of 1s precision to be an INTERVAL rather than a POINT IN TIME? It specifies a granularity of points are allowed to be endpoints of a validity period, but these are still POINTS AFAICT.

> It means that, for example 10:00:01 is AFTER 10:00, even though 10:00:01 is not a valid endpoint of a validity period (and it doesn't have to be, as it is a measurement result, not a validity period endpoint).

> Does RFC or BR requires a browser to round down the measured current time to full seconds, before comparing them against the validity period?

As a random member of the public, this seems like a reasonable interpretation to me... though the time format which expiry dates are required to be expressed in is explicitly not allowed to include fractional seconds... so maybe it is meant as an interval not a point in time.

RFC 5280 says:

> The universal time type, UTCTime, is a standard ASN.1 type intended for representation of dates and time. UTCTime specifies the year through the two low-order digits and time is specified to the precision of one minute or one second. [...] For the purposes of this profile, UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is zero.

> For the purposes of this profile, GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.

In other words, the RFC specifies specifically requires the granularity of the time to be a second, and the notBefore and notAfter are worded such that is valid for all t in the range notBefore ≤ t ≤ notAfter. Computing the number of seconds this is valid for as notAfter - notBefore is a classic fencepost error.

Yes, but the relevant portion of the RFC for inclusive time ranges is

> CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime.

> The validity period for a certificate is the period of time from notBefore through notAfter, inclusive.

The way I'm reading this a conforming application must first decode the date to a point in time, and then must perform an inclusive check on that decoded date as a point in time.

The certificate expiring at 10:00:00 is not valid at 10:00:00.0001, the restrictions on the time format are just saying you can't make a certificate that is valid at 10:00:00.0001 and not valid at 10:00:00.0002.

So the fence post error "exists" here, but the size of it is t = limit granularity as granularity goes to 0 = 0...

In fact, your post makes it clear that a certificate expiring at 09:59:59 presents a problem too; there's a whole second where checks may be invalid before 10:00:00. This would depend on the browser implementation which is not specified in the RFC (I checked). Hopefully they all do truncation of fractional seconds.

The easiest fix though, is for LetsEncrypt to say their certs are valid for 90 days and a second.

If that's the case, the previous implementation was correct and they'll start issuing certificates with 90 days - 1 second now.

I disagree.

I think they intended your reading, but if I attempt to read it as strictly as possible I'd say they have defined a representation of a particular set of points in time, not intervals, and the "inclusive" in the definition of notAfter tells us that the interval is closed, not that it extends to the beginning of the following second.

RFC 5280 further says: [1]

> The validity period for a certificate is the period of time from notBefore through notAfter, inclusive.

It says nothing about the comparison precision, just the storage format. It says CAs MUST encode validity dates as UTCTime / GeneralTime. It does not say this encoding must be used for comparison.

So I don't think it's actually defined if 2020-01-02 03:04:05.01Z is actually <= 2020-01-02 03:04:05Z.

That would mean this is not a 1 second-mistake but instead an infinitesimal mistake.

[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2....

A thought experiment.

Pretend I told you that you could get 50% off a meal at my restaurant from Monday through Friday, inclusive.

Presumably you would expect that if you visited my restaurant on a weekday, the offer would apply; fine to arrive on Monday morning or Friday evening, but not on Saturday morning. In that case, the "resolution" of the parameters of the offer is "a day".

In this case, the resolution is "a second"; but the same meaning of inclusive applies - the validity is up until the end of the second specified in as the notAfter time.

The comparison precision you can achieve is irrelevant; the required semantics (though odd) are defined by the RFC.

Days, are intervals, not points in time. Traditionally a day is the time from sunup to sundown, in modern contexts it usually goes from midnight to midnight.

This is the question about timestamps, are the points in time, or are they second long intervals. I think the logical reading is the first.

This opens up the question of "what the hell is the word inclusive doing there", I think the answer is it is being used to say "if you don't know whether you're inside or outside the interval, you are inside". If your clock runs on a 2 second interval, and you know it's somewhere between 9:59:59 and 10:00:01, when the certificate expires as 10:00:00, you take the inclusive definition and say "still valid" because otherwise you might be rejecting a valid certificate.

It is perhaps also being used to say that "both ends of the interval aren't open". If I have on certificate that expires at 10am, and another that becomes valid at 10am, then there is no gap between there validity.

I guess my point is that you can only give the word "inclusive" any meaning if you accept that the authors of the RFC intend the validity times to be interpreted as intervals rather than instant, however unusual that is.

"Inclusive" still has a meaning in this interpretation. It means that the certificate is valid on the moment of the end date, as opposed to ceasing to be valid on that moment. That is what they mean by "both ends of the interval are closed".

Yeah; I suppose you could look at it from the real analysis point of view! Terrible spec, basically.

I can't seem to find anywhere in the RFC that the resolution is indeed a second. The actual format for storing the time indeed has a resolution of a second, but where exactly in the RFC does it say that a certificate with notAfter 2020-01-01 00:00:05 is valid at 2020-01-01 00:00:05.22?

I too find the reasoning odd. I work extensively with times in my day job. If a time period starts at 2021-06-10Z22:23:00 and finishes at 2021-06-10Z22:23:01 then that represents one second. For it to represent two seconds, the end time would be 2021-06-10Z22:23:01.999... which is the same as 2021-06-10Z22:23:02. If the RFC does not explicitely state that this is the desired interpretation, I find it odd to assume this is the case.

My local bar has a $1 bottled beer for some brands on Tuesdays. It is advertised as being for Tuesdays. Their weekday hours are 11am - 1am. If I show up at 12:30am Tuesday morning I don't get the deal because it is considered part of Monday's service. If I show up at 12:30am Wednesday I get the $1 beer because it is considered part of Tuesdays service.

Your bar sounds like children saying it's still weekend because they didn't sleep yet.

Maybe you should explain to them how a clock works? :)

Reply on news.ycombinator.com