[cabfpub] Certificate validity periods

Eric Mill eric at konklone.com
Tue Feb 7 05:47:55 UTC 2017


To #2, I think that it is reasonable to ask for installation to be
performed every year, and especially when it feels the most *unreasonable*
to the user. This isn't meant to be ideological punishment for not
automating -- it's that the systems for which certificate rotation causes
the greatest pain are also likely to be the systems for which algorithm
rotation (or protocol rotation, etc.) causes the greatest pain. In other
words, making certificate rotation more frequent is mostly going to pain
the people you were going to be arguing with anyway in the months after the
first major SHA-2 weakness is published.

There's also the possibility of doing this in laddered stages. You could
imagine a ballot which sets a 26-month limit for a year, and then a
13-month limit which takes effect the year after that. That provides a
generous adjustment timeline for enterprises, but a clearly stated
direction by the Forum which provides both short- and long-term benefits.
It might also just feel less jarring to customers, which makes everyone
calmer.

-- Eric

On Tue, Feb 7, 2017 at 12:15 AM, Peter Bowen via Public <public at cabforum.org
> 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
>



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


More information about the Public mailing list