The length of an RSA public key gives an indication of the strength of the encryption — the shorter the public key is; the easier it is for an attacker to brute-force. An attacker, armed with a compromised private key derived from a short public key, would be able to decrypt both past and future SSL-secured connections if she were able to incept the encrypted traffic. She could also impersonate the organisation to which the SSL certificate was issued if she has the opportunity to manipulate DNS lookups. Both the CA/B Forum (a consortium of certificate authorities (CAs) and major browser vendors) and NIST [PDF] (the agency which publishes technical standards for US governmental departments) have recommended that sub-2048-bit RSA public keys be phased out by the end of 2013.

According to the CA/B Forum’s own Baseline Requirements [PDF] — effective 1st July 2012 — member certificate authorities are required to reject a request to sign an RSA public key shorter than specified in the following table:

Nevertheless, these key sizes are not guaranteed as several CA/B Forum members have issued several non-compliant SSL certificates since 1st July 2012. Trustwave, Symantec, KEYNECTIS, and TAIWAN-CA have all signed certificates which fall foul of their organisation’s requirement of 2048-bit RSA public keys for certificates expiring after 2013, demonstrating that the key length requirement is being treated as a guideline (which by definition is neither binding nor enforced), rather than a rule.

They are by no means the only CAs signing short RSA public keys: more than 10 years after Netcraft’s first blog post on the topic and 12 years after RSA-155 [PDF], 512-bit RSA public keys are still appearing in SSL certificates. A 512-bit RSA public key was signed as recently as July 2012 by Swisscom.

Most, but not all, of the major browser and operating system vendors either disallow access or display a warning message when accessing a website using an SSL certificate with a 512-bit RSA public key. The latest versions of Safari (although not the mobile version on iOS 5.1), Opera, Google Chrome, and Internet Explorer (via an update to Windows; planned to be rolled out in October 2012). Notably, Mozilla Firefox does not yet reject such certificates.