[cabfpub] gTLD proposal

Jeremy Rowley jeremy.rowley at digicert.com
Thu Jan 31 21:02:23 UTC 2013


1) " Could you explain more why you feel this wouldn't be feasible? That is, why this should be a SHOULD and NOT a MUST?"
[JR] The proposal uses SHOULD until ICANN has approved a particular gTLD.  Once a gTLD is approved,  non-issuance becomes a requirement (under the next paragraph of the motion).  A "MUST" is  not appropriate prior to ICANN releasing the gTLD because (i) the migration of customers is a significant effort, meaning that some will likely require a temporary certificate, (ii)  ICANN may decide not to approve a new gTLD in near future (especially .corp), and (iii) we may find some older systems that simply cannot convert to using a FQDN and will need time for an update from the provider.   

2) "I find the original proposal (immediate revocation) much more in line with security best practices there. This  effectively permits subscribers to 'squat' on someone else's property for 60 days. The information within the certificate is expressly unvalidated, so I can't see why a CA would want to represent the information as validated."
[JR] I agree that from a security practice immediate revocation is better.  However, this phase-out is going to affect a LOT of people.  The original deprecation date of 2016 was selected to permit users to transition away from using internal server names, an especially difficult task considering use of these names was still a recommended practices for systems in 2010.  I've heard a lot more complaints about the Forum's decision to deprecate this practice than comments supporting the change.  As such, I'm reluctant to simply ignore the needs of legitimate users simply because ICANN has decided to usurp the Forum's carefully contemplated phase-out period.   

Plus, I don't think we can presume this information is not validated.  When the certificate issued, the CA likely verified that the organization using the certificate had a server using the internal server name.  Although the rules for validating the certificate are changing mid-lifecycle, the validation performed is probably still correct - there is still a server with the domain name controlled by the company.

3) " Considering that this practice is altogether intended to be phased out by 2016 (as Per 9.2.1 - re: Internal Server Names), I'm not sure why deference needs to be given here."
[JR] Three years is a significant change in the phase-out period. Many have expressed concerns about meeting the 2016 deadline.  Moving up the date to 2013 increases these problems exponentially - not only do these network administrators need new equipment immediately, they also need training and support they haven't planned for.

4) "A further point of consideration - registry controlled / public suffix lists are dynamic, much like gTLDs have become. What requirements are there regarding CAs that have previously issued certificates that are now considered within the public suffix space. You already see this for ccTLDs that restructure their DNS topologies and request addition/modifications to the PSL. Shouldn't CAs be required to revoke those as well? If not immediately, within a "near-immediate" timeframe?" 
[JR] Probably, but the section only to wildcard certificates.  I'm certainly willing to expand the gTLD section to include approved public suffix lists if you have a list where approved suffixes are published.  What I don't want to do is move up the 2016 deadline across the board.



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Thursday, January 31, 2013 12:52 PM
To: jeremy.rowley at digicert.com
Cc: public at cabforum.org
Subject: Re: [cabfpub] gTLD proposal

On Thu, Jan 31, 2013 at 8:19 AM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> Thanks Gerv - comments in-line.
>
> On 31/01/13 05:36, Jeremy Rowley wrote:
>>       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,
>
> We should add some references so that CAs know where the official place is to look for such an announcement, or for "ICANN approval" as used later in the clause.
> [JR] I'm happy to add a link once ICANN has established a set URL for these announcements.  One of the things I'd like to discuss with Jeff Moss at the face-to-face is advanced notice for CAs of a new gTLDs approval and a location where CAs can check the status of the proposed gTLDs.
>
>  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.
>
> This second sentence seems to say "you shouldn't do the things we are regulating in the first sentence". Or have I misunderstood?
> [JR] The first sentence only requires a warning to customers.  The second sentence recommends that CAs immediately stop issuing these type of certificates. I realize this is not feasible in all cases, which is why this is a "SHOULD" instead of a "MUST"

Could you explain more why you feel this wouldn't be feasible? That is, why this should be a SHOULD and NOT a MUST?

>
>> 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.
>
> I believe the original form had an "immediate revocation if it turns up visible on the Internet" clause? Did you decide to drop that?
> [JR] Yes.  Considering that many of these certificates also include an FQDN, they will likely be available on the Internet.  Most of the new gTLDs will not be operational immediately after the announcement and  since there is only a 60 day phase out for these certificate, I'd rather not unnecessarily complicate the process.

I find the original proposal (immediate revocation) much more in line with security best practices there. This  effectively permits subscribers to 'squat' on someone else's property for 60 days. The information within the certificate is expressly unvalidated, so I can't see why a CA would want to represent the information as validated.

Considering that this practice is altogether intended to be phased out by 2016 (as Per 9.2.1 - re: Internal Server Names), I'm not sure why deference needs to be given here.

>
> One thing I noticed is that the motion lacked a clear requirement not to issue these certificates after the gTLD is approved by ICANN. As such, I'd like to modify the motion slightly:
>
> ----------------
>
> 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.).

A further point of consideration - registry controlled / public suffix lists are dynamic, much like gTLDs have become. What requirements are there regarding CAs that have previously issued certificates that are now considered within the public suffix space. You already see this for ccTLDs that restructure their DNS topologies and request addition/modifications to the PSL. Shouldn't CAs be required to revoke those as well? If not immediately, within a "near-immediate"
timeframe?

>
> 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 ICANN has approved a new gTLD for operation, as evidenced by  an announcement on [www.ICANN.org]:
>
> 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 cease issuing Certificates containing a Domain Name that includes the new gTLD unless the CA has first verified the Subscriber's control over or exclusive right to use the Domain Name  in accordance with Section 11.1.
> 4)      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 ----
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public



More information about the Public mailing list