<html 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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:148640501;
mso-list-type:hybrid;
mso-list-template-ids:-325577456 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1557665763;
mso-list-type:hybrid;
mso-list-template-ids:-332267006 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:1659844117;
mso-list-template-ids:260107084;}
@list l2:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:1681009326;
mso-list-template-ids:361105730;}
@list l3:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4
{mso-list-id:1694114494;
mso-list-type:hybrid;
mso-list-template-ids:362029688 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l4:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l4:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l4:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l4:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l4:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l4:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l4:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l4:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l4:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Please see the <b>REVISED</b> draft minutes below.
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Validation Subcommittee – 11 January 2024
<span style="background:yellow;mso-highlight:yellow">[REVISED 24/01/2024]</span> </span>
</b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Minute Taker</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">:
Michael Slaughter (Amazon)</span><span style="font-size:13.5pt;font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> </span><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"><br>
<br>
<b>Attendees</b>: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Clint Wilson (Apple), </span><span style="font-family:"Times New Roman",serif;color:#070706;mso-fareast-language:EL">Corey
Bonnell</span><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> (DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Eva Vansteenberge
(GlobalSign), Gregory Tomko (GlobalSign), Inigo Barreira (Sectigo), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Paul
van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Rebecca Kelley (Apple), Rollin Yu (TrustAsia), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Stephen Davidson (DigiCert), Thomas Zermeno (</span><a href="http://ssl.com/"><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">SSL.com</span></a><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">),
Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)<br>
<br>
Corey read the note well statement.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Agenda</span></b><span lang="EL" style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></p>
<ol start="1" type="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1">
<span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">Status update for the MPIC <o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1">
<span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">Status update on Method 7 ballot <o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1">
<span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">Usage of third parties for domain control verification. <o:p></o:p></span></li></ol>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">MPIC Update </span></b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Chris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> and
<b>Ryan</b> were not present at the meeting </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">and did not<span style="color:black"> provide an update.
</span><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Clint</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that while he can’t provide an official update, based on his
understanding with Chris and Ryan before the holidays the text of the ballot is more or less stable. He then offered that if folks want to review it the ballot text is available as a branch on Ryan’s repo. Most of the work remaining with the ballot is proactively
addressing potential IP concerns prior to the official discussion period and voting.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Aaron</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> shared a link to the ballot and said that he agreed with Clint that
the ballot is stable. Aaron explained that the recent activity is related to a single comment thread about the phrasing of a single sentence.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Doug</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> emphasized that time is of the essence as the deadlines called out
in the ballot are in December and CAs will need time to prepare. Doug said the sooner we can get this ballot into a formal discussion period the better to move it forward. Doug asked about the IP discussion and if there were concerns that the ballot will not
happen.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Clint</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said he doesn’t believe there are IP concerns but added that because
the changes originated with the Princeton team presenting to the CABF, when they hadn’t signed the IPR agreement is being looked at as a potential area of concern. Client added that Ryan and Chris are working with the Princeton team to get a “release of IP
statement”. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Trev</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said this seems kind of weird since the ballot is a collaborative
solution to a problem. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Aaron</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> agreed with Trev and said that the Princeton legal team disagrees
and is pushing the issue. Aaron said that both the Google and the LE legal teams are involved. Aaron added that the Princeton legal team has declared that it will never be appropriate for the Princeton team to sign the IPR agreement and join the CABF as an
interested party but they are willing to make a statement regarding the IP claims which can be brought to the CABF for consideration.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Trev</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> did not agree with the idea of getting the Princeton people to sign
an IPR in the first place because a presentation at the CABF is not materially different from passing around a link to an interesting finding. She then suggested that the Server Cert working group should look further into identifying a way of handling security
researchers when they are sharing findings and not solutions. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Ben</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that isn’t about protecting Princeton but rather protecting CAs
and answering any kind of objections that CAs might pull out at the last minute. He said that all of this effort is directed towards satisfying CAs and certificate issuers and that Princeton has not been that concerned about the IPR but rather they would not
like to sign something that touches on some tangential intellectual property right that they own somewhere else.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> clarified that the Princeton team did not just present findings,
they also contributed to the solution which is where the IP challenges are coming from. Dimitris said that the rules are not intended to protect CAs but rather the entire eco-system. He added that if we were to implement something in the BRs and then someone
claimed royalties for that implementation, that would have a negative impact to the eco system.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Trev</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that we are not going to raise the security bar without getting
input from security researchers. We have to be able to engage with them without the expectation of an IPR. We should put together more forum level guidance so that we don’t run into this in the future. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that no one is blocking us from bringing in researchers or
reading the news but we have to develop solutions with members to make sure they are not going to claim anything that they contributed to the Forum. This is currently achieved by asking Members (including Interested Parties) to sign the IPR agreement.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">Trev</span></b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"> said that we should put together more forum level guidance so we don’t run into this in the
future. <o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo2">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Ben</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said historically, there was the example of the Navy SSL patent which
someone got a hold of and started suing all of the biggest subscribers they could find. Ben agreed with Dimitris that the IPR agreement is to protect the eco-system.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li></ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Method 7 Ballot Up</span></b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></p>
<ul type="disc">
<li class="MsoListParagraph" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo3">
<b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">Slaughter</span></b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"> provided background on the ballot and explained that he was able to capture the feedback
from the previous discussion 30/11/2024 and it has been incorporated into a new revision: </span><span style="color:windowtext"><a href="https://github.com/slghtr-says/servercert/pull/1/files"><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">https://github.com/slghtr-says/servercert/pull/1/files</span></a></span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">. <o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo3">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Slaughter</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> requested feedback on the updated language in the form of comments
on the PR. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li></ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Delegated Third-Parties and Domain Validation </span></b><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></p>
<ul type="disc">
<li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Corey</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> introduced the 3rd topic of the meeting.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Corey</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that the BRs are clear that the use of DTPs in the validation
process is prohibited. Corey said that CAs are going to be using data centers and upstream ISPs that are going to be handling various aspects of the domain validation process. He said it can be somewhat unclear if it is appropriate to use upstream service
providers that provide connectivity to the Internet. Corey referenced a recent Bugzilla bug where the use of the Google web-based DNS tool was deemed as a DTP and not allowed.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> recalled the original discussion to forbid DTPs from performing
domain validation tasks. He said that his understanding was that it had to with the complete domain validation process and that the expectation of the forum at the time was not to deny any third-party component used as part of the process but rather the entity
that makes the final decision. Dimitris said that despite the intent, the current language in the BRs explicitly states that using DTPs for any part of the domain validation process is prohibited in sections 3.2.2.4 and 3.2.2.5, which is problematic.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">David</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> Kluge said that the discussion and definition is relatively simple
but not if you dig deeper. He then explained that section 3.2.2.4 contains a clear prohibition on the use delegated third parties in domain validation but if you look at the definition of DTP it contains a three-fold test to determine what a DTP is. It is
defined as a person or legal entity that fulfills one or more of the CA’s requirements but is not in scope of the CA’s audit. David then explained that a third-party is not necessarily a delegated third-party unless it also performs a duty that the CA has.
This can get you into trouble if you expand the definition too broadly and extend it to Internet Service Providers (ISPs), Data Center Providers etc. David suggested that we take a look at a few examples and determine where it makes sense to draw the line
between the appropriate and inappropriate use of delegated third parties.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Trev</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that Dimitris’ explanation of the original intent seems like
the consistent interpretation. She added that for EV we have validation specialists and that even for DV we expect the CA to exercise authority over the decision-making process. She added that when she thinks of delegating domain validation, she defines it
as delegating the decision rather than the specific mechanisms to retrieve the data required to make the decision. She then asked how a CA could actually perform domain validation if retrieving critical information from a third-party such as WHOIS or a registrar
is not allowed. She concluded that the CA exercises judgement over the data it receives.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Clint</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> agreed that this is a pretty complex area of concern but thinks that
the conclusion of the bug (</span><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1872371"><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL">https://bugzilla.mozilla.org/show_bug.cgi?id=1872371</span></a><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">)
is correct. Clint agreed with Trev that CAs have to get data from somewhere but it has to be from the right sources. Clint explained that is why QIS and QGIS exist. For DNS based data, third parties have to be involved because of how the internet works.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Clint</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that in the process of validating a domain there are boundaries
around what the CA is doing and how it is engaging with the third-parties. CAs have to use the protocol but we should expect the CA to use the protocol authoritatively by directly connecting to the root zone and from there navigating down the DNS hierarchy
to the target. Clint said that by using a 3rd party DNS resolver for example, you are delegating an important function in parsing and retrieving the zone information that the CA is trying to get their hands on. Clint asserted that the resolver needs to be
in the CAs control. Clint said that if we can come to an agreement on where that line exists, it would be really good to add that clarity to the BRs.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Tobias</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> agreed with Clint’s perspective and said there are really two DNS
protocols. 1) Between the client and stub resolver. 2) Between the resolver and the authoritative name servers. Tobias said that the only systems worth checking are the authoritative ones. Tobias then asked if there was actual disagreement about whether or
not using a third-party service for DNS resolution is acceptable.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">David</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said the current language is not as specific as it should be and
that it doesn’t distinguish between the different parts of the domain name system and leaves it open for interpretation. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Tobias</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> asked if there is agreement that using a 3rd-party DNS resolver
should only be allowed if it is a dedicated third-party that is in scope of the audit. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">David</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> answered that he doesn’t know and that establishing what the concerns
are might help. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Martijn</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that he agreed with Clint and Tobias and that some parts of
the BRs are more specific where DNS is not. Martijn said that we can look at the WHOIS language as an example of where the language says the information has to be retrieved directly from the domain registrar or registry operator. Martijn agrees that we should
only be using third-parties to request authoritative answers from root servers or registries directly and that we should have improvements in the BRs to make that clearer.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Mads</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> Henriksveen said that he will not argue about the suggestions of what
is allowed and not allowed, there is some missing language in the BRs. Currently there are some practices that are accepted by the industry and some that are not but it is not obvious what is and what isn’t. Mads added that he hopes that we can add some language
that clarifies this for all domain validation methods. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Aaron</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that he fundamentally agrees with Clint that DNS lookups need
to be made to an authoritative resolver. As discussed in the BugZilla bug there were actually two issues with using Google DNS 1) Google Public DNS is a DTP and DTPs are forbidden and 2) Google Public DNS doesn’t commit to adhering to satisfying all of Public
CA requirements such as DNSSEC. Aaron said that the second issue is why contacting the authoritative name server is the thing that needs to be clarified as the requirement.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Aaron</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that we need to be talking about this in the context of multiple
domain validation methods such as the agreed-upon changes to a website and CAA record-based methods that also rely on DNS lookups. Aaron said that DNS lookups are required for 95% of the domain validation methods so we need to be looking at this holistically.
Aaron added that the second concern is how many CAs are using third-parties such as MailChimp to send e-mails for e-mail validation and does that count as a delegated 3rd party?</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> thanked Aaron and said that he tried to highlight some of those
issues in the e-mail to the forum list on December 28<sup>th</sup> which invoked all of the issues from the TLS BRs and SMIME. Dimitris said Aaron mentioned an indirect requirement that comes from DNSSEC and added that there are other requirements that come
from other documents such as 5280 that have resulted in several CAs missing them and caused multiple public incidents. Dimitris said that repeated incidents is a strong indication that something is wrong with the BRs. He added that in the current BRs there
is no rule or requirement that an authoritative name server needs to be queried. That comes indirectly from the DNSSEC checks that CAs must perform, and most implementations already take that into account by checking with Authoritative name servers, but that
doesn’t cover 100% of the implementations. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Corey</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said there are two themes emerging: 1) Why is the use of a third-party
problematic 2) the discussion on DNSSEC. Corey suggested that we continue the discussion on why the use of public resolvers is problematic. Corey asked if anyone could provide an explanation on why the use of public resolvers is problematic. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> clarified that we are talking about delegated third-parties as
part of some component or function executed in the BRs but added that we don’t have any tools to create a light-weight audit for delegated 3rd parties. Dimitris added that it doesn’t really make sense from a security standpoint to require delegated third parties
to be audited against the entirety of the BRs when they are only performing some limited function. He said that this was part of the MPIC proposal regarding the remote vantage points. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">David</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said he thinks it might help to frame the problem as a data quality
concern. The delegated third-party discussion is about a legal entity allocation but that is not what really matters for the quality of the validation. So, it may help to further specify what the quality or reliability expectations are for the data. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Tobias</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> replied that it’s also about responsibility.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">David</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said yes as an extension in that you care about responsibility because
if you have insufficient responsibility, you have bad quality. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Tobias</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> replied that the CAs are responsible to the root programs and have
oversight and the ability to react. He expressed the concern that if we just allow DTPs after examining the data, we will not have the same degree of oversight. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">David</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> replied that you also run into enforcement problems if you only look
at the entity allocation without having a measure for the quality of the data itself.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> suggested to David that we bring in some risk analysis for the
different components that could participate in the validation process such as the DNS resolver.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Tobias</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> responded that the problem is difficult because some of the big
public resolvers are likely way more trustworthy because of the level they are operated at. Specifying this out in a way that makes them acceptable is going to be hard. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Trev</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said she thinks Dimitris’ suggestion is right and unless we do a risk
assessment, we will continue spin in fear circles. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Mads</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that even if we found a DTP that is 100% reliable it is still
not allowed because it’s a DTP so measuring the quality of the data is not the way to go. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">David</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said he agrees we could do an analysis of what criteria flow into
data quality and get a better understanding of the likelihood of these occurring and help provide some direction to the discussion.
</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said as we start unpacking the discussion and expand to other
DTPs (SMS, Phone etc..) performing a risk assessment would be helpful. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Tobias</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said he disagrees and thinks there is solid reason to draw the line
where it is. He added that the idea that we could just delegate the main validation out to DTPs is very problematic. Tobias said that DTPs are usually not operated for the purpose of performing domain validation so the requirements would not be considered
at every step along the way. He said their usage for other purposes may also make them vulnerable to a wider range of attacks. He concluded that we would need a very complicated framework to determine when these are acceptable which he does not believe would
be worthwhile. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Mads</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said a risk assessment is something that we could use to help draw
that line. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Aaron</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said for the sake of being able to continue the discussion past the
end of the meeting, Aaron sent a very simple clarification as a starting point on how to clarify this language as a reply to Dimitris’ thread. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> forwarded the thread to the server cert working group for IP reasons
among others. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Corey</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said the language that Aaron sent out could be considered as a treatment
to a symptom and that the underlying issue is that there is a lack of clarity of when a DTP is acceptable or not. Corey said that a risk assessment exercise would help identify the larger set of threats and potential resolutions.</span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Clint</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said addressing the symptom is worthwhile since it is currently an
open wound and recommended that we also bring 3.2.2.5 into scope. Tearing this apart for other purposes will have diminishing returns and would be very challenging. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Aaron</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said he is unopposed to a two-prong approach but does not think the
clarification should wait on the security assessment. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Corey</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> asked if there is value in performing a risk assessment. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Dimitris</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> said that once the experts start talking about a given topic like
e-mail validation then it will lead to some useful productive discussion about the risks, threats and appropriate mitigations which is in essence part of a risk assessment. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li><li class="MsoListParagraph" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l4 level1 lfo4">
<b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL">Corey</span></b><span style="font-family:"Times New Roman",serif;color:black;mso-fareast-language:EL"> concluded that we will spend some time on the next call and open
the floor up to how we want to do the risk assessment. </span><span style="font-family:"Times New Roman",serif;mso-fareast-language:EL"><o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From: </span></b><span style="color:black">"Slaughter, Michael" <slghtr@amazon.com><br>
<b>Date: </b>Monday, January 22, 2024 at 22:08<br>
<b>To: </b>"validation@cabforum.org" <validation@cabforum.org><br>
<b>Subject: </b>2024-01-11 Validation-sc draft minutes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="color:black">Validation Subcommittee – 11 January 2024<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:black">Minute Taker</span></b><span style="color:black">: Michael Slaughter (Amazon)</span><span style="font-size:13.5pt;color:black"> </span><span style="color:black"><br>
<br>
<b>Attendees</b>: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Clint Wilson (Apple), </span><span style="color:#070706">Corey
Bonnell</span><span style="color:black"> (DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Eva Vansteenberge (GlobalSign), Gregory Tomko (GlobalSign), Inigo
Barreira (Sectigo), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE
Foundation), Rebecca Kelley (Apple), Rollin Yu (TrustAsia), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Stephen Davidson (DigiCert), Thomas Zermeno (</span><a href="http://ssl.com/">SSL.com</a><span style="color:black">), Tobias Josefowitz (Opera Software
AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)<br>
Note: Paris = David Kluge (GTS)<br>
<br>
Corey read the note well statement.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="color:black">Agenda<o:p></o:p></span></b></p>
<ol start="1" type="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo5">
Status update for the MPIC <o:p></o:p></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo5">
Status update on Method 7 ballot <o:p></o:p></li><li class="MsoListParagraph" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l3 level1 lfo5">
Delegated Third-Parties and Domain Validation <o:p></o:p></li></ol>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="color:black">MPIC Update <o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="color:black">Chris and Ryan will provide an update at the next meeting. <br>
<br>
Aaron provided a link to the ballot and explained that the flurry of activity that has happened in the last 2 weeks is related to a single comment thread about the phrasing of a single sentence and that the majority of the ballot is stable. <br>
<br>
Doug emphasized that time is of the essence since the dates start in the December and CAs will need time to perform planning and implementation.<br>
<br>
Clint explained that delays were due to ongoing IPR agreement challenges with Princeton research team. <br>
<br>
Aaron said that both the Google and the LE general consuls are working on this effort. The Princeton legal team has made a statement that it will never be appropriate for the Princeton team to sign the IPR agreement and join as an interested party<br>
<br>
Trev said that we should talk about how we can handle future security researchers in a way that doesn’t require them to sign an IPR agreement when they are share findings rather than solutions.<br>
<br>
Ben explained that the IPR agreement is mainly for protecting the CAs. <br>
<br>
Dimitris clarified that the Princeton team did not just present findings, they also contributed to the solution. Dimitris said that the rules are not intended to protect CAs but rather the entire eco-system. If the forum requires MPIC but then someone implements
royalties then that will have a negative impact on the eco-system. <br>
<br>
Trev said that we are not going to raise the security bar unless we continue to receive feedback from researchers. We have to be able to engage with them without the expectation of an IPR. We should put together more forum level guidance so that we don’t run
into this in the future. <br>
<br>
Ben said historically, there was the Navy SSL patent which someone got a hold of that was used to extract money from multiple parities. Ben then agreed with Dimitris’ point about protecting the eco-system. </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="color:black">Method 7 Ballot Update<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="color:black">Slaughter provided background on the ballot and explained that he was able to capture the feedback from the previous discussion 30/11/2024 and it has been incorporated it into a new revision: </span><a href="https://github.com/slghtr-says/servercert/pull/1/files">https://github.com/slghtr-says/servercert/pull/1/files</a><span style="color:black">. <br>
<br>
Slaughter requested feedback on the updated language in the form of comments on the PR. </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="color:black">Delegated Third-Parties and Domain Validation <o:p></o:p></span></b></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Corey introduced the 3rd topic of the meeting by explaining that the BRs are unclear about which aspects of the domain validation process are allowed to be performed by third-party
services such as Google’s public DNS resolver. The purpose of this discussion is to try and build some consensus about what is appropriate and what is not. <br>
<br>
Dimitris recalled the discussion to forbid delegated third parties from performing domain validation tasks and that it was his understanding is that the discussion was centered around the complete process of domain validation. He didn’t think the expectation
of the forum was to deny any third-party component used as part on the process but rather who makes the final decision. <br>
<br>
David Kluge said that the definition is relatively simple but not straightforward and explained that 3.2.2.4 clearly prohibits the use delegated third parties in main validation process and that delegated third party is defined as a different personal or legal
entity that fulfills one or more of the CA’s requirements. David explained that this definition in the broadest interpretation could extend to Internet Service Providers (ISPs), Data Center Providers etc... at which point section 3.2.4 “collapses in on itself”.
David then suggested that we look at a few examples and determine where it makes sense to draw the line between appropriate and inappropriate use of delegated third parties.<br>
<br>
Trev said what confuses her about this is that there seems to be a consistent definition and that we expect the CA to exercise authority over the decision-making process. She added that when she thinks of delegating domain validation, she considers that as
delegating the decision rather than the mechanism to get the information. The CA is responsible for exercising judgment over the data it receives. <br>
<br>
Clint agreed that this is a pretty complex area of concern but thinks that the conclusion of the bug (</span><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1872371">https://bugzilla.mozilla.org/show_bug.cgi?id=1872371</a><span style="color:black">) is
correct. Clint said that CAs have to get data from the right sources which is why QIS and QGIS exist. For DNS data, third parties have to be involved based on how the internet works. In the process of validating a domain the CA may rely on third parties but
the he would expect the protocol to be verified directly by the CA. For example, ensuring that DNS lookups are authoritative by directly connecting to the root zone and going down the DNS hierarchy. Clint said using 3rd party DNS resolver for example steps
over that of being a “necessary” third party. Clint said we can come to an agreement on where that line exists and that it would be really good to add that clarity to the BRs.<br>
<br>
Tobias: agreed with Clint and said there are two DNS protocols. 1) Between the client and stub resolver. 2) Between the resolver and the authoritative resolver and the only one’s worth checking are the authoritative ones. Tobias then asked if there was actual
disagreement about whether or not using a third-party service for DNS resolution is acceptable if the language just needs to be improved.<br>
<br>
David replied that at this point, the language is not as specific as it should be since it doesn’t distinguish between the different parts of the domain name system leaves it open for interpretation. <br>
<br>
Tobias asked if there is agreement that using a 3rd-party DNS resolver should only be allowed if it is a dedicated 3rd party that is in the scope of audits. <br>
<br>
David answered that he doesn’t know and that establishing what the concerns are might help. <br>
<br>
Martijn said that we can look at the WHO-IS language as an example of where the language says the information has to be retrieved directly from the domain register or registry operator. The DNS language does not have that kind of specificity. Martijn agrees
that we should only be using third-parties to request authoritative answers from browsers or registries directly and that we should make the text more around that. <br>
<br>
Mads said that he will not argue about what is allowed and not allowed but as a CA that missed recently, I think there is some missing language in the BRs that is missing. Currently there is some practice that is accepted by the industry and some that are not
but it is not obvious what is and what isn’t. Mads added that he hopes that we can add some language that helps clarify this for all of the domain validation methods. <br>
<br>
Aaron said that he fundamentally agrees with Client that DNS lookups need to be made to an authoritative resolver. There were actually two issues with using Google DNS 1) They are a third-party which are forbidden and 2) Google Public DNS doesn’t commit to
adhering to satisfying all of the requirements such as always performing DNS-SEC lookups. I think the second issue is why contacting the authoritative name server is the thing that is required and what needs to be clarified as the requirement. Aaron said that
we need to be talking about this in the context of multiple domain validation methods including the File and CAA record-based methods that also rely on DNS lookups. DNS is required for 95% of the domain validation methods so we need to talk about this holistically.
The second concern is how many CAs are using third-parties such as MailChimp to send e-mails for e-mail validation and does that count as a delegated 3rd party?<br>
<br>
Dimitris said he tried to highlight some of those issues in the e-mail to the forum list on December 28th. Dimitris said Aaron mentioned an indirect requirement that comes from DNS SEC. and added that there are other requirements that come from other sources
such as 5280 that have caused problems. Dimitris said we are talking about repeated incidents that is outside of domain validation which is a strong indication that something is wrong that we need to clarify or make more explicit. Dimitris added that there
is no rule or requirement that an authoritative need to be queried as that indirectly comes from the DNS checks that CAs must perform. <br>
<br>
Corey said there are two themes emerging: 1) Why is the use of a third-party problematic 2) the discussion on DNSSEC. Corey asked if anyone could provide an explanation on why there is a problem with delegating to third parties. <br>
<br>
Dimitris clarified that we are talking about delegated third-parties as part of some component or function executed in the BRs but we don’t have any tools to create a lighter-weight audit for delegated 3rd parties. Dimitris added that it doesn’t really make
sense from a security standpoint to required delegated third parties to be audited against the entirety of the BRs when they are only performing some function. He continued that this was part of the MPIC proposal for the remote vantage points. <br>
<br>
David said he thinks it may helpful to frame the problem as a data quality concern. The delegated third-party discussion is about a legal-entity distinction but that is not what really matters for the quality of the validation. So, it may help to really focus
on the reliability expectations of the third party. <br>
<br>
Tobias said that it’s also about responsibility and that the CAs are responsible to the root programs and have oversight and the ability to react. He expressed the concern that if we just allow the usage of DTPs, we will not have the same degree of oversight. <br>
<br>
Dimitris suggested to David that we bring in some risk analysis to the different components that could participate in the validation process. For example, a public DNS resolver and analyze if we can trust Google to not return wrong data and examine the probabilities. <br>
<br>
Tobias responded that the problem is really difficult and that some of the big public resolvers are way more trust worthy. Specifying this out in a way that makes it acceptable is going to be really hard. <br>
<br>
Trev said I think that Dimitris’ suggestion is right and we need to do a risk assessment or else we will continue to go round and round in fear circles. <br>
<br>
Mads said that even if we found a DTP that is 100% reliable it’s still not allowed because it’s a DTP so he doesn’t believe that measuring the quality of the data is the way to go. <br>
<br>
David said he things we could do an analysis to get a better understanding of the likelihood of these occurring because at this moment I think the discussion is purely conceptual since we don’t have any quantification for these scenarios. <br>
<br>
Dimitris said a risk assessment that covers all DTPs including those for sending e-mails would be helpful. <br>
<br>
Tobias said he thinks there is solid reason to draw the line where it is and that the idea that we could delegate the main validation out to DTPs is very problematic. Tobias said that DTPs are usually not operated to the level required, the requirements around
validation would not be considered at every step along the way and their usage would make them vulnerable to attacks. He concluded that we would need a very complicated framework to determine when these are acceptable which he does not believe is worthwhile. <br>
<br>
Mads said a risk assessment is something that we could use to help draw that line. <br>
<br>
Aaron said for the sake of being able to continue the discussion, I sent a very simple clarification on how to clarify this language as a reply to Dimitris’ thread. <br>
<br>
Dimitris asked for the thread to be forwarded to the server cert working group. <br>
<br>
Corey said the language that Aaron sent out was treatment to a symptom and that we would also need a risk assessment exercise to identify the larger set of threats and potential resolutions.<br>
<br>
Clint said addressing the symptom is worthwhile since it is currently an open wound and recommended that we also address 3.2.2.5. Tearing this apart for other purposes will have diminishing returns and would be challenging. <br>
<br>
Aaron said he is fine with a two-prong approach but does not think the clarification should wait on the security assessment. I think the clarification should proceed at full steam ahead.<br>
<br>
Corey asked if there is value in performing a risk assessment. <br>
<br>
Dimitris said that once the experts start talking about a given topic like e-mail validation then it will lead to some useful productive discussion about the risks. threats and appropriate mitigations. <br>
<br>
Corey concluded that we will spend some time on the next call and open the floor up to how we want to do the risk assessment. </span><o:p></o:p></p>
</div>
</body>
</html>