Posts Tagged ‘WebTrust’

CAs Support Standards and Regulations

Friday, May 17th, 2013 | Bruce Morton

This post was originally published on the CA Security Council blog.

There is an industry myth that certification authorities (CAs) are not regulated. In fact publicly-trusted SSL CAs support the development of industry regulations and have been audited annually to ensure compliance to the many requirements.

To provide some history, SSL CAs have always self-policed themselves by having external audits performed. In the ‘90s, the CAs wrote certificate policies and certification practice statements requiring annual compliance audits. Since there were no CA audit criteria, the CAs contracted for SAS 70 audits.

In 2000, the AICPA and CICA developed the WebTrust for CA audit criteria. The CAs switched to being audited to meet the WebTrust criteria and many browsers required successful WebTrust for CA audits to maintain root certificates embedded in their software.

In 2005, the CAs and the browsers combined to form the CA/Browser Forum. The purpose was to improve the issuance and management of SSL certificates. The first release was the Extended Validation (EV) SSL certificate requirements and in 2007, the issuing CAs were audited in accordance with the WebTrust for EV criteria.

However, the EV criteria did not cover standards for non- EV certificates. The CA/Browser Forum addressed this problem by developing the Baseline Requirements for SSL certificates. In 2012, the CAs started issuing certificates meeting the Baseline Requirements and in 2013 those CAs will be audited to the SSL Baseline Audit criteria, which was also developed by WebTrust personnel.

Now, when SSL CAs display their audit results, expect to see WebTrust for CA, WebTrust for EV and Baseline Requirements reports.

In addition to improving the CA certificate issuance and management standards, the CA/Browser forum has also introduced Network and Certificate System Security Guidelines which is hoped to be added to the audit criteria in the future. Also the European Telecommunications Standards Institute (ETSI) has adopted the CA audit criteria and has updated their standards.

For more information on SSL CA audits and other standards that help regulate the industry, please see the CASC whitepaper.

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

Self-Signed Certificates don’t deliver Trust

Thursday, April 4th, 2013 | Bruce Morton

This post was originally published on the CA Security Council blog.

We’ve heard the argument that website operators could just use self-signed certificates. They are easy to issue and they are “free.” Before issuing self-signed certificates, it’s a good idea to examine the trust and security model. You should also compare self-signed certificates to the publicly trusted certification authority (CA) model; and then make your own decision.

Self-Signed Certificate Model

  • Owner says who they are
  • Owner issues on their own policy
  • Owner is responsible for quality
  • Owner may not follow industry guidelines
  • Owner may not provide certificate status
  • Compromised certificates may not be able to be revoked
  • Owner is not audited
  • Issuer of certificate may not be authorized by the domain owner
  • Certificates may not be renewed if there are no reminders
  • Self-signed certificate model does not provide trust and the browser provides a trust dialogue box to indicate such

Publicly-trusted CA-Signed Certificate Model

  • CA verifies the owner of the domain and the certificate applicant
  • CA operates to a policy in conformance with the requirements of the browser and operating system vendors. The requirements include the CA/Browser Forum Baseline Requirements, Extended validation (EV) Guidelines and recommendations from NIST.
  • CA provides quality to the certificate. Checks include compromised keys, minimum key size, ensuring hashing algorithms, maximum validity period and proper certificate extensions.
  • CA updates policy based on industry best practices
  • CA provides certificate status through CRL and OCSP
  • Compromised certificates can be revoked
  • CA is audited to certificate issuing criteria such as WebTrust for CA, WebTrust for EV and SSL Baseline Requirements
  • Certificate requesters for a Domain validated certificate are authorized by the owner of the domain. Requesters for Organization and Extended Validation certificates are authorized by a member of the organization specified in the certificate.
  • CAs provide multiple reminders to ensure the certificates are renewed before they expire. CAs may also provide certificate discovery tools to find certificates on your systems which may not have reminders.
  • Publicly trusted CA model is based on the CA being a trusted third party to the browser/OS vendor, the website certificate subscriber and the end-users of the website. The CA is obligated to meet the requirements of all three parties.

So, when should you use a self-signed certificate?

When trust, security, service, quality and reliability are not your criteria.

Tags: , ,
Posted in Certificate Management, SSL Deployment | Add Comment | No Comments »

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 »