[cabf_validation] Draft Teleconference Minutes - 2021-06-03

[Ryan Sleevi]

# Validation Minutes 2021-06-03

Tim read the Antitrust Statement.

## Attendees
  * Andrea Holland
  * Aneta Wojtczak
  * Ben Wilson
  * Bruce Morton
  * Clint Wilson
  * Corey Bonnell
  * Curt Spann
  * Dean Coclin
  * Dimitris Zacharopoulos
  * Enrico Entschew
  * Inigo Barreira
  * Janet Hines
  * Kati Davids
  * Natalia Kotliarsky
  * Niko Carpenter
  * Paul van Brouwershaven
  * Rebecca Kelley
  * Ryan Sleevi
  * Thomas Zermeno
  * Tim Hollebeek
  * Tobias Josefowitz
  * Trevoli Ponds-White
  * Wayne Thayer

## Agenda

  * organizationalUnit
  * Planning for the F2F

## organizationalUnit

Paul shared the status of the OU discussion. Believes they've shared a
multi-step approach to get rid of the OU that should satisfy everyone. Ryan
had raised concerns on the list on how to improve. Paul's concern is on the
timeframe and how to phase out, given that CAs had been doing this for
years, and that some customers may need more time to update their systems,
such as when used for mTLS authentication by governments and large
enterprises. Paul was hoping to hear more feedback from other browsers
about their timeframe.

Clint said generally speaking, supportive of removing OU. The last
discussion Clint had with Paul had discussed Fall 2022 / Spring 2023, and
lately, Fall 2022 seems fairly reasonable for removing. Sounds like the
core conversation is on dates; there's consensus on removing OU, just a
question as to when. There's not much data presented yet as to why it
should be any longer than one round of certificate replacement. Certificate
lifetimes are a year, and the need for why the deprecation should take
longer than one cycle has not really been presented or well justified.
Potentially supportive of the timeframe Ryan suggested, or potentially
pushing it out a little, but not much longer.

Paul said the concern was, in part, for how these organizations budget. If
they're going to switch to a private/managed PKI, or rewrite their
application not to use the OU for programmatic purposes, that will take
time. Budgeting alone may take six months to a year, then the actual work
needs to be done.

Trevoli said that if you make it past two years, it just won't get done, as
there's no urgency to actually budget in the first place. While we all
agree governments move slowly, it seems like if we make the effective date
slightly past a year from when it's adopted, that would be good. Trevoli
pointed out the recent Biden cybersecurity EO gave a timeframe of 120 days,
with some things in 60 days. While that's not an argument for doing the OU
deprecation in 60 days, it's clear that governments can move faster when
it's important. What we previously discussed is having a document
discussing the why for organizations to understand, but did not think
longer than a year was necessary.

Paul agreed that urgency can speed up things. However, Paul felt that
because there were no publicly disclosed security issues, he disagreed with
the urgency, and did not feel we had data which justified it.

Ryan said that there's a difference between disagreeing about the data we
have and saying we don't have data. The OU conversation is simply a smaller
part of a bigger conversation: Should it take longer than a year to replace
a certificate, for whatever reason? Google's position was that no, it
should not take more than a year to replace or change a certificate or
profile. Whether this is the removal of trust in a CA, changes to the
certificate profiles, changes to the certificate algorithms, Google's
interest and efforts in the CA/B Forum have been improving the agility of
the ecosystem to ensure we can respond quickly to security issues. As a
concrete example,  the concern of customers pinning to the OU field,
Google's position is that this has been repeatedly highlighted as a
problematic practice, that CAs should be communicating with their customers
to highlight the risk, and countless CA incidents highlighting where
pinning is bad and has caused harm.

Ryan stated that they'd talked to organizations affected by the OU
deprecation. Google had also shared its data in terms of organizations
affected by this, and how it's distributed. There are a few large
organizations with many OUs, but then a long tail that are using it for
things like certificate inventory management, which is more of a
convenience factor, rather than something that requires significant
changes. Totally understand there are cases where organizations do have to
change PKIs or software, but they're not the dominant case. If we were
taking any other action - removing trust in a CA, changing how things are
validated - what is the timeframe that is reasonable to expect the
ecosystem to be able to move? Google's position is that a year should be
the upper bound to be able to accomplish those changes. Looking at the many
CA incidents of delayed revocation, caused by customer delays or manual
processes, long replacement cycles are not improving the ecosystem, and we
need to be able to respond to incidents like Heartbleed, DigiNotar,
SHAttered. The discussion is partly tied to specifics of OU, but it's also
part of a bigger discussion about what is acceptable for the ecosystem.

Ryan mentioned this topic had been discussed for years. A number of CAs had
already stopped issuing OU by default already, so that they could identify
the customers who depended on it and the challenges to migration and use
cases, and make sure they were represented in the Forum. To Clint's
suggestion, Fall 2022 feels long, but it's potentially something that
Google could go along with, but with an expectation that the CA/B Forum
needs to improve these timeframes for changes.

Paul asked if updating to October 2022 would be reasonable? Ryan mentioned
that it would likely be better to be August/September, largely because as
you approach October, CAs have highlighted that production freezes can
start before the end of the month. August tends to overlap some with
European holidays, but the range of August/September seems to be the sweet
spot.

Dimitris suggested looking at past ballots to figure out whether most
ballots are in the beginning of September or end of September, we can just
go with that. Tim pointed out that there aren't any hard and fast rules.
There have been past discussions about when is reasonable for a ballot,
such as in Bilbao. November 1 seemed to be a hard cut-off. Tim's not sure
October is a good idea, but September/October should be fine. Dimitris
pointed out we'd recently used July 1 as well, even if it's right in the
middle of some vacations.

Clint pointed out 398 days from now is the end of July, add another month,
and that's the end of August, and that seems like a fairly reasonable
target. Tim and Dimtris agreed. Wayne pointed out the BRs have August 1,
September 1, September 8, September 30, October 1, November 1, so to Tim's
point, there's no hard consistency. August 1 seems to be popular, as well
as a bunch of September 30.

Ryan highlighted the concern would be similar to SHA-1, and the goal being
to mitigate surprises for organizations. Getting CAs to immediately move to
SHOULD NOT and default disallow these, so that they can be surfaced to
customers quickly. In Clint's example of renewal cycles, if a given
customer's first renewal without getting an OU is just weeks before the
effective date, they may be unaware of the changes until then, and just
have a few weeks to make the changes. Paul's ballot tries to deal with
this, but Google's been raising in the Forum for months that CAs can and
should stop by default, to help highlight that changes are coming. The
selection of a date is largely a factor of helping ensure customers are
aware of changes. This depends on CAs taking steps to communicate to their
customers, and CAs taking steps to stop issuing by default in advance of
the deadline, to help their customers. This is something every CA can
measure of their customers to determine customers who may be affected, and
to reach out to them and communicate.

Paul agreed and said they've been informing their customers, and the
majority is moving off. The goal was to not overload the CA support teams
by having to answer questions about why it's not permitted by default, by
first communicating the changes for a time, before moving to disable it by
default. Immediately ceasing issuance would just increase the CA's support
load having to explain it. Paul said he'd follow-up to see if September 30,
2022 is a date they could endorse. Ryan suggested again September 1, based
on how many folks say going into the end of October that they're
encountering freezes. September 30 would only give a few weeks for those
customers, September 1 would give more.

Ryan pointed out that regardless of the date we choose, the day before
whatever deadline, there will be a set of customers who then go get a batch
of certificates using the old profile, such as with an OU field. That's
nonsense, because if the CA has any issues and needs to revoke those
certificates, they won't be replaceable, so it's not quite a strategic
reserve, but it happens. The most important thing is for CAs to stop
issuance by default as soon as possible, to help bring attention to
customers. Ultimately, that's up to the CAs.

Tim felt that shouldn't be called nonsense, but agreed the best way to help
customers migrate is get a ballot passed and get a date on the calendar.
One of the concerns DigiCert has heard from some customers, even though
most customers are reasonable, is "point to the requirements that says I
have to do this". DigiCert can point to e-mails showing the industry
direction and the good practices, but the customers come back with "It's
not yet a requirement". It would help a lot for customers to migrate to
have a fixed deadline to point to. There will still be users who, despite
whatever communication efforts are made, will say they weren't aware of the
change, and claim they need more time. Some of those requests will be
legitimate, some will be people wanting to make their lives easier by
taking more time to comply, and that puts everyone in an awkward position
trying to understand which group the user belongs to. The best way to avoid
that is to get a deadline in place.

## Planning for Face-to-Face

Dean mentioned that Wayne, Jos, and Karina met on Wednesday to work and
plan the F2F agenda. Given the virtual conference has higher attendance,
trying to have less repetition between sessions which might not have had
all members, and so wanted to figure out how much time the subcommittee
would need for the F2F.

Tim was unsure if we needed to have a lengthy OU discussion, but we could
have a status update. Tim would provide a review of work in the validation
subcommittee and an overview of the discussion. There may also be a
discussion of ballot results, depending on how things in progress go.

Tim asked if there were other topics for the agenda. Ryan mentioned he was
unable to attend the previous call, but saw there was productive discussion
about backdating certificates. Ryan wanted to have some time to make sure
that conversation was resolved, so certificate profiles could make
progress. Tim agreed to add profiles work, and suggested backdating might
be a conversation that could be had now, since he wasn't sure how the
conversation was resolved. Ryan said it sounded like there was some
conclusion for subscriber certificates, that it wasn't strictly necessary
but had been how CAs have historically done things. Tim suggested adding it
to the agenda. Ryan mentioned he could also try just prohibiting it and
using that for discussion.

Related to profiles, Ryan mentioned he sent mail to the list about types of
infrastructure certificates used by CAs. One example was OCSP Responder
Certificates, which the profiles work now tackles. There was also some
discussion about smart cards for HSMs, which should also be covered by the
profiles work. The question to be answered is "Is every certificate you're
issuing covered by one of the certificate profiles?", to make sure that
they're all covered. Tim mentioned he and Corey were also interested in
covering OCSP and CRL profiles.

Wayne raised the matter of default-deny, which had been on the backburner
for a while. Ryan said he was trying to address that conversation with
profiles, to ensure that there are very clear technical requirements about
where extensibility is permitted. Ryan wasn't sure if Wayne was talking
about procedures or technical requirements, but Ryan's goal with profiles
has been to move the discussion forward for technical requirements.

Wayne also highlighted that we had SC30v2 -
https://cabforum.org/2020/07/16/ballot-sc30v2-disclosure-of-registration-incorporating-agency/
- and wanted to know if there had been follow-up now that CAs have been
publishing this information. Ryan mentioned it's now been about 9 months
since the effective date, so this could be an opportunity for the
validation WG to review those, see where there is commonality between CAs,
and where there may be disagreement. Tim agreed to add it to the agenda for
discussion.

Tim said that it sounds like an hour is sufficient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210603/ce0ed609/attachment-0001.html>