Thanks, understood. In the end, I don’t object if there’s a useful reason to make the change.
Would it make sense to state any rule change in a format such as this? “*** [do something] at least every 13 months or up to 398 days maximum, whichever time period the CA chooses.” That way, the humans immediately understand the rule, but can code using days if preferred. From: Eric Mill [mailto:[email protected]] Sent: Sunday, February 5, 2017 4:05 PM To: Kirk Hall <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] Durations On Sun, Feb 5, 2017 at 6:44 PM, Kirk Hall <[email protected]<mailto:[email protected]>> wrote: I don’t understand what problem this proposal is intended to address. If a CA sticks with “13 months” it should always end up with fewer than 398 days. Yes, that's exactly why the proposal exists. If one goal of the proposal is to try to get to a more uniform interpretation of what 13 (or 39) months is, we can add a rule to the BRs like the following: If any provision in these requirements permits or requires a time period stated in months, CAs shall calculate the time period as follows: (a) The hour, minute, and second of the end of the time period shall be the same as for the start of the time period. (b) The month of the end of the time period shall be the specified number of months ahead of the month of the start of the time period. (c) The date of the end of the time period shall be the same date as the start of the time period, unless there is no equivalent date for the month at the end of the time period. In that event, the CA shall choose the closest available date that exists for the month at the end of the time period. Examples: 13 Month Period (Start of Period – End of Period) 2016-04-16 12:00:01 - 2017-05-16 12:00:01 2016-03-31 12:35:16 - 2016-04-30 12:35:16 2015-01-31 04-06-55 - 2015-02-29 04-06-55 2016-01-31 04-06-55 - 2017-02-28 04-06-55 Something like that should bring uniformity among all CAs. Besides the impact to removing timestamps as a potential source of entropy, encoding that as logic -- on the CA side as an issuance check, or the client side as an enforcement check -- is going to be more complicated than a flat maximum of days. It will be more subject to error and arguments. Look, I’m not passionate about this, but I don’t understand where the proposal is coming from. Has anyone been asking for validity periods or revetting periods to be set in number of days rather than months? Peter is, and he described the conversation that sparked that request: It actually started when I got complaints that the calculation I used in cablint was wrong. The rule in cablint is that April 18, 2017 to April 19, 2018 is longer than 12 months. But people complained for 27 or 39 months that I should count from the end of the month — e.g. April 30, 2016 to July 31, 2019 should be 39 months. It makes sense that Peter would be the first to raise this specifically, since he maintains cablint (a tool that automatically checks certificates for various BR violations). Cablint has only in the last year or so started playing a prominent role in the CA ecosystem, by virtue of integration into crt.sh (and into other processes, such as the SHA-1 exception process). The proposal to use days for the formal requirement, instead of a human-friendly requirement, is to make measurements by tools like cablint more uniform and less prone to bugs or arguments. It doesn't constrain CAs from using more human-friendly approaches to issuance dates. -- Eric From: Public [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Eric Mill via Public Sent: Sunday, February 5, 2017 3:05 PM To: CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>> Cc: Eric Mill <[email protected]<mailto:[email protected]>> Subject: Re: [cabfpub] Durations Just to try to +1 Jacob's point by summing it up -- by requiring a maximum of 398 days, CAs can continue to safely issue any "human-friendly" form of 13 month renewals, in ways that don't cause calendar drift. Any such human-intuitive strategy will be guaranteed to stay under 398 days, and then clients/tools that enforce compliance can take the computer-intuitive strategy of checking if the cert's valid for 398 days or less. -- Eric On Sun, Feb 5, 2017 at 4:56 PM, Jacob Hoffman-Andrews via Public <[email protected]<mailto:[email protected]>> wrote: On Sun, Feb 5, 2017 at 1:34 PM, Kirk Hall via Public <[email protected]<mailto:[email protected]>> wrote: Many of us have complex validation and issuance programming already based on months and anniversaries, and there doesn't seem to be a good reason to reprogram all this to a set number of days Peter's proposal wouldn't require you to reprogram any of that, because it is strictly more permissive than the months / anniversaries code you already have. The best approach would be to continue what you are doing, and always issue on the first of the month or some other anniversary. Then you get the human-readable benefit, and would be sure that you are within the 398 day period. - plus, again, it's harder for humans to calculate the last time or the next time a task had to be done. That's my opinion. The 398 day period (vs 365 days) is specifically intended to give the wiggle room needed for subscribers and CAs to be able to schedule a renewal at the same time each year. If you always schedule your renewal for March 1 every year, you would still be able to do that just fine, and have a month (or ~31 days) of leeway. > Should be easy to reach agreement on what 13 months means, and how to measure > it. Yep, that's the topic of this thread! Peter is proposing that the easiest way to measure 13 months is to define it as 398 days. I think you will find broad consensus among programmers that it's easier to reliably measure periods in terms of days than in terms of months. Another way to think of this: The goal is to renew every year (~365 days), but give people some leeway so they can keep the renewal on the same date. If we make that leeway 32 days, everything works out nicely. _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public -- konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone> -- konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
