<div dir="ltr"># Draft Minutes of the Validation Subcommittee call on Jan 16, 2020<br><br>## Attendees<br>Joanna Fox, Dean Coclin, Daniela Hood, Clint Wilson, Mike Reilly, Wayne Thayer, Doug Beattie, Corey Bonnell, Janet Hines, Li-Chun Chen, Dimitris Zacharopoulos, Rich Smith, Ryan Sleevi<br><br>## Agenda<br>* SC25 Update (Doug)<br>* Onion ballot (Wayne)<br>* Recap of GitHub issues filed by Ryan and draft ballots (Ryan)<br>* F2F Planning (Ryan)<br><br>Wayne read the Antitrust Statement.<br><br>## SC25 Status:<br>Doug provided an update on SC25. It was sent to the validation list, instead of the servercert list. The other was the redline was not an immutable link, so that’s another update. Corey provided some additional updates. Ryan offered to help if there were any issues getting that drafted. Wayne mentioned having trouble getting immutable links prepared.<br><br>Dimitris mentioned we have some instructions page on the wiki, which also describes how to get the commit hash, which could do with some additional review.<br><br>## Onion Proposal:<br>Wayne circulated a draft on the validation list to incorporate the issuance of .onion certificates into the BRs. To refresh: several years ago (2015?), we added an appendix on how to issue a certificate containing a Tor .onion address. Since then, the Tor address spec has been updated that addresses the concerns that originally led us to require EV and the extension. Several Tor domains are not able to obtain EV certificates for various reasons, and folks reached out to see if it was possible to update the language to allow issuance of DV. Wayne circulated a proposal based on Fotis’ original proposal. Since then, not many comments, other than from Let’s Encrypt. Ryan mentioned he’ll do another pass on the proposal, but believes Google will endorse. He shared examples of existing users of the .onion certificates, such as Facebook and NY Times, having operational challenges deploying certificates due to the burden of replacing the certificates. Wayne was going to send another email seeking a second endorser.<br><br>## Subject Ballot Name<br>Ryan shared that he opened Issue 154 on GitHub [1], explaining the two sets of tables provided on that issue. The focus was trying to focus on things currently trusted and have BR audits, but also examined those that are TLS capable but may not have audits. The focus was on the first set, since that represents things intentionally used for TLS, but the second set is provided for completeness for people to look at.<br><br>The most popular subject field was the organizationalUnit, followed by locality information, including state or province. The locality information was largely dominated by a single CA/member. Another OID was serialNumber, although several of those CAs have been subsequently clarified by the issuer as not intended for TLS, even though they were capable of TLS, and are in the process of being replaced. The last one of substantial note was the organizationIdentifier field.<br><br>Several CAs included e-mail addresses in the CA certificate, which was questionable to begin with, and a few included postal code. One CA made use of an OID for LEI.<br><br>The table includes a breakdown of the subject field of the certificate, along with the O field of the issuer or, for CA certificates issued so long ago they lack an O field, the comonName. The intent of the ballot is to provide a time-limited exception with a sunset, and then have a discussion about what fields to continue. For example, for some CAs including locality information, their locations have changed as they’ve gone through mergers and acquisitions and are no longer correct. Same with e-mail addresses, including some that bounce. This ballot doesn’t immediately address these situations; it will allow them with a SHOULD NOT/MAY, to discourage them but recognize things like cross-certification may need them.<br><br>For the set of CAs without BRs audit, the numbers are very different, because that situation is much wilder of a wild west.<br><br>Dimitris stated that most of the European CAs are forced to use the organizationIdentifier in the subject due to eIDAS Annex IV (b) [2]. All of the DG CONNECT consultants have convinced the supervisory bodies that this is the field it needs to appear in. Dimitris stated he knows this for a fact because HARICA had not included an organizationIdentifier, and received a yellow-card from their supervisory body requiring that they add it for their QWACs.<br><br>Ryan stated that while this ballot would allow it, the statement about being required by regulation is not correct, but that’s a discussion we can continue after the ballot. The nuance between what SBs require, what CABs implementing the standards require, there’s a lot more fluidity. There’s no question that organizationIdentifier is being used, though, and this ballot would allow it to continue.<br><br>There are a few attributes where the CA has already stated they don’t plan to issue more certificates with that attribute, so they may not be needed, but we’ll go ahead and allow these fields and continue discussion about what should be allowed.<br><br>Wayne mentioned he shared the link to GitHub, and pointed out that the tables start out collapsed and you need to click to expand them.<br><br>[1] <a href="https://github.com/cabforum/documents/issues/154">https://github.com/cabforum/documents/issues/154</a><br>[2] <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910&from=EN#d1e32-114-1">https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910&from=EN#d1e32-114-1</a><br><br>## Arpa validation<br><br>[Ed Note: To make it easier for those reading the notes; on the call Ryan kept saying in.arpa/in6-arpa. The correct names are in-addr.arpa / ip6.arpa and have been corrected below to make it more understandable]<br><br>Ryan mentioned that another issue to discuss was Issue 153 [3]. This came up during the discussion of some lints for ZLint, and Ryan wanted to bring it to the validation list to discuss. The question is about how .arpa addresses should be valid.<br><br>The background was that there was a CA that issued a wildcard certificate for an IPv6 address; *.something.ip6.arpa. For those not familiar with in-addr.arpa and ip6.arpa addresses, they provide a mapping back from the IP expressed as a hostname, in the reverse, back to the IP. For example, 1.2.3.4.in-addr.arpa maps to 4.3.2.1<br><br>Domains validated in this space are functionally being used as IP addresses, because there’s this identity function. One of the questions was about wildcards in in-addr.arpa and ip6.arpa, where we don’t allow wildcards in IP addresses. The second question was in how in-addr.arpa and ip6.arpa are administered. Arpa is one of the special-use domain names that are maintained by IETF/IANA [4] and has its own policies. Within .arpa, in-addr.arpa and ip6.arpa have special meaning, and the subdomains are delegated to the regional internet registries, the entities responsible for delegating and assigning IP addresses. Examples are ARIN or RIPE. The question was whether or not these are registry controlled, which seem to be supported by the RFCs, and that means these can’t have wildcards.<br><br>A suggested solution is that we call out in-addr.arpa or ip6.arpa as requiring they be treated as IP addresses and use a validation process similar to 3.2.2.5. This isn’t exactly right, because of how IP addresses can be validated. Another possibility would be to forbid the use of these addresses, and say use an IPAddress subjectAltName, and don’t expect these names within a certificate.<br><br>While folks on the call probably haven’t had a chance to review this yet, wanted to bring it on the call to figure out what questions folks might have for discussion on the list.<br><br>Dimitris mentioned he was a little confused. When IP addresses are added to certificates, CAs have to use the subjectAltName extension, and use a specific iPAddress type. That type has the IP addresses, not the reverse form in-addr.arpa. Ryan confirmed that’s correct, and the issue is that this is a DNS name that can be used to express an IP address mapping. Ryan explained a CA had issued a wildcard certificate, effectively *.2.3.4.in-addr.arpa, which would effectively allow validating any IP from 4.3.2.[1-255].<br><br>Dimitris stated he didn’t think we should allow something like this. He wasn’t sure if this was too aggressive, but it seems like a risk to allow a certificate to resolve to any number of IP addresses you might or might not control. Ryan agreed, and the issue was the BRs are not clear on the status quo. One option was forbid wildcards, another was treat them like IP addresses, or another is just to forbid in-addr.arpa/ip6.arpa.<br><br>Ryan wanted to get feedback from folks, and stated that from an analysis of publicly trusted certificates, this was not common. He mentioned that the CA that had issued was, as best he could tell, really the only one that was doing this, and had already had issues with arpa, and that issuance with .arpa is super rare.<br><br>Wayne wanted to know how many certificates are out there, and if it’s just one CA that had issues several certificates, it seemed like the best step would be to clarify that it’s not permitted until someone comes forward with a use case that really makes sense.<br><br>Corey chimed in and stated it seemed like there were a significant number of these certificates out there, sharing a crt.sh link [5] for this. Ryan asked if it was publicly trusted, and Corey clarified he saw DigiCert, Sectigo, Cloudflare, and a few others. Wayne qualified it was hundreds, a few thousand. Corey stated he agreed with Dimitris and we should move towards prohibiting these. We have several different RFCs clarifying the intent was not for these to be used as hostnames.<br><br>Wayne stated the best starting position was to deny these, and get clarification from CAs about why to allow these / why to permit them. Wayne asked if Ryan was going to start a discussion on this. Ryan stated it was, he wanted to bring it up on the call to see what sort of questions folks had to make sure to address them on the list. Wayne added it to the Trello board to continue tracking.<br><br>[3] <a href="https://github.com/cabforum/documents/issues/153">https://github.com/cabforum/documents/issues/153</a><br>[4] <a href="https://www.iana.org/domains/arpa">https://www.iana.org/domains/arpa</a><br>[5] <a href="https://crt.sh/?dNSName=%25.in-addr.arpa&exclude=expired">https://crt.sh/?dNSName=%25.in-addr.arpa&exclude=expired</a><br><br>Browser Alignment<br>Wayne asked if there were any other topics to discuss for the F2F. Ryan brought up the browser alignment ballot, which tries to align the BRs with browser policy and which lives in a branch [6]. Mozilla just published their Policy 2.7 [7] which still needs to be integrated. Ryan indicated he hadn’t heard anything from Microsoft regarding any planned winter updates to their root store policy. Mike clarified in the chat that they didn’t expect any changes being needed to the ballot.<br><br>Ryan recapped the changes in the ballot.<br><br>Wayne asked where we were at in terms of taking it to a ballot, versus waiting for the update to the documents on GitHub. Ryan indicated the plan was to land this behind Jos’ markdown cleanup ballot, and that he had also been waiting for Mozilla Policy 2.7 to be published. 2.7 is out now and he needs to update, but he’s not sure the status on Jos’ ballot. The reason for this is that this ballot has overlap with that other ballot.<br><br>Dimitris mentioned the infrastructure call was short, and just Dimitris and Jos, but that he can go forward with updating the ballot and just needs to find the time to update the ballot but is pretty much ready.<br><br>Wayne asked if the idea was that we shouldn’t have any other ballots when the cleanup ballot is going through. Ryan clarified that no, that wasn’t the case, it was just because there was overlap between the ballots, and wanted to avoid having to prepare variants of “If the markdown ballot passes, this is what things look like” and “If the markdown ballot fails, this is what things look like” for this ballot. If the markdown ballot isn’t soon, then it may be the Markdown ballot needs to address this. It also overlapped with SC23/SC24, and so was nice to also not to have to provide variants for that.<br><br>[6] <a href="https://github.com/sleevi/cabforum-docs/tree/2019-10-Browser_Alignment">https://github.com/sleevi/cabforum-docs/tree/2019-10-Browser_Alignment</a><br>[7] <a href="https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/">https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/</a><br><br>## F2F Meeting Planning<br>Wayne suggested we could begin with discussing the ballots currently in process. A more meaty topic would be discussing default-deny and going through the BRs and looking for issues to clarify. He suggested we could spend some time in the F2F going through and clarifying this.<br><br>Ryan mentioned he was not optimistic if CAs haven’t been looking at their CP/CPSes to look for potential issues. Ryan mentioned another topic was the validation of organization information for EV certificates. This was dependent on CAs going through some of their data sources and disclosing them, but might make progress on going through. Dean agreed that it’d be useful, and one of the things brought up in Thessaloniki as a topic for discussion.<br><br>Wayne said it seemed like a reminder was needed. Ryan agreed, as so far, only DigiCert has shared data about their validation sources. Wayne was going to send out a reminder to the list, and asked if any other CAs could step up to commit to sharing their data sources.<div><br></div><div>Doug committed GlobalSign to share some of their data sources before the F2F.<br></div></div>