[cabf_validation] Minutes of the Validation Subcommittee - 28 Jan 2021

[Clint Wilson]

Validation Subcommittee Meeting - 28 Jan 2021

Antitrust statement was read

Attendance: 
Tim Hollebeek, Wayne Thayer, Clint Wilson, Corey Bonnell, Aneta Wojtczak, Ben Wilson, Dimitris Zacharopoulos, Daniela Hood, Paul VanBrouwershaven, Johnny
Reading, Rebecca Kelley, Janet Hines, Ryan Sleevi, Natalia Kotliarsky, Michelle Coon, Niko Carpenter, Andrea Holland, Trevoli Ponds-White, Rich Smith, Dean Coclin

Agenda
OUs
Wildcard for ADN
.onion validation
Refresh of issues in GitHub
Certificate profiles and tooling

OUs
Clint: Apple has reached out to some of the CAs that aren't in the CA/BF and found a number of usages that are not in-line with expectations. We've invited them to share those here, but are still waiting for that. That's all to say, we're making an effort to really understand what use-cases exist out there, but really haven't found any that change the picture much.
Dimitris: Academic usage, like having the department or administrative unit in there. Usually it helps when the cert's about to expire, and get some requests. We validate the OUs by mapping the OU to subdomains.
Paul: AT&T has tried to join as an interested party specifically for this topic, haven't quite managed to get in yet.
Dimitris: I have a comment on Ryan’s last on-list response. I understand where he’s coming from that everything needs to be independently validated. We know the bootstrapping process includes, in his terms, self-reported information from the applicant for a new legal entity; things like address, postal address, phone numbers, even the name of the company is something that’s applied for. The Registration agency or agency of incorporation, verifies the eligibility of the applicant. So what are we validating for identity? we need to have an anchor somewhere.
Ryan: Issues with Identity Verified and Stripe Inc are great examples, and go to what are reliable data sources. Using the UK as an example, with Companies House, they had quality issues and now there are a number of legal regulations to try to tamp down on those issues and introduce consequences. We're anchoring legal identity on the legal systems and jurisdictions. When an applicant comes in, they provide a bunch of information, but it's the job of the CA to validate that against the authoritative source. WIth OU, the official data source is the company itself. The essence of Paul's proposal is that the company makes the assertion, so that's good enough. The CA asking "Are you telling me the truth" is really not good enough. An applicant can attest "I have an OU of Google inc", and Paul's done some work to try to prevent that. The problem with OU is the proposals aren't reliable, repeatable, and independently verifiable. The OU doesn't have an authoritative data source.
Dimitris: The CA would just need to verify that they're in communication with a legal rep. The legal rep is also who would change legal records. Isn't that similar/sufficient?
Ryan: No, and this is the issue GLEIF is running into. They remove entities from their RA source. We assume there's a legal system backing these 3rd party sources and that if data is misreported, there's a consequence. If nothing bad happens, then it's not really an acceptable data source. They removed the Mexican Business register because it didn't have consequences, while the Tax service did. It's difficult to have consistent, reliable, repeatable verification that the legal rep is stating the same information. But assuming that we do have that, the next question is what are the consequences for if they lie or mislead? That varies widely by jurisdiction. How do you verify the legal rep? It's hundreds of pages long probably to describe the full process. Have they been disbarred or similar? What are the consequences if they give a bad opinion? The goal is to get to a point where, regardless of which CA you use, you get a consistent result in the certificate.
Paul: Now we're going from that reliable data source, finding the legal rep, and that's where we're checking it. That's the person that's filling the tax forms and has control of the data sources. We've added additional roles around pre/suffixes. We've required they provide a directory structure showing the organizational unit. If we don't trust that information on that level, where we've strongly validated the information, that OU and the data in there is similarly validated as other DN information coming from the same source.
Ryan: Your ballot doesn't do what you state it does, specifically the legal rep verification. That might not be intentional.
Paul: We're trying to find a workable solution. I don't want to go on and propose 20 versions. I want to find out what's reasonable. If the legal rep verification isn't viable, then where do we go. I think we need to focus on the OU and the values that can go in there. The domain name is something you can validate in a technically controlled way, but that's not true of address or other DN fields.
Ryan: We don't trust the legal rep, we trust the jurisdiction of incorporation. How that information gets into the data source isn't important. We trust the government data source; the fact that a legal rep populates that is independent of that. What's proposed here is different from everything else here. There are use-cases for why someone would want something. But what hasn't come up, is why these use-cases are relevant for browsers. Yes, client facing companies want to give their customers what they ask for. But we need to show that the set of values and goals match what the browser product does.
Paul: You mentioned that there are risks and that OUs are dangerous. Can you give an example?
Ryan: Unverified information is a risk. Unless the CA is able to prove that the information is verified to a suitable level for our needs, there's inherent risk of displaying in a trusted location the information. Another risk is impact on revocation and replacement. Another risk is dependency on improper certificate usage that prevents ecosystem agility. When there are examples of companies using the OU for authorization or similar, it introduces a risk where the ecosystem can't improve because of the reliance on a field that's not validated to a level expected by browsers. As an example of poor validation practices, if CA X is issuing certificates improperly, and they need to migrate to CA Y, anything that blocks that (due to inconsistent validation or additional validation requirements) is a risk to the ecosystem. These are the most common issues in incident reports and shouldn't come as a surprise as the risks.
Dimitris: We always start from the government agency, and that's where we receive the information about the legal rep. It's like getting authorization for EV Issuance in a lot of ways.
Ryan: I know that's what Paul meant, but that's not what it says.
Paul: If we would go for that process and define it in that way, would it be acceptable?
Ryan: The fundamental problem with OUs, you have to describe the use-case and help us (browsers) understand how it addresses the concerns we've raised.
Paul: We have shared the use-case, but you don't think it's valid.
Ryan: Correct
Paul: Communicating that you split your organization up into various units is a valid use-case.
Ryan: That explains the disconnect. You have to provide and explain a use-case that's valid for our products and warrants acceptance of the risks I've outlined. Saying customer X wants this thing, that's insufficient.
Tim: I think I'll cut this off here. Yes it's true that OUs exist in companies, but the vast majority of actual usage was mostly metadata and other information that arguably violated the current rules. It's important to realize that a lot of the current OU usage was improper anyway, so fixing the rules isn't going to help a ton of people. We've been mostly successful with helping customers migrating away from using OUs.
Paul: You say you're successful, but those customers end up coming to us to ask for the certs. The majority of usage is not how they're supposed to be used. But there are usages that match the intent.
Tim: You have to look at whether the current values even meet the current requirements, which many don't, which is very disappointing.
Paul: I'm trying to implement something on what we expect today. We're trying to improve things without rewriting the BRs.
Tim: The current reqs are so bad, so we need something that's clear.
Paul: We tried to do this and to get the feedback from the group and get something that's workable.

Wildcards in ADNs and HTTP Validation
Ryan: The intent is to make progress on this, and it's important to make progress. We've asked for data, which Let's Encrypt has provided, but we need more CAs to do that. We want to make a decision based on data, but we have to make a product decision. We do want to remove Wildcards in HTTP validation. We want to and will consider the data. We monitor what's in CT and we're aware of valid use-cases, but we don't know how common they are, which is what we want to take into consideration. We'd like to make progress in the forum, but we can make progress in our root program. We'd prefer to partner with CAs on this.
Paul: Can you share that data with the list.
Ryan: I have.
Paul: I haven't seen it.
Ryan: We do see validating *.corp.com with HTTP. Validation corp.com at that level is a valid use-case. How many of the issued certs would need to use a new method if this change went into effect? If it's 1 customer with 10k certs using the same validations, we want to know those numbers vs 10k customers with 10k validations that would need to change. How many certs are using validation methods that need to change. The more CAs that can help provide data (# certs, # customers, # validations) would be helpful. We're thinking about the impact for when we pick the date. We want to make data driven timeline decisions.
Paul: I do agree it's a good change, but don't have much data at this time. We're moving these checks to DNS, this could unintentionally cause more orgs to give more people more access to DNS, which could ultimately weaken security.
Ryan: I agree that's a risk. I think there are bounds to the risks we can truly include in scope, but it's definitely a consideration. Understanding the scope of use of HTTP for wildcard validation would help us determine the risk as well, at least comparatively between e.g. a 7% and a 70% impact. We started asking for these data before the winter holidays, so I'm just wanting to emphasize that this is still needed and it's important.
Tim: We're running out of time, but don't have next steps.
Ryan: Next steps for wildcard/HTTP are for CAs to share data because we do need to make a decision soon. We're not going to continuously postpone as data trickles in. % of wildcard certs, which used X method vs Y method vs Z method, etc.
Dimitris: A useful takeaway is there are no objections to moving forward with this change, so drafting the language of the ballot could help.
Ryan: I'll send language. We'd like to move with a ballot in the forum, but if no data is provided we'll move forward with a root update.
Rich: I don't have data yet. Our concern is not really the timeframe for using the method for future validations; that could almost be tomorrow (for example; it's not a huge challenge to turn it off). We don't allow many customers to reuse domain validations in general, the ones we do allow it for are larger enterprises. It's a matter of subdomain enumeration. Our concern is when we can't reuse currently-valid domain validations based on this method.
Ryan: Absolutely, that's the concern we have. The data helps with this. We don't think it needs to happen tomorrow, but probably needs to happen sooner than a year from now, so finding the sweet spot in there is what we're after. Maybe the year IS justified if 98% of the wildcard certs out there are impacted. The data will drive that decision.

.onion validation
Ryan: There are a cluster of bugs related to this, related to v2 onions. There's a carveout in 3.2.2.4 pointing to the appendix, but in 3.2.2.8 we have a CAA req which will never pass for an .onion, but CAs would need to perform multiple (expectantly failed) lookups for a domain we know won't respond. So there are a few changes needed 
Dimitris: There's also the internal name issue, where the definition prohibits .onion since it doesn't exist in IANA's DB. 
Ryan: We carveout in 3.2.2.4 and appendix b that .onion aren't internal names.
Dimitris: But then appendix B points you back to 3.2.2.4.
Ryan: I hadn't seen that new comment, and might require some unpacking.
Dimitris: I can try drafting a ballot and outlining the problems, maybe?
Ryan: I was planning a cleanup ballot for some of these EV things, so we can work together on that.

Tim: See everyone in two weeks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210128/a55be64a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210128/a55be64a/attachment-0001.p7s>