Note: My Web pages are best viewed with style sheets enabled.

Certificate Authority Review Checklist

Copyright © 2005, 2007 by David E. Ross

Version 28Dec08-2.1.0

Introduction

Requirements

A. Documentation

B. Public Access

C. Operational Review

Requirements Trace

Extended Validation (EV) Certificates

Document Versions

Introduction

This document lists those requirements that are to be checked when attesting to a browser developer regarding a request by a certificate authority (CA) to have its root certificates included in the browser's certificate database. Attestation by an outside reviewer will be made based on an overall evaluation of the CA's documents, public persona, and operations in accord with this document. Thus, a CA does not necessarily have to meet each listed requirement.

Attestation does not mean approval of the CA's request. It merely provides a technical analysis on which to base the decision whether grant such approval. This Checklist was developed with the intent that a third-party review would be conducted of a CA. The checklist pages are intended to be printed by the reviewer, who would then fill in the "Verified" or "Comments" columns; dates in those columns indicate when the requirement was assessed, not when it was documented by the certificate authority. The completed Checklist would then be submitted to the browser devleoper along with a letter from the reviewer, summarizing what he or she actually did during the review and expressing an opinion on the results.

This checklist somewhat reflects the ISO-9000 concept:

Say what you do, do what you say, and prove it.

The requirements in §A (Documentation) indicate what the CA formally declares that it does. (Say what you do.)
The requirements in §C (Operational Review) indicate what the CA actually does. (Do what you say.)
The proof is in the outside review that relies on this checklist. (Prove it.)

Unrelated to the ISO-9000 concept, §B (Public Access) lists requirements that address the transparency of operations necessary for a CA's certificates to be trusted by the public.

The allocation of a requirement to a particular section is not restrictive. That is, a requirement listed in §C might be reflected in a document cited in §A. Indeed, requirements in one section might imply requirements in another section.

This checklist was developed through a review of AICPA/CICA WebTrust Program for Certification Authorities (© 2000 by American Institute of Certified Public Accountants, Inc. and Canadian Institute of Chartered Accountants; WebTrust is a trademark and service mark of those two).

Reflecting the many years as a software test engineer and requirements analyst by the developer of this Checklist, the requirements listed here have been rephrased and reorganized to be more computer-oriented than the WebTrust Program. However, the latter is widely accepted. For that reason, each requirement in the Checklist indicates the related WebTrust Program §1.1 (Principle 1: CA Business Practices Disclosure) criteria (if any) in the "WT" column. Additionally, the "Requirements Trace" section indicates the Checklist requirements for each WebTrust Program §1.1 criterion and also explains why other WebTrust Program criteria are not addressed in this Checklist. The mapping between WebTrust criteria and the requirements is not one-to-one. Some criteria appear more than once; some requirements show more than one criterion. Further, an accurate mapping of WebTrust criteria to these requirements (or vice versa) is not possible because:

In rephrasing the criteria to create the requirements, some criteria were split into two or more requirements. In other cases, some criteria were combined into a single requirements. And in even other cases, a group of criteria were decomposed and recombined into a group of requirements.
Some WebTrust criteria appear redundant or relate to business practices that are not necessarily specific to the practices of CAs. Those criteria were not considered when developing this checklist.
Some requirements added to this checklist have no corresponding WebTrust criteria.

Where this checklist appears to use public-key/private-key terminology, it is because X.509 certificates are indeed analogous to PGP keys. The certificate used in signing (e.g., a root certificate signing an intermediate certificate) is similar in function to a PGP private key, and the certificate used by others to authenticate a Web site, file source, or E-mail is similar in function to a PGP public key. The developer of this Checklist regrets if this use of terminology — resulting from his greater familiarity with PGP than with X.509 certificates — is confusing.

Where a requirement refers to another requirement in a different table, there is a link to that table. Where a requirement refers to another requirement in the same table, there is no link.

I grant the free and unlimited right to use this document to the Mozilla Foundation, its employees, and its volunteers for the sole purpose of evaluating CAs to determine if their root and intermediate certificates should be included with products of the Foundation. That grant is conditional upon the following:

This copyright notice remains with the document.
The Mozilla Foundation makes no profit from the use of this document.
Employees and volunteers of the Mozilla Foundation receive no compensation — other than reimbursement of actual expenses — for the use of this document.

Similar free and unlimited use of this document might be granted to other non-profit organizations and to volunteers for such organizations upon request. If a for-profit enterprise or an individual for hire wishes to use this document, payment of a royalty can be negotiated.

Last updated 14 November 2007