MENU
  • Enom.com
  • Resellers

Enom Blog

July, 2019
Archive

  • The Importance of Authentication in SSL

    July 23, 2019

    Advice, SSL

     Like

    Views: 3212

    Update: Our latest Digicert Webinar covers the importance of authentication in SSL, and how it’s a key factor in properly marketing and selling certificates:


    Browsers have evolved to offer a better user experience and greater attention to security. Perhaps most importantly, they now display a security warning to users when they land on a website that lacks encryption:

    This is a step forward to a safer Internet, but encryption is only part of the security equation. 

    Without a means to verify the owner of that website, the user can’t be sure who they are sending their information to. 

    When SSL certificates were first introduced, they served both these critical purposes:  

    1.  Encrypting the data in transit

    2.  Authenticating the website to which the data is being sent

    They were issued by a small handful of Certificate Authorities (CAs), accredited and compliant third parties able to provide both encryption and authentication of your website. 

    But as the Internet grew, so did the number of CAs in the market, and the variety of SSL options. And what was the main differentiating factor among these certificates? The level of authentication they provided.

    Today, SSL products range from free “encryption-only” certificates, which can be registered in a matter of minutes, to Extended Validation (EV) SSL certificates, which, as their name suggests, involve a thorough validation (authentication) process as part of their registration. 

    When choosing an SSL certificate for your site, or helping a customer select one for theirs, your main question should be: what level of authentication do I need? After reading this blog, the answer will be clear.

     

    Minimal Authentication: Domain-Validation (DV) Certificates 

    DV certificates are often described as “encryption-only” because they don’t provide confirmation of who the website owner really is. To register a DV certificate, the website owner simply needs to prove ownership of the domain name(s) they are trying to secure. 

    Think of a DV certificate like a library card: they are easy to obtain and aren’t considered a credible form of identification. 

     

     

    When to use a DV certificate

    These certificates are sufficient if you’re securing a page just to maintain browser compliance (and avoid those warnings), or if you’re hosting a site that purely provides information and you want it done securely.

     

    Basic Authentication: Organization-Validation (OV) Certificates

    Before issuing an Organization-validated certificate, the Certificate Authority vets the organization and individual applying for the certificate. If a website visitor chooses to view the OV certificate, they’ll find this verified company information included in the details. 

    You can think of an OV certificate like a driver’s license: obtaining one involves a bit more hoop-jumping, but they are better trusted as a form of identification. 

     

     

     When to use an OV certificate

    If you collect any basic personal information from your users, for example, login credentials, they’ll likely want to know who they are sending this information to. An OV certificate from a reputable CA may provide sufficient authentication and assurance in these cases. 

    However, Extended Validation certificates (see below) are often a better fit for e-commerce pages or business-critical sites where consumer trust is particularly important.

     

    Advanced Authentication: Extended-Validation Certificates

    Extended-validation (EV) certificates involve the most rigorous authentication process and, consequently, provide the highest level of assurance to website visitors. 

    What’s more, as mentioned above, they do this in a very obvious way: a green address bar that includes the name of the company. Finally, the CA Browser Forum, the SSL industry’s governing body, sets specific guidelines to govern the registration and authentication process for EV certificates. 

    These factors combine to make EV certificates the gold standard, and the assurance they provide becomes ever more essential as the average Internet user becomes savvier and security standards rise. 

    Continuing with our analogy, EV certificates can be thought of as passports: they are internationally recognized as the most trusted way to verify a website owner’s identity.

     

     

    When to use an EV Certificate  

    We recommend using an EV if you’re looking to establish a high level of consumer trust or collecting sensitive information, which could range from login credentials to national identifiers, to credit card information. While not all browsers treat EV certificates the same way, for users, the additional visual cues can inspire trust and confidence to proceed with the transaction or activity.

     

    Looking to better market your SSL lineup?

    Our partners at DigiCert have some great resources to help you educate your customers and help them find the right fit.  Through your partnership with us, you have access to an array of brands and certificate types to help make sure you properly meet the needs of your specific customer for their specific project. You can view our SSL offering here.

     


    This post was sponsored by DigiCert, an Enom partner, and leading Certificate Authority.

     

     

    Read More

  • The Evolution of the Domain Transfer Process

    July 16, 2019

    GDPR, Industry Insight

     Like

    Views: 2981

    people exchanging keys

    ICANN’s Inter-Registrar Transfer Policy (IRTP) defines the procedures and rules for domain name transfers. When it was first introduced in 2004, the Policy was limited to inter-registrar transfers. Over the years, it has been revised by Policy Development Process (PDP) Working Groups and expanded to include governance of domain ownership transfers and a transfer dispute process. But the original rules for inter-registrar transfers remained mostly unchanged until May 2018, when the Temp Spec came into effect, modifying the process for a post-GDPR world where Whois data, which had long been the primary means of transfer verification, was no longer publicly available.

    But the Temp Spec is temporary. So what’s the long-term plan?

    The last few months have been interesting. First, we’re now in the gap between the Temp Spec’s expiration and any formal update to the Transfer Policy. ICANN’s Expedited Policy Development Process (EPDP) team has recommended continuing to use the process outlined in the Temp Spec in the interim. The EPDP team also made several recommendations as to how the Transfer Policy should be modified, which we can expect to see reflected in those updates.

    Secondly, and much to the delight of domain policy enthusiasts (we exist!), the Transfer Policy came due for review by the GNSO Council. This is a standard practice for all ICANN Consensus policies: once a policy has been in place for a number of years, ICANN Staff compiles a report on its effects, which the GNSO Council uses to decide if the policy needs to be modified. This time around, the decision is a pretty clear one—the fact that we’re still following the Temp Spec method instead of the pre-GDPR transfer process points to the need to update the Policy. The Revised Inter-Registrar Transfer Policy Status Report is almost a formality, given the circumstances, but it includes some findings and related suggestions which will hopefully spark data-driven improvements to the Transfer Policy alongside the necessary GDPR-motivated updates.

     

    Recent Transfer Policy changes

    It’s been just over a year since Enom made necessary changes to our domain transfer process, and domains are still moving into and out of our platform smoothly. The biggest difference between our pre- and post-GDPR transfer process is that we are no longer able to use a “Form of Authorization” to confirm a domain owner’s transfer request. Instead, the authcode is used to verify that the request is valid and to initiate the inbound transfer within the registry system. We also now direct all transfer-related messaging to the registrant contact, since we no longer use an administrative contact for gTLDs.

    These changes are in keeping with the Temp Spec and with what we anticipate to be the future of the Transfer Policy. They’re also aligned with the work being done by the registrar and registry joint TechOps team: developing a more streamlined, user-friendly transfer process that remains secure against domain theft.

     

    Transfer Policy Status Report

    The Report discusses the impact that the Temp Spec had on the inter-registrar transfer process, but its overall scope is broader, with a focus on three main goals that transfer-related PDP working groups have been considering since they first began exploring how to improve the transfer process in 2005:

    – Portability

    – Preventing abuse

    – Providing information1

    The related central questions are:

    – Can registrants easily transfer their domain names?

    – Are processes standardized and efficient for registrars?1

     

    Takeaways from the Report

    The Report shows ICANN Compliance has noted a steady decline in the rate of transfer-related Compliance tickets, suggesting that there are fewer overall concerns about the process, perhaps because domain owners have gained experience with it. However, ICANN’s Contractual Compliance metrics do show that transfer issues remain the second-most common reason for people to contact ICANN Compliance, following only Whois inaccuracy concerns. This suggests that there’s room for simplification and further education around the transfer process.

    Another takeaway from the Report is that there was a significant spike in inter-registrar transfers in late 2016, likely caused by registrants changing their registrar just before the new Change of Registrant (COR) process and related lock came into effect. The Report also notes that immediately following the introduction of the COR lock requirement, ICANN Compliance began to receive a significant number of complaints about it.2 This tracks with our own customer service data which indicates frustration and confusion about COR locks generally, and we will be interested to see how COR lock complaint numbers change over time.

    As acknowledged in the Report, ICANN cannot directly track abusive transfers, as such situations are not reported consistently and cannot be independently verified.

     

    ICANN’s suggestions for improvement

    ICANN provides four suggestions for how to enhance the Transfer Policy moving forward, and we have some thoughts on each of them.

    ICANN Suggestion 1: Require registrars to log when a domain owner obtains their transfer authorization code.2

    Our perspective: Logging when an authorization code is retrieved by an end-user is a great idea, although implementation would be complicated. In many domain management interfaces, this code is visible by default on the domain name details page—there is no affirmative request to retrieve the code. So for many resellers and registrars, this requirement would involve significant development work, but that work is well worth doing.

    ICANN Suggestion 2: Provide a process or options to remove the 60-day COR transfer lock to better serve registrants’ needs.2

    Our perspective: The 60-day transfer lock has indeed proven to be a nuisance to both registrars and registrants, and there is some confusion as to whether and how it may be removed after it has been applied. We welcome clarification of the requirements but expect it to be a long process including consideration of whether alternative verification safeguards would become necessary.

    ICANN Suggestion 3: Clarify the Transfer Policy section about when a transfer can be denied due to non-payment.2

    Our perspective: This change would be a useful clarification. The section of the Policy where this is laid out can be confusing and difficult to parse, so making it more straightforward should help registrars more easily understand their rights and obligations in this regard.

    ICANN Suggestion 4: Clarify if the Change of Registrant process is applicable when the real underlying contact info is updated on a domain with an active Whois Privacy service.2

    Our perspective: This has been a topic of discussion between us and ICANN for quite some time. We believe that, if the underlying ownership data on a privacy-protected domain changes, that’s a Change of Registrant. If the purpose of the COR process is to protect domain owners against hijacking, this is just as important for domains using Whois privacy as it is for those without. ICANN, however, argues that privacy-protected domains are effectively owned by the privacy service, and so COR is not applicable. We want this issue to be clarified, but at this point it’s a question of contractual interpretation, which always needs to be approached with care.

    We appreciate that ICANN’s Contractual Compliance team has provided these suggestions and, if the GNSO Council decides that the Transfer Policy needs to be updated, which certainly seems to be the case, we look forward to working with the multistakeholder community to review these and other possible changes to the Policy.

    The future of the IRTP

    We always advocate for processes that keep things simple for the registrant while maintaining a high level of security and accountability. Tucows (our parent company) staff are part of the TechOps team, participating in the group’s efforts towards streamlining the transfer process to make domain transfers easier for domain owners while maintaining security against unauthorized transfers. Our hope is that the transfer process in use today under the Temp Spec will simply be turned into official policy. After all, it’s been in effect for over a year with no demonstrable detriment to domain owners.

    Our Support metrics show that domain transfers make up a significant portion of Support interactions, with most questions focused either on ccTLDs with special processes, or general transfer status requests (“When will my transfer be complete?”). We’re working on providing more information to our customers and resellers via our Knowledge Base, which we hope will help support you through this process.

    The work that we do in the ICANN community is complex, as is its impact on registrants and resellers. It’s important to make sure the decisions we’re making are data-driven, rather than based on gut feelings that could turn out to be incorrect or only accurate for a small portion of users. This report is a great start; we’re glad to see critical review and engagement with the process and hope that the data provided in the Inter-Registrar Transfer Policy Status Report will be taken into consideration as part of future efforts towards updating the Transfer Policy.

     


    1. ICANN Org. “Revised Inter-Registrar Transfer Policy Status Report .” Icann.org, ICANN, Mar. 2019, 4.
    2. ICANN Org. “Revised Inter-Registrar Transfer Policy Status Report .” Icann.org, ICANN, Mar. 2019, 31-32.

    Read More

FEATURED POSTS

  • How to Win by Treating Your Customers as Members

    August 13, 2020

  • A Great Domain for Freelancers and Entrepreneurs? Try .ME

    June 22, 2020

  • Bandzoogle: website builder for musicians

    June 1, 2020

  • security lock and credit cards on keyboard

    Avoiding COVID-19 Cyberattacks with Security Best-Practices

    April 28, 2020

CATEGORIES

  • Advice
  • Announcement
  • Developers
  • DNS
  • Featured
  • Fun
  • GDPR
  • Industry Insight
  • New TLDs
  • News
  • Premium Domains
  • Promotion
  • Resellers
  • Roadmap
  • SSL
  • Uncategorized
  • WTB

ARCHIVES

  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • April 2020
  • March 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • September 2018
  • August 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • January 2016
  • December 2015
  • November 2013
Support

Report Abuse
Help Center
Contact Us

Resources

WHOIS Lookup
Maintenance Alerts
Developers
Products & Services

Domain Name Search
Premium Domains
Web Hosting
SSL Certificates
Website Builder
Basic Email
Bulk Tools

© 2021 Enom Blog |