Re: [cabfpub] Durations

2017-02-05 Thread Gervase Markham via Public
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

Re: [cabfpub] Durations

2017-02-05 Thread Kirk Hall via Public
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-boun...@cabforum.org] On Behalf Of Gervase Markham via

Re: [cabfpub] Durations

2017-02-05 Thread Gervase Markham via Public
On 05/02/17 20:32, Kirk Hall wrote: > Gerv - can't machines be programmed to notice that April 18, 2017 is > 13 months after March 18, 2016? Yes, they can, most easily by subtracting one date from the other, getting a number of days, and comparing that to a number of days representing "13

Re: [cabfpub] Durations

2017-02-05 Thread Peter Bowen via Public
Kirk, > 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

Re: [cabfpub] Durations

2017-02-05 Thread Kirk Hall via Public
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

Re: [cabfpub] Durations

2017-02-05 Thread Jacob Hoffman-Andrews via Public
On Sun, Feb 5, 2017 at 1:34 PM, Kirk Hall via Public 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

Re: [cabfpub] Durations

2017-02-05 Thread Eric Mill via Public
On Sun, Feb 5, 2017 at 6:44 PM, Kirk Hall 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

Re: [cabfpub] Durations

2017-02-05 Thread Eric Mill via Public
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

Re: [cabfpub] Durations

2017-02-05 Thread Kirk Hall via Public
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

[cabfpub] Fwd: Re: [cabfquest] Draft Ballot 186 - Limiting the Reuse of Validation Information

2017-02-05 Thread Dimitris Zacharopoulos via Public
Re-porting for Jürgen Dimitris. Forwarded Message Subject: Re: [cabfquest] Draft Ballot 186 - Limiting the Reuse of Validation Information Date: Fri, 3 Feb 2017 17:35:12 +0100 From: Jürgen Brauckmann Reply-To: questi...@cabforum.org

[cabfpub] Fwd: automation Re: Draft Ballot 186 - Limiting the Reuse of Validation Information

2017-02-05 Thread Dimitris Zacharopoulos via Public
Re-porting for Jürgen Dimitris. Forwarded Message Subject: automation Re: [cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information Date: Fri, 3 Feb 2017 17:59:58 +0100 From: Jürgen Brauckmann Organization: DFN-CERT Services