On Friday, April 20, 2018 at 9:31:32 AM UTC-4, Tim Shirley wrote: > First of all, it's important to distinguish between the BR requirement, which > is defined in terms of certificate *issuance* dates, and the value in the > "Not Before" field. I'm guessing the "Not Before" value in this certificate > is not the actual issuance timestamp, since it's unlikely it was issued right > at the stroke of midnight. The CA is probably rounding, but we don't know if > they're rounding up or down. But it would only be mis-issuance if the > issuance occurred outside of the allowed time window. There's nothing I can > see to show when the certificate was actually issued; it first showed up in > CT logs on March 13, so we know it was issued on or before that, but that's > all we know for sure about the issuance time. > > So what is the allowed time window according to the BRs? I'd argue that the > intent was that it be >=. If you read the first bullet's "after" as >, then > you have to also read the second bullet's "prior to" as <. So what rule > applies to certificates issued ON March 1, 2018? Apparently none. Certainly > that wasn't the intent, which is why I interpret the requirement as >=. That > is, the dividing line is the moment in time when we moved from February into > March, such that one rule or the other is always in effect.
I agree, it was not the intent, nor is it consistent with the other modifications in 193 ( https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/ ). > But even if you accept my premise there, then you have to ask "in what > timezone?" March 1 00:00:00 2018 GMT in North America is February 28. So I > could see someone making the argument that issuance at that moment in time is > fine if the CA is in North America but it's mis-issuance if the CA is in > Europe, since the requirements don't state that the measurement is UTC. This > is why I'm not a fan of such precise enforcements of date-related compliance. > There are a lot of different ways to interpret dates/times, but none of the > readings materially change the net effect of the rule. That is, all readings > change the max validity period to ~825 days (which itself is subject to > debate as to its precise meaning in terms of seconds) within a day or two of > each other. So, enforcing the date as Mar 1 as opposed to Mar 2 doesn't seem > to add a lot of value and leads to confusion like this. I'm curious how auditors would view this, since I think this says that's all that matters. >From the client side, we continue to take the most restrictive interpretation >that is reasonable, and thus in Chrome, any certificate whose notBefore is >= >2018-03-01 00:00:00 UTC and whose difference (in days measured as 60*60*24 >seconds) is greater than 825 days from the notAfter is rejected. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
