<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=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;}
@font-face
{font-family:"Calibri Light";
panose-1:2 15 3 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
h2
{mso-style-priority:9;
mso-style-link:"Heading 2 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:18.0pt;
font-family:"Calibri",sans-serif;
color:black;}
h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
margin-top:2.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
page-break-after:avoid;
font-size:12.0pt;
font-family:"Calibri Light",sans-serif;
color:#1F3763;
font-weight:normal;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
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;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-family:"Calibri",sans-serif;
color:black;
font-weight:bold;}
span.Heading3Char
{mso-style-name:"Heading 3 Char";
mso-style-priority:9;
mso-style-link:"Heading 3";
font-family:"Calibri Light",sans-serif;
color:#1F3763;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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:779183899;
mso-list-template-ids:2003088332;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:973365964;
mso-list-template-ids:351933290;}
@list l2
{mso-list-id:1500274073;
mso-list-template-ids:-61458528;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3
{mso-list-id:1798832464;
mso-list-type:hybrid;
mso-list-template-ids:253637518 -677244322 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l3:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-bidi-font-family:"Times New Roman";
color:black;}
@list l3:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l3:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l3:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<div>
<div>
<div>
<p class="MsoNormal">These are the draft minutes of the teleconference described in the subject of this message as prepared by Michael Slaughter (Amazon).<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Please review the minutes and propose edits if necessary. These minutes will be considered for approval at the next meeting. The recording of the meeting will be deleted once the
minutes are approved.<o:p></o:p></p>
<h2>Attendees (in alphabetical order)<o:p></o:p></h2>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Wayne Thayer, Tim Hollebeek, Amanda Mendieta,, Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Clint Wilson, Corey Bonnell, Daryn Wright, Dimitris
Zacharopoulos, Doug Beattie, Dustin Hollenback, Enrico Entschew, Iñigo Barreira, Janet Hines, Joanna Fox, Johnny Reading, Jose Guzman, Kati Davids, Martijn Katerbarg, Michael Slaughter, Niko Carpenter, Paul van Brouwershaven, Pekka Lahtiharju, Rebecca Kelley,
Ryan Dickson, Ryan Sleevi, Stephen Davidson, Thomas Zermeno, Trevoli Ponds-White, Tyler Myers and Wendy Brown.<span class="apple-converted-space"> <o:p></o:p></span></span></p>
<h2>Agenda<o:p></o:p></h2>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraphCxSpFirst" style="margin-left:0in;mso-add-space:auto;mso-list:l3 level1 lfo3">
<span class="apple-converted-space">Nomination of Corey as Validation Subcommittee Chair<o:p></o:p></span></li><li class="MsoListParagraphCxSpMiddle" style="margin-left:0in;mso-add-space:auto;mso-list:l3 level1 lfo3">
<span class="apple-converted-space">Method 7, when the CA is involved (Amazon)<o:p></o:p></span></li><li class="MsoListParagraphCxSpLast" style="margin-left:0in;mso-add-space:auto;mso-list:l3 level1 lfo3">
<span class="apple-converted-space">Mozilla Compliance Self-Assessment <o:p></o:p></span></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo3">
CRL validity period ballot (SC52) <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo3">
<span style="color:black">Unicode usage - Script spoofing, symbols and other characters</span><o:p></o:p></li></ol>
<h2>Minutes<o:p></o:p></h2>
<h3 id="preparation"><b><span style="font-family:"Calibri",sans-serif;color:black">Preparation<o:p></o:p></span></b></h3>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo6">
The recording started <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo6">
Roll call was taken by Tim <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo6">
The antitrust statement was read by Tim <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo6">
Minute taker was assigned (Michael Slaughter)<o:p></o:p></li></ul>
<h3><b><span style="font-family:"Calibri",sans-serif;color:black">1. Nomination of Corey as Validation Subcommittee Chair <o:p></o:p></span></b></h3>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Tim proposed naming Corey Bonnell as the new chair of the validation subcommittee.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><br>
Wayne endorsed Corey and offered to continue to serve<span class="apple-converted-space"> </span>the committee in a supporting role.<br>
<br>
Tim asked if the group would be comfortable confirming Corey as chair through consensus given the large attendance on the call. Dimitris responded that consensus is fine.<span class="apple-converted-space"> </span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><br>
Corey Bonnell was named chair of the Validation Subcommittee. Congratulations Corey!<span class="apple-converted-space"> </span><o:p></o:p></span></p>
<h3><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></h3>
<h3><b><span style="font-family:"Calibri",sans-serif;color:black">2. Method 7, when the CA is involved (Amazon)<o:p></o:p></span></b></h3>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">Tim started the discussion by asking if Trev would like to comment on the discussion taking place in the e-mail thread with subject: “[cabf_validation] Method 7, when the CA is involved”.<span class="apple-converted-space"> </span><br>
<br>
Trev asked Doug for confirmation that his question on the mailing list regarding how private keys are handled in AWS was addressed which Doug affirmed. Trev then asked why the inability to export a private key from AWS mattered in the context of the e-mail
thread.<br>
<br>
Ryan S. clarified that it used to matter because the revocation requirement was that the applicant and subscriber must not share a private key. Ryan S. further explained that the rule did not work for CDNs and was fixed in the BRs but Amazon’s policies pre-date
that. The key point is that in the case of Amazon, AWS is the subscriber and AWS is abiding by the agreement as opposed to ATS (Amazon Trust Services) performing the validation itself.<span class="apple-converted-space"> </span><br>
<br>
Dimitris said that we have previously discussed that there is not a meaningful difference between an applicant or subscriber delegating the CNAME to a CA, a third-party or a reseller for the purpose of domain validation. Dimitris noted that while subscriber
agreements require two parties thus preventing a CA from signing its own agreement, there is nothing that would prevent a CA from creating a third-party entity and affiliate to effectively accomplish the same thing.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. agreed that there are loopholes and referenced prior discussions around a reseller that e-mailed DigiCert private keys that went into the boundary of a CA’s obligation. He said that when it comes to the validation process, what matters is that it is
the applicant that needs to demonstrate control and that it is important for the applicant to have the challenge values required to perform that demonstration of control. While there are third parties, applicant representatives and entities with signing authority,
whatever the model it is the applicant that needs to perform the validation. The line between a CDN and reseller is something that the BRs have not tackled but the question of the CA performing the validation should be clearer because it comes down to the
question of is the applicant demonstrating control.<br>
<br>
Dimitris responded that if the applicant delegated their DNS to the CA then it would be identical to delegating DNS to a CDN or a reseller.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. replied that the difference is that when it comes to a CDN or reseller it is not the applicant providing the “random value” to itself.<span class="apple-converted-space"> </span><br>
<br>
Dimitris agreed and said that the issue exists with the method itself. If we can delegate the CNAME to another entity then it is not the applicant that is demonstrating control.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. said that 3.2.2.4 is defining a protocol where there’s a secret value that is constructed by the CA which is then reflected by the applicant to CA that confirms the value. The intent here is that whatever channel that the applicant is using to request
the certificate from the CA they use that same channel to reflect that secret back to the CA. The notion of the CA asking themselves for a secret that the CA knows creates a disconnect because that’s breaking part of the protocol leg. If the applicant gives
their secret to someone else to prove things that’s also different. In the situation of CNAME delegation, we are saying that the applicant is not in possession of the secret themselves. There is no authentication of that request using that secret which is
the issue and why it’s prohibited.<span class="apple-converted-space"> </span><br>
<br>
Corey noted that the BRs are little bit confusing when it comes to defining random values vs. random tokens. Certain validation methods such E-MAIL require secret values while other methods such as DNS or HTTP validation do not require that value to remain
secret.<span class="apple-converted-space"> </span><br>
<br>
Tim agreed and said that the there was a proposed ballot in the past that would have clarified the definition of the random value and random token by using different terms since they have very different security properties. Tim indicated that he would like
to revisit that and fix it at some point.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. said this discussion reminds him of past discussions around Peter Bowen’s proposed method “3.2.2.4.13” also known as the “DNS operator exception for non-DNS operators“. That exception, which was discussed at the Herndon, VA F2F, allows a CA that is
also a registrar can use the fact that a certificate request comes from the same account that is bound to the DNS.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. said that the question being asked here is whether we are trying to validate a certificate request or are we trying to validate a relationship with a CA that allows all requests. The conversations in the past couple of months have focused on binding
to an account which suggests that the authorization is not for a request. Recent changes to 3.2.2.4 such as shortening the reuse period of a validation however, indicate explicitly that these are intended to be request authorizations. Are you authorizing certificate
requests or are you authorizing certificate accounts? This is the tension that is underplaying some of the issues here.<span class="apple-converted-space"> </span><br>
<br>
Tim responded that it ultimately comes down to what do we want. What does ownership or control mean? The dealing with Random Value performs the same role by verifying that the delegation still exists which is an important security property. It’s worth actually
writing down the security analysis of some of these proposed methods and figuring out if they actually do what we want or if they don’t do what we want instead of just hand waving about general principles.<span class="apple-converted-space"> </span><br>
<br>
Wayne said that he agrees that the core problem here is whether we’re delegating to what Ryan S. referred to as an account or what I consider permanent domain control approval or whether it’s something that we have to repeat every time. Wayne said that there
are benefits to automation when someone can authorize a domain on an ongoing basis and not have to touch it every time to do a renewal. Wayne continued that obviously there are ways that they can automate the process but being able to set a CAA record that
says I authorize this CA to issue certs for my domain as a domain validation process is worth talking about but is unclear if we’re open to trying to do that or not.<span class="apple-converted-space"> </span><br>
<br>
Trev asked Wayne to clarify if by permanent, he intended to say revokable which Wayne confirmed he did. Trev continued on to say that the methods are oriented towards validating each request and agrees that it is not great for automation. Trev asked if we are
interested in having the ability to for people to be able to say “I would like to delegate until such time” and “I no longer want to delegate”.<span class="apple-converted-space"> </span><br>
<br>
Wayne asked if we next write-up a domain validation method that relies on a CAA extension that stays in effect as long as the domain controller leaves it there.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. said that may be interesting but there are a number of complexities including Trev’s point about making the persistent delegation revocable and various CA security implications. Ryan S. said that you want the CA to check for the value prior to every
issuance and not rely on a one year thing which is not something that is provided for in 3.2.2.4 today. Ryan S. agreed that it is worth at least discussing what we would like to have and figure out how to fit that in if that is what we want.<span class="apple-converted-space"> </span><br>
<br>
Wayne said noted that the BRs don’t do a good job of distinguishing between an applicant and when the CA is the applicant. Wayne asked when CNAME delegation is performed by the CA when issuing certificates for itself, is that an example of CA delegation to
the CA or does that mean they’re verifying controls from the actual applicant?<span class="apple-converted-space"> </span><br>
<br>
Tim affirmed the latter and agreed that the lack of clarity in the BR around a CA issuing certificates for itself is a major problem. Tim said that they treat themselves as an applicant when appropriate and as the CA when appropriate in that self-issuance scenario.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. said that applicant is the entity that controls or operates the device named in the certificate. In the situation of DigiCert issuing certificates for<span class="apple-converted-space"> </span></span><a href="http://digicert.com/">DigiCert.com</a><span style="color:black">,
DigiCert is the applicant since they’ve agreed to a “terms of use” because they are an affiliate of the C A - because they are the CA. Ryan S. said it gets messy when it comes to the definition of subscribers versus applicants but agreed with Dimitris’ point
that it comes down to figuring out who is agreeing to the contract.<span class="apple-converted-space"> </span><br>
<br>
Wayne said that if a site was hosted by Google in Google Cloud Services with a certificate issued by Google Trust Services you could argue that Google Cloud is the applicant and Google Trust Services is the CA but you could also argue that they’re really the
same entity. This presents another gray area wanted to see if other people are concerned.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. said that he was deeply concerned about that aspect and that it came down to determining who was the applicant and applicant representative in this situation that is agreeing to the subscriber agreement. Ryan S. said that the Google Cloud team held
a lot of conversations and deep dives to ensure that Google Cloud was also going to abide by the BRs in the design.<span class="apple-converted-space"> <o:p></o:p></span></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<h3><b><span style="font-family:"Calibri",sans-serif;color:black">3. - Mozilla Compliance Self-Assessment <o:p></o:p></span></b></h3>
<p class="MsoNormal"><span style="color:black">Wayne introduced the topic by explaining that the Mozilla compliance self-assessment was recently updated and had some questions that made him wonder if things have changed since they were originally implemented
when compared to the stricter more literal interpretation that we have taken BRs over the past three to four years. The most glaring example is section 3.2.2.4 which was modified three or four years ago to say “CAs shall maintain a record of which domain validation
method was used including the relevant BR version number”.<span class="apple-converted-space"> </span><br>
<br>
Wayne said what a pain it would be if that literally meant the CAs had to update their system to log a new BR version every time the version number of the BRs changed. Wayne said that he knows a number of CAs are not literally logging the relevant BR version
number and asked if we need to do something about that. Wayne said that looking at the questions Mozilla asked made him question if he could really say he met the rule.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. asked why wouldn’t CA log the BR version number and be able to support retroactive explorations to identify the version of the BRs the system was assessed against at a given point in time.<span class="apple-converted-space"> </span><br>
<br>
Trev responded that a CA wouldn’t necessarily make a change in their system for every ballot using the Spring cleanup ballot as an example since that would only impact processes outside of the system.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. responded with a question about why CAs would not maintain a global state tracker for such situations.<span class="apple-converted-space"> </span><br>
<br>
Tim said that the important point is the goal here and that a lot of CAs are interpreting the goal of the requirement as the CA must be able to determine which version of the BRs was in effect at the point in time when an issue occurred. Tim said this does
not require a CA to have a database table entry with a BR version for every certificate and that a lot of CAs have interpreted the requirement as having the ability to figure that out for every single certificate.<span class="apple-converted-space"> </span><br>
<br>
Wayne agreed with Tim on how it was interpreted 3 to 4 years ago and asked if that interpretation was still valid.<span class="apple-converted-space"> </span><br>
<br>
Ben called out that the process that we’ve adopted now is to adopt a new number and retire the old number.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. said that the reason why we have version number was to figure out situations where there’s an interpretation issue with related sections such as the reuse period. The intent was to capture not only the method used but also the underlying assumptions.
That information should be readily accessible and queryable particularly for incidents.<span class="apple-converted-space"> </span><br>
<br>
Tim said to no confuse method and BR version. The method needs to be recorded because it can be hard to figure that out but the fact is there is only one relevant version of the BRs at any given point in time.<span class="apple-converted-space"> </span><br>
<br>
Dimitris added that it’s even more complicated because the CA must keep track of the BR version at both the time of validation and the time of issuance.<span class="apple-converted-space"> </span><br>
<br>
Trev said that she is wondering about how quickly would the CA need to push that version number and asked if timing considerations are part of the goal. She added that if we start to get too specific about expecting these things and doesn’t want to get into
another “one-second over” discussion because the requirements are unclear.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. agreed with Trev and Dimitris and said that if there are ambiguities then we should absolutely resolve them in a safe way that doesn’t cause a bunch of need for revocations.<span class="apple-converted-space"> </span><br>
<br>
Tim said that he was assuming when CAs reuse validations they know the exact time and date where the previous validation was performed. It occurs to me that some CAs might not be doing that. If you are not doing that you are in for a world of hurt, so please
do that.<span class="apple-converted-space"> </span><br>
<br>
Wayne asked if we want to do anything about the language “CAs shall maintain a record of which domain validation method including relevant BR version number they used to validate every domain.” or assume that the language is fine.<span class="apple-converted-space"> </span><br>
<br>
Tim said that the language might be too specific and recommended that we start an e-mail thread for more discussion on the topic.<span class="apple-converted-space"> </span><br>
<br>
Wayne took the action to start the e-mail thread.<span class="apple-converted-space"> </span></span><o:p></o:p></p>
<h3><b><span style="font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></b></h3>
<h3><b><span style="font-family:"Calibri",sans-serif;color:black">4. CRL Validity Ballot (SC52)<o:p></o:p></span></b></h3>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">Wayne said we should restart the ballot.<span class="apple-converted-space"> </span><br>
<br>
Tim said that he knows that people have opinions and agreed that the discussion should be moved to the list.<span class="apple-converted-space"> <o:p></o:p></span></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<h3><b><span style="font-family:"Calibri",sans-serif;color:black">5. Unicode usage - Script spoofing, symbols and other characters<o:p></o:p></span></b></h3>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black">Paul introduced the topic by saying that he shared a report he generated on the list about some issues he detected within subject DNs in relation to the
issue from Sectigo on Mojibake encodings or characters in the certificate. Paul said he identified a number of things that don’t look good but aren’t strictly prohibited. This includes Unicode replacement characters, non-principal or zero wide spaces and other
characters that clearly do not belong within the organizational name. There are also more advanced issues such as the mixing of scripts such as Greek and Latin.<span class="apple-converted-space"> </span><br>
<br>
Paul asked the validation working group if this is something we care about and want to address or do we want to have some guidelines around these encoding issues?<br>
<br>
Tim said that it’s vaguely complicated since some of these things are potentially okay but they’re also within spitting distance of security issues.<span class="apple-converted-space"> </span><br>
<br>
Paul said that some problems are clearly not okay. Unicode characters should not be in any string and the zero white space character has no meaning within any printed text.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. asked if the characters are in the authorized data set. Using EV as an example, if it from the registration authority is that ok? “Garbage in, garbage out” but that’s an upstream problem.<span class="apple-converted-space"> </span><br>
<br>
Tim said it’s similar to the “companies house” example. If I register backslash in companies house as my company name is that now my legitimate company name.<span class="apple-converted-space"> </span><br>
<br>
Ryan S. to the extent that we accept companies house as a legitimate data source. The question is if this is in the authorized data set. The examples that Paul as raised may indicate that there are breakdowns in CA pipelines or it may indicate that registration
agencies are sloppy or liberal and to the extent that we respect the sovereignty of those registration agencies, maybe that’s not our problem. I guess the question is if we tackle this by ensuring that there’s a consistent understanding of what a reliable
data source is in the case of OV and what a qualified QGIS/QIIS means in the case of EV then maybe this problem becomes a flag that says you have an ingestion problem but if that is what upstream says, then that is what upstream says.<span class="apple-converted-space"> </span><br>
<br>
Tim asked Paul if he wanted to make it a mini-project to figure out what’s good and what’s going on here.<span class="apple-converted-space"> </span><br>
<br>
Paul said even if businesses provide data that is encode with errors should we ignore those errors or should we encode our systems to say well this is not the proper data so we can’t accept it. That stance might prevent that subscriber from getting a certificate
or going back to their business registration to get information updated.<span class="apple-converted-space"> </span><br>
<br>
Tim said those actions might take some time and they might be facing a renewal. We would have to think carefully about the consequences of how we face this.<br>
<br>
Ryan S. said that on a technical level as the only thing that matters here is the domain. These have no bearing on a TLS connection so there is a compelling argument that says if these are aligned with upstream then that’s great and if we have a consistent
understanding of upstream then we can revisit the question of if those sources are appropriate. Ryan S. said I can appreciate challenging the authority based on the quality but to get there first we have to enumerate who the authorities are.<span class="apple-converted-space"> </span><br>
<br>
Tim agreed with Ryan S. and said that the first step is making sure that everybody moves in the direction of better agreement with the upstream sources.<br>
<br>
Next meeting is January 27th and will be run by Corey.<span class="apple-converted-space"> </span><br>
<br>
<b>Adjourned.</b></span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span class="apple-converted-space"><span style="color:black"><o:p> </o:p></span></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>