Posts Tagged ‘Extended Validation’

What’s the deal with 2048-bit keys?

Wednesday, June 23rd, 2010 | Bruce Morton

Entrust has been getting a lot of questions about the move to 2048-bit RSA keys.  The move is causing some web administrators concern, so we thought it would be a good time to clarify the reasoning behind the move to 2048-bit keys.

The US National Institute of Standards and Technology (NIST) prepared a special report SP 800-57 in 2005 for comment.  The updated report SP 800-57 in March 2007 Part 1 and subsequent reports Part 2 and Part 3, laid the foundation for how application developers and certification authorities would manage key sizes for digital certificates such as those used for SSL/TLS, code signing, and document signing. The recommendation was that 1024-bit RSA keys should only be depended on until 31 December 2010, after which the minimum key size should be 2048-bit RSA.  This recommendation has been adopted and published by a number of organizations:

Adobe CDS Certificate Policy

  • CDS Subordinate CAs shall use an RSA key pair with at least 2048 bits.
  • CDS Subscriber certificates shall use an RSA key pair with at least 2048 bits.

CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates

  • Requires a minimum of 2048-bit RSA keys for Root and Subordinate CAs.
  • Requires a minimum of 1024-bit RSA keys for end entity certificates and 2048-bit keys for end entity certificates that expire after 31 December 2010.

Microsoft Certificate Root Program

  • All new Root certificates must have a minimum be 2048-bit RSA keys.
  • 1024-bit Roots will be removed from the Microsoft Root Certificate Program by 31 December 2010.
  • All end entity certificates issued after 31 December must have a minimum of 2048-bit RSA keys.

Mozilla Foundation dates for phasing out MD5-based signatures and 1024-bit moduli

  • December 31, 2010 – CAs must stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs must stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root.
  • December 31, 2013 – Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits.

The reason for moving to stronger subscriber keys is to protect the data of Subscribers and Relying Parties.  Cryptanalytic attacks against a particular key size become more practical as computing power increases and new techniques are developed.  See, for instance, 768-bit RSA key in December 2009.  A broken end-entity key could expose encrypted session data or allow a man-in-the-middle attack.

Entrust has been proactive in adopting the standards and recommendations. Entrust has put in restrictions that all certificates that expire after 2010 have a minimum of 2048-bit RSA keys. In addition Entrust is actively moving to 2048-bit root certificates. As times move forward, we will keep our eyes on the technology and the standards and implement policy to protect our subscribers and relying parties.

EV, what’s the difference?

Wednesday, June 16th, 2010 | Bruce Morton

With the acquisition of the VeriSign SSL business by Symantec, we’re getting a lot of questions about EV SSL certificates.  Is your EV the same as theirs?  Why is your EV so much cheaper?  What’s the difference?

The bottom line is yes; our EV SSL certificates are the same as theirs.  In fact, EV SSL certificates from all certification authorities are the same.  This is because all EV SSL certificates are issued and managed in accordance with the same standard.  This standard is called the Guidelines For Issuance And Management Of Extended Validation Certificates (EV Guidelines). The EV Guidelines were developed by an industry group called the CA/Browser Forum (CAB Forum) which Entrust has chaired since 2005. 

In addition to following the same guidelines, all EV SSL certification authorities are audited by third party security auditors in accordance with criteria based on the guidelines. Proof of which is posted on the CA’s website in the form of a WebTrust for Extended Validation seal and auditor’s report.

So what’s the difference?  The difference is customer service.  Entrust provides the industry leading certificate management, combined with great customer service, and a choice of licensing models. We let our customers manage their certificates the way they want them managed … in accordance with the guidelines of course.

So why are our EV certificates so much cheaper?  Simply, we charge less. We deliver great value at a reasonable price.

Is it Paypal? Or is it Paypal?

Monday, January 4th, 2010 | Steve Duncan

Can you rely on the website address to tell if you’re on a phishing site? Not anymore, according to some websites.

It seems that the International Corporation for Assigned Names and Numbers (ICANN) has recently allowed non-latin domain names to be registered.  This is in an effort to encourage internet content build-up from other countries.

Reacting to this news, some creative authors have found a way to display common website addresses using a combination of Cyrillic and English letters.  For example the Russian Cyrillic characters “raural” look exactly like “paypal”.   Check out the  Times Online article here and the Paypal example here.   This IDN homograph phishing attack is nothing new, just a lot easier according to some authors.

Some  potential issues have been addressed: depending what type of browser you use, you’ll likely get a warning;  IDN implementations won’t allow mixed-script URLs so a nefarious registrant can’t mash up a domain name using multiple scripts.  But one can’t help wondering what happens  on older browsers, or mobile browsers?

No matter what the case, it’s just become a bit more unreliable to depend on the domain name displayed in the browser address bar.  It’s too bad because that’s usually the best way to train non-technical users to be sure they’re on the right website.   Of course another way to rely on a website is through the SSL information.  But try explaining to your great aunt that she needs to click on the little lock icon at the bottom right of her browser.  And with the proliferation of certificates that only validate domain names (DV certificates), many SSL sessions just don’t offer the reliability.

Browser manufacturers and Certificate Authorities have taken the first step towards making it easier by introducing Extended Validation (EV) certificates.  The standardized EV Guidelines specifically mention that:

The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization.

In other words, this problem wouldn’t happen if sites were protected by EV certificates.  EV guidelines also dictate that  certificate providers validate the company name that owns the website as well as the true website name, and this  information is displayed in the “chrome” of the browser, such as in the menu bar.  Most browsers provide visual cues for EV certificates.  Usually the address or address bar turns green.  But is it enough?  Would your great aunt know to look for green visual cues and the name of the company?  Perhaps.  Perhaps not.  Perhaps the next step is for browsers to provide more dramatic visual cues.  Like “You are about to send information securely to <Insert verified company name here>”.    Let’s hope the browser vendors can stay ahead of the criminals on this one.