<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof"><b class="x_ContentPasted0" style="font-style: inherit; font-variant-ligatures: inherit; font-variant-caps: inherit; background-color: ; color: rgb(36, 36, 36); font-family: Calibri, sans-serif; font-size: 11pt;">January 26th, 2023,
Validation Subcommittee Meeting</b><br>
</div>
<div dir="ltr">
<div class="x_elementToProof elementToProof" style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<p class="x_ContentPasted0" style="margin-top: 0px; margin-bottom: 0px;margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin:0in; font-size:11pt; font-family:Calibri,sans-serif; color:rgb(36,36,36); background-color:rgb(255,255,255)">
<br class="x_ContentPasted0">
</p>
<div class="x_ContentPasted0" style="margin:0px 0in; font-size:11pt; font-family:Calibri,sans-serif; color:rgb(36,36,36); background-color:rgb(255,255,255)">
Note taker identified. (<b class="x_ContentPasted0"></b><b class="x_ContentPasted1">Aneta Wojtczak-Iwanicka</b><span class="x_ContentPasted1" style="font-weight:400; margin:0px"> </span><span class="x_ContentPasted1" style="font-weight:400; background-color:rgb(255,255,255); display:inline!important">-
Microsoft</span>)<br class="x_ContentPasted0">
</div>
<p class="x_ContentPasted0" style="margin-top: 0px; margin-bottom: 0px;margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin:0in; font-size:11pt; font-family:Calibri,sans-serif; color:rgb(36,36,36); background-color:rgb(255,255,255)">
<br class="x_ContentPasted0">
<b class="x_ContentPasted0">Antitrust Statement:</b><span class="x_ContentPasted0"> </span>Corey Bonnell read the Antitrust Statement<br class="x_ContentPasted0">
<br class="x_ContentPasted0">
<b class="x_ContentPasted0">Attendance:</b><br class="x_ContentPasted0">
</p>
<p class="x_ContentPasted0 elementToProof" style="margin-top: 0px; margin-bottom: 0px;margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin:0in; font-size:11pt; font-family:Calibri,sans-serif; color:rgb(36,36,36); background-color:rgb(255,255,255)">
<b class="x_ContentPasted0">Aaron Poulsen</b><span class="x_ContentPasted0"> </span>- (Amazon),
<b>Andrea Holland</b> -<span class="x_ContentPasted6" style="background-color:rgb(255,255,255); display:inline!important">(VikingCloud)</span>, <span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Aneta Wojtczak-Iwanicka</b><span class="x_ContentPasted0"> </span>-
(Microsoft), <b><span data-markjs="true" data-ogac="" data-ogab="" data-ogsc="" data-ogsb="" class="x_ContentPasted7" style="margin:0px; background-color:rgb(255,255,255)">Bruce</span><span style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted7"> </span></span><span data-markjs="true" data-ogac="" data-ogab="" data-ogsc="" data-ogsb="" class="x_ContentPasted7" style="margin:0px; background-color:rgb(255,255,255)">Morton</span><span class="x_ContentPasted7" style="font-weight:400; background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted7"> </span>–
Entrust</span></b>,<span class="x_ContentPasted2" style="margin:0px"> </span><b class="x_ContentPasted2">Chris Clements</b><span class="x_ContentPasted2" style="margin:0px"> </span><span class="x_ContentPasted2" style="background-color:rgb(255,255,255); display:inline!important">-
(Google Chrome),</span><span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Ben Wilson</b><span class="x_ContentPasted0"> </span>- (Mozilla),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Clint Wilson</b><span class="x_ContentPasted0"> </span>-
(Apple), <b><span data-markjs="true" data-ogac="" data-ogab="" data-ogsc="" data-ogsb="" class="x_ContentPasted5" style="margin:0px; color:rgb(66,66,66); background-color:rgb(255,255,255)">Corey</span><span style="color:rgb(66,66,66); background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted5"> </span></span><span data-markjs="true" data-ogac="" data-ogab="" data-ogsc="" data-ogsb="" class="x_ContentPasted5" style="margin:0px; color:rgb(66,66,66); background-color:rgb(255,255,255)">Ras</span></b><span class="x_ContentPasted5" style="color:rgb(66,66,66); background-color:rgb(255,255,255); display:inline!important"><b>mussen</b>
– OAT</span>,<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Corey Bonnell<span class="x_ContentPasted0"> </span></b>- (DigiCert),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Dimitris Zacharopoulos</b><span class="x_ContentPasted0"> </span>-
(HARICA),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Doug Beattie</b><span class="x_ContentPasted0"> </span>- (GlobalSign),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Dustin Hollenback</b><span class="x_ContentPasted0"> </span>-
(Microsoft),<b class="x_ContentPasted0"><span class="x_ContentPasted0"> </span>Enrico Entschew</b><span class="x_ContentPasted0"> </span>- (D-TRUST),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Martijn Katerbarg</b><span class="x_ContentPasted0"> </span>-
(Sectigo)<b class="x_ContentPasted0">, <b class="x_ContentPasted3">Michael Slaughter</b><span class="x_ContentPasted3" style="font-weight:400; margin:0px"> </span><span class="x_ContentPasted3" style="font-weight:400; background-color:rgb(255,255,255); display:inline!important">-
(Amazon),</span> Michelle Coon</b><span class="x_ContentPasted0"> </span>- (OATI),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Nargis Mannan</b><span class="x_ContentPasted0"> </span>- (SecureTrust), <b class="x_ContentPasted4">Paul van
Brouwershaven</b><span class="x_ContentPasted4" style="margin:0px"> </span><span class="x_ContentPasted4" style="background-color:rgb(255,255,255); display:inline!important">- (Entrust),</span><span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Pekka
Lahtiharju</b><span class="x_ContentPasted0"> </span>- (Telia Company),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Rebecca Kelle</b><b>y</b> - (Apple),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Ryan Dickson</b><span class="x_ContentPasted0"> </span>-
(Google),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Tobias Josefowitz</b><span class="x_ContentPasted0"> </span>- (Opera Software AS),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Trevoli Ponds-White</b><span class="x_ContentPasted0"> </span>-
(Amazon),<span class="x_ContentPasted0"> </span><b class="x_ContentPasted0">Wayne Thayer</b><span class="x_ContentPasted0"> </span>- (Fastly),
<b>Janet Hines</b> - (<span class="x_ContentPasted16" style="background-color:rgb(255,255,255); display:inline!important">VikingCloud)</span><br class="x_ContentPasted0">
</p>
<p class="x_ContentPasted0" style="margin-top: 0px; margin-bottom: 0px;margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin:0in; font-size:11pt; font-family:Calibri,sans-serif; color:rgb(36,36,36); background-color:rgb(255,255,255)">
<br>
</p>
<p class="x_ContentPasted0" style="margin-top: 0px; margin-bottom: 0px;margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin-top:0px; margin-bottom:0px; margin:0in; font-size:11pt; font-family:Calibri,sans-serif; color:rgb(36,36,36); background-color:rgb(255,255,255)">
<br>
</p>
<div class="x_ContentPasted0" style="margin:0px 0in; font-size:11pt; font-family:Calibri,sans-serif; color:rgb(36,36,36); background-color:rgb(255,255,255)">
<b class="x_ContentPasted0">Minutes:</b><br class="x_ContentPasted0">
1/12 VSC minutes (<span class="x_ContentPasted9" style="background-color:rgb(255,255,255)">Michael Slaughter</span>) were approved.<br class="x_ContentPasted0">
<br>
</div>
<h3 class="x_ContentPasted0" style="margin:0px 0in 6px; font-size:13.5pt; font-family:Calibri,sans-serif; font-weight:bold; color:rgb(36,36,36); background-color:rgb(255,255,255)">
Meeting Minutes</h3>
<div class="x_ContentPasted10">1. Review of minute-taker roll. Would anyone like to be added or removed to the roll?<br>
</div>
<div class="x_ContentPasted10 elementToProof">Corey: W<span class="x_ContentPasted12" style="background-color:rgb(255,255,255); display:inline!important">e have about 7 people right now and we would like to get a couple more folks that would be willing to volunteer
to be added to the rotation.</span></div>
<div class="x_ContentPasted10 x_ContentPasted13">Ryan Dickson, <span style="color:rgb(36,36,36); font-family:Calibri,sans-serif"><span class="x_ContentPasted14 x_ContentPasted15" style="">Michael Slaughter, Chris Clements, <span class="x_ContentPasted17">Janet
Hines volunteered to be added to the minute-taker rotation.</span></span></span><br>
</div>
<div class="x_ContentPasted10 x_ContentPasted11"><br>
</div>
<div class="x_ContentPasted10 x_ContentPasted11">2. Certificate Profiles - pull requests review:</div>
<div class="x_ContentPasted10 x_ContentPasted11">
<ol data-editing-info="{"orderedStyleType":6,"unorderedStyleType":1}">
<li style="list-style-type:"a) "">
<div><span><span class="x_ContentPasted18 x_ContentPasted19" style="text-align:start; background-color:rgb(255,255,255); display:inline!important">Pull request - Add policyQualifiers -> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F412&data=05%7C01%7Canetaw%40microsoft.com%7Cbadfd9c224314897cb1408db08a30e27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113268635795029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V9KokJW6pU8FTEkvJ4byoZj3WIstiUh%2BEmuvrcA27Es%3D&reserved=0" data-auth="Verified" originalsrc="https://github.com/cabforum/servercert/pull/412" shash="KaOiaWb1ok5DXUjoAlRAGXdrSluBYLujswB/mjK1bhn3JE/f3H4JBW/NcEvuul92QyFe0iu2l2TPpKN5WDC+PG/RoNkfEPXL35K/7TBtegzAvmYaRkSuD1tPz1fr+T+G3i9h0twtVOKMdrVkNgH+CmpIj3pb+LFujRSDs5KSp28=" class="x_ContentPasted20" style="margin:0px">https://github.com/cabforum/servercert/pull/412</a><span class="x_ContentPasted20" style="background-color:rgb(255,255,255); display:inline!important"> </span></span></span></div>
<div style="list-style-type:"a) "">
<div class="elementToProof"><span><span class="x_ContentPasted18 x_ContentPasted19" style="text-align:start; background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted20" style="background-color:rgb(255,255,255); display:inline!important">Corey: <span class="x_ContentPasted25" style="margin:0px; background-color:rgb(255,255,255)">This
is a footnote to provide some guidance and some rationale for why t</span></span></span></span>he inclusion of policy qualifiers is not recommended.<br>
Corey: Does anyone have any comments on this proposed language?<br>
</div>
</div>
<div class="x_ContentPasted28" style="list-style-type:"a) "">Ben: Okay, I'm there just a second, let me just read it really quick.
<div class="elementToProof">Ben: Okay, thanks.<br>
</div>
</div>
<div style="list-style-type:"a) "">
<div class="elementToProof">Corey: <span class="x_ContentPasted27" style="margin:0px; text-align:start; background-color:rgb(255,255,255)">Any corrections we need to provide? If not, I guess we can consider this approved then we'll go ahead and merge the same.
I'll go ahead and do that after the call.</span></div>
</div>
<div style="list-style-type:"a) "">
<div>Corey: All right, thank you Wayne for this, we'll go ahead and get this merged.</div>
</div>
<div style="list-style-type:"a) "">
<div><span><span class="x_ContentPasted18 x_ContentPasted19" style="text-align:start; background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted20" style="background-color:rgb(255,255,255); display:inline!important"><br>
</span></span></span></div>
</div>
</li><li style="list-style-type:"b) "">
<div><span><span class="x_ContentPasted18 x_ContentPasted19" style="text-align:start; background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted20 x_ContentPasted22" style="background-color:rgb(255,255,255); display:inline!important">Pull
request - Profiles extended effective date -> <span style="color:rgb(0,0,0); background-color:rgb(255,255,255); display:inline!important"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F413&data=05%7C01%7Canetaw%40microsoft.com%7Cbadfd9c224314897cb1408db08a30e27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113268635795029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FbguSj8AmetoVXnlso3oAzLkanRyriiHQ5JEmRav9Ls%3D&reserved=0" data-auth="Verified" originalsrc="https://github.com/cabforum/servercert/pull/413" shash="LwugvE0CpOi/cqeWNnAF5IMuFYACh+hgkq1IrD/8c0CwJMDYyv2rpP7cvGuS5g/04GDrOzR4Y2tCxPcevlyiGLoslpi3ntKufPavyAhR+HsLz9MJe+0qXVTorTdrVyiCm3EtUiXjkdN0rivXC0lt8Xg8QM6KPaU/mxsytK3AI5Q=" id="LPNoLPOWALinkPreview">https://github.com/cabforum/servercert/pull/413</a></span><span class="x_ContentPasted21" style="background-color:rgb(255,255,255); display:inline!important"></span></span></span></span></div>
<div class="x__Entity x__EType_OWALinkPreview x__EId_OWALinkPreview x__EReadonly_1">
</div>
<div style="list-style-type:"b) "">
<div class="elementToProof"><span><span class="x_ContentPasted18 x_ContentPasted19" style="text-align:start; background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted20 x_ContentPasted22" style="background-color:rgb(255,255,255); display:inline!important">Corey: <span class="x_ContentPasted29" style="background-color:rgb(255,255,255); display:inline!important">The
profiles extended effective date, so we had some good discussion last time. We d<span class="x_ContentPasted30" style="background-color:rgb(255,255,255); display:inline!important">ecided it'd be good to push out the effective date for a couple more
months to give all CAs a chance to comply. </span></span></span></span></span>A pretty straightforward change is just changing the effective date f<span class="x_ContentPasted32" style="display: inline !important;">rom April 15th to September 15th. <span class="x_ContentPasted33" style="display: inline !important;">Does
anyone have any objection or any proposed changes that you would like to see in this PR? </span></span>All right, not hearing anything. We'll go ahead and consider this approved as well, and we'll go ahead and merge that into the branch.</div>
</div>
<div style="list-style-type:"b) "">
<div><span><span class="x_ContentPasted18 x_ContentPasted19" style="text-align:start; background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted20 x_ContentPasted22" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted29" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted30" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted31" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted32" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted33" style="background-color:rgb(255,255,255); display:inline!important"><br>
</span></span></span></span></span></span></span></span></div>
</div>
</li><li style="list-style-type:"c) "">
<div><span><span class="x_ContentPasted18 x_ContentPasted19" style="text-align:start; background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted20 x_ContentPasted22 x_ContentPasted23" style="background-color:rgb(255,255,255); display:inline!important">Pull
request - This PR fixes issues in section 7.1.2.7.3 and 7.1.2.7.4 -> <span class="x_ContentPasted24" style="background-color:rgb(255,255,255); display:inline!important"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F416&data=05%7C01%7Canetaw%40microsoft.com%7Cbadfd9c224314897cb1408db08a30e27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638113268635795029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KGDkX9FlIvP2rM%2Bv8HlxqkqN8ocb0LKNtnzA8Znlubo%3D&reserved=0" data-auth="Verified" originalsrc="https://github.com/cabforum/servercert/pull/416" shash="DJKafPu2eubZIHmJ6aYVrNL35Fqy9gs39zC8e10DoI3qu+5mIqin1Ow00RbM7bVSjGDlaZryv2fXDGoiyL5VdxV74OwPPI+2b652u93Ff+n/RKi1GRSsfL3Y3L4Q8tQ5I387xWLqyemfmdfGZWtMROKFi1AguJEq6ykLvl+JWRY=" id="LPNoLPOWALinkPreview_1">https://github.com/cabforum/servercert/pull/416</a></span></span></span></span></div>
<div class="x__Entity x__EType_OWALinkPreview x__EId_OWALinkPreview_1 x__EReadonly_1">
</div>
<div class="elementToProof">Corey: We have Aneta's change, she noticed a couple fixes <span class="x_ContentPasted35" style="text-align:start; background-color:rgb(255,255,255); display:inline!important">that need to be done in the subject attributes for each
of the validation level certificate types. It i<span class="x_ContentPasted37" style="background-color:rgb(255,255,255); display:inline!important">s a good change, and it actually removes a lot of the
<span class="x_ContentPasted38" style="background-color:rgb(255,255,255); display:inline!important">
old text, it isn't really relevant anymore, because you can't put OU in subscribers' certs anymore</span>. T<span class="x_ContentPasted39" style="background-color:rgb(255,255,255); display:inline!important">his also corrects the typo here at the table header.
W<span class="x_ContentPasted40" style="margin:0px; background-color:rgb(255,255,255)">e can see the inclusion of the domain component attribute as well </span></span></span></span><span class="x_ContentPasted37" style="display:inline!important"><span class="x_ContentPasted39" style="display:inline!important"><span class="x_ContentPasted40">to
provide consistency with the other attributes. </span></span></span><span class="x_ContentPasted36" style="display:inline!important">Does anyone have any questions or comments on this change?</span></div>
<div style="list-style-type:"c) "">
<div><span class="x_ContentPasted36" style="display:inline!important">Corey: <span class="x_ContentPasted41" style="text-align:start; background-color:rgb(255,255,255); display:inline!important">All right, not hearing anything we can consider this 3rd PR approved
so we'll go ahead and get these merged into the profiles branch.</span></span></div>
</div>
</li></ol>
</div>
<div class="x_ContentPasted10 x_ContentPasted11">
<div class="x_ContentPasted11"><br>
</div>
<div class="x_ContentPasted11 elementToProof">3. Resume discussion of “Applicant” and “Applicant Representative” from BR section 9.6.3<br>
</div>
<div class="x_ContentPasted11 elementToProof"><br>
</div>
<div class="x_ContentPasted11 elementToProof">Corey: <span class="x_ContentPasted42" style="margin:0px; background-color:rgb(255,255,255)">So, just to provide some context. I do have a to do list </span>for some of the items that we identified throughout a
review of the previous sections. I will be converting those to GitHub issues for project tracking. So, we can divvy those out and <span class="x_ContentPasted43" style="background-color:rgb(255,255,255); display:inline!important">make any changes to the BRs
if necessary. <span class="x_ContentPasted44" style="background-color:rgb(255,255,255); display:inline!important">Continuing the tally here and once we complete this exercise for the BRs, I will go ahead and send that out.</span></span></div>
<div class="x_ContentPasted11 elementToProof"><span class="x_ContentPasted43" style="display: inline !important;"><span class="x_ContentPasted44" style="display: inline !important;">Corey: 9.<span class="x_ContentPasted45" style="display: inline !important;">6.3,
so we're basically at the section that defines the subscriber agreement. Essentially all the terms that need to be added to the subscriber agreement. W<span class="x_ContentPasted46" style="display: inline !important;">e're looking and seeing where the use
of the term's </span></span></span></span>applicant/applicant representative were used. <span class="x_ContentPasted48" style="display: inline !important;">If I recall correctly about a month and a half ago, we had some <span class="x_ContentPasted49" style="display: inline !important;">pretty
good, robust discussion in the previous sections, especially around the ca warranties. </span></span><span class="x_ContentPasted50" style="display: inline !important;">So, I think we'd like to continue that discussion here. S<span class="x_ContentPasted51" style="display: inline !important;">o,
we see here in the in the 1<sup>st</sup> <span class="x_ContentPasted52" style="display: inline !important;">paragraph, we do have s<span class="x_ContentPasted53" style="display: inline !important;">ome introductory text that does use the word applicant :
<i>"The CA SHALL </i><span class="x_ContentPasted54" style="display: inline !important;"><i>require, as part of the Subscriber Agreement or Terms of Use that the Applicant make the commitments and warranties in this section for the benefit of the CA, and the
Certificate Beneficiaries"</i> </span></span></span></span></span>Does anyone have any comments or questions on the use of the term here?<br>
</div>
</div>
<div class="x_ContentPasted8">
<div class="x_ContentPasted8">Ben: T<span class="x_ContentPasted55" style="background-color:rgb(255,255,255); display:inline!important">he applicant isn't bound <span class="x_ContentPasted56" style="background-color:rgb(255,255,255); display:inline!important">I
guess until they sign, and then they become the subscriber.</span></span> <span class="x_ContentPasted57" style="background-color:rgb(255,255,255); display:inline!important">So, is it better to use applicant/subscriber? T<span class="x_ContentPasted59" style="background-color:rgb(255,255,255); display:inline!important">hey
are the same entity. So, I don't know if that matters, I guess.</span></span></div>
<div class="x_ContentPasted8"><span class="x_ContentPasted57" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted58" style="background-color:rgb(255,255,255); display:inline!important">Trevoli: R<span class="x_ContentPasted60" style="background-color:rgb(255,255,255); display:inline!important">ight
after that, it says that you're supposed to make the terms of user subscriber agreement legally enforceable against the applicant not the subscriber.</span></span><br>
</span></div>
<div class="x_ContentPasted8"><span class="x_ContentPasted57" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted58" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted60" style="background-color:rgb(255,255,255); display:inline!important">Ben:
Right.</span></span></span></div>
<div class="x_ContentPasted8 elementToProof"><span class="x_ContentPasted57" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted58" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted60" style="background-color:rgb(255,255,255); display:inline!important">Trevoli: <span class="x_ContentPasted61" style="background-color:rgb(255,255,255); display:inline!important">What
is weird to me.</span></span></span></span></div>
<div class="x_ContentPasted8 elementToProof"><span class="x_ContentPasted57" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted58" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted60" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted61" style="background-color:rgb(255,255,255); display:inline!important">Ben:
I guess, you know, it's the entity, the fact that they're referred to by a different term here, <span class="x_ContentPasted62" style="margin:0px; background-color:rgb(255,255,255)">It does present an interesting l</span></span></span></span></span>egal argument
that somebody could make.</div>
<div class="x_ContentPasted8 elementToProof">Corey: <span class="x_ContentPasted63" style="background-color:rgb(255,255,255); display:inline!important">I guess is the argument being that a<span class="x_ContentPasted64" style="background-color:rgb(255,255,255); display:inline!important"> subscriber
after the certificate is issued, only then can they a</span></span>gree to these terms? </div>
<div class="x_ContentPasted8">Ben: No, I think the applicant agrees and then at some point when the certificate is issued then they are the subscriber. </div>
<div class="x_ContentPasted8">Trevoli: Don't you become a subscriber when you agree to the subscriber agreement?</div>
<div class="x_ContentPasted8"><span class="x_ContentPasted65" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted66" style="background-color:rgb(255,255,255); display:inline!important">Ben: <span class="x_ContentPasted67" style="background-color:rgb(255,255,255); display:inline!important">Yeah,
that is a good question. I don't know if we want to get wrapped around this too much. </span></span></span></div>
<div class="x_ContentPasted8">Trevoli: <span class="x_ContentPasted69" style="background-color:rgb(255,255,255); display:inline!important">So, I guess here's kind of my question Ben. </span>If you're not a subscriber until we issue a certificate then, why is
a subscriber agreement legally enforceable against the applicant? Unrelated to certificate issuance.</div>
<div class="x_ContentPasted8"><span class="x_ContentPasted57" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted58" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted60" style="background-color:rgb(255,255,255); display:inline!important">
<div style="margin:0px; background-color:rgb(255,255,255)">Ben: Once you sign an agreement, are you then the subscriber and then regardless of whether the certificate has been issued and if you had a dispute about why the CA did not issue you the certificate
or why the CA issued a certificate that was defective. How would you make that claim? Are you making a claim as a subscriber or as an applicant or doesn't really matter? <span class="x_ContentPasted70" style="background-color:rgb(255,255,255); display:inline!important">I
don't think it really matters. </span></div>
<div style="margin:0px; background-color:rgb(255,255,255)" class="elementToProof">
<span class="x_ContentPasted70" style="background-color:rgb(255,255,255); display:inline!important">Dimitris: I<span class="x_ContentPasted71" style="background-color:rgb(255,255,255); display:inline!important">t's just an additional note here, before the certificate
is issued the applicant still needs to agree on some terms about processing their personal data f</span></span>rom the CA side, so they do have some rights. Even though there's no certificate issued yet.</div>
<div style="margin:0px; background-color:rgb(255,255,255)"><span class="x_ContentPasted70" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted71" style="background-color:rgb(255,255,255); display:inline!important">
<div style="margin:0px" class="elementToProof">Clint: I think there's some parts of the Subscriber Agreement or Terms of Use that apply to the applicant, and the others that apply to the subscriber and maybe some of that apply to both. Would it help clarify
this if we let's say something like "is legally enforceable against the applicant and once or if the certificate is issued against the subscriber", just making it explicit that it's both if they both, when the certificate gets issued but it's at least the
applicant, regardless of whether the certificate gets issued?</div>
<div style="margin:0px">Corey: Wondering if the subsequent paragraphs make that clear, it says: "<i>The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant."</i> So, I guess part
of the CAs obligation is to ensure that that is legally binding. But I guess, maybe you were taking a different angle Clint?</div>
<div style="margin:0px" class="elementToProof">Clint: No, that's the sentence where I was thinking of adding the clarification, legally enforceable against the Applicant and the Subscriber or add the Applicant as a Subscriber. I don't know exactly how to phrase
that, but just to link those two, because there is kind of a transition of what this single entity is referred to.</div>
<div style="margin:0px">Corey: I see.</div>
</span></span></div>
<div style="margin:0px; background-color:rgb(255,255,255)">Ben: That's why I'm thinking putting a slash might be the best way to even though it doesn't look very good. This whole section, the title, your title is subscriber representations and warranties.</div>
<div style="margin:0px; background-color:rgb(255,255,255)">Trevoli: Well, we've already discussed, I think prior the titles of these sections here, not necessarily tethered to how we use them.</div>
</span></span></span></div>
<div class="elementToProof">Corey: Yeah, I think these section titles are coming right out of RFC3647, and then there's some liveries taken in terms of the actual content within those sections. I feel like the idea of, like applicant/subscriber maybe we could
have a defined term that encompasses both, the Applicant and the Subscriber. I don't know what you would call that, but it basically makes it clear that that's the entity that we're talking about regardless of whether or not the certificates have been issued,
a<span class="x_ContentPasted72" style="background-color:rgb(255,255,255); display:inline!important">nd that might be a little more concise <span class="x_ContentPasted73" style="background-color:rgb(255,255,255); display:inline!important">applicant slash
subscriber.</span></span></div>
<div>Trevoli: I mean, I think really for me the problem with this section it just goes back to the discussion we've had before where really over indexes on the 1st certificate.</div>
<div>Corey: Yeah.</div>
<div class="elementToProof">Trevoli: The certificates don't even live that long anymore, so I would presume that someone wants a certificate for more than a year. So, like, this whole section is probably an extremely tiny percent of the people that CAs actually
deal with. </div>
<div>Corey: Yeah, that makes sense. Is there any other comments on the 1st? Kind of skipped over the 2nd paragraph a little, I guess maybe we covered it, but
<i>"Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries either: 1. The Applicant's agreement to the Subscriber Agreement with the CA, or 2. The Applicant's acknowledgement of the
Terms of Use."</i>. I think the differentiation here is the bandwidth to a few months ago was the Terms of Use relevant to the case where the CA is also issuing end entity certificates to itself.</div>
<div class="elementToProof">Ben: So, I'm thinking that, if we have applicant on the one hand, and subscriber on the other hand and we wanted to choose 1 or the other. I'm thinking a subscriber might be better here because it just flows better, and the only
other thing that that we would get into is the question about representations and warranties are sort of made before the certificate is issued as to who they are and et cetera, and that everything's accurate in there certificate application.</div>
<div>Trevoli: I liked your 1st suggestion better Ben.</div>
<div>Ben: The slash. </div>
<div>Trevoli: Yeah, I mean, that makes it clear that we literally mean it. So, if the purpose of this section is to say, after they already have a certificate, then the CA still needs to make sure that it's legally enforceable against the Subscriber. I'm not
sure if legally enforceable against the applicant is specific to solve a problem related to before you issue them a certificate or if it really means applicant, or a subscriber there as an example, but I assume it means both. It makes sense that in the numbers
that's just the applicant. Actually, no it doesn't because you're not a subscriber till you get a certificate. So, you could probably apply for like 10 certificates and they could all be rejected, and you still wouldn't be a subscriber even though you've already
agreed to the subscriber agreement. </div>
<div>Bruce: I think you're a subscriber if you've signed the agreement. In the enterprise world I have an company sign an agreement and there can be 150 different applicants for certs, but there's only 1 subscription agreement.</div>
<div>Trevoli: Bruce, that makes more logical sense to me but that's not the definition that we have in the doc, but I would agree with you is the rational definition.</div>
<div>Trevoli: I pasted the definition.</div>
<div class="elementToProof">Bruce: We even say an applicant like it says an applicant can apply to have a certificate renewed. So, t<span class="x_ContentPasted74" style="display: inline !important;">hey're already a subscriber, but they're also an applicant<span class="x_ContentPasted75" style="display: inline !important;"> but<span class="x_ContentPasted76" style="display: inline !important;"> it
might not be the case like an applicant can have a certificate</span></span></span> renewed, but they're not the subscriber because their company is a subscriber. It is completely different for an individual than for the corporate world, but this has to cover
both.<br>
</div>
<div class="elementToProof">Clint: They tend to transpose these terms as applicant to certificate requester and subscriber to certificate recipients in my mind because like Trev was saying, it's more logical. The subscriber agreement in my mind covers things
like account access and access to portals and software and all sorts of things like that. It has nothing to do with the definition of subscriber here so there's really two definitions of subscriber that CAs are trying to meet. One in the BRs and one outside
of the BRs and it is pretty times confusing and convoluted to deal with both of those simultaneously.</div>
<div>Trevoli: Yeah, exactly. I would assume that before you issue a certificate, if you charge money for them, you've probably taken information about a payment device. So, you have made an account and you have probably applied for a subscription.</div>
<div class="elementToProof">Corey: So, in terms of next steps here, we're looking for the split between the certificate requester and the certificate recipient but really fundamentally it comes down to we don't really have a clean way of representing the case
where the entity already has a certificate but they're applying for additional certificates, and I think this is just another manifestation of that.</div>
<div class="elementToProof">Trevoli: I would say, I don't even think of it I like where Clint is going. I didn't even think of it as a certificate recipient. It's the certificate holder because it's issued, it's when they have certificates issued. So it's not
even the person that you're going to issue it from or to, it's only after they have a certificate, are they subscriber? It's just weird, but that's the words in the BRs.</div>
<div class="elementToProof">Corey: All right, so <i>"The CA MAY use an electronic or "click-through" Agreement provided that the CA has determined..."</i> . So, it's basically saying you can have a checkbox on your webpage or a flag in your API. "<i>A separate
Agreement MAY be used for each certificate request, or a single Agreement May be used to cover multiple future certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the Applicant is clearly covered by that Subscriber
Agreement or Terms of Use".</i> So, I guess it's interesting to me, it is clearly covered now. I'm not really a lawyer, but I guess that would mean that the certificate requests for subsequent certificates, the previously signed subscriber agreement is also
legally enforceable in terms of use for the additional certificates.</div>
<div>Ben: Yeah, that's how it would work. </div>
<div class="elementToProof">Clint: Yeah, I sort of read this as addressing the case that the term brought up where it's like you're an applicant every time you ask for a certificate and how does that work but they're an applicant. They get their first certificate
and that's maybe wide over indexes on first certificate because of the specs. Most CAs follow the second half of this clause of using a single agreement to cover all of the certificates they issue after the first one, as long as that agreement encompasses
the types of certificates that they're requesting on each subsequent request.</div>
<div>Trevoli: My two suggestions maybe making us more clear as spins for suggestion of just putting the applicant slash subscriber everywhere pretty much where it's like the same thing, or just literally split the section up into two sections. The first time
an entity or an applicant gets a certificate from a CA, blah, blah, blah to all of this stuff and then say like thereafter. After whatever do all this stuff with the subscriber, you could just rewrite the section to be clear. Maybe we specifically would want
to say that there's some rules related to how you change the subscriber agreement if someone's already a subscriber. I don't want to do anything extra, but I'm just throwing it out there. Maybe you want to do that, but the easiest thing would probably say
applicant versus subscriber.</div>
<div class="elementToProof">Corey: Maybe the splitting of the different sub sections and division of obligations to the first one and the subsequent certs. if we take a look at the required terms that we have to have within a subscriber agreement, maybe we
can see if there would be value in splitting those out. <br>
</div>
<div>Trevoli: Yeah. </div>
<div>Corey: All right. So, we're seeing that <i>"The Subscriber Agreement or Terms of Use Must contain provisions imposing on the Applicant itself (or made by the applicant on behalf of its principal or agent under a subcontractor or hosting service relationship
the following obligations and warranties".</i> There is that hosting service relationship again we've seen that in a couple other places in the BRs. "<i>1st Accuracy of Information: An obligation and warranty provide accurate and complete information at all
times to the CA, both in the certificate requests and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA. 2nd Protection of the Private Key: An obligation and warranty by the Applicant to take all
reasonable measures to assure control of, keep confidential, and properly protect at all times the Private key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or
token); The 3rd, The Acceptance of the Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;"</i> </div>
<div class="elementToProof">Ben: Did you notice the switch?</div>
<div>Corey: Yes, and I'm wondering if that's because once they accept the certificate since the certificates been issued, they are now a subscriber as opposed to an applicant Tobias: And there is a definition in 1.6.1 that says exactly that.</div>
<div>Clint: Yes, so kind of goes back to my earlier point a subscriber agreement covers both applicant and subscriber, so to transplant, maybe that's the simplest thing is you just put applicants slash subscriber in a couple of locations where it's clearly
intended to apply to both.</div>
<div class="elementToProof">Tobias: It's the same entity. It's just different roles but they fill in the interaction. I mean the definition in 1.6.1. says : "<i>The natural person or legal entity that applies for (or sees renewal of) a Certificate. Once the
Certificate is issued, the Applicant is referred to as the Subscriber".</i> So, it's the same entity and you can be an applicant while you're a subscriber in relation to another certificate.</div>
<div class="elementToProof">Corey: All right, so it looks like for this particular sub item for number 3 it looks like we might want to consider and the other items as well, the applicants slash subscriber just to cover the case where certificates have previously
been issued. It's clear that these obligations are relevant to them. Is there any comment on
<i>Accuracy of Information and Protection of private key?</i> All right, moving on to use the cert,
<i>"Use of Certificate: An obligation and warranty to install the certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate, solely in compliance with all applicable laws and solely in accordance
with the Subscriber agreement or Terms of Use".</i> Rather interesting requirement, I think. I suppose that's some type of mitigation against fishing, but if you have a server misconfiguration and add a new host name for your server or you delete a host name
from your server. You reconfigure your servers such that your certificate installed where it's not with one of the subjectAltNames, this is no longer relevant technically violating subscriber agreement, which is rather interesting.</div>
<div class="elementToProof">Clint: Even just the word installed a certificate, it's just a file sitting there. Did I transfer the file on the server? Is that installed? Is it configuration? This one seems a little bit wonky.<br>
</div>
<div class="elementToProof">Trevoli: Yeah, I was wondering too that things like that do not work. <span class="x_ContentPasted77" style="background-color:rgb(255,255,255); display:inline!important">Just like, I do not know, maybe it used to work in the olden
days whenever this was written.</span></div>
<div>Ben: Do we want to put a flag on this and come back to it another day? This is something we should really look into. </div>
<div>Clint: The second part seems fine. It's just the first part, right?</div>
<div>Trevoli: The second part seems totally logical. </div>
<div>Ben: Well, the first part probably came from somewhere that had some other language and then we replaced server with servers and subjecAltNames. This idea came from somewhere and was modified for this purpose.</div>
<div>Tobias: I would be fine with removing the 1st part.</div>
<div>Trevoli: Yeah, let's make it a to do. Let's just remove the first sentence. </div>
<div>Corey: Yeah, I'm adding it right now.</div>
<div>Trevoli: You can easily just put that in your subscriber agreement as well.</div>
<div>Tobias: And also, why would you?</div>
<div>Trevoli: I totally agree. I'm just saying if it's super important to you. You could put it in there.</div>
<div>Corey: The CA specific term you mean?</div>
<div class="elementToProof">Trevoli: Yes. You know, if you're like paranoid people are going to install a certificate on a server where they won't work on you care about that.</div>
<div>Corey: All right, for the fifth item, we have: "<i>Reporting and Revocation: An obligation and warranty to: a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse
or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;
".</i>On the first read, I think it sounds pretty reasonable. Did anyone have any comments on that one?<br>
</div>
<div class="elementToProof">Tobias: We discussed this right and it's rather obvious that we can't actually expect any subscriber to do this. No, at least not a high percentage of them. I think it's more than that gives us a legal reason to act in case something
like this happens.</div>
<div class="elementToProof">Trevoli: Isn't that the entire purpose of this? On the off-chance CA decides to sue someone. </div>
<div>Tobias: Yeah, exactly. No, besides it is just basically so then the CA can revoke.</div>
<div>Trevoli: Yes, this exists just so we can say like tough. We're rocking it. You agreed to it.</div>
<div>Corey: All right, <i>"Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise."</i></div>
<div>Trevoli: Yes, I would say, totally, I want to talk about things that probably will never happen. It is 6.</div>
<div>Corey: Yeah, especially since it hard to say every use of the private key. So, even if you have like a cert issued off a private PKI. It just so happens to certify the public key for that compromised private key technically according to this, you have
to stop using that cert too. I'm not sure if we want to do anything about that but I guess those are the rules.</div>
<div class="elementToProof">Trevoli: I only care about doing something about it if someone is going get mad, if a CA decides not to ever go after this or enforce it. </div>
<div class="elementToProof">Corey: <span class="x_ContentPasted78" style="background-color:rgb(255,255,255); display:inline!important">
All right, given the lack of a</span>ny strong desire to modify these things, moving on to
<i>"Responsiveness: An obligation to respond to the CA’s instructions concerning Key Compromise or Certificate misuse within a specified time period"</i>. </div>
<div class="elementToProof">Trevoli: <span class="x_ContentPasted79" style="background-color:rgb(255,255,255); display:inline!important">
It seems like the same as 5 </span>except that I doubt anyone could reasonably put in there and you need to respond if we tell you on a day that your company is closed for key compromise you need to respond to us.</div>
<div>Corey: 24 hours, for certain subscribers, I imagine that is probably next to impossible in certain circumstances.</div>
<div>Tobias: It's the same thing I didn't really like it, but a certificate is revoked if there is no response. </div>
<div>Corey: All right, <i>"Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation
is required by the CA’s CP, CPS, or these Baseline Requirements.". </i>So, I think this is kind of just the cover all for all the things that we just discussed. </div>
<div>Clint: It seems like one of the more important ones to have. </div>
<div class="elementToProof">Corey: Yes, I think this was actually added at some point, I think it was SC-30 or SC-31. It was like clean up some clarifications ballot about a couple of years ago, I think it was added. All right, any further discussion on 9.6.3?
if not, I think we are getting close to the end. We'll go to jump in at 9.8, really quick to see if there's anything relevant here. "<i>If the CA has not issued or managed the Certificate in compliance with these Requirements and its Certificate Policy and/or
Certification Practice Statement, the CA MAY seek to limit its liability to the Subscriber and to Relying Parties, regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered as a result of the use or reliance
on such Certificate by any appropriate means that the CA desires."</i> Any other comments on that particular passage? </div>
<div class="elementToProof">Trevoli: If the lawyers don't care about it, I don't care about it. </div>
<div class="x_ContentPasted80">Corey: Yeah, clearly an engineer wrote this passage. Indemnities: "<i>Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers
who have a Root Certificate distribution agreement in place with the Root CA do not assume any obligation or potential liability of the CA under these Requirements or that otherwise might exist because of the issuance or maintenance of Certificates or reliance
thereon by Relying Parties or others."</i> I don't think this is directly relevant to what we were looking at, or what we are scanning for. <span class="x_ContentPasted81" style="background-color:rgb(255,255,255); display:inline!important">Any discussion on
this?</span></div>
<div class="x_ContentPasted80 elementToProof">Ben: Just like a flag for everyone to put in their hat and that is that at some point, I'm going to want to revise this because Mozilla doesn't have Roots certificate distribution agreements in place. We agree to
distribute, but we don't have an agreement in place. It's not really an agreement. We can take it, so we would like to be identified despite this provision, or we would like to revise this, so that it says something other than having a root certificate distribution
agreement in place.<br>
</div>
<div class="elementToProof">Tobias: You talk to your legal department they will probably, but I don't know, but time they might say something like, it doesn't look like an agreement, but it is an agreement.</div>
<div>Ben: Well, we don't have one so that is just an FYI, m<span class="x_ContentPasted82" style="background-color:rgb(255,255,255); display:inline!important">ake a flag thanks</span>.</div>
<div class="elementToProof">Corey: Thanks, Ben. Yeah, I think some root programs they do have. I think Microsoft, they stated publicly they do have such agreements in place.</div>
<div>Ben: This was really written for Microsoft's benefit.</div>
<div>Corey: I see. Okay, well, that makes sense then.</div>
<div class="elementToProof">Dimitris: Especially if you look at the second part. It has actually allowed subscribers/relying parties to file claims against the application software suppliers. They directly cause a certificate to be displayed as not trustworthy.
It looks like it probably came from the eighties or something.</div>
<div class="elementToProof">Ben: I don't think we talk about subscriber indemnities. Most CAs probably in their sections of their cps's would say subscribers or applicants are supposed to indemnify CAs for misrepresentations. if you're the victim of an imposter
you don't have to get to indemnify because you're not really the party that made the allegations or made the representations to obtain the certificate, but if you were able to get that person that applicant who wasn't really the lawful person then you could
go after them for some kind of misrepresentation unless they are judgement proof, or you can find them.<br>
</div>
<div class="elementToProof">Dimitris: I think other than Microsoft, other root programs don't have a specific agreement signed, so you're holding the same boat. </div>
<div class="elementToProof">Ben: W<span class="x_ContentPasted83" style="background-color:rgb(255,255,255); display:inline!important">hat happens is a lot of CAs will just copy this language
</span>into their CP and CPS and I will make a comment that we don't like that language because we wanted to cover us too, so I'll have them replace the contract language with something more vague.</div>
<div>Trevoli: Well, let's definitely update it then it's going make everyone change it in their CP if it's in their CP. Action item that's what I got out of this.</div>
<div>Corey: So, it looks like Ben, you'll be driving this change.</div>
<div>Ben: Yes, when I find time. Okay, it's not a high priority. It's a back burner. </div>
<div>Corey: All right, I think we are at the end. I think we made it all the way through the BRs and we have quite a to do list here that probably has at least a dozen items in it. So, I will clean up that list and circulate it before the next call and then
we can start identifying the high priority items that we'd like to address through this work. So, I think this is a good exercise, at least in my case, I wanted a couple of things from this close reading of the BRs I hope, you know, everyone else did as well.
So, I think this is a good exercise. We just have to take the next steps.</div>
<div class="elementToProof">Doug: Quick question on that, how does this ballot going to relate to the profiles ballot? Is it going to be an add on to the profile's ballot? How are we going to roll this out? </div>
<div>Corey: This is an entirely different effort. There is not a lot of clarity right now in the BRs in terms of the difference between an applicant and a subscriber and some of the obligations relating to the CAs. So, this is an entirely different effort from
profiles ballot. This is kind of like another major piece of work that we would like to tackle.</div>
<div class="elementToProof">Trevoli: I would hope that we don't do it as one ballot unless we identify places where that makes sense, but it seems like a lot of the action items were kind of disparate to a section, some of them.<span class="x_ContentPasted84" style="background-color:rgb(255,255,255); display:inline!important"><span class="x_ContentPasted84"> </span>So,
like case by case. </span></div>
<div>Doug: So, when you do a ballot, it'll be based on the baseline of the proposed ballot. <span class="x_ContentPasted85" style="background-color:rgb(255,255,255); display:inline!important">You see what I mean, there might be conflicting changes.</span></div>
<div>Trevoli: Yeah, so not optimistic. I am optimistic that we will pass the certificate profiles ballot, and that will be the official BRs before we even get to writing up a ballot for one of these changes, I believe in us.<br>
</div>
<div class="elementToProof">Doug: Okay, that answers my question. Yeah, yeah, I know the motivation for the profiles pilot. </div>
<div class="elementToProof">Corey: I think in this case, though what was nice about this work is that it largely doesn't touch section 7. I think we all want the profiles ballot to pass, and it sounds like there's good agreement and good consensus on the content.
I see this work is largely independent of that, just given that we're touching different parts of the BRs for this work. I think section 7, I don't think had really anything a substance in terms of this analysis. All right, so I will take an action item prior
to the next call to circulate the to do list and we'll go ahead and discuss and identify the higher priority items that we want to address first for this. Thank you everybody. I think we have about just one minute left, so we'll just wrap up now. The next
meeting will be February 9th.</div>
<div>Dimitris: Cory, just for the next agenda, we should start discussing items for the F2F.</div>
<div class="elementToProof">Corey: You're right, that's only a month away. Yes, we'll definitely do that. Thank you everybody.</div>
</div>
<br>
</div>
<div class="x_elementToProof elementToProof ContentPasted0" style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<b>Meeting adjourned.</b><br>
</div>
<div class="x_elementToProof">
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div id="x_Signature">
<div></div>
<div></div>
<div style="margin-top:16px; margin-bottom:16px" class="elementToProof"><span style="font-size:12pt"><span style="margin:0px; font-size:14px; color:rgb(0,0,0); text-align:start; background-color:rgb(255,255,255)"><font color="#000000" face="Calibri, Helvetica, sans-serif" style="color:rgb(0,0,0)"><span style="margin:0px; font-size:14.6667px">Thanks,<br>
</span></font></span></span></div>
<div style="margin-top:16px; margin-bottom:16px" class="elementToProof"><span style="font-size: 14.6667px;">Aneta</span></div>
</div>
</div>
</div>
</body>
</html>