[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Jeremy Rowley]

Thanks for the reply!

APPROVALS:
For approvals, we wouldn’t need to seek any customer approvals, and we don’t build that in our contract for any certificates. The blackout period anger related to approvals is caused by the requirement to seek internal approval on policy changes in the timeline required. Inevitably, there will be requests for extensions while the process moves through the policy ladder to say “yes, you can use two year certs”. In addition, a lot of banks and government testing require interoperability testing with any profile change, including something as minor as a validity period change. This doesn’t require permission from the CA, but requires some period of time between the bank and the end point. Even though the answer is going to be “no interoperability issues”, the process of testing is sacred to these organizations.

VERIFICATION:
I don’t think we have the same issue as the other CAs on re-verification, or rather our issue is limited to the pain caused by reverification of authenticity (which is why I focused on this). Instead than separating out the dates for reverification vs. cert lifecycle, I think we can come up with a ballot that simplifies reverification of authority that allows for additional methods. One method could be for a blanket authority approve to appointed by contract for a period of time or verification through control over a corporate email address. Just spit-balling, and we can probably bring up the ideas separately in the validation working group. Really, verification of authority hasn’t been addressed in years and we should update that section to keep up with some of the recent changes in technology.

Jeremy


From: Ryan Sleevi <sleevi at google.com>
Sent: Tuesday, August 27, 2019 2:35 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Christian Heutger <ch at psw.net>
Subject: Re: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes



On Tue, Aug 27, 2019 at 4:01 PM Jeremy Rowley <jeremy.rowley at digicert.com<mailto: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/e152fe9a/attachment-0001.html>