<div dir="ltr"># Validation Minutes 2021-06-03<br><br>Tim read the Antitrust Statement.<br><br>## Attendees<br>  * Andrea Holland<br>  * Aneta Wojtczak<br>  * Ben Wilson<br>  * Bruce Morton<br>  * Clint Wilson<br>  * Corey Bonnell<br>  * Curt Spann<br>  * Dean Coclin<br>  * Dimitris Zacharopoulos<br>  * Enrico Entschew<br>  * Inigo Barreira<br>  * Janet Hines<br>  * Kati Davids<br>  * Natalia Kotliarsky<br>  * Niko Carpenter<br>  * Paul van Brouwershaven<br>  * Rebecca Kelley<br>  * Ryan Sleevi<br>  * Thomas Zermeno<br>  * Tim Hollebeek<br>  * Tobias Josefowitz<br>  * Trevoli Ponds-White<br>  * Wayne Thayer<br><br>## Agenda<br><br>  * organizationalUnit<br>  * Planning for the F2F<br><br>## organizationalUnit<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>## Planning for Face-to-Face<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>Wayne also highlighted that we had SC30v2 - <a href="https://cabforum.org/2020/07/16/ballot-sc30v2-disclosure-of-registration-incorporating-agency/">https://cabforum.org/2020/07/16/ballot-sc30v2-disclosure-of-registration-incorporating-agency/</a> - 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.<br><br>Tim said that it sounds like an hour is sufficient.<br></div>