[Servercert-wg] Discussion Period Begins on Ballot SC48 - Domain Name and IP Address Encoding

Tue Jul 13 18:33:23 UTC 2021

Hi Ryan,

Comments inline.

> 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).

Agreed: emoji are disallowed by all three IDNA standards.

> 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).

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.

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.

> 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.

>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.

> 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.

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.

> I'm not 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.

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.

Thanks,

Corey

[1] https://groups.google.com/g/mozilla.dev.security.policy/c/ad6NfLGZ730/m/2XoMxZ4FFQAJ

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, July 13, 2021 1:06 PM
To: Corey Bonnell <Corey.Bonnell at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Cc: Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp>
Subject: Re: [Servercert-wg] Discussion Period Begins on Ballot SC48 - Domain Name and IP Address Encoding

On Tue, Jul 13, 2021 at 6:53 AM Corey Bonnell via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Hi Yoshiro,
Comments inline.

> I understand what you said, but I'm still feeling that the concept of
"P-Label" is too wide and including invalid IDNs (even in IDNA2003, which
prohibit registering unassigned code point). Emoji domain names are the case
of such invalid IDNs.  I think registering such invalid IDNs is TLD registry
operators' fault, and CAs should not provide patchwork to rescure tha fault.

As I understand it, these domains with invalid code points are supported in
client software today. Prohibiting certificates to be issued for a whole
class of registered domains is a rather large and potentially disruptive
change. While the topic is certainly worthy of discussion and potential
future proposals, I don't think such a proposal fits with the shorter
implementation timelines proposed in this ballot.

Corey,

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).

I believe the point that you're trying to highlight is that despite them being disallowed:

1.	Client software has not consistently enforced this on the client side
2.	This bears similarity to how underscores ('_') were always prohibited by the "preferred name syntax", but still required a ballot (SC12) to adopt and explicitly sunset that for CAs.
3.	Separate from any TLD policies, subdomains can, have been, and are registered with these invalid characters (e.g. xn--ls8h.example.com <http://xn--ls8h.example.com>  is a domain that can be registered today, despite TLD policies)

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).

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.

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.

I'm not 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.

[1] https://www.icann.org/en/system/files/files/sac-095-en.pdf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210713/16fdf3ec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210713/16fdf3ec/attachment-0001.p7s>