Kirk.Hall at entrustdatacard.com
Sun Feb 5 21:50:57 UTC 2017
Fair enough - but let's come up with enforceable rules such as "when counting, include the first day but not the last day" (that's actually a court rule for determining how many days a party has to file or do something) or "the last second in the period should be the same as the first second in the period" (so if something starts at 09:01:00 it should end at 09:01:00 to reach a full "day").
You're going to face the same problem if you move everything to number of days -- does it include the first and last day, or not? How to calculate?
Honestly, I can't see why this is so important, as most of these rules (13 months, 395 days, whatever) are just arbitrary abstractions we choose for ourselves to follow -- it's not like we are calculating the half-life of cesium... Should be easy to reach agreement on what 13 months means, and how to measure it.
From: Peter Bowen [mailto:pzb at amzn.com]
Sent: Sunday, February 5, 2017 1:45 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Durations
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.
We have seen browsers start to enforce these durations at connection time. I want to ensure that there is a common definition of the rules so I don’t end up issuing a certificate that I think is valid but someone else says is not, which then results in my customer having a really bad time.
> On Feb 5, 2017, at 1:34 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com> wrote:
> The whole idea of choosing 13 months / 39 months for certificate lifetime or revetting was to have something easy for people to calculate and remember. Many of us actually use an anniversary date for this - 1 year or 3 years - with extra time allowed in case revetting or reissuance is delayed for some reason, such as slow responses by the customer. But having an anniversary date is kind of important, and easy to remember.
> If you celebrate your birthday every 365 days instead of annually, the date of your birthday celebration will keep creeping earlier and earlier in the year due to Leap Year - you and your parents will get confused. Likewise, if you do a task every 90 days instead of quarterly, the date will creep further and further back over time and be harder to keep track of.
> If I understand correctly, Peter, this conversation started because you were searching among all issued certificates to get statistics on what the typical issued duration for a certificate is, correct? If so, why can't you program your search so that an initial duration of anywhere between (365+28) and (366+31), or between 393 and 397 days, is a "13 month certificate" or even just a "1 year certificate" for purposes of your statistics?
> 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 - 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.
> -----Original Message-----
> From: Peter Bowen [mailto:pzb at amzn.com]
> Sent: Sunday, February 5, 2017 1:09 PM
> To: CA/Browser Forum Public Discussion List <public at cabforum.org>
> Cc: Kirk Hall <Kirk.Hall at entrustdatacard.com>
> Subject: Re: [cabfpub] Durations
>> can't machines be programmed to notice that April 18, 2017 is 13 months after March 18, 2016?
> Of course. Computers can be programmed to solve very hard problems and are do so every day. That being said, this is actually much harder than it might seem at first glance because the Gregorian calendar is non-uniform.
> Consider a fairly simple case: Starting from March 31, 2017, when is the end of 13 months? Is it April 30, 2018 or May 1, 2018?
> And a slightly more complex case: Starting from Feb 28, 2015, when is the end of 13 months?
> Once these are resolved, we can get to rules on calculating months, but these are highly subjective. I don’t really want to have a whole appendix on calculating dates if I can avoid it.
>> On Feb 5, 2017, at 12:32 PM, Kirk Hall via Public <public at cabforum.org> wrote:
>> Gerv - can't machines be programmed to notice that April 18, 2017 is 13 months after March 18, 2016? It seems easy to do that, and much easier for humans to evaluate than 398 days.
>> -----Original Message-----
>> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of
>> Gervase Markham via Public
>> Sent: Sunday, February 5, 2017 1:26 AM
>> To: CA/Browser Forum Public Discussion List <public at cabforum.org>
>> Cc: Gervase Markham <gerv at mozilla.org>
>> Subject: Re: [cabfpub] Durations
>> On 04/02/17 22:16, Kirk Hall via Public wrote:
>>> Peter - don't you think "13 months" already encompasses all cases
>>> like what you show below (start date and end date 13 months apart
>>> based on the dates themselves, even if that means the number of days
>>> varies a little), and will encompass all situations, like when the
>>> 13th month has 28, 29, 30 or 31 days?
>> We want a definition which is both easy to explain to humans, and easy for computers to verify. Subtracting two dates to get a single number of days between is an easy thing for a computer to do (with the appropriate library), and comparing that to a defined number is also simple.
>> So a definition like "398 days (just over 13 months)" fits both criteria IMO.
>> Public mailing list
>> Public at cabforum.org
>> Public mailing list
>> Public at cabforum.org
More information about the Public