Posts Tagged ‘Mozilla’

Mozilla Endorses SSL Baseline Requirements

Wednesday, February 27th, 2013 | Bruce Morton

The CA/Browser Forum Baseline Requirements have been endorsed by Mozilla and have been included in their certificate authority (CA) certificate policy.

The Baseline Requirements are an auditable set of certificate management requirements that were finalized in November 2011. Their purpose is to set a level of management requirements for all SSL certificates. The Baseline Requirements also apply to Extended Validation (EV) certificates, but EV has its own guidelines to manage stricter verification.

The members of the CA/Browser Forum made them effective as of July 1, 2012. For the most part, the major vendors of publicly-trusted SSL certificates have now been compliant for the last eight months. The audit authorities developed audit criteria and both WebTrust and ETSI have integrated the Baseline Requirements into their CA audit programs.

The final task was to have a browser vendor require the Baseline Requirements in their certificate policy. Mozilla has done that with its Mozilla CA Certificate Policy (Version 2.1), which was released on February 14, 2013.

Here is a high-level look at the changes included in the Mozilla policy update:

  • Multifactor authentication or limit domains for all accounts capable of directly causing a certificate issuance
  • Root certificates should only issue subordinate CA certificates. End-entity certificates could be issued from a root in accordance with Baseline Requirement section #12
  • All subordinate CAs must be technically constrained or publicly disclosed and audited
  • Technical constraints are performed by adding an Extended Key Usage (EKU) to the subordinate CA certificate that specifies the key usage that the CA is to be used to issue. The constrained CAs must also do the following for the specified certificate types:
    • Server authentication (SSL) – must also include a Name Constraints X.509V3 extension
    • Secure email – must issue certificates can only be issued for authorized email addresses or mailboxes
    • Code-signing certificates must issue the end entity certificates including a subject distinguished name with organization, locality (where relevant), state or province (where relevant) and country name
    • If technical constraints for a subordinate CA is not possible, then they must be audited in accordance with Mozilla’s certificate policy and must be publicly disclosed
    • CA operations and issuance of SSL certificates must be done in accordance with Baseline Requirements version 1.1

Mozilla also has more details and a set of frequently asked questions, including implementation dates. The bottom line is that all new CAs must meet the Baseline Requirements and all existing CAs must be audited to the Baseline requirements by February 15, 2014.

I would like to thank Mozilla for endorsing and requiring the Baseline Requirements.

Tags: , , , , ,
Posted in Certificate Management, Secure Browsing | Add Comment | No Comments »

Key Size Update

Monday, January 24th, 2011 | Bruce Morton

Last summer I posted a blog about the move 2048-bit RSA keys in SSL certificates. While I was drafting my post, NIST was working on a new Special Publication. This document, just released as NIST SP 800-131A, allows a transition period to from 1024-bit to 2048-bit RSA keys. In the period of 1 January 2011 through 31 December 2013, 1024-bit keys are allowed, but their use is deprecated. In response, the industry has adjusted its policies and practices, for example:

Mozilla – Dates for Phasing out MD5-based signatures and 1024-bit moduli

  • December 31, 2010 – All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits. Additionally, CAs with root certificates that have RSA key size smaller than 2048 bits should stop issuing intermediate and end-entity certificates from those roots.  (Note those should words used to say must.)
  • Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after 2010.
    • This means that CAs should only consider issuing a 1024-bit certificate if it is requested and justified by the subscriber for a specific reason, such as interoperability with devices that do not yet support certificates with larger key sizes.
    • The CA must assess the risk involved in issuing such a certificate for legacy use/interoperability, and determine if they are willing to accept the risk, as well as any possible liability. The subject and relying parties also need to determine if they will accept any risks and liabilities.
  • All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of 2013.

Microsoft - A Note on Implementation of the Requirement to Issue Longer Key Length Certificates

  • We based our technical requirement for migrating away from 1024-bit RSA certificates on NIST Guidance, and NIST updated it with 800-131
  • In general this means that CAs should continue to deploy stronger key length certificates, and the vast majority of CAs have already migrated to 2048-bit RSA in most scenarios; but if they must continue to issue 1024-bit RSA end-entity certificates in certain contexts (e.g. hardware, smart cards, and other devices in capable of accepting longer key lengths), those certificates should be considered “deprecated” or “restricted” according to the use of those terms, defined in the NIST document.
  • In any event, end-entity 1024-bit certificates should not expire after December 31, 2013.

Entrust has adjusted its policies and practices as well. Although 1024-bit RSA keys are highly restricted, Entrust will issue non-EV SSL certificates with 1024-bit RSA keys to a maximum validity of 31 December 2013 in support of inter-operability and backwards compatibility issues. All other certificates will continue to have a minimum key size of 2048-bit RSA.

Tags: , , , , , ,
Posted in SSL Deployment, Secure Browsing | Add Comment | No Comments »

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 issued 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.

Updated January 24, 2011: Here is a Key size update post based on the release of NIST Special Publication 800-131A.

Tags: , , , , , , , ,
Posted in SSL Deployment, Secure Browsing, Technical | Add Comment | No Comments »