<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:"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;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Ryan and others, <o:p></o:p></span></a></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>1 - What if that second sentence in the definition of Base Domain Name read something like, “For new gTLDs approved under ICANN Specification 13, the domain www.[gTLD] may also be considered to be a Base Domain.” ?<o:p></o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>2 - What if the definition of Test Certificate were modified to read, “A Certificate with a maximum validity period of 30 days and that: (i) includes a critical extension with the specified Test Certificate CABF OID or (ii) does not chain to any root certificate subject to these Requirements.” ?<o:p></o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Ben<o:p></o:p></span></span></p><span style='mso-bookmark:_MailEndCompose'></span><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Friday, July 22, 2016 12:26 PM<br><b>To:</b> Ben Wilson <ben.wilson@digicert.com><br><b>Cc:</b> CABFPub <public@cabforum.org><br><b>Subject:</b> Re: [cabfpub] Ballot 169 - Revised Validation Requirements<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Regrettably, despite multiple readings throughout this, I appear to have missed some things in the definitions.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm mostly hoping for clarification, as it might simply be wording issues that can be corrected without changing the substance or intent of the ballot.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, Jul 22, 2016 at 11:06 AM, Ben Wilson <<a href="mailto:ben.wilson@digicert.com" target="_blank">ben.wilson@digicert.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>Base Domain Name:</b> The portion of an applied-for FQDN that is the first domain name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "<a href="http://example.co.uk" target="_blank">example.co.uk</a>" or "<a href="http://example.com" target="_blank">example.com</a>"). For gTLDs, the domain <a href="http://www.[gTLD">www.[gTLD</a>] will be considered to be a Base Domain.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Why the "For gTLDs" clause? Is "<a href="http://www.[gTLD]">www.[gTLD]</a>" reserved by ICANN? Is this meant as a clause for Spec-13 situations? For example, as I read it, if Google wanted to get a certificate for "foo.google", the combined definition of "Authorization Domain Name" and "Base Domain Name" would potentially prohibit this - that is, as worded, it suggests "For gTLDs" is mutually exclusive with the preceding sentence.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm unclear if this was meant to be "will also be" - but if so, it's unclear why the gTLD case isn't handled previously. Is it meant to permit the WHOIS lookups for such spec-13 gTLDs? If so, it would only be necessary if you're applying for a bare certificate (either "*.[gTLD]" or [gTLD], and the latter is either prohibited or strongly-discouraged per ICANN SSAC on single-label hosts)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>QUESTION: Can someone explain the context/intent of this clause?<o:p></o:p></p></div><div><p class=MsoNormal>SUGGESTION: Can this clause be removed? Would the addition of the word "also" change the semantic meaning or interpretation?<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>Test Certificate:</b> A Certificate with a maximum validity period of 30 days and which i) includes a critical extension with the specified Test Certificate CABF OID, or ii) which chains to a root certificate not subject to these Requirements.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The only change of potential substance is with ii).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Consider a case of the following hierarchy:<o:p></o:p></p></div><div><p class=MsoNormal>Root A - publicly trusted, complies with the BRs<o:p></o:p></p></div><div><p class=MsoNormal>Root B - not meant to comply with the BRs, an independent infrastructure<o:p></o:p></p></div><div><p class=MsoNormal>Intermediate B - a version of Root B (same name/keypair) signed by Root A, and subsequently revoked (perhaps during the CA complying with the BRs, or perhaps the CA did not train its staff appropriately and assumed they knew not to cross-sign B).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The question is whether Root B can be used to issue Test Certificates. My reading is that it could, just as Root B could potentially issue any other type of certificates within the current BRs (it'd be strongly inadvisable, but not unheard of for a CA to screw this up).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Now consider another scenario:<o:p></o:p></p></div><div><p class=MsoNormal>Root A - publicly trusted, complies with the BRs<o:p></o:p></p></div><div><p class=MsoNormal>Root B - not meant to comply with the BRs, and independent infrastructure<o:p></o:p></p></div><div><p class=MsoNormal>Int 1 - An intermediate signed by Root A, within scope of the BRs and audits<o:p></o:p></p></div><div><p class=MsoNormal>Int 1-B - The same name/keypair as Int 1, but signed by Root B.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Can Int 1 be used to issue test certificates? As currently worded, it seems to suggest it can be, because there exists a path such that Int 1-B chains to a root which is not subject to these requirements, even though Int 1 does. Now, if Int 1 issues a "Test Certificate" (that is, operationally, the 'intermediate subject to the BRs'), is this a violation? Within the context of the rest of the ballot, it seems like Int 1 has *not* violated the BRs, solely because of Int 1-B's existence.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>SUGGESTION: Modify ii) to express the inverse : "there are no [certificate paths/chains] to a root certificate subject to these Requirements"<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It doesn't solve the first problem, but in trying to slightly tweak the wording, attempts to guard against a misinterpretation that leads to the second problem.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div></div></div></div></body></html>