[cabfpub] Certificate validity periods

[Scott Rea]

Thanks Peter for summarizing, this gives me some hope of getting my
message load back under control.

Side note: someone needs to give Ryan more work to do, he's got waaay
too much time to think through and respond to these threads - if
messages were a racehorse, he would have already won the Melbourne
Cup... ;-)

Perhaps the best thing we can do for the WebPKI community, is make it as
simple and easy as possible to replace or upgrade existing certificates
- then it matters less how long the existing cert was issued for,
because if an issue arises that requires a current cert to be updated,
then that becomes a simple process and no longer a barrier, so just
replace it, and there is no need to wait until an expiration. By
greasing the skids of cert replacement, a lot of the challenges
discussed on this thread could be mitigated. So instead of heaping an
ever increasing regulatory load on CAs, lets just encourage them to
deploy simple easy replace strategies instead.

Oh, on the number of days discussed earlier - please, please don't go
with some obscure value arrived at by multiplying the color of the moon
with the flavor of the beer - 398 days? Really? 400 is much cleaner,
easy to remember, easy to calculate - do we need to require a PhD in
Mathematics to work out how many days are allowed?

BTW: IGTF some time ago moved to a 400 day upper bound based on may of
the reasons discussed herein. Those nuclear and physical science guys
all have PhD's, so I am happy to recommend their approach to the Forum.

Regards,
-Scott

On 2/7/2017 9:15 AM, Peter Bowen via Public wrote:
> 
> We have had 50+ messages in the threat on the ballot proposal from Google but it seems like it has gone somewhat off course and gotten stuck on a tangent.
> 
> Going back to the original topic, I think there is a lack of clarity on why this is being proposed.  Ryan Sleevi, in an email in the thread, provided some links to older emails.  Many of them were from before I was involved with the Forum, so I went back and read through them.
> 
> Back in https://cabforum.org/pipermail/public/2013-November/002493.html, Gerv wrote:
> 
> "The problem with long-life certs is not any of the above; it's the
> reduced agility of the certificate system as a whole. Every time we make
> an improvement, we have to wait 5 years and 3 months before we can rely
> on every certificate having been issued under the new rules or with the
> new feature. That's too long."
> 
> Since then certificates have been limited to 39 months, so that time has gone down somewhat.  Assuming CAs require at least three months notice for changes (and I think most of us would like more than than), the delay between approving a change and it being universally deployed is three and a half years.  Assuming we all agree that subscribers expect the certificates they already have to continue to work until they expire, then the only way to increase the rate of change is to reduce the maximum duration of validity.
> 
> Ryan's email from last week echoes what Gerv said 3+ years ago.  Ryan wrote:
> 
> "The validity period of certificates represents the single greatest impediment towards improving the security of the Web PKI. This is because it sets the upper-bound on when legacy behaviours may be safely deprecated, while setting a practical lower-bound for how long hacks and workarounds need to be carried around by clients."
> 
> I think the real question here is whether we, as the Forum, think that the current state of things is such that having a 3.5 year (or longer) deprecation period is acceptable or whether this number needs to come down to something much shorter.  My inference from reading Ryan's emails is that Google thinks that sixteen months is about the longest that any deprecation period should last and, of that time, the concept to GA/stable release cycle for CAs should take no longer than three months.
> 
> The real questions, in my mind are:
> 
> (1) How long is reasonable for taking something from concept to production?  
> 
> (2) What is the longest reasonable deprecation window?
> 
> To find one possible answer to #1, I looked at the Chromium release schedule.  The standard there is 54 days (about 8 weeks) from branch to stable.  Any time to handle "intent to implement"/"intent to ship" and actually implement the code is before this window.  I know many dev teams use two week "sprints" for planning and are usually booked at least a couple of sprints ahead, so let's call this six weeks.  Based on this, I would say the minimum reasonable period for concept to production should be about 14 weeks.  This assumes a very aggressive release cycle.  It does not take into account that many CAs are using third party software, which means that integration time will be needed if code changes are required -- call this another eight weeks of planning, testing, and migration.  So 22 weeks is probably the shortest reasonable answer for #1.
> 
> I think the answer to #2 is the lynchpin.  Certificates can be quite complex to install on some systems, frequently requiring downtime of the system.  How often should this be required?
> 
> Thanks,
> Peter
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> 

-- 
Scott Rea, MSc, CISSP
Ph (801) 874-4114