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

[Ryan Sleevi]

On Tue, Jul 13, 2021 at 6:53 AM Corey Bonnell via Servercert-wg <
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 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/2af8da24/attachment.html>