ICANN hires new VP from Yahoo!

ICANN has poached a Yahoo! executive to head up its outreach efforts in Asia.
Singapore-based Kuek Yu-Chuang, who held a similar role at Yahoo, has been named vice president for global stakeholder engagement for Asia. He starts August 1.
Asia is one of the regions in which ICANN is trying to establish itself a more prominent presence.
Singapore has been named as a “hub”, ostensibly of equal importance to its LA headquarters, and it was announced in April that a satellite office will also be opened in China.
Before Yahoo, Yu-Chuang had experience working for the Singapore government.

Four registrars terminated

Four small domain name registrars have lost their ICANN accreditation and their domain names have been transferred to another.
ICANN announced on Friday that US-based C I Host and Central Registrar (Domainmonger.com), along with Panama-based Power Brand Center have all been terminated for non-compliance.
Breach notices had been sent earlier this year covering everything from broken Whois to a failure to cooperate with audits.
Dotted Ventures, also American, had allowed its accreditation to lapse in March. It had, however, also been sent a breach notice for non-payment of ICANN fees in April.
The gTLD domains they managed, which amount to between a couple of hundred and a couple of thousand each, have all been transferred to UK-based Astutium, which isn’t much bigger.
Customers of each terminated registrar will receive notices from Astutium instructing them how to proceed, ICANN said. There shouldn’t be a cost to transfer, so any request for cash may be a phishing attack.

Verisign says people might die if new gTLDs are delegated

If there was any doubt in your mind that Verisign is trying to delay the launch of new gTLDs, its latest letter to ICANN and the Governmental Advisory Committee advice should settle it.
The company has ramped up its anti-expansion rhetoric, calling on the GAC to support its view that launching new gTLDs now will put the security and stability of the internet at risk.
People might die if some strings are delegated, Verisign says.
Among other things, Verisign is now asking for:

• Each new gTLD to be individually vetted for its possible security impact, with particular reference to TLDs that clash with widely-used internal network domains (eg, .corp).
• A procedure put in place to throttle the addition of new gTLDs, should a security problem arise.
• A trial period for each string ICANN adds to the root, so that new gTLDs can be tested for security impact before launching properly.
• A new process for removing delegated gTLDs from the root if they cause problems.

In short, the company is asking for much more than it has to date — and much more that is likely to frenzy its rivals — in its ongoing security-based campaign against new gTLDs.
The demands came in Verisign’s response to the GAC’s Beijing communique, which detailed government concerns about hundreds of applied-for gTLDs and provided frustratingly vague remediation advice.
Verisign has provided one of the most detailed responses to the GAC advice of any ICANN has received to date, discussing how each item could be resolved and/or clarified.
In general, it seems to support the view that the advice should be implemented, but that work is needed to figure out the details.
In many cases, it’s proposing ICANN community working groups. In others, it says each affected registry should negotiate individual contract terms with ICANN.
But much of the 12-page letter talks about the security problems that Verisign suddenly found itself massively concerned about in March, a week after ICANN started publishing Initial Evaluation results.
The letter reiterates the potential problem that when a gTLD is delegated that is already widely used on internal networks, security problems such as spoofing could arise.
Verisign says there needs to be an “in-depth study” at the DNS root to figure out which strings are risky, even if the volume of traffic they receive today is quite low.
It also says each string should be phased in with an “ephemeral root delegation” — basically a test-bed period for each new gTLD — and that already-delegated strings should be removed if they cause problems:

A policy framework is needed in order to codify a method for braking or throttling new delegations (if and when these issues occur) either in the DNS or in dependent systems that provides some considerations as to when removing an impacting string from the root will occur.

While it’s well-known that strings such as .home and .corp may cause issues due to internal name clashes and their already high volume of root traffic, Verisign seems to want every string to be treated with the same degree of caution.
Lives may be on the line, Verisign said:

The problem is not just with obvious strings like .corp, but strings that have even small query volumes at the root may be problematic, such as those discussed in SAC045. These “outlier” strings with very low query rates may actually pose the most risks because they could support critical devices including emergency communication systems or other such life-supporting networked devices.
…
We believe the GAC, and its member governments, would undoubtedly share our fundamental concern.

The impact of pretty much every recommendation made in the letter would be to delay or prevent the delegation of new gTLDs.
A not unreasonable interpretation of this is that Verisign is merely trying to protect its $800 million .com business by keeping competitors out of the market for as long as possible.
Remember, Verisign adds roughly 2.5 million new .com domains every month, at $7.85 a pop.
New gTLDs may well put a big dent in that growth, and Verisign doesn’t have anything to replace it yet. It can’t raise prices any more, and the patent licensing program it has discussed has yet to bear fruit.
But because the company also operates the primary DNS root server, it has a plausible smokescreen for shutting down competition under the guise of security and stability.
If that is what is happening, one could easily make the argument that it is abusing its position.
If, on the other hand, Verisign’s concerns are legitimate, ICANN would be foolhardy to ignore its advice.
ICANN CEO Fadi Chehade has made it clear publicly, several times, that new gTLDs will not be delegated if there’s a good reason to believe they will destabilize the internet.
The chair of the SSAC has stated that the internal name problem is largely dealt with, at least as far as SSL certificates go.
The question now for ICANN — the organization and the community — is whether Verisign is talking nonsense or not.

ICANN reveals 81 passes and one failure in latest new gTLD results batch

The weekly batch of new gTLD Initial Evaluation results has just been published, revealing 81 passes and one failure — the first failure that isn’t a dot-brand.
DOTPAY SA, a Swiss company, only scored 7 out of the necessary 8 points on its financial evaluation and is therefore now categorized as “Eligible for Extended Evaluation”.
That might be bad news for the other .pay applicant, Amazon, which will now have to wait some months for extended evaluation to take place before the contention set can be resolved.
DOTPAY’s .pay bid is the fourth application to fail Initial Evaluation.
The 81 passing applications this week are (links are to DI PRO):

.salon .music .loft .creditunion .careers .polo .vip .homedepot .mrporter .sarl .observer .dance .forsale .blue .game .market .fashion .tour .iwc .george .pink .fox .spiegel .reise kinder .hoteis .nike .arab .dev .diamonds .nico .cloud .law .tickets .photography .pay .channel .java .academy .nexus zippo .plus .enterprises .goog .apartments .supplies .gmbh .krd .fan .company .wow .spot .travelers .love .joburg .exchange .basketball .directory .art .today .money .kitchen .read .jot .vodka .icu .doha .hospital .chat .theguardian .jetzt .capital .natura .camp .protection .wow .gcc .pizza .supply .amex .wed .ott

There are now 514 passing applications. We’re up to 600 in the priority number queue.

ICANN won’t say how Demand Media passed its new gTLD background check

After badgering ICANN for a few weeks, I’ve finally got a firm “no comment” on the question of how new gTLD applicant Demand Media managed to pass its background checks.
The question of whether it’s possible for serial cybersquatters to bypass ICANN screening and be awarded new gTLDs just by setting up shell companies is still open, it seems.
As DI and other blogs have been reporting for the past few years, there was a question mark over Demand Media’s eligibility for the new gTLD program due to its history of cybersquatting.
Under ICANN rules, any company that lost three or more UDRP decisions with at least one loss in the last three years would not pass its background screening. The Applicant Guidebook states:

In the absence of exceptional circumstances, applications from any entity with or including any individual with convictions or decisions of the types listed in (a) – (m) below will be automatically disqualified from the program.
…
m. has been involved in a pattern of adverse, final decisions indicating that the applicant or individual named in the application was engaged in cybersquatting as defined in the Uniform Domain Name Dispute Resolution Policy (UDRP), the Anti-Cybersquatting Consumer Protection Act (ACPA), or other equivalent legislation, or was engaged in reverse domain name hijacking under the UDRP or bad faith or reckless disregard under the ACPA or other equivalent legislation. Three or more such decisions with one occurring in the last four years will generally be considered to constitute a pattern.

Demand Media subsidiary Demand Domains has lost over 30 UDRP cases, most recently in 2011, but its United TLD Holdco subsidiary has sailed through its Initial Evaluations.
Technically, shouldn’t it have failed screening and therefore IE?
Domain Name Wire speculated in November 2010 that ICANN had deliberately introduced loopholes in order to let Demand — and, at the time, Go Daddy — into the new gTLD program.
At that time, ICANN had just removed references to “any person or entity owning (or beneficially owning) fifteen percent or more of the applicant” in the background screening section of the Guidebook.
That might have introduced a loophole allowing subsidiaries of cybersquatters to apply.
But Demand Media seemed to think it was still at risk, asking ICANN in December 2010 to change the background check rules.
ICANN did. In the next version of the Guidebook, published in April 2011, it added the “In the absence of exceptional circumstances” qualifying language.
It’s also possible that this was the loophole that allowed Demand to pass screening.
Judging by the UDRP complaints it was involved in in the past, the company usually argued against the “bad faith” element of the policy. It often said it didn’t know about the complainant’s trademark and/or said it had offered to transfer the domain at no charge.
But more than 30 UDRP panelists didn’t buy that argument and still found against Demand. The company lost far more complaints than it won.
The fact that the company apparently managed to clean its act up a few years ago — not being hit with any complaints since 2011 — suggests that its act wasn’t all that clean to begin with.
Either way, neither ICANN nor Demand wants to talk about how the company passed screening, so I guess we’re still left wondering whether this section of the Guidebook is worth the PDF it’s written on.

Chinese geo gTLD bidder drops out of two-way fight

The Chinese government-controlled news agency Xinhua has dropped out of the race for the new gTLD .广东 — the local name of Guangdong, China’s most populous province.
The withdrawal clears a path for the only other applicant for the string, Guangzhou Yu Wei Information Technology, to pass more quickly through the ICANN approval process.
Guangzhou Yu Wei is affiliated with Zodiac Holdings, the Cayman Islands-based portfolio applicant founded by James Seng, but it also has backing from the Guangdong provincial government.
As a formally designated Geographic string, government backing is necessary for approval.
Xinhua had not appeared especially enthusiastic about its bid. Its prioritization number of 1772 means it didn’t bother to participate in ICANN’s lottery last December.
Zodiac, on the other hand, took advantage of the IDN bias in the process and wound up with a priority of 79. It passed Initial Evaluation in early April.
The company filed a Community application, but a Community Priority Evaluation will obviously no longer be required. It intends to restrict .广东 to registrants that can prove a local presence.
Zodiac is using .cn registry CNNIC as its back-end registry provider.

The True Historie of Trademark+50 and the Deathe of the GNSO (Parte the Thirde)

ICANN’s decision to press ahead with the “Trademark+50” trademark protection mechanism over the objections of much of the community may not be the end of the controversy.
Some in the Generic Names Supporting Organization are even complaining that ICANN’s rejection of a recent challenge to the proposal may “fundamentally alter the multi-stakeholder model”.
Trademark+50 is the recently devised adjunct to the suite of rights protection mechanisms created specially for the new gTLD program.
It will enable trademark owners to add up to 50 strings to each record they have in the Trademark Clearinghouse, where those strings have been previously ruled abusive under UDRP.
Once in the TMCH, they will generate Trademark Claims notices for both the trademark owner and the would-be registrant of the matching domain name during the first 60 days of general availability in each new gTLD.
Guinness, for example, will be able to add “guinness-sucks” to its TMCH record for “Guinness” because it has previously won guinness-sucks.com in a UDRP decision.
If somebody then tries to register guinness-sucks.beer, they’ll get a warning that they may be about to infringe Guinness’ trademark rights. If they go ahead and register anyway, Guinness will also get an alert.
Trademark+50 was created jointly by ICANN’s Business Constituency and Intellectual Property Constituency late last year as one of a raft of measures designed to strengthen rights protection in new gTLDs.
They then managed to persuade CEO Fadi Chehade, who was at the time still pretty new and didn’t fully appreciate the history of conflict over these issues, to convene a series of invitation-only meetings in Brussels and Los Angeles to try to get other community members to agree to the proposals.
These meetings came up with the “strawman solution”, a list of proposed changes to the program’s rights protection mechanisms.
Until two weeks ago, when DI managed to get ICANN to publish a transcript and audio recording of the LA meetings, what was said during these meetings was shrouded in a certain degree of secrecy.
I don’t know why. Having listened to the 20-hour recording, I can tell you there was very little said that you wouldn’t hear during a regular on-the-record public ICANN meeting.
Everyone appeared to act in good faith, bringing new ideas and suggestions to the table in an attempt to find a solution that was acceptable to all.
The strongest resistance to the strawman came, in my view, from the very small number (only one remained by the end) of non-commercial interests who had been invited, and from the registrars.
The non-coms were worried about the “chilling effect” of expanding trademark rights, while registrars were worried that they would end up carrying the cost of supporting confused or frightened registrants.
What did emerge during the LA meeting was quite a heated discussion about whether the IPC/BC proposals should be considered merely “implementation” details or the creation of new “policy”.
That debate spilled over into 2013.
Under the very strictest definition of “policy”, it could be argued that pretty much every aspect of every new rights protection mechanism in the Applicant Guidebook is “implementation”.
The only hard policy the GNSO came up with on trademarks in new gTLDs was back in 2008. It reads:

Strings must not infringe the existing legal rights of others that are recognized or enforceable under generally accepted and internationally recognized principles of law.

Pretty much everything that has come since has been cobbled together from community discussions, ad hoc working groups, ICANN staff “synthesis” of public comments, and board action.
But many in the ICANN community — mainly registries, registrars and non-commercial interests — say that anything that appears to create new rights and/or imposes significant new burdens on the industry should be considered “policy”.
During the LA meetings, there was broad agreement that stuff like extending Trademark Claims from 60 to 90 days and instituting a mandatory 30-day notice period before each Sunrise period was “implementation”.
Those changes won’t really incur any major new costs for the industry; they merely tweak systems that already have broad, if sometimes grudging, community support.
But the attendees were split (IPC/BC on the one side, most everyone else on the other) about whether Trademark+50, among other items, was new policy or just an implementation detail.
If something is “policy” there are community processes to deal with it. If it’s implementation it can be turned over to ICANN staff and forgotten.
Because the registries and registrars have an effective veto on GNSO policy-making and tend to vote as a bloc, many others view a “policy” label as a death sentence for something they want done.
A month after the strawman meetings, in early December, ICANN staff produced a briefing paper on the strawman solution (pdf) for public comment. Describing what we’re now calling Trademark+50, the paper stated quite unambiguously (it seemed at the time):

The inclusion of strings previously found to be abusively registered in the Clearinghouse for purposes of Trademark Claims can be considered a policy matter.

Chehade had previously — before the strawman meetings — strongly suggested in a letter to members of the US Congress that Trademark+50 was not doable:

It is important to note that the Trademark Clearinghouse is intended be a repository for existing legal rights, and not an adjudicator of such rights or creator of new rights. Extending the protections offered through the Trademark Clearinghouse to any form of name (such as the mark + generic term suggested in your letter) would potentially expand rights beyond those granted under trademark law and put the Clearinghouse in the role of making determinations as to the scope of particular rights.

Personally, I doubt then-new Chehade wrote the letter (at least, not without help). It mirrors Beckstrom-era arguments and language and contrasts with a lot of what he’s said since.
But it’s a pretty clear statement from ICANN’s CEO that the expansion of Trademark Claims to Trademark+50 night expand trademark rights and, implicitly, is not some throwaway implementation detail.
Nevertheless, a day after the staff briefing paper Chehade wrote to GNSO Council chair Jonathan Robinson in early December to ask for “policy guidance” on the proposal.
Again, there was a strong suggestion that ICANN was viewing Trademark+50 as a policy issue that would probably require GNSO input.
Robinson replied at the end of February, after some very difficult GNSO Council discussions, saying “the majority of the council feels that is proposal is best addressed as a policy concern”.
The IPC disagreed with this majority view, no doubt afraid that a “policy” tag would lead to Trademark+50 being gutted by the other GNSO constituencies over the space of months or years.
But despite ICANN staff, most of the GNSO Council and apparently Chehade himself concluding that Trademark+50 was policy, staff did a U-turn in March and decided to go ahead with Trademark+50 after all.
An unsigned March 20 staff report states:

Having reviewed and balanced all feedback, this proposal appears to be a reasonable add-on to an existing service, rather than a proposed new service.
…
It is difficult to justify omission of a readily available mechanism which would strengthen the trademark protection available through the Clearinghouse. Given that the proposal relies on determinations that have already been made independently through established processes, and that the scope of protection is bounded by this, concerns about undue expansion of rights do not seem necessary.

This caught the GNSO off-guard; Trademark+50 had looked like it was going down the policy track and all of a sudden it was a pressing reality of implementation.
Outraged, the Non-Commercial Stakeholders Group, which had been the strongest (if smallest through no fault of their own) voice against the proposal during the strawman meetings filed a formal Reconsideration Request (pdf) with ICANN.
Reconsideration Requests are one of the oversight mechanisms built into ICANN’s bylaws. They’re adjudicated by ICANN’s own Board Governance Committee and never succeed.
In its request, the NCSG told a pretty similar history to the one I’ve just finished relating and asked the BGC to overturn the staff decision to treat Trademark+50 as implementation.
The NCSG notes, rightly, that just because a domain has been lost at UDRP the string itself is not necessarily inherently abusive. To win a UDRP a complainant must also demonstrate the registrant’s bad faith and lack of rights to the string at issue.
To return to the earlier example, when notorious cybersquatter John Zuccarini — an unambiguously bad guy — registered guinness-sucks.com back in 2000 he told Guinness he’d done it just to piss them off.
That doesn’t mean guinness-sucks.beer is inherently bad, however. In many jurisdictions I would be well within my rights to register the domain to host a site criticizing the filthy brown muck.
But if I try to register the name, I’m going to get a Trademark Claims notice asking me to verify that I’m not going to infringe Guinness’ legal rights and advising me to consult a lawyer.
Chilling effect? Maybe. My own view is that many people will just click through the notice as easily as they click through the Ts&Cs on any other web site or piece of software.
Either way, I won’t be able to claim in court that I’d never heard of Guinness^TM, should the company ever decide to sue me.
Anyway, the NCSG’s Reconsideration Request failed. On May 16 the BGC issued a 15-page determination (pdf) denying it.
It’s this document that’s causing consternation and death-of-the-GNSO mutterings right now.
Last week, Neustar’s lead ICANN wonk Jeff Neuman asked for the Reconsideration Request to be put on the agenda of the GNSO Council’s June 13 meeting. He wants BGC representatives to join the call too. He wrote:

This decision was clearly written by legal counsel (and probably from outside legal counsel). It was written as a legal brief in litigation would be written, and if upheld, can undermine the entire bottom-up multi-stakeholder model. If ICANN wanted to justify their decision to protect their proclamation for the 50 variations, they could have done it in a number of ways that would have been more palatable. Instead, they used this Reconsideration Process as a way to fundamentally alter the multi-stakeholder model. It not only demonstrates how meaningless the Reconsideration process is as an accountability measure, but also sends a signal of things to come if we do not step in.

He has support from other councilors.
I suspect the registries that Neuman represents on the Council are not so much concerned with Trademark+50 itself, more with the way ICANN has forced the issue through over their objections.
The registries, remember, are already nervous as hell about the possibility of ICANN taking unilateral action to amend their contracts in future, and bad decision-making practices now may set bad precedents.
But Neuman has a point about the legalistic way in which the Reconsideration Request was handled. I spotted a fair few examples in the decision of what can only be described as, frankly, lawyer bullshit.
For example, the NCSG used Chehade’s letter to Congress as an example of why Trademark+50 should be and was being considered “policy”, but the BGC deliberately misses the point in its response, stating:

The NCSG fails to explain, however, is how ICANN policy can be created through a proclamation in a letter to Congress without following ICANN policy development procedures. To be clear, ICANN cannot create policy in this fashion.

Only a lawyer could come up with this kind of pedantic misinterpretation.
The NCSG wasn’t arguing that Chehade’s letter to Congress created a new policy, it was arguing that he was explaining an existing policy. It was attempting to say “Hey, even Fadi thought this was policy.”
Strike two: the NCSG had also pointed to the aforementioned staff determination, since reversed, that Trademark+50 was a policy matter, but the BCG’s response was, again, legalistic.
It noted that staff only said Trademark+50 “can” be considered a policy matter (rather than “is”, one assumes), again ignoring the full context of the document.
In context, both the Chehade letter and the March staff document make specific reference to the fact that the Implementation Recommendation Team had decided back in 2009 that only strings that exactly match trademarks should be protected. But the BGC does not mention the IRT once in its decision.
Strike three: the BGC response discounted Chehade’s request for GNSO “policy guidance” as an “inartful phrase”. He wasn’t really saying it was a policy matter, apparently. No.
Taken as a whole, the BGC rejection of the Reconsideration Request comes across like it was written by somebody trying to justify a fait accompli, trying to make the rationale fit the decision.
In my view, Trademark+50 is quite a sensible compromise proposal with little serious downside.
I think it will help trademark owners lower their enforcement costs and the impact on registrars, registries and registrants’ rights is likely to be minimal.
But the way it’s being levered through ICANN — unnecessarily secretive discussions followed by badly explained U-turns — looks dishonest.
It doesn’t come across like ICANN is playing fair, no matter how noble its intentions.

A little iCal tool that might make your ICANN life a little easier

I’ve created a little free service that might make it a little easier for regular participants in ICANN public comment periods to keep track of deadlines.
It’s basically an iCal feed that should automatically update your online calendar whenever a new comment period is created or extended by ICANN.
This is the link: http://domainincite.com/pro/publiccommentcalendar.php
If you click it you’ll see it attempts to download a .ics (iCal) file to your computer. The contents are automatically created, daily, based on whatever deadlines ICANN has published on its web site.
If you use Google Calendar (as I do) you can add the calendar to your existing calendars by clicking the “Other calendars” drop-down in the Google Calendar sidebar, then “Add by URL”.
My Apple-using guinea pigs tell me that the same functionality is possible with the Mac’s built in Calendar software, by clicking on “File” and “New Calendar Subscription”.
It seems to work with Yahoo! Calendar too.
Subscribing should immediately add the 30-odd current public comment deadlines to your calendar, automatically adjusted to your time zone.
With Google Calendar, the entries are easy enough to remove if you don’t like what you see. I expect the same is true in other software.
If it’s working properly, updates should be automatically reflected in your calendar on a daily basis.
It hasn’t been tested on any other platforms yet, but iCal seems to be a widely-embraced technical standard so I can’t see why it won’t work everywhere.
As you may be able to tell, I’m providing this service for free very much “as is”. If ICANN changes the layout of it its web site or my code is dodgy, it will stop working properly.
In other words, if it breaks and you miss a deadline, don’t blame me.
But if it does work and it makes keeping track of things a little simpler, feel free to buy me a pint.
Bug reports, suggestions and grovelling thanks to the usual address.

Two more new gTLD bids bite the dust

ICANN appears to have formally killed off two new gTLD applications that had asked for subsidized application fees.
The bids for .idn and .ummah both failed to meet the criteria of ICANN’s Applicant Support Program back in March, but were only officially marked as dead over the weekend.
The .ummah application was voluntarily withdrawn by Ummah Digital, while the applicant for .idn (an Indian company called NameShop) unsuccessfully fought the decision.
Nevertheless, NameShop has now been flagged on ICANN’s site with “Did not meet all criteria” for the Applicant Support Program.
We’re taking this as a signal it’s been officially kicked out of the current application round and have updated the DI PRO database accordingly.
As well as failing applicant support, NameShop would have failed the Geographic Names component of its Initial Evaluation because IDN is the reserved three-letter country code for Indonesia.
NameShop had attempted to change its application from .idn to .internet — something that would no doubt have cause a deal of consternation among potential objectors and other applicants.
By flunking the company on the applicant support criteria, ICANN has luckily avoided having to make that difficult call.

Is the .home new gTLD doomed? ICANN poses study of security risks

ICANN has set up a study into whether certain applied-for new gTLD strings pose a security risk to the internet, admitting that some gTLDs may be rejected as a result.
Its board of directors on Saturday approved new research into the risk of new gTLD clashes with “internal name certificates”, saying that the results could kill off some gTLD applications.
In its rationale, the board stated:

it is possible that study might uncover risks that result in the requirement to place special safeguards for gTLDs that have conflicts. It is also possible that some new gTLDs may not be eligible for delegation.

Internal name certificates are the same digital certificates used in secure, web-based SSL transactions, but assigned to domain names in private, non-standard namespaces.
Many companies have long used non-existent TLDs such as .corp, .mail and .home on their private networks and quite often they obtain SSL certs from the usual certificate authorities in order to enable encryption between corporate resources and their internal users.
The problem is that browsers and other applications on laptops and other mobile devices can attempt to access these private namespaces from anywhere, not only from the local network.
If ICANN should set these TLD strings live in the authoritative DNS root, registrants of clashing domain names might be able to hijack traffic intended for secure resources and, for example, steal passwords.
That’s obviously a worry, but it’s one that did not occur to ICANN’s Security and Stability Advisory Committee until late last year, when it immediately sought out the help of the CA/Browser Forum.
It turned out the the CA/Browser forum, an alliance of certificate authorities and browser makers, was already on the case. It has put in new rules that state certificates issued to private TLDs that match new gTLDs will be revoked 120 days after ICANN signs a contract with the new gTLD registry.
But it’s still not entirely clear whether this will sufficiently mitigate risk. Not every CA is a member of the Forum, and some enterprises might find 120 day revocation windows challenging to work with.
Verisign recently highlight the internal certificate problem, along with many other potential risks, in an open letter to ICANN.
But both ICANN CEO Fadi Chehade and the chair of SSAC, Patrick Falstrom, have said that the potential security problems are already being addressed and not a reason to delay new gTLDs.
The latest board resolution appears to modify that position.
The board has now asked CEO Fadi Chehade and SSAC to “consider the potential security impacts of applied-for new-gTLD strings in relation to this usage.”
The Root Server Stability Advisory Committee and the CA/Browser Forum will also be tapped for data.
While the study will, one assumes, not be limited to any specific applied-for gTLD strings, it’s well known that some strings are more risky than others.
The root server operators already receive vast amounts of erroneous DNS traffic looking for .home and .corp, for example. If any gTLD applications are at risk, it’s those.
There are 10 remaining applications for .home and five for .corp.