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

Wed Jul 14 08:27:53 UTC 2021

Hi Corey and Ryan,

Thank you for your responses.

Probably, I understood Corey's point.  Delaying BR revision is not my intention, my comments were to clarify terminology and references.  I'd like to continue discussion about how to validate domain names written on certificates and hope to revise BR stepwise in appropriate timings (not this timing).

My understanding for the purpose of SC48 is former part of Ryan's point (one views SC48 as clarifying existing requirements), and with that understanding, I rephrase my comments as follows:

  - The term "P-Label" is newly defined and is not familiar with readers.  So I think it is not appropriate, then, I propose to use "ACE prefixed label" instead, because A-label is too restrictive for the purpose.  ACE (stands for ASCII Compatible Encoding) prefix is well defined in RFC 3490 (IDNA2003) and effective in RFC 5890 (IDNA2008) as well.

Followings are my memorandum for future/further discussion.

  - [middle term target] CA should validate ACE prefixed label (at least) adjacent to PSL (stands for Public Suffix List) according to IDNA2008.
    ex: for "www.xn--love.com", the PSL is "com" so that "xn--love" should be validated according to IDNA2008.

  - [middle term target] Current BR does not define how to handle EAI (stands for Email Address Internationalization) in certificate (which is defined in RFC 8399), so it should be addressed.  Especially, how to designate EAI in CAA RR should be clarified (which is not defined in RFC 8399).

  - [long term target] When SLD LGR (stands for Second Level Domain names Label Generation Rules) were deployed moderately in the future, CA should validate label (not limited to IDN) adjacent to PSL according to SLD LGR of the PSL.  (Please see <https://www.icann.org/public-comments/lgr-second-level-2-2020-03-30-en> for background reading.)

Best regards,

-- 
Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp>

On Tue, 13 Jul 2021 18:33:23 +0000 Corey Bonnell <Corey.Bonnell at digicert.com> wrote:

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