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

Thu Jul 15 08:50:29 UTC 2021

Hi Corey,

Thank you very much for your response and thoughts.

- for P-Label

  I am, personally, not convinced to use P-Label, but there is no other comment regarding the terminology so I will follow the WG's decision. I believe we will find suitable terminology during the discussion of middle/long term target.

- for S/MIME WG

  I'd like to see the discussion about RFC 8399, so please point out date or subject of the messages on the mailing list if available.

- for per-TLD basis validation

  I have many thoughts regarding this topic, but it is TL;DR and completely out of scope from this discussion, so I omit it here.

Best regards,

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

On Wed, 14 Jul 2021 12:40:08 +0000 Corey Bonnell <Corey.Bonnell at digicert.com> wrote:

> Hi Yoshiro,
> > 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.
> 
> The challenge here is that we need to express a type of domain label
> with the following qualities:
> 1. Is an XN-label
> 2. Contains valid output from the Punycode algorithm. This Punycode output
> may be the encoding of IDNA 2003, UTS46, IDNA 2008, and more. A bug/feature
> (depending on how you view whether CAs should issue for registered domains
> that contain invalid IDN) is that
> valid Punycode output but invalid IDNs may appear.
> 
> As far as I know, there is no standard available today that defines a "slot"
> that can simultaneously include IDNA 2003, UTS46, or IDNA 2008 labels. Since
> we have no standard definition we can reference, we by necessity need to
> define our own type of label. While I realize "P-Label" is a novel term, we
> have historically created our own terminology to concisely refer to concepts
> that only exist in the BRs. The issue with using "ACE prefixed label" is
> that it is too permissive for our purposes; section 5 of RFC 3490 [1]
> defines it as any domain label with two alphanumeric ASCII characters
> followed by two hyphens. For example, "aa--foobarbaz" is an ACE prefixed
> label.
> 
> >   - [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.
> 
> I agree that we should discuss whether restricting the repertoire of allowed
> code points on a per-TLD basis is a viable path forward. There are
> complications here, since there are legacy registered domains under the
> "com" TLD that contain valid IDNA 2003/UTS 46 but are invalid according to
> IDNA 2008 (e.g., xn--19g.com, which is mentioned in section 2 of
> UTS 46). 
> 
> > [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).
> 
> RFC 8398 has been discussed quite a bit in the S/MIME WG, and CAA processing
> for S/MIME certificate issuance has also been briefly discussed.
> None of these details have been fully fleshed out or finalized, so your
> participation and insights in that working group would be very welcome.
> 
> Thanks,
> Corey
> 
> [1] https://datatracker.ietf.org/doc/html/rfc3490#section-5
> 
> -----Original Message-----
> From: Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp> 
> Sent: Wednesday, July 14, 2021 4:28 AM
> To: Corey Bonnell <Corey.Bonnell at digicert.com>
> Cc: Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG Public
> Discussion List <servercert-wg at cabforum.org>
> Subject: Re: [Servercert-wg] Discussion Period Begins on Ballot SC48 -
> Domain Name and IP Address Encoding
> 
> 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
> > 
> 