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

Corey Bonnell Corey.Bonnell at digicert.com
Mon Jul 12 13:12:38 UTC 2021


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

-------------- 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/20210712/41e85979/attachment.p7s>


More information about the Servercert-wg mailing list