Registries propose PKI-based new gTLD sunrises

Neustar and ARI Registry Services have come up with an alternative to ICANN’s proposed new gTLDs sunrise period process, based on a secure Public Key Infrastructure.
The concept was outlined in a draft paper published today, following an intensive two-day tête-à-tête between domain companies and Trademark Clearinghouse providers IBM and Deloitte last month.
It’s presented as an alternative to the implementation model proposed by ICANN, which would use unique codes and was criticized for being inflexible to the needs of new gTLD registries.
The PKI-based alternative from Neustar and ARI would remove some of the cost and complexity for registries, but may create additional file-management headaches for trademark owners.
Under the ICANN model, which IBM and Deloitte are already developing, each trademark owner would receive a unique code for each of their registered trademarks and each registry would be given the list of codes.
If a trademark owner wanted a Sunrise registration, it would submit the relevant code to their chosen registrar, which would forward it to the registry for validation against the list.
One of the drawbacks of this method is that registries don’t get to see any of the underlying trademark data, making it difficult to restrict Sunrise registrations to certain geographic regions or certain classes of trademark.
If, for example, .london wanted to restrict Sunrise eligibility to UK-registered trademarks, it would have no easy way of doing so using the proposed ICANN model.
But IP interests participating in the development of the Trademark Clearinghouse have been adamant that they don’t want registries and registrars getting bulk access to their trademark data.
They’re worried about creating new classes of scams and have competitive concerns about revealing their portfolio of trademarks.
Frankly, they don’t trust registries/rars not to misuse the data.
(The irony that some of the fiercest advocates of Whois accuracy are so concerned about corporate privacy has not been lost on many participants in the TMCH implementation process.)
The newly proposed PKI model would also protect trademark owners’ privacy, albeit to a lesser extent, while giving registries visibility into the underlying trademark data.
The PKI system is rather like SSL. It used public/private key pairs to digitally sign and verify trademark data.
Companies would submit trademark data to the Clearinghouse, which would validate it. The TMCH would then sign the data with its private key and send it back to the trademark owner.
If a company wished to participate in a Sunrise, it would have to upload the signed data — most likely, a file — to its registrar. The registrar or registry could then verify the signature using the TMCH’s public key.
Because the data would be signed, but not encrypted, registrars/ries would be able to check that the trademark is valid and also get to see the trademark data itself.
This may not present a privacy concern for trademark owners because their data is only exposed to registries and registrars for the marks they plan to register as domains, rather than in bulk.
Registries would be able to make sure the trademark fits within their Sunrise eligibility policy, and would be able to include some trademark data in the Whois, if that’s part of their model.
It would require more file management work by trademark owners, but it would not require a unique code for each gTLD that they plan to defensively register in.
The Neustar/ARI proposal suggests that brand-protection registrars may be able to streamline this for their clients by enabling the bulk upload of trademark Zip files.
The overall PKI concept strikes me as more elegant than the ICANN model, particularly because it’s real-time rather than using batch downloads, and it does not require the TMCH to have 100% availability.
ICANN is understandably worried that about the potentially disastrous consequences for the new gTLD program if it creates a TMCH that sits in the critical registration path and it goes down.
The PKI proposal for Sunrise avoids this problem, as registries and registrars only need a stored copy of the TMCH’s public key in order to do real-time validation.
Using PKI for the Trademark Claims service — the second obligatory rights protection mechanism for new gTLD launches — is a much trickier problem if ICANN is to stick to its design goals, however.
ARI and Neustar plan to publish their Trademark Claims proposal later this week. For now, you can read the Sunrise proposal in PDF format here.

Why domain names need punctuation

ICANN wants to know whether it should formally ban “dotless” domain names in the gTLDs for which it oversees policy.
While the Applicant Guidebook essentially prohibits registries using their new gTLDs without dots, there’s not yet a hard ban in the template Registry Agreement.
But that could change following a new ICANN public comment period.
A dotless domain might appear in a browser address bar as http://tld or, with more modern browsers, more likely just tld. A small number of ccTLDs already have this functionality.
To make it work, TLDs need to place an A record (or AAAA record for IPv6) in the root zone. This is known as an apex A record, which the Applicant Guidebook says ICANN will not permit.
The result, IANA root zone manager Kim Davies told us in July 2011, is a “default prohibition on dotless domains”.
Davies could not rule out apex A/AAAA records entirely, however. Specific requests for such functionality might be entertained, but would likely trigger an Extended Evaluation.
ICANN’s Security and Stability Advisory Committee is of the opinion that dotless gTLDs should not be permitted on various security grounds, including the fact that lots of software out there currently assumes a domain without a dot is a trusted host on the local network.
You can read the SSAC report here.
Dotless domains would also mess up browsers such as Chrome, which have integrated address/search bars; when you type “loreal” do you intend to search for the brand or visit its TLD’s web site?
But a far more intuitive, non-technical argument against dotless domains, as CentralNic’s Joe Alagna noted in his blog over the weekend, is that they do not pass the cocktail party test.
It’s hard enough trying to communicate the address “domainincite.com” across a noisy cocktail party as it is, but at least the dot immediately informs the listener that it’s a domain name.
Without dots, are we even talking about domain names any more?
The first phase of the new comment period runs until September 23. We understand that, depending on responses, a new ban on dotless domains could be introduced to the standard new gTLD registry agreement and possibly even added to legacy registry agreements in future.

DI PRO offers full-text new gTLD comment search

With ICANN today saying that it is “very inclined” to extend the public comment period on new gTLD applications, I thought it timely to announce a new feature for DI PRO subscribers.
If you’ve used ICANN’s web site to try to read some of the 4,000+ comments received to date, you might have noticed that it’s not always particularly easy to find what you’re looking for.
So I thought I’d write something a bit more functional.
These are some features of the new DI PRO new gTLD public comment search engine that I don’t think the ICANN site currently offers:
Search the full text of the comments. This is useful for, say, figuring out which comments discuss particular themes or issues, or are part of organized astroturf campaigns.
Search and sort by commenter affiliation. Want to see every comment filed by Tiffany or Lego or Heinz? If the commenter has disclosed his or her affiliation, you can do that.
Search by partial commenter name. There’s no need to remember the full name of the commenter you’re looking for. First name, last name, or just a few letters will suffice.
Search by alternate applicant name. The DI PRO database understands which applications originate from the likes of Google and Donuts and Famous Four Media, even if the application has been filed by a subsidiary with a different name.
The database is updated at least twice daily, rather than in real-time, so users may find a small delay between the time a comment appears on the ICANN site and the time it is indexed by DI.
Subscribers can start searching here.

ICANN trademark tech summit confirmed for Brussels in just two weeks

ICANN has confirmed that it will hold a technical summit to discuss the forthcoming Trademark Clearinghouse in Brussels less than two weeks from now.
The two-day meeting will be held at the offices of Deloitte, which along with IBM has been contracted as the TMCH provider, from August 20 to 21.
As you might expect by now from the new gTLD program, the summit’s organization wasn’t particularly timely or well-communicated, leaving parts of the community fuming.
The meeting was demanded by registries and registrars at the Prague meeting in June — they want a chance for their technical guys to get into the nitty-gritty of the TMCH implmentation.
But confirmation that it’s actually going ahead only arrived in the last couple of days, leaving companies in the US and Asia-Pacific regions facing steep last-minute air fares or the less-ideal option of remote participation at ungodly hours.
I get the impression that the TMCH providers, which have been less than communicative with the registrars and registries they will soon be servicing, might be as much to blame as ICANN this time.
The TMCH is a repository for trademark data that new gTLD registries will be obliged to use in their sunrise and immediate post-launch periods.
While the policy argument has ostensibly been settled, many technical details that still need to be ironed out could have huge implications.
For example, if the registration process flow requires live queries to the TMCH, downtime could be devastating for registries if, as is expected, several gTLDs wind up launching simultaneously.
And if the TMCH protocols prove to be too complex and costly for registrars to implement, many may not bother, potentially leading to a bunch of damp squib gTLD launches.
So it’s important stuff. DI may even be in attendance, hotel prices and/or Belgian vagrancy laws permitting.

ICANN shuts down new gTLD portal after finding more security bugs

ICANN has closed down part of its new generic top-level domain portal after finding “potential vulnerabilities” that put “confidential applicant information” at risk.
The shutdown — which has been going on for at least 30 hours — affects the Customer Service and Knowledge Base parts of the site, but ICANN said it is so far not aware of any attacks against the system.
While it’s waiting for a patch, ICANN has decided to move the affected areas behind the unpopular Citrix remote terminal software used previously in the TLD Application System.
This notice was posted on the site:

ICANN performs ongoing monitoring and analysis of our systems, including the Customer Service system. As part of this work, we recently identified potential vulnerabilities in the system used for Customer Service and the Knowledge Base (containing new gTLD articles and information).
Patches are being provided to ICANN to address these issues.
In the mean time, given that use of the Customer Service system was recently expanded, and now includes confidential applicant information, the decision was taken to move the system behind Citrix. This will provide for additional security for applicant information.
We are now testing the installation. This should be completed in the next few days. This decision is a proactive measure. There have been no known compromises to the data, attacks or other actions by third parties (other than our own analysis).

Off the top of my head — and I may be under-counting — this is the fifth significant technical glitch to hit the new gTLD program since April.
There was the notorious TAS bug, which took the system offline entirely for six weeks while ICANN fixed a data leakage vulnerability and upgraded its system capacity.
There was the Reveal Day screw-up, during which Arab community members noticed that all the applied-for Arabic gTLDs were broadcast back-to-front in a presentation.
Then ICANN accidentally published the home addresses of many applicants’ officers and directors, something it had promised not to do. This was probably human error and it has since apologized.
Then the “digital archery” batching system was yanked, after it emerged that TAS performance still wasn’t up to the task and that the scoring results were unreliable.
Former new gTLD program director Michael Salazar resigned a month ago; it is widely believed that he was taking the fall for the gTLD system bugs to that point.
While the latest bug appears — so far — to have not compromised any data, some applicants have nevertheless been frustrated by the fact that the customer service portal has been offline for over a day.

Is this why digital archery is borked?

Another possible explanation has been put forward for ICANN’s suspension of digital archery, this time by one of the third-party digital archery service providers.
The ambitiously named Digital Archery Experts says it alerted ICANN to the presence of a technical problem a week ago.
Chief technology officer Dirk Bhagat described it thus:

Instead of generating the timestamp immediately, we believe the TAS timestamp generation process may be delayed by increases in system load…
Since most applicants are aiming for the 000 millisecond variance at the minute mark, this can introduce varying timestamps since applicants are shooting for the exact same second on the minute. We have also noted that our results were a lot more consistent when attempts were made to hit the target at various offsets after the minute mark, for example, aiming for 15:32:07 instead of 15:32:00.

It’s not exactly rocket science. In short, he’s saying that the TAS can’t handle too many applicants logging in and shooting at the same time; more load equals poorer performance.
This won’t be news to many applicants, some of whom saw downtime last week that seemed to be caused by a meltdown of the sluggish Citrix virtual machine software.
It also seems to be consistent with the hypothesis that the massive amount of calibration going on — much of it by digital archery service providers themselves — has caused more load than TAS can handle.
With only 20% of applications currently assigned a timestamp, and only a week left on the clock, the situation could only have been exacerbated by lots of last-minute arrows being fired.
While digital archery may be conceptually similar to grabbing a dropping domain or hitting a landrush, it seems pretty clear that TAS is not as redundantly provisioned as the typical registry SRS.
Bhagat said that ICANN could mitigate the impact of the problem by separating timestamp generation as much as possible from the parts of the infrastructure impacted most by system load.
This might all be academic, however.
ICANN suspended digital archery yesterday, a day after new gTLD program director Michael Salazar quit for reasons unknown.
Digital archery and batching are high on the agenda here at ICANN 44 in Prague, and many attendees hope that the controversial system may be gone for good before the week is out.
That includes some members of the Governmental Advisory Committee, which in an open meeting yesterday seemed to be coming to the conclusion that it would advise ICANN to ditch digital archery.
The GAC and the ICANN’s board’s new gTLD program committee are having their first public facetime this afternoon at 1630 local time, at which a better sense of how both plan to proceed might emerge.

DI launches new gTLD application tracker with built-in string similarity checker

I’m excited to announce the launch of a comprehensive new gTLD application tracking service, featuring a unique built-in string similarity checker, right here on DI.
The service will provide the foundation for all of DI’s new gTLD program analysis over the coming months and years, and is designed to bring together all the best information about each application under one roof.
DI PRO subscribers can start playing with it now here.
All 1,930 applications can currently be searched and sorted by applicant, string, back-end registry provider, and status.

Users can also cross-reference applications in contention sets and read salient extracts from each application.
The gTLD application database will shortly be linked to the existing PROfile service, meaning DI PRO subscribers will have access to a database of over 3,000 domain name industry companies.
More features and bid-by-bid analysis will be added as the program progresses, but the feature I’m most excited about today is the string similarity checker, which is already built into every application profile.
This tool checks for visual and phonetic similarity with other applications, existing gTLDs and ccTLDs, as well as strings that are specially protected by the ICANN Applicant Guidebook.
Semantic similarity functionality will be added in the next few days.
Similarity is important for two reasons:
1) the String Similarity Panel, which will create new contention sets based on similar but not identical strings in a couple of months, and
2) the String Confusion Objection, which enables applicants to force rivals into the same contention set based on visual, aural or semantic similarity.
In testing, it’s already thrown up some possible future objections and contention sets that I had not previously considered, and early beta testers — applicants themselves — tell me they think it’s fantastic.
Here’s a screenshot from one of the .sex applications, to give you a taste.

Note that, unfortunately, the string similarity feature does not currently support the relatively small number of IDN string applications.
If you’re not already a DI PRO subscriber, you can sign up instantly here using PayPal. If you have any questions about the service, please email subs@domainincite.com.

Is digital archery bugged too?

ICANN’s digital archery system, which will be used to decide the fates of many new gTLD applicants, may have a bug, according to one applicant.
In a must-read post over on CircleID, Top Level Domain Holdings CEO Antony Van Couvering presents some intriguing evidence that ICANN’s system may be mis-recording timestamps.
Van Couvering hypothesizes that that when applicants’ clicks are recorded before their target time, the software records “the wrong seconds value, but with the right milliseconds value”.
He’s asked ICANN to look into the issue, and has added his voice to those clamoring for gTLD batching to be scrapped entirely.
With so many applicants using custom software to fire their arrows, millisecond differences will be hugely important.
However, as Van Couvering notes, ICANN does not plan to reveal applicants’ scores until July 11, so it’s impossible to tell if this alleged “bug” in the test suite is replicated in the live firing range.
The digital archery system uses the now-notoriously flawed TLD Application System.
JUNE 12 UPDATE:
In a follow-up post, Van Couvering reports, based on a conversation with ICANN, that the “bug” was indeed present, but that it was in the presentation layer, rather than the underlying database.
In other words, it was cosmetic and unlikely to influence the outcome of the batching process.

Google Chrome handles new TLDs badly

Sint Maarten’s new .sx country-code top-level domain has been online for at least a couple months now, but Google’s Chrome browser appears to be still a bit wary of it.
Typing “registry.sx” and “nic.sx” into Chrome’s combined URL/search bar today, instead of being sent to my chosen destination I was instead sent to a page of Google search results.
The browser presented the message “Did you mean to go to http://registry.sx?”.

Once my intentions were confirmed, Chrome bounced me to the registry’s web site and seemed to remember my preference on future visits. Other Chrome users have reported the same behavior.
Chrome is understood to use the Public Suffix list to figure out what is and isn’t a domain, and .sx does not currently appear on that list.
Internet Explorer and Firefox (also a Public Suffix list user) both seem already to resolve .sx names normally.
While not a massive problem for .sx, which has just a handful of second-level domains active, new gTLD applicants might want to pay attention to this kind of thing.
Chrome has a significant share of the browser market – about 15% by some counts, as high as 38% by others.
Launching a new gTLD without full browser support could look messy. Chrome isn’t blocking access to .sx, but its handling of the new TLD is not particularly graceful.
Imagine a scenario in which you’ve just launched your dot-brand, and instead of arriving at your web site Chrome users are instead directed to Google (with the top sponsored result a link you’ve probably paid for).
ICANN is currently pondering ways to promote the universal acceptance of TLDs for precisely this reason.
Searches for the pop producer Will.I.Am prompt Chrome to attempt to find an address in the Armenian ccTLD.

Newbie domain registrant discovers Whois, has Twitter meltdown

The need for the domain name industry to enforce accurate Whois is often cited by law enforcement and intellectual property interests as a consumer protection measure.
But most regular internet users haven’t got a clue that Whois even exists, let alone what data it contains or how to use it.
A study (pdf) carried out for ICANN’s Whois Review Team last year found that only 24% of consumers know what Whois is.
This stream of tweets I chanced across this afternoon, from what appears to be a first-time domain registrant, is probably more representative of consumer attitudes to Whois.
UPDATE (April 27): I’ve removed the tweets per the request of the Twitter user in question.