[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

[Eric Mill]

Customer demand for 2+ year certificates is probably the least important
signal to consider. Customers want long-lived certificates so they can
worry about them less, and support manual workflows. But that's not a
security benefit, and the role of the Baseline Requirements (and the CA/B
Forum) isn't to optimize for meeting customer demand -- it's to improve
internet security.

Whether or not customers can tolerate and adapt to shorter certificates is
a more reasonable question. And a maximum of 1 year seems very much like
something enterprises should be able to tolerate, even if they don't like
it. And the data posted here so far suggests that plenty of significant
customers do know how to tolerate using 1 year certificates.

You can still do manual certificate management on a 1 year cycle. What you
can't do is stick a certificate somewhere and forget where it is until it's
time to panic, and that's a good thing. If enterprises experience 1-year
limitations as pain, that's pain they should start experiencing as soon as
possible.

This ballot (to me, anyway) came out of nowhere without any prior
discussion focused on a potential ballot, and it's a big change from the
status quo on the CA side, so I can understand why it's caused a strong
reaction.

But my reaction to seeing this ballot pass would be great relief -- not
just for making future deprecation cycles take less long, and not just to
minimize damage from compromised certificates when revocation is clearly
unenforceable in any meaningful way at scale today (regardless of Chrome's
behavior) -- but because it would meaningfully push enterprises towards a
more responsible baseline of infrastructure management.

-- Eric

On Fri, Feb 3, 2017 at 5:37 PM, Ryan Sleevi via Public <public at cabforum.org>
wrote:

>
>
> On Fri, Feb 3, 2017 at 4:35 PM, Geoff Keating <geoffk at apple.com> wrote:
>
>> Weren’t most of the long-lived certificates that caused problems those
>> issued before the current limit of ~3 years?
>
>
> Nope, not in our experience. I'm hoping Jody can share his graph, but much
> of our 'breakage' experience was from sites where the CA waited to stop
> issuing SHA-1 certs until it was explicitly forbidden - that is, they did
> not even default to SHA-256, or made it considerably *more* difficult for
> their customers to obtain SHA-256 signed certs.
>
>
>> In particular:
>>
>> - A 10-year certificate issued right before the BRs were adopted would
>> expire 30 June 2022
>> - A 5-year certificate issued when special circumstances were allowed,
>> could expire 31 March 2020
>> - The no-SHA-1 requirement came into force January 2015, and may have
>> been a little rushed (or, really, should have been done sooner so that the
>> hurry wasn’t necessary)
>>
>
> The no-SHA-1 requirement came in force January 2016 - not 2015. We passed
> the Ballot in 2015, following Microsoft's announced deprecation in Nov 12,
> 2013 - https://technet.microsoft.com/en-us/library/security/2880823.aspx
>
> So it seems to me this point is addressing a problem that has already been
>> mostly solved; there’s a big difference between waiting 7 years to do
>> something, and being able to do it in 3 years.  As we’ve seen, it appears
>> that once you’re down to about 2 years, the limiting factor is not
>> certificate expiry but getting the rest of the Internet to catch up.
>>
>
> Except we're not down to 3 years (or 2). For domain validation at present,
> we're at 6.5 years. Reducing to two years only gets us to 5.5 years. I
> think our ideal target should be O(months), and while it'll take the
> industry - CAs and vendors alike - to get there, it's possible if we take
> it seriously.
>
>
>> As for revocation, I believe it is a problem that can be solved, and even
>> if it can't, it does not really motivate a reduction to 1 year; you would
>> need to go to 1 week or similar.  This is a much longer discussion than I
>> can have here.
>>
>
> Right, I believe it's a *necessary* condition to move to shorter
> certificates, but not a *sufficient*. We know short-term certificates
> (which, regrettably, some CAs opposed) offer one viable path, but we also
> know that if we want to see more of the Web move to HTTPS, and we want to
> see CRLs become viable (for their significant privacy and efficiency
> gains), then we also need a series of checks and balances to limit CRL
> growth. Expiration is but one aspect (of many) to that, but even if we
> don't solve that problem quite yet, we can at least acknowledge the net
> positive to the problem.
>
> _______________________________________________
> 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/20170203/a35c0871/attachment-0003.html>