New BR 11.1.4 regarding Applied-for new gTLD strings

[Kathleen Wilson]

All,

The CA/Browser Forum has introduced Baseline Requirement #11.1.4 to
address security concerns that are introduced as applied-for new gTLD
strings are granted. As soon as applied-for new gTLDs are approved, they
must be treated as if they are delegated TLDs, and can no longer be used
in internal name certificates.

*Background:*

http://newgtlds.icann.org/en/applicants/customer-service/faqs/faqs-en
�The new gTLD program is an initiative that will enable the introduction
of new gTLDs (including both ASCII and IDN) into the domain name space.�

http://newgtlds.icann.org/en/about/program
�A gTLD is a domain name extension such as the familiar .com, .net, or
..org. There are roughly two dozen now, but soon, there could be hundreds.�

Important Note: The new gTLD program means that the most common
internal/private TLD, .corp, could soon be added to the domain name
space, and would have to be treated as a delegated TLD. Other
possibilities include, but are not limited to .internal, .local,
..private, .site, and .home.

http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf
�Finding 4: The practice for issuing internal name certificates allows a
person, not related to an applied for TLD, to obtain a certificate for
the TLD with little or no validation, and launch a man-in-the-middle
attack more effectively.
If an attacker obtains a certificate before the new TLD is delegated,
he/she could surreptitiously redirect a user from the original site to
the attacker site, present his certificate and the victim would get the
Transport Layer Security/SSL (TLS/SSL) lock icon. This poses a
significant risk to the privacy and integrity of HTTPS communications as
well as other protocols that use X.509 certificates (e.g. TLS/SSL-based
email communication).�


*Response:*

The CA/Browser Forum (https://www.cabforum.org/documents.html) has added
Baseline Requirement #11.1.4 to address the issues that this new gTLD
program introduces�

11.1.4 New gTLD Domains
CAs SHOULD NOT issue Certificates containing a new gTLD under
consideration by ICANN. Prior to issuing a
Certificate containing an Internal Server Name with a gTLD that ICANN
has announced as under consideration to make operational, the CA MUST
provide a warning to the applicant that the gTLD may soon become
resolvable and that, at that time, the CA will revoke the Certificate
unless the applicant promptly registers the domain name.
Within 30 days after ICANN has approved a new gTLD for operation, as
evidenced by publication of a contract with the gTLD operator on
[www.ICANN.org] each CA MUST (1) compare the new gTLD against the CA�s
records of valid certificates and (2) cease issuing Certificates
containing a Domain Name that includes the new gTLD until after the CA
has first verified the Subscriber's control over or exclusive right to
use the Domain Name in accordance with Section 11.1.
Within 120 days after the publication of a contract for a new gTLD is
published on [www.icann.org], CAs MUST revoke each Certificate
containing a Domain Name that includes the new gTLD unless the
Subscriber is either the Domain Name Registrant or can demonstrate
control over the Domain Name.

ICANN has implemented a notification service to aid CAs in discovering
contracting milestone for applied-for-gTLD strings, which can you can
subscribed to at:

https://mm.icann.org/mailman/listinfo/gtldnotification

Currently the service has the following features:
- Notification of the list of all the applied-for-strings ordered by its
priority. If there are multiple applications for a given string, ICANN
will list all the possible priority numbers for that string.
- Whenever a contract is executed between a TLD operator and ICANN, an
email notification will be sent indicating the date the contract is
signed, the string, and the URL where the contract will be posted.


In this discussion thread I would like to discuss BR 11.1.4 and the
notification service. We should also consider sending another CA
Communication to make sure that all CAs in Mozilla�s program are aware
of this issue and the action that they should take.

Note: I will start a separate discussion to propose updating Mozilla�s
CA Certificate Policy to require version 1.1.3 of the BRs.

Thanks,
Kathleen