[cabfpub] [cabfquest] New gTLD Issue

[Ryan Sleevi]

On Thu, Jan 9, 2014 at 8:58 AM, Bruce Morton <bruce.morton at entrust.com>wrote:

>  I’m not sure if this has been discussed, but I see a problem with moving
> to new gTLDs.
>
>
>
> BR 11.1.4 states “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.”
>
>
>
> The solution is to advise the customer to register the domain and if they
> cannot, then the certificate would be revoked. This does assume that a
> registry is available. The problem is that there is no guarantee that the
> registry will be available within 120 days.
>
>
>
> In many cases the Subscriber will be eligible to register the domain. If
> there is no registry, then there is no conflict with anyone else
> registering the same domain name. As such there is no increased risk.
>

The goal is, of course, to phase these names out entirely, and the plan
described is a temporary plan until 1 November 2015 comes in to play and no
new private registrations are allowed. Some browsers (eg: Chrome) have gone
ahead and already disallowed publicly trusted CAs (eg: those in the known
root stores) from issuing against non-IANA assigned TLDs.


>
>
> I’m trying to figure out the wording for the standard, but if there is no
> registry available after 120 days, then the certificate SHOULD NOT be
> revoked. The Subscriber should be given 30 days from when the registry is
> available to get the domain deployed. The problem is there is no notice
> when a registry is available, so as a service, the CA could check for the
> registry on a regular basis and advise the Subscriber when the registry is
> available.
>
>
The goal of the wording was to prevent a situation where the current
subscriber is unable to register the name, and some other party -
presumably with an as-legitimate-or-more-legitimate claim to the name - is
able to register. By allowing 30 days from when the registry is available,
this creates an opportunity for the subscriber to 'mount an attack' for up
to 30 days before the CA performs the registration-or-revoke check.

As I read it, the language here provides for subscribers who are also
applying for registries, since even after gTLD approval, there is still the
execution of the registry agreement and pre-delegation testing.

Speaking on the browser side, we'd strongly oppose any proposals or
interpretations that encourage the continued use of these certificates. The
choice of 120 days was a compromise from the initial proposal of
"immediate". The goal of 120 days is not to give a window of continued
acceptable operation - it's to provide a maximum upper-bound of time needed
for the subscriber to transition away from the name. The only equitable AND
enforceable balance is one that's applied consistently.


>
>
> It should also be determined how this would be integrated with BR 9.2.1
> which states that certificates without registered domains must not be
> issued after 1 November 2015 and must be revoked by 1 October 2016. If the
> gTLD has been approved, but there is no registry, then we should consider
> not taking this action until a registry is available.
>

Respectfully, I would have to disagree. These names should not have been
issued to begin with, since it undermines the security of SSL for all users
who might use those names, and assurances that customers are "OV validated"
does little to provide any sort of programmatic guarantees.


>
>
> Thanks,
>
>
>
> Bruce Morton
>
> Entrust Certificate Services
>
> +1 613.270.3743
>
> ECS Blog <http://www.entrust.com/author/bruce-morton/>
>
>
>
> _______________________________________________
> Questions mailing list
> Questions at cabforum.org
> https://cabforum.org/mailman/listinfo/questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140109/5535ca94/attachment-0002.html>