<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Aptos;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:11.0pt;font-family:"Arial",sans-serif;color:#212121'>These are the Final Minutes of the Teleconference described in the subject of this message, prepared by Doug Beattie (GlobalSign) and approved on the August 8<sup>th</sup> meeting.</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>## Validation Subcommittee Minutes | Thursday, 2024-07-11<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>### Attendance<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Aaron Poulsen (Amazon), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnell (DigiCert), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Gurleen Grewal (Google), Joseph Ramm (OATI), Kiran Tummala (Microsoft), Mahua Chaudhuri (Microsoft), Michael Slaughter (Amazon), Michelle Coon (OATI), Miguel Sanchez (Google), Nate Smith (GoDaddy), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Scott Rea (eMudhra), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>### Note Well<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The statement was read concerning the meeting recording, antitrust policy, code of conduct, and intellectual property rights agreement. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>### Approval of minutes<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The minutes for the following meetings were approved:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- May 2nd Validation Working Group<o:p></o:p></p><p class=MsoNormal>- F2F May 30 F2F meeting minutes<o:p></o:p></p><p class=MsoNormal>- June 27th Validation Working Group<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Side note: Slaughter is looking for endorsers for the CA assisted ballot, so please reach out to him it you're interested.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>### Discussion on email sent to the list on June 20th about Domain Validation method 3.2.2.4.7<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Doug provided an overview of the email:<o:p></o:p></p><p class=MsoNormal>- <a href="https://lists.cabforum.org/pipermail/validation/2024-June/001989.html">https://lists.cabforum.org/pipermail/validation/2024-June/001989.html</a> <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The primary topic was where "in" the CNAME record would a random value be located? It's clear where it would be located in a DNS TXT and CAA record. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slaughter said his interpretation is that the CNAME record would contain the random value in the RDATA field (i.e., the domain-name). Corey and Clint agreed. During the meeting examples like _12345.example.com were provided as valid use where "12345" is the random value.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Wayne pointed out that the definition of Authorization Domain Name (ADN) helps with the interpretation here as it defines how CNAMEs are to be used. It says "The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation)".<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The current 3.2.2.4.7 definition treats DNS TXT, CAA and CNAME records all the same but it might be better to split this out into three different more clearly specified statements. Ben opened an issue for this during the call where we can discuss this topic further and decide if additional clarification is needed: <a href="https://github.com/cabforum/servercert/issues/533">https://github.com/cabforum/servercert/issues/533</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott suggested providing some examples to help improve understanding of topics like this. Corey and others said that providing an partial illustrative list might imply that those are the only ways and it's also hard to create an exhaustive list. We need to be mindful of that if we proceed with including some examples.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Summary: Between section 3.2.2.4.7 and the definition of ADN, it's now clear that the random value can be in a CNAME record (as being part of the domain-name of the sub-domain record itself), or the CA can follow the CNAME record and use that FQDN for the purposes of domain validation per the definition of ADN.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>### Discussion on improvements to CRLDP and CPS qualifier URI schemes in section 7<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Enrico discussed the improvement to the HTTP references via a short presentation for some updates to the language for these topics.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>He suggested that, for AIA (id-ad-ocsp and id-ad-caIssuers), every accessMethod SHALL be the uniformResourceIdentifier scheme HTTP and other schemes SHALL NOT be present<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>PolicyQualifier for id-qt-cps: will use http or https only.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott asked if the first entry in the CDP should be http and have we made LDAP defunct? After a short discussion, it was pointed out that LDAP has been removed from all URIs in the BRs. Wendy and Corey agreed that the referenced to "the first GeneralName containing the HTTL URL..." was probably there to assure this comes before any LDAP URIs, so this can probably also be removed.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Wendy pointed out that we might want to make references to RFC 3986, section 3.1, in one place vs., every time we reference http to make future updates easier and to avoid conflicting references. Clint provided some further clarification regarding that reference to which Enrico will also incorporate into the follow-up discussions.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Summary: Enrico will put the proposed language in github and circulate with the changes in a ballot type redline vs. a github issue for additional review<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>###Security analysis of the use of DNS resolvers for method 7 validation<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Security properties of using in-house or hosted DNS resolvers.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This was to follow up on last call where we discussed:<o:p></o:p></p><p class=MsoNormal>- Operating DNS resolvers should be done in-house<o:p></o:p></p><p class=MsoNormal>- Others say that it's difficult to operation an in-house resolver securely and that outsourcing this you could leverage this additional knowledge.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tobias said that any DNS resolver used for domain validation has to be a first party resolver, or one that is specifically operated and configured for such purposes. He's seen examples where getting forged responses into DNS have caused security issues, or false responses to the DNS resolvers.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As long as this a specifically configured and secured resolver, it's not absolutely necessary that it be hosted by the CA, but it needs to be specifically configured for this purpose.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slaughter asked what does "specific for this purpose mean"<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tobais said that for domain validation specially, DNS is so flawed that we need an extra layer for domain validation. The way we bring this to domain validation is to look at the flaws in DNS and mitigate them the best we can. There are some easy steps that every CA can do. The first one is to make sure that the resolvers used for domain validation are only queried by the CA for the exclusive use of domain validation and no other uses.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slaughter: Agree, DNS is not great and this is the reality we live in. We need to do this to minimize the risk and maximized the correctness for domain validation. Taking a blanket statement that all DTPs are equivalent is not true. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tobias: I'm 100% convinced that there are no available DNS providers that would provide this level of security. Nothing else needs this level of service.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slaughter disagrees: CAs are responsible for performing domain validation and it's the CAs responsibility to use secured components for this purpose and it's not necessary for them to use in-house. It's not easy to run and lock down DNS.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tobias: The key point is that we need to control who provides input to the resolver in order to reduce the risk of exposing details to enable an attacker, or that results in improperly cashed results.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slaughter: yes, those are valid attacks and the CA needs to reduce the risk, one way is to not use the resolver for any other purpose. There are other ways to do this so the blanket statement of not using 3rd party resolvers may not hold.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tobias: I don't think there is a DTP that offers what CAs need, so in that way it's an academic discussion. On top of that, if we do included this as DTP we will need to figure out how to audit DTPs for this. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: What we'd like to do base decisions on security analysis and even though there may not be any.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The auditing of the use of a 3rd party DNS was deemed compliant in the past, but this does not cover the operation of the DNS provider itself (just that the CA is using it).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It would be valuable if we could agree on the security outcome of this and then drive the requirements.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Clint: CAs need to consistently represent that the validation was authoritative and secure. He finds it difficult to understand how a 3rd party could run DNS to the level needed, but perhaps the CA is also intimately involved in the resolver settings and use.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slaughter does not fundamentally believe that it is more secure to have a 120 implementations of DNS resolvers than a few well known ones operated by DNS experts.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Clint agrees that CAs must have a DNS resolver dedicated to these DNS queries.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Clint: can we see some concrete examples?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slaughter: Let's not deviate too far from our DTP topic into this DNS subject. It's the CAs responsibility and the CA needs to understand and address the risks, and using your own resolver and prohibition the use of a DTP for this is more of an implementation decision (either can work). The BRs should not blanket prohibit 3rd party resolvers, but rather clearly specify the risks that need to be mitigated and be audit on that.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Corey: We'll continue this discussion next week.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>