<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>Corey,</div><div><br></div><div>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).</div><div><br></div><div>I believe the point that you're trying to highlight is that despite them being disallowed:</div><div><ol><li>Client software has not consistently enforced this on the client side</li><li>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.</li><li>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)</li></ol><div>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).</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>[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><br></div></div></div>