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

Tue Jul 13 02:38:07 UTC 2021

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-characters/
> 
> -----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/cf4e17a43977dcf7cb9c9e41efd2d
> 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/cf4e17a43977dcf7cb9c9e
> > 41efd2 df4be4707e13..a42756b50d2d377396673983908f059cccd2bd9f>
> > https://github.com/cabforum/servercert/compare/cf4e17a43977dcf7cb9c9e4
> > 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/cf4e17a43977dcf7cb9c9e4
> > 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
> > 
> >  
> > 
> 