[cabfpub] gTLD proposal

Fri Feb 1 15:25:50 UTC 2013

I think we should push back on ICANN on this. They are changing the Internet infrastructure they are custodians of and getting paid a lot of money regulate that change. They are in the position to collect information that we need.

The public suffix list is a hack. It should go away. There needs to be a mechanism for determining if a domain is a public suffix or not but that information should be distributed through the DNS and not through an ad hoc list that a third party is meant to be maintaining under ill-defined criteria and without the active participation of the TLD operators. 

At the moment TLDs are very expensive. But there is no particular reason that a TLD should be any more expensive than a domain in .com or .net. I can't see the current two tier domain registration scheme as being stable long term. They will expand to a few hundred domains, then a few thousand and then the IPR lobby in ICANN will decide that they want domains like .google and .microsoft as the norm and there will be a move to open up the root zone like any other registry and there will be a likelihood of millions of domains appearing overnight. There is no possibility we could keep up in that environment so we have to push back now before a precedent is set.

The proper way to publish this information is in the DNS itself. ICANN should propose a record type to IETF that is a 'public suffix' extension. All Registries under the authority of ICANN would be directed to publish the new record in all domains that are public suffixes (.com, .net) the country code TLDs that are not under ICANN authority would be advised to publish the record at their public delegation points (.co.uk, .ac.uk).

The Public Suffix list should only be operated as a short term measure until this important task is taken on by the body that is equipped to do it properly. CABForum is not equipped to manage that type of list and we are not the only party that depends on it. Javascript implementations also depend on the public suffix list as do several others.

Any actions we take in the short term to react to this change should have a sunset period.

Another point to bear in mind here is that ICANN is not the owner of the TLD space. It is operating the DNS root zone under contract and that contract could change in the future. So the wording of any requirements should specify DNS root management authority rather than ICANN directly. 

On Jan 31, 2013, at 12:36 AM, Jeremy Rowley wrote:

> Hi everyone,
>  
> Because ICANN will begin the process of issuing new generic Top Level Domains (gTLDs) in 2012, certain Certificates for non-public names will need to be revoked on an accelerated schedule in order to prevent collisions and possible MITM attacks on newly registered domains.  ICANN is primary concerned about the number of *.gTLD certificates that CAs have previously issued.   For example, *.XXX may exist despite being .XXX being approved for registration back in 2010.
> 
> The attached motion is intended to eliminate erratic use of wildcard characters and mitigate the ICANN security concerns while providing a transition period for affected customers.  I’m looking for an additional endorser.
>  
> ----------------
>  
> 
> Jeremy Rowley made the following motion, and Rick Andrews  and ______________  endorsed it:
> 
> ---- Motion Begins ----
> 
> ---- Erratum Begins ----
> 
> Add the following as new Section 11.1.3:
> 
> 11.1    Authorization by Domain Name Registrant
> 
> 11.1.3 Wildcard Domain Validation
> 
> Before issuing a certificate with a wildcard character (*) in a CN or subjectAltName of type DNS-ID, the CA MUST establish and follow a documented procedure† that determines if the wildcard character occurs in the first label position to the left of a “registry-controlled” label or “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for further explanation).
> 
> If a wildcard would fall within the label immediately to the left of a registry-controlled† or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or “*.local”, but MAY issue “*.example.com” to Example Co.). 
> 
> Prior to September 1, 2013, each CA MUST revoke any valid certificate that does not comply with this section of the Requirements.
> 
> †Determination of what is “registry-controlled” versus  the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a “public suffix list” such as http://publicsuffix.org/.  If the process for making this determination is standardized by an RFC, then such a procedure SHOULD be preferred.
> 
> Add the following as new Section 11.1.4:
> 
> 11.1.4 New gTLD Domains
> 
> 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. CAs SHOULD NOT issue Certificates containing a new gTLD under consideration by ICANN.
> 
> Within 30 days after a CA is made aware that ICANN approved a new gTLD for operation:
> 
> 1)     Each CA MUST compare the new gTLD against the CA’s records of valid certificates.
> 
> 2)     If a valid certificate contains a FQDN whose public suffix is the same as the new gTLD, the CA MUST re-verify that the Subscriber is either the Domain Name Registrant or has control over the FQDN in accordance with Section 11.1. 
> 
> 3)     The CA MUST revoke a Certificate containing a Domain Name that includes the new gTLD if the Subscriber is not the Domain Name Registrant and the Subscriber cannot demonstrate control over the domain within 60 days after the new gTLD becomes publicly resolvable in the DNS.
> 
> ---- Motion Ends ----
> 
> ---- Erratum Ends ----
> 
> Thanks,
> 
> Jeremy
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130201/646daf4a/attachment-0003.html>