3 ms·

> 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

by gpm 5y ago

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

jcranmer 5y ago
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.
- Grollicus 5y ago
  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.5 https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2....
  - NovemberWhiskey 5y ago
    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.
    - gpm 5y ago
      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.
      - NovemberWhiskey 5y ago
        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.
        shawnz 5y ago
- gpm 5y ago
  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...
  - grumple 5y ago
    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.
  - mkishi 5y ago
    If that's the case, the previous implementation was correct and they'll start issuing certificates with 90 days - 1 second now.
- mjw1007 5y ago
  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.

by gpm 5y ago

jcranmer 5y ago

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.

Grollicus 5y ago
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.5 https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2....
- NovemberWhiskey 5y ago
  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.
  - gpm 5y ago
    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.
    - NovemberWhiskey 5y ago
      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.
      - shawnz 5y ago
gpm 5y ago
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...
- grumple 5y ago
  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.
- mkishi 5y ago
  If that's the case, the previous implementation was correct and they'll start issuing certificates with 90 days - 1 second now.
mjw1007 5y ago
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.