<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:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
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;}
/* List Definitions */
@list l0
{mso-list-id:447624197;
mso-list-type:hybrid;
mso-list-template-ids:150357982 435968438 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:Wingdings;
mso-fareast-font-family:"Yu Gothic";
mso-bidi-font-family:"Times New Roman";}
@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:1136532042;
mso-list-template-ids:-1605873248;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:1337002285;
mso-list-template-ids:-1929243168;}
@list l3
{mso-list-id:2062171599;
mso-list-type:hybrid;
mso-list-template-ids:1330172520 644642744 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3: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:Wingdings;
mso-fareast-font-family:"Yu Gothic";
mso-bidi-font-family:"Times New Roman";}
@list l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[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><p class=MsoNormal>Hi Ryan,<o:p></o:p></p><p class=MsoNormal>Comments inline.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> I believe the point being made here is that they're already prohibited today, by IDNA. SAC095 [1] provides the citations to explain how that flows, and this is true for both IDNA2003 and IDNA2008 (that is, that these characters are DISALLOWED).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Agreed: emoji are disallowed by all three IDNA standards.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> As I understand it (and I hope I'm not misrepresenting the concerns), the concern here is that the definition of P-Label then has the same functional effect (on invalid IDNA) that 202 would have had on underscores: It ends up explicitly permitting them, when today, they are implicitly forbidden (by IDNA).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This raises the question of what role the CA plays in prohibiting or allowing domain names which conform to preferred name syntax but whose presentation format in a higher-level “protocol” (i.e., IDNA) may be incorrect. Despite IDNA 2003 being prescribed by RFC 5280, the consensus a few years ago was that CAs are permitted to include labels that violate IDNA 2003 in certificates [1] as they are not expected to check for such labels. Given this precedent, CAs are currently not required by at least one Root Program to check adherence to IDNA, as the role of the CA is to validate control of the Applicant’s domain.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This historical view is further bolstered by Root Programs’ statements that CAs should use ACE encoding exclusively and not encode CN as U-Labels, as the presentation of IDNs is a user client concern and should not be forced by the CA. In other words, there’s a clean “separation of concerns”: the CA is responsible for the validation of domains, and the browser is responsible for the presentation of such domains.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> I think the core perspective issue is whether one views SC48 as clarifying existing requirements or whether it's introducing requirements that don't exist. If it's the former, the change to P-Label's definition to reiterate the prohibition on DISALLOWED characters is no change (provided they're disallowed by both IDNA2003 and 2008). If it's the latter, however, then the change would be imposing a more stringent requirement than practiced today, and something to be measured just in case. Similarly, if stating existing requirements is the goal, then the current P-Label definition doesn't state existing requirements, but in fact opens them up more widely (similar to underscore), while if the latter, then the current definition is a stepping stone to a more consistent set.<o:p></o:p></p><p class=MsoListParagraph><o:p> </o:p></p><p class=MsoNormal>From the Ballot 202 discussions, it was clear that browser expectations, written requirements and interpretations held by CAs were not aligned. This, coupled with the failure of Ballot 202 and the MDSP discussion referenced above, leaves us in a state where there are no clear requirements regarding CA obligations for IDN processing. It also important to note that the definition of P-Label is not less restrictive than the validation requirements for XN-labels as proposed in Ballot 202. The intent of SC48 is to align those expectations with policy, at least to the extent proposed in Ballot 202. And for that, it is a useful improvement. By no means is it intended to be an end-state.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> While I'm firmly of the belief that the goal is to state existing (longstanding) requirements, I understand that as with many other technical requirements, CAs are often unaware of them, and thus their customers have come to depend on the invalid behaviour, and so transition time is needed. So I'm supportive of deferring this work - not because our goal is to allow these invalid characters (which I agree with Yoshiro's seeming conclusion, that this language will be read to be doing exactly that), but to minimize disruption or reasons for CAs to (wrongly) object, as they did with Ballot 202.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As I explained above, the current written requirements regarding IDN validation for CAs is not clear, as it is not stated on what the role of the CA, as an ecosystem participant, is regarding enforcing IDNA adherence. Several TLDs continue to permit invalid IDN registered domains despite the ICANN-provided guidance that you pointed to in SAC095. And as I mentioned previously, clients accept such invalid domain names. If the role of the CA is to also encompass the validation of the well-formedness of IDNs in addition to Punycode output, then the requirements should state that. Clear guidance in this regard is also incredibly important, as the definition of “valid IDNA” is dependent upon several inputs to the ToASCII algorithm. These are currently unstated for the web PKI and prescribing a particular set of inputs may cause breakage in certain user agents.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> I'm <b>not</b> supportive of using the behaviour as client software as a justification for misissuance (#1 from above), no different than any other issue. As I understand it, these have always forbidden, so I would hope and expect to see CA incident reports (or an analysis about why SAC 095 is wrong). But I wouldn't want to fully block progress here on that.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Given the discussion on MDSP as well as the proposed language in Ballot 202, I would be interested to see where in the relevant documents (BRs, RFCs, etc.) it is stated that CAs must not include domain names in certificates if they violate IDNA.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>[1] <a href="https://groups.google.com/g/mozilla.dev.security.policy/c/ad6NfLGZ730/m/2XoMxZ4FFQAJ">https://groups.google.com/g/mozilla.dev.security.policy/c/ad6NfLGZ730/m/2XoMxZ4FFQAJ</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Ryan Sleevi <sleevi@google.com> <br><b>Sent:</b> Tuesday, July 13, 2021 1:06 PM<br><b>To:</b> Corey Bonnell <Corey.Bonnell@digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br><b>Cc:</b> Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp><br><b>Subject:</b> Re: [Servercert-wg] Discussion Period Begins on Ballot SC48 - Domain Name and IP Address Encoding<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Jul 13, 2021 at 6:53 AM Corey Bonnell via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal>Hi Yoshiro,<br>Comments inline.<br><br>> I understand what you said, but I'm still feeling that the concept of<br>"P-Label" is too wide and including invalid IDNs (even in IDNA2003, which<br>prohibit registering unassigned code point). Emoji domain names are the case<br>of such invalid IDNs. I think registering such invalid IDNs is TLD registry<br>operators' fault, and CAs should not provide patchwork to rescure tha fault.<br><br>As I understand it, these domains with invalid code points are supported in<br>client software today. Prohibiting certificates to be issued for a whole<br>class of registered domains is a rather large and potentially disruptive<br>change. While the topic is certainly worthy of discussion and potential<br>future proposals, I don't think such a proposal fits with the shorter<br>implementation timelines proposed in this ballot.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Corey,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I believe the point being made here is that they're already prohibited today, by IDNA. SAC095 [1] provides the citations to explain how that flows, and this is true for both IDNA2003 and IDNA2008 (that is, that these characters are DISALLOWED).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I believe the point that you're trying to highlight is that despite them being disallowed:<o:p></o:p></p></div><div><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>Client software has not consistently enforced this on the client side<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>This bears similarity to how underscores ('_') were <b>always</b> prohibited by the "preferred name syntax", but still required a ballot (SC12) to adopt and explicitly sunset that for CAs.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>Separate from any TLD policies, subdomains can, have been, and are registered with these invalid characters (e.g. <a href="http://xn--ls8h.example.com">xn--ls8h.example.com</a> is a domain that can be registered today, despite TLD policies)<o:p></o:p></li></ol><div><p class=MsoNormal>As I understand it (and I hope I'm not misrepresenting the concerns), the concern here is that the definition of P-Label then has the same functional effect (on invalid IDNA) that 202 would have had on underscores: It ends up explicitly permitting them, when today, they are implicitly forbidden (by IDNA).<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think the core perspective issue is whether one views SC48 as clarifying existing requirements or whether it's introducing requirements that don't exist. If it's the former, the change to P-Label's definition to reiterate the prohibition on DISALLOWED characters is no change (provided they're disallowed by both IDNA2003 and 2008). If it's the latter, however, then the change would be imposing a more stringent requirement than practiced today, and something to be measured just in case. Similarly, if stating existing requirements is the goal, then the current P-Label definition doesn't state existing requirements, but in fact opens them up more widely (similar to underscore), while if the latter, then the current definition is a stepping stone to a more consistent set.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>While I'm firmly of the belief that the goal is to state existing (longstanding) requirements, I understand that as with many other technical requirements, CAs are often unaware of them, and thus their customers have come to depend on the invalid behaviour, and so transition time is needed. So I'm supportive of deferring this work - not because our goal is to allow these invalid characters (which I agree with Yoshiro's seeming conclusion, that this language will be read to be doing exactly that), but to minimize disruption or reasons for CAs to (wrongly) object, as they did with Ballot 202.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm <b>not</b> supportive of using the behaviour as client software as a justification for misissuance (#1 from above), no different than any other issue. As I understand it, these have always forbidden, so I would hope and expect to see CA incident reports (or an analysis about why SAC 095 is wrong). But I wouldn't want to fully block progress here on that.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>[1] <a href="https://www.icann.org/en/system/files/files/sac-095-en.pdf">https://www.icann.org/en/system/files/files/sac-095-en.pdf</a><o:p></o:p></p></div></div></div></div></body></html>