[cabfpub] Durations

Mon Feb 6 00:05:10 UTC 2017

On Sun, Feb 5, 2017 at 6:44 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com>
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:public-bounces at cabforum.org] *On Behalf Of *Eric
> Mill via Public
> *Sent:* Sunday, February 5, 2017 3:05 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Eric Mill <eric at konklone.com>
> *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 <
> public at cabforum.org> wrote:
>
> On Sun, Feb 5, 2017 at 1:34 PM, Kirk Hall via Public <public at cabforum.org>
> 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
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
>
> --
>
> konklone.com | @konklone <https://twitter.com/konklone>
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170205/2c200b03/attachment-0003.html>