[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Tue, Aug 27, 2019 at 4:01 PM Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> There’s a problem with this ballot most people are ignoring and that’s
> that any CA voting is “damned if you do and damned if you don’t”. I suspect
> almost everyone will wait until the last minute to vote, to see how the
> ballot is going to turn out, for a couple of reasons.
>
> First, CAs are getting a lot of different input and some CAs believe there
> are some business advantages to opposing this ballot, regardless of the
> outcome. Any CA that votes for this ballot will have other CAs use that as
> marketing material against the voting CA. We saw this with the last change
> (from 3 years to 2 years) and with the underscore character deprecation.
> Regardless of outcome, with 85% of the customers answering the survey
> against the change in validity period, the risk is high that a CA will face
> some negative reaction if they vote in the affirmative.
>
> On the other side, all of the browsers seem universally aligned with the
> change and the security reasons for the change are (imo) compelling. To
> avoid being dragged into the middle, the safest bet for a CA is to not
> vote. The second safest bet is to wait until the ballot draws out and then
> vote no if the ballot will pass.  I dislike the politics on the voting so
> I’m hoping calling attention to them will mix things up.
>
> Second, voting “no” gives the CA someone to blame for the change that
> insulates the CA from ramification of the change. The blame then can be on
> the ballot voters for the shortened lifecycle. Angry customers can be
> deflected to the browsers/CAs who vote yes.  Waiting for the browsers to do
> this unilaterally is the safest CA action for any CA because then you can
> point to the browsers, even if you agree with the change. Anyway. That’s my
> two cents.
>

Thanks Jeremy, for putting it so effectively!

This is, unfortunately, the reality for many ballots which might prohibit a
CA from doing something. If they've never issued certificates using the
to-be-forbidden thing (e.g. a weak validation method, a weak signature
algorithm, etc), voting in favor of the positive security change comes with
no downsides. However, for any CA that has or is issuing certificates with
a to-be-forbidden thing, it's understandably in the interests of
appearances, and their customers, to oppose the change, even when it might
pass, so that they can tell their customers "We fought hard for you, but we
were out-voted"

Unfortunately, the structure of the Forum makes it difficult for CAs to
vote for the right thing (for users and security), although it provides an
excellent venue for discussion about considerations and tradeoffs, which I
really appreciate you doing here. This is something that I'd been looking
for from a variety of CAs, to make sure I understand the tradeoffs.


> Strategy aside, the concerns we’ve heard from customers and internal
> people about the ballot run down as follows with the following solutions:
>
>    1. The timing.  The ballot is proposed for April. April is tax season.
>    Since we have a lot of banks and government entities, tax season is hard
>    for them. A shift to 1-year certs doesn’t present significant technical
>    obstacles in making the change, but the problem in getting approvals is
>    bureaucratic, meaning the change in policy needs to happen before the
>    effective date. It’s not accurate to say we have until March 2021 to
>    migrate people to 1-year certs because the approval to migrate to 1-year
>    certs must happen in March 2020.  This also happens to coincide with when
>    we are shutting down some legacy Symantec systems. When you combine the
>    two, you end up with a very awkward month for several customers facing both
>    a console migration and a profile migration, even though the profile
>    migration is small.
>
> Could you indicate what you mean by approvals, or how that impacts this
ballot? I readily admit, I'm not entirely familiar with the process you're
describing here.

It sounds as though that even if the CA/Browser Forum, or individual
browsers, were to require something, CAs would still have to seek customer
approval here. I'm not sure I understand why or how that would possibly be.

With respect to the profile migration, my assumption here is that CAs would
do what they did for the lifetime reduction, do what they did for SHA-1, do
what they did for the deprecation of validation methods, and do what they
did for Certificate Transparency enforcement. Namely, before the transition
date, issue a bunch of certificates using the old profile, so that folks
didn't have to deploy right away. That was such an inbuilt assumption here
that it's why I was highlighting the value proposition as being June (now
July) 2022 - I assume there's going to be a supernova-style burst of
issuance in the weeks before, and that's why the change to April, rather
than March - to avoid February freezes that might make that challenging.


>
>    1. Verification. Re-verification of entity information every year
>    isn’t a significant obstacle except for the verification of authority.
>    Calling a person’s supervisor to confirm their relationship to the
>    organization takes a long time and places a significant burden on someone
>    generally not part of the certificate enrollment process. I think we should
>    add a new method to verify authority. We can do this from now through the
>    effective date of the ballot.  We’ll need to work out the details, but
>    anything that can ease the burden of requiring reconfirmation of employment
>    annually would address this concern.  Tim and I will brainstorm on
>    something and propose it to address this issue. If you can address
>    authority, you address the complexity in issuance.
>
> I'm both sympathetic to this and a bit concerned by this, but I really
appreciate you raising it and highlighting it.

For OV and EV certificates, these are, by design, manual processes which
require a lot of hand-holding activity by CAs. On the one side, they allow
for additional information which, if validated correctly, consistently, can
provide value to relying parties that might want to make use of this
information. On the other, however, these certificate profiles continue to
be used as a reason to hold back the ecosystem from changes, because many
of the beneficial changes that might be discussed, such as strengthening
validation methods, reducing information reuse, or anything that might
require certificate replacement or reissuance, end up impacting these
profiles much more than the core DV profile.

What I'm hearing from a surprising number of CAs is that 6 months isn't
sufficient time for them to revalidate their customers, or even for them to
assess the full scope and impact to their customer base (i.e. how many
would need to be revalidated). I won't lie, that concerns me, because
agility is the means by which we make progress. Unfortunately, similar to
your analysis of the voting incentives, unfortunately, OV and EV also
present incentives to both site operators and CAs. CAs can use this as a
reason to oppose changes or request further delays, because they'd have to
revalidate. Subscribers may prefer the use of OV or EV certificates,
because then they too can argue the challenges in replacing these
certificates. Yet the losers are the browsers or those who use DV
certificates, because they're gated upon the slowest mover.

One way that might help improve things is if Browser members clearly
communicated their expectations as to how long a CA would be expected to
revalidate their entire corpus of certificates. For example, if Browsers
were to say CAs should be able to fully revalidate their certificates
within one month of a change, that sort of requirement would help budget
and capacity planning, by ensuring that the CA always had a plan on file to
ensure that they could revalidate. It would encourage exploration into ways
to further improve automation around validation and contact, and as you
suggest, might lead to improved methods to account for this. It might lead
CAs to staff more validation specialists, or rethink their approach to
contracts with respect to validation, to ensure they could fulfill those
needs, and might allow a re-evaluation of the benefits of OV and EV
certificates relative to their ecosystem challenges.

That said, I can also understand that "springing" such a requirement on CAs
like that wouldn't help move the needle forward. I'm intrigued by your
suggestions here to improve things, and that might be a meaningful way
forward, while we discuss and gather feedback from our CA partners about
the challenges with revalidation and their plans to address those
challenges.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/3c5206d4/attachment-0001.html>