Hacker News Reader

Comment by Grollicus | Hacker News Reader

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....

View on HN

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