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

Tue Jul 13 10:53:33 UTC 2021

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.

> Only exception is that if a label start with "xn--" (case independent) but
is not a valid A-label, contains deviation characters defined in UTS#46 can
be treated as legitimate.

There are additional divergences in IDNA2003 and 2008 beyond the 4 deviation
code points that need to be considered. See
https://unicode.org/reports/tr46/#IDNAComparison for a more comprehensive
list. As noted in that table, there are several thousand code points that
are allowed in IDNA2003 and UTS46 but not IDNA 2008, and there appear to be
registered domains that contain such code points. As mentioned above,
prohibiting such registered domains from obtaining certificates is a highly
disruptive change, as it may render the domain useless if it's used to host
a website.

The current proposal of requiring valid output of the Punycode ToASCII
algorithm in XN-labels strikes a balance between useful improvements to the
ecosystem while not introducing potentially large changes that will take
significant time and effort to fully define and determine impact to
registered domain names.

Thanks,
Corey

-----Original Message-----
From: Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp> 
Sent: Monday, July 12, 2021 10:38 PM
To: Corey Bonnell <Corey.Bonnell at digicert.com>
Cc: 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,

Thank you for your response and explanation of the background.

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.

Of course, I understand legitimate and daily used IDNs under IDNA2003
(probably registered more than 10 years ago) should be treated as valid even
though we use the term A-label.
This case can be explicitly explained in BR like:
Only exception is that if a label start with "xn--" (case independent) but
is not a valid A-label, contains deviation characters defined in UTS#46 can
be treated as legitimate.

Best regards,

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

On Mon, 12 Jul 2021 13:12:38 +0000 Corey Bonnell
<Corey.Bonnell at digicert.com> wrote:

> Hi Yoshiro,
> Thanks for raising this on the list. The specification of the Defined 
> Term "P-Label" and its use throughout the document is deliberate. As 
> you mentioned, RFC 5890 defines "A-label", but it is important to note 
> that A-labels must contain only the ACE encoding of valid IDNA2008 
> labels. Since current practice in certificates today is a mix of 
> IDNA2003, UTS46, and
> IDNA2008 (and even labels which contain valid Punycode output but are 
> not compliant with the three standards) we need a term to define those 
> set of XN-labels that contain valid Punycode output but may not adhere 
> to a particular IDNA standard. For that reason, P-label was defined to 
> succinctly state those properties.
> 
> The proposed requirement is the same in Ballot 202 [1]:
> 	CAs MUST NOT include Domain Labels which have hyphens as the third 
> and fourth characters unless the first character is "x" or "X", the 
> second character is "n" or "N", and the fifth and later characters are 
> a valid Punycode string.
> 
> Thanks,
> Corey
> 
> [1]
> https://cabforum.org/2017/07/26/ballot-202-underscore-wildcard-charact
> ers/
> 
> -----Original Message-----
> From: Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp>
> Sent: Monday, July 12, 2021 5:08 AM
> To: Corey Bonnell <Corey.Bonnell at digicert.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 all,
> 
> My apologies for this delayed response.
> 
> I've read the difference on Github:
> https://github.com/cabforum/servercert/compare/cf4e17a43977dcf7cb9c9e4
> 1efd2d f4be4707e13...a42756b50d2d377396673983908f059cccd2bd9f
> 
> Followings are my comments regarding to modification.
> The line number is indicating modified (green) part of the difference.
> 
> - line number 164
>   The term "P-Labels" is unappropriate, it should be replaced by
"A-labels"
> which is defined by RFC 5890 (and also referred by RFC 8499).
> 
> - line number 164
>   RFC 8399 updates RFC 5280 for using internationalized string in 
> certificates, and this line (plus corresponding main part) should 
> refer to RFC 8399 explicitly.
>   ex: Fully-Qualified Domain Names MUST consist solely of A-labels and 
> Non-Reserved LDH Labels according to RFC 8399.
> 
> - line number 365
>   The term "P-Label" should be replaced by "A-label". Please see above.
> 
> - line number 555
>   Reference to RFC 8399 should be added prior to this line.
> 
> 
>   * * *
> 
> Following is my memorandum not directly related to this ballot, but 
> probably need to be considered in the near future.
> 
>   RFC 8399 also describes EAI (Email Address Internationalization) in 
> certificate.
>   Future BR should address EAI as well, especially EAI in CAA RR (BR 
> describes email address in CAA RR at 3.2.2.4.13).
>   RFC 8659 does not define how to handle EAI in CAA RR, therefore, any 
> guidance for using EAI as CAA email contact will be required.
> 
> Best regards,
> 
> --
> Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp>
> 
> On Tue, 6 Jul 2021 13:00:11 +0000 Corey Bonnell via Servercert-wg 
> <servercert-wg at cabforum.org> wrote:
> 
> > This email begins the discussion period for Ballot SC48 - Domain 
> > Name and IP Address Encoding
> > 
> >  
> > 
> > 
> > Purpose of Ballot
> > 
> > 
> > Ballot 202 set out to clarify requirements regarding encoding of 
> > domain names and IP addresses in Subscriber Certificates, but the 
> > Ballot ultimately failed to pass. Since then, there have been 
> > numerous differences in interpretation of the written requirements.
> > 
> > This Ballot seeks to resolve these differences in interpretation and 
> > to provide unambiguous guidance on the correct encoding of domain 
> > names and IP addresses in Subscriber Certificates.
> > 
> >  
> > 
> > The following motion has been proposed by Corey Bonnell of DigiCert 
> > and endorsed by Ryan Sleevi of Google and Dimitris Zacharopoulos of
> HARICA.
> > 
> >  
> > 
> > 
> > Motion Begins
> > 
> > 
> > This ballot modifies the "Baseline Requirements for the Issuance and 
> > Management of Publicly-Trusted Certificates" ("Baseline 
> > Requirements"), based on Version 1.7.6:
> > 
> > MODIFY the Baseline Requirements as specified in the following Redline:
> > 
> >  
> > <https://github.com/cabforum/servercert/compare/cf4e17a43977dcf7cb9c
> > 9e
> > 41efd2 df4be4707e13..a42756b50d2d377396673983908f059cccd2bd9f>
> > https://github.com/cabforum/servercert/compare/cf4e17a43977dcf7cb9c9
> > e4 1efd2d f4be4707e13...a42756b50d2d377396673983908f059cccd2bd9f
> > 
> >  
> > 
> > This ballot modifies the "Guidelines for the Issuance and Management 
> > of Extended Validation Certificates" ("EV Guidelines") as follows, 
> > based on Version 1.7.6:
> > 
> > MODIFY the EV Guidelines as defined in the following redline:
> > 
> > https://github.com/cabforum/servercert/compare/cf4e17a43977dcf7cb9c9
> > e4 1efd2d f4be4707e13...a42756b50d2d377396673983908f059cccd2bd9f
> > 
> >  
> > 
> > 
> > Motion Ends
> > 
> > 
> > This ballot proposes a Final Maintenance Guideline.
> > 
> > The procedure for approval of this ballot is as follows:
> > 
> >  
> > 
> > Discussion (7+ days)
> > 
> > Start Time: 2021-07-06 13:00:00 UTC
> > 
> > End Time: 2021-07-13 13:00:00 UTC
> > 
> >  
> > 
> > Vote for approval (7 days)
> > 
> > Start Time: TBD
> > 
> > End Time: TBD
> > 
> >  
> > 
> 

-------------- 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/be7c5142/attachment-0001.p7s>