<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
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;
font-weight:bold;}
h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:13.5pt;
font-family:"Calibri",sans-serif;
color:black;
font-weight:bold;}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-family:"Calibri Light",sans-serif;
color:#2F5496;}
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.EmailStyle25
{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:603999366;
mso-list-type:hybrid;
mso-list-template-ids:-1332812158 644644462 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@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:700283067;
mso-list-template-ids:-685506320;}
@list l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l2
{mso-list-id:859589597;
mso-list-template-ids:539255762;}
@list l3
{mso-list-id:1822456361;
mso-list-template-ids:-1779009068;}
@list l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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;}
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 bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='color:windowtext'>Hi Corey and all,<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>I’d like to revisit the balloting discussion/approach for the profile updates that were discussed in the below meeting. <o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>I’m concerned about being compliant with 1 of 2 versions of the BRs (CAs can pick and choose?) and how we address updates (especially updates outside the profiles section) between the ballot being approved and the effective date.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Do we really want to permit an older version of the BRs to be considered valid and auditable when there are newer versions? That goes against “CAs must comply with the latest version of the BRs”. I’d much prefer a single stream of updates where CAs are audited against the latest one only as we have done historically.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Could we consider placing the new section 7 in a new appendix, Appendix C, and keeping the current section 7? We could state that this becomes effective on <date> and CAs are encouraged to start complying with this sooner. CAs may be compliant with section 7 and/or Appendix C during this time. O the effective date we have a new ballot that moves Appendix C into Section 7.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Another alternative is to highlight each and every “material” change with specific effective dates - ugly<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>I’m not a huge fan of some of these statements in the meeting notes which triggered this email, including:<o:p></o:p></span></p><ul type=disc><li style='mso-list:l0 level1 lfo4'>Dimitris said that the BRs say that CAs must always comply with the latest version. Tim said that if auditors asked, we would point to explicit text of the latest BRs that says you may comply with a previous version.<o:p></o:p></li><li style='mso-list:l0 level1 lfo4'>Wayne said that we need to confirm that something in the new profiles is not prohibited by the old profiles. Tim replied that he doesn't think this is the case and Wayne suggested we add a sentence to state that clearly for readers as for the intent.<o:p></o:p></li><li style='mso-list:l0 level1 lfo4'>Wayne says that CAs could pick-and-choose which corrupts the interpretation of the new changes. CAs should either comply entirely with the old or entirely with the new profiles. That might eliminate some of the risk of pick-and-choose. The implementation time period is relatively short so it's not a huge risk and would only apply for 6 months<o:p></o:p></li><ul type=circle><li style='mso-list:l0 level2 lfo4'>Doug: Don’t we want CAs to start complying with the new profiles sooner vs. later, but if they need to be compliant 100% with the old <b>or</b> new, then that means CAs must implement all changes on the same day. Am I reading this correctly?<o:p></o:p></li></ul><li style='mso-list:l0 level1 lfo4'>Tim considers that everything in the new profiles is not considering anything done in the previous profiles as "illegal". Wayne said that we need to confirm that something in the new profiles is not prohibited by the old profiles. Tim replied that he doesn't think this is the case and Wayne suggested we add a sentence to state that clearly for readers as for the intent<o:p></o:p></li></ul><p>If this is worth discussing (again), then could we add this to the agenda for this week’s call?<o:p></o:p></p><p>Doug<o:p></o:p></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='color:windowtext'>From:</span></b><span style='color:windowtext'> Validation <validation-bounces@cabforum.org> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Validation<br><b>Sent:</b> Thursday, November 25, 2021 12:39 PM<br><b>To:</b> validation@cabforum.org<br><b>Subject:</b> [cabf_validation] Draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - November 18, 2021<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><br>These are the Draft Minutes of the Teleconference described in the subject of this message as prepared by Dimitris Zacharopoulos (HARICA).<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 id=attendees>Attendees (in alphabetical order)<o:p></o:p></h2><p>Amanda Mendieta (Apple), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnell (Digicert), Dimitris Zacharopoulos (HARICA), Enrico Entschew (D-TRUST), Inigo Barreira (Sectigo), Joanna Fox (TrustCor Systems), Johnny Reading (GoDaddy), Kati Davids (GoDaddy), Michael Slaughter (Amazon), Michelle Coon (OATI), Niko Carpenter (SecureTrust), Paul van Brouwershaven (Entrust), Rebecca Kelley (Apple), Ryan Dickson (Google), Steven Deitte (GoDaddy), Thomas Zermeno (SSL.com), Tim Hollebeek (Digicert), Tyler Myers (GoDaddy), Wayne Thayer (Mozilla).<o:p></o:p></p><h2 id=agenda>Agenda<o:p></o:p></h2><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1'>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:l2 level1 lfo1'>Certificate Profiles and effective dates<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1'>Delegate DNS to the CA for Domain Validation<o:p></o:p></li></ol><h2 id=minutes>Minutes<o:p></o:p></h2><h3 id=preparation>Preparation<o:p></o:p></h3><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo2'>The recording started<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo2'>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:l3 level1 lfo2'>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:l3 level1 lfo2'>Minute taker was assigned (Dimitris)<o:p></o:p></li></ul><h3 id=sc-52-specify-crl-validity-intervals-in-seconds>1. SC-52: Specify CRL Validity Intervals in Seconds<o:p></o:p></h3><p>Tim asked for Members to check the ballot and whether the changes will negatively affect other areas like Request Tokens, Audit periods, etc.<o:p></o:p></p><h3 id=certificate-profiles-and-effective-dates>2. Certificate Profiles and effective dates<o:p></o:p></h3><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>A ballot becomes effective when it clears IPR<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>Possible explicit effective dates in the actual ballot<o:p></o:p></li></ul><p>Tim said it would be very challenging to write a version of the BRs that contains the old profiles, the new profiles and effective dates for those.<o:p></o:p></p><p>The problem is simple. After the transition date, we want CAs to use the new profiles. Before that effective date, CAs would be OK to use the old profiles.<o:p></o:p></p><p>All certificates issues after the transition date, must comply with the new certificate profiles. Until that transition date, the CA MAY use the profiles described in the previous BR version.<o:p></o:p></p><p>The cleanup for this would just remove the transition date when it is no longer necessary.<o:p></o:p></p><p>Bruce agreed that this is a nice approach. He asked what would happen if a subsequent ballot changed the language in the profiles sections. Tim said we could agree not to modify the profiles section until the transition date of the Profiles ballot. In case we find an issue in the profiles, there will still be a linked version to a BRs version and follow-up ballots will be able to modify this language in whatever ways necessary in order to express the changes required.<o:p></o:p></p><p>Clint agrees with the approach.<o:p></o:p></p><p>If we discover that we have made a mistake in the language, we will have time to run a subsequent ballot to fix issues before the problematic language becomes effective.<o:p></o:p></p><p>Wayne says that CAs could pick-and-choose which corrupts the interpretation of the new changes. CAs should either comply entirely with the old or entirely with the new profiles. That might eliminate some of the risk of pick-and-choose. The implementation time period is relatively short so it's not a huge risk and would only apply for 6 months.<o:p></o:p></p><p>Tim had the impression that the current language already forbids the pick-and-choose option and would welcome suggestions for improvements to making this clearer.<o:p></o:p></p><p>In any case, Tim considers that everything in the new profiles is not considering anything done in the previous profiles as "illegal". Wayne said that we need to confirm that something in the new profiles is not prohibited by the old profiles. Tim replied that he doesn't think this is the case and Wayne suggested we add a sentence to state that clearly for readers as for the intent.<o:p></o:p></p><p>Wayne said that if the Profiles ballot extends to parts of the BRs outside section 7, for example definitions and such, modulo other ballots that happen in the interim period, we could say that the CA either must comply with this version or that version, but not pick-and-choose. However, he agreed that this is difficult to achieve when there are subsequent ballots.<o:p></o:p></p><p>Dimitris said that the BRs say that CAs must always comply with the latest version. Tim said that if auditors asked, we would point to explicit text of the latest BRs that says you may comply with a previous version.<o:p></o:p></p><h3 id=delegating-dns-to-the-ca-for-domain-validation>3. Delegating DNS to the CA for Domain Validation<o:p></o:p></h3><p>Wayne described the issue of method 7 DNS domain control authorization. Method 7 allows the use of CNAME records to redirect from one domain to another where at some point you check a TXT record that contains the Random Value and complete the Domain Validation process.<o:p></o:p></p><p>The CA can register a Domain Name "cadomainvalidations.com". Then create subdomains off of that Domain Name and ask Applicants to create CNAME records that point to those subdomains. This would allow the CA to essentially self-authorize and self-issue renewed certificates.<o:p></o:p></p><p>The topic was discussed in m.d.s.p. back in 2019 where Jeremy Rowley from Digicert and Ryan Sleevi from Google had a disagreement about whether this practice is allowed in the BRs or not.<o:p></o:p></p><p>Some CAs might be using this practice today. It's best if we are explicit about it and either explicitly allow or forbid this practice.<o:p></o:p></p><p>What are the associated risks?<o:p></o:p></p><p>If a CA were to use this method, without having any binding between the organization that was instructed to create a CNAME that points to a subdomain controlled by the CA, if there was no binding between that and the actual request coming in for the certificate, then anyone could request a certificate once it was CNAMEd, once the CNAME was set by the rightful Domain Name holder. The CA cannot distinguish whether the request comes from the Domain Name holder or not. You have to bind this delegation with a particular account at the CA systems so to accept only requests that are authorized and linked to this delegated account.<o:p></o:p></p><p>Add language to method 7 that says that the Random Value must be bound to the Applicant's account. So, you might have a Random Value but also have an account authorization.<o:p></o:p></p><p>Would this be a new method? Wayne suggests that this is a yes, it should be an entirely new method that describes what is and what is not allowed.<o:p></o:p></p><p>If the Applicant delegates via CNAME the Domain Authorization to a Domain that the CA controls, then the CA binds that delegation with an account in its systems, and then the risk is prevented. Then, when the CA wants to issue a certificate, it is practically self-validating. Then, why should the CA generate the Random Value in the first place? It's just an exercise that doesn't add any security value or prove anything. Just the fact of creating a CNAME pointing to a subdomain of the CA, should be considered authorization, and a "permanent" one.<o:p></o:p></p><p>This authorization starts to look like how the CAA works. Just like a Domain Name holder points the CAA to a domain name, it could point to a CNAME as a permanent authorization, or a CA "account identifier". The CA would then be able to issue certificates in perpetuity as long as this record is in place.<o:p></o:p></p><p>So, the idea is to codify that as a validation method that uses CAA or CNAME to delegate this issuance authorization to the CA under a particular "account identifier".<o:p></o:p></p><p>Dimitris asked if we should first discuss if this practice is problematic and introduces significant risks and whether it is specific to delegations to CA or delegations in general. In many ways today, it is very difficult, almost impossible for a CA to distinguish between an Applicant and a Reseller.<o:p></o:p></p><p>Is the delegation problem problematic in general?<o:p></o:p></p><p>Who is the Applicant (especially on a hosting provider)? Need to check if this is currently allowed in method 7.<o:p></o:p></p><p>Wayne recalled that in the 2019 email thread, there was discussion about whether Amazon Web Services is the Applicant for certificates asked by their customers or not.<o:p></o:p></p><p>Tim: There are ways to implement this, it is allowed, but you can do it in a very bad way. We need to update the BRs so that if someone is going to allow it, here's how it should be done, in a secure manner.<o:p></o:p></p><p>Dimitris said that method 7 clearly allows delegating Domain Names to hosting providers. Perhaps there is an issue for hosting providers that are also CAs that perform the validation. Is the problem identified in the fact that CAs could do it directly, so instead of having two parties, an "Applicant" and a "CA", we have the CA wearing two hats? Tim replied that it's unclear. It depends how you read some of those words in the BRs.<o:p></o:p></p><p>Wayne recalled that the original question came from a CA that asked "am I allowed to do this"? That spawned the discussion but it was not clearly resolved. The cases we should consider are Amazon, GoDaddy, Google and Microsoft who are also hosting providers and CAs. Are they allowed to do this? Can the CA do it directly? If not, can the CA <em><span style='font-family:"Calibri",sans-serif'>that is also a hosting provider</span></em> do it?<o:p></o:p></p><p>Bruce recommended that we just assume that it is currently permitted and proceed with making it clear whether it is permitted or not going forward. CAs have been audited, nobody said it's not permitted, we can't change the past.<o:p></o:p></p><p>Wayne added that this is a typical situation where we should debate what are the CAs' and Browsers' expectations and in the end it doesn't really matter that much, it just needs to be clear so there is a common understanding going forward.<o:p></o:p></p><p>Binding a Random Value to a specific customer could be a trivial change. However, it doesn't really answer the question about whether this is allowed or not.<o:p></o:p></p><p>In general, adding random values to a domain that the CA controls, is just "theater".<o:p></o:p></p><p>Permanent delegations are risky. Tim said that CAs still need to check delegation every time. Currently it's probably not required because of the validation reuse clause.<o:p></o:p></p><p>Tim recommends that instead of allowing that in method 7, we should create a new method that allows it with better security properties.<o:p></o:p></p><p>Tim said that for the random value to work, the CA would need to check that the CNAME is in place so this is covered. However, Dimitris pointed out that this validation action can be reused for 398 days, except for the CAA that needs to take place on every certificate issuance. So, requiring the CNAME delegation check on every issuance, would be an improvement over the current requirements. Tim thought that this would then make this method special in a way he doesn't feel is necessary.<o:p></o:p></p><p>Wayne asked if we could add a sentence in method 7 that says "if a CNAME is used to redirect the Domain Control to the CA then something must be tied to the account".<o:p></o:p></p><p>Tim will write a straw-man proposal for further discussion.<o:p></o:p></p><p>Corey mentioned that this could easily be the case in method 2 where the Applicant adds a CA email address in the WHOIS record. Niko said it could also apply to method 18 with a permanent redirect that always redirects to the CA-controlled Domain Name.<o:p></o:p></p><p>It goes back to the original question whether delegating Domain Control validation to the CA is an acceptable practice or not. An arbitrary third-party is OK to be delegated for Domain Control validation. Why not for the CA?<o:p></o:p></p><p>Tim recommended to leave the other methods until we find good language for method 7. He also thinks that this delegation would be good for agility purposes.<o:p></o:p></p><p>Tim mentioned that the Random Value is like a "bearer token" between the Applicant and the CA. If the CA gets authorization by an action from the Applicant at the Authorization Domain Name level, then the "bearer token" becomes irrelevant.<o:p></o:p></p><p>Niko replied that, without stating whether this is for better or worse, the Random value shows intent at the time of setting that DNS record, while the CNAME record doesn't have that property.<o:p></o:p></p><p>Wayne said that he agrees with Corey that this delegation issue probably applies to several Domain Validation methods but it might make more sense to start with improving the DNS method first.<o:p></o:p></p><p>Wayne asked whether we should ban it for the other methods until we look at the issue thoroughly. Tim suggested not to touch the other methods until we do some analysis.<o:p></o:p></p><p>Bruce mentioned that we could ban it and wait for a CA that uses it to come forward. Tim was negative with that approach and asked how does one know whether an email address is or is not controlled by the CA?<o:p></o:p></p><p>Dimitris: This is probably the case for the WHOIS email addresses but not the constructed email address method. But, similarly, how can we differentiate whether a Domain Name is controlled by a CA or not? It could very well point to a Domain Name that is not the one the CA is using for their brand name. It's not possible to track this down.<o:p></o:p></p><p>Bruce made an observation that we tried very hard to remove "any other method" and it appears that we currently do have "any other method" being effectively allowed. Perhaps we didn't define things specifically enough? Tim replied that we always knew this would be an iterative process where methods and language would be continuously improved. We have made very good progress in the Domain Validation methods, things are much better than what they used to be. All agreed.<o:p></o:p></p><h3>Adjourned<o:p></o:p></h3></div></body></html>