Wednesday, 14 March 2012

How to become a Certificate Authority

CAs - there are certainly a lot of them, but where do they come from?, how are they made?  First of all don't believe anything I have to say on the matter; I have never gone through the process and anything you read here is speculation and incomplete information.

However, if you were to start looking around the internet for how to become a CA's, here is some of the information you may find, some of which you may find interesting.

So any business can become a CA but it's pointless unless you get your root certificate into a browser.  To do this you first need to ensure you meet the requirements of the various browser certificate programs.  These are:

Microsoft Root Certificate Program

Mozilla CA Certificate Policy (Version 2.0)

Apple Root Certificate Program

Google appears to use the underlying OS certificate store.  So on Windows this will be the same as what IE uses, however on Linux, the different distributions seem to use the ca-certificates package.  It is interesting to note it's description:

$apt-cache show ca-certificates
Package: ca-certificates
Description-en: Common CA certificates
 This package includes PEM files of CA certificates to allow SSL-based
 applications to check for the authenticity of SSL connections.
 It includes, among others, certificate authorities used by the Debian
 infrastructure and those shipped with Mozilla's browsers.
 Please note that certificate authorities whose certificates are
 included in this package are not in any way audited for
 trustworthiness and RFC 3647 compliance, and that full responsibility
 to assess them belongs to the local system administrator.

The ca-certificates seems to include mostly Mozilla certificates, although a few others as well.  The ca-certificates package also seems to power the Java key store as well.  

According to the above certificate programs, any of the following standards is sufficient to convince the browsers (depending on the browser maker) to include you as a CA.

Microsoft Mozilla Apple*
ANSI X9.79-1:2001 N Y N
ETSI TS 101 456 V1.2.1 (2002-04) or later version Y Y N
ETSI TS 102 042 V2.1.2 (2010-04) or later version Y Y N
ISO 21188:2006 Y Y N
WebTrust Principles and Criteria for Certification Authorities Y Y Y
WebTrust for Certification Authorities—Extended Validation Audit Criteria Y Y Y
*Actually Apple may accept more, but you have to prove equivalence.

The ANSI and ISO organisations should be familiar to most people, but what about ETSI and WebTrust?  Well ETSI is the European Telecommunications Standards Institute and WebTrust is made up of the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accounts (CICA).

The 2002 ETSI standard actually only applies to CAs that want to create certificates for digital signatures.
"These policy requirements are specifically aimed at qualified certificates issued to the public, and used in support of qualified electronic signatures ..." (Section 1)
As a standard it is based on:
"The present document makes use of the principles defined in IETF RFC 2527 [2] and the framework defined in ANSI X9.79 (see bibliography). The aim of the present document is to achieve best possible harmonization with the principles and requirements of those documents." (section 5.1 NOTE 2)
The later ETSI standard (which linked above is from 2011-12) is based on the earlier 2002 ETSI and covers the full range of CA activities.  The later standard also references RFC 3647 (from 2003), which obsoleted RFC 2527 (1999).  RFC 3647 is itself based on an American Bar Association document "PKI Assessment Guidelines, v0.30, Public Draft for Comment, June 2001", which references the WebTrust standard (at the time, which was v1.0 issued in August 2000 and was a licensed document).

The version 2.0 WebTrust (AICPA/CICA) standards (linked above) were created by some folk from the big accountancy firms (Deloitte & Touche, Ernst & Young, KPMG) but declares that it is based on ISO 21188, and is consistent with ANSI and IETF (the RFCs) standards. 

"This document was developed by a CICA/AICPA Task Force using ISO 21188 “Public Key Policy and Practices Framework” and Version 1.0 of the AICPA/CICA WebTrust Program for Certification Authorities."
"The Principles and Criteria for Certification Authorities are consistent with standards developed by the American National Standards Institute (ANSI), International Organization for Standardization (ISO), and Internet Engineering Task Force (IETF). The Principles and Criteria are also consistent with the practices established by the CA Browser Forum (see" (Page 6)

Although I didn't have access to the ISO 21188 (2006) document, I found a couple of references that implied it was based on the ANSI X9.79 (from either 2000 or the X9.79-1 from 2001) standard.  Again, I didn't have access to the ANSI document, but I found this Mozilla mail threat from 2005 which seem to indicate that the ANSI document shared a lot in common with the v1.0 WebTrust standard (from August 2000).

The ANSI X9.79 standard, according to these presentations, here and here, draw the criteria that CA's must reach from several other ANSI, BS, FIPS, IETF and ISO standards.  It does seem to be the granddaddy for all the other CA standards.

Standards are one thing, but all the CA Certificate programs call for an independent audit against one of the standards.  It seems that the WebTrust is the most used standard nowadays and even comes with a draft report that auditors can give to a prospective CA indicating hat passed the audit.  A choice quote from that draft is (where ABC is the name of the CA):
"ABC-CA’s management is responsible for its assertion. Our responsibility is to express an opinion on management’s assertion based on our examination."
So basically the CA is audited against what they assert and not a list of mandated requirements.  This is not necessarily a bad thing, but it does make you wonder about the relationship between auditors and auditees when the later is paying the former.  Admittedly that is a problem for auditors regardless of what they are auditing against.

So how does this change your perception of how a CA becomes a CA?  Well for me there aren't a lot of real surprises here, but I would be very interested to see the actual audit reports produced by the independent auditors.  I think there is a real argument that since the public is putting so much trust in the CAs then they should make their audit reports publicly available, or at least release substantial parts of it.

No comments:

Post a comment