[cabfpub] Certificate validity periods

[Jeremy Rowley]

Yes - it'd make a few items in EV be revalidated more frequently. Basically, a 27 month requirement would create consistency amongst the certificate types for domain validation and phone validation. The rest of the validation can often be reused (under the EV Guidelines).  

Considering the current BRs set the revalidation at 39 months, 27 months cuts off more than two years from the time to implement change.  (With renewal occurring in the last day of the month).  Two years is a huge improvement and, I think, a great first step. 


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Wednesday, March 30, 2016 2:21 PM
To: Jeremy Rowley; Rich Smith; public at cabforum.org
Subject: Re: [cabfpub] Certificate validity periods

On 30/03/16 13:11, Jeremy Rowley wrote:
> I’m not so sure a lack of desire to change code is a great reason to 
> avoid something that increases security. However, I do like the 27/27 
> proposal as a great step forward. Are the browsers opposed to 27/27? 
> The only thing in EV really impacted by the longer validity times is 
> domain validation thanks to the reuse section of the EV Guidelines.

What does 27/27 make longer? EV vetting validity periods?

Thing is, if you set a max validity period for vetting, and say that the renewal has to happen within that period, then your actual max validity is 2N - 1 i.e. for 27 month validity, it's 26 + 27 = 53, because people can renew for the maximum period one month before the deadline.

If we said 27/27, where the second 27 meant that the _notAfter_ date (as opposed to notBefore) could never be more than 27 months after the vetting, that would be much better.

Gerv

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160330/35228e68/attachment-0001.p7s>