Configuration-Control Specification

Creation Date : 20091214
Editor: Iang
Status: 20100426 WIP
CCS Status - work-in-progress

1. Introduction

The Configuration-Control Specification (CCS COD2) controls and tracks those documents, processes and assets which are critical to the business, security and governance of the CAcert operations.

This document is the procedure for CCS. This document itself is a component of the CCS, see §2. All other documentation and process specified within is derivative and is ruled by the CCS.

CCS is formated, inspired and designed to meet the needs of David Ross Criteria - Certificate Authority Review Checklist - section A.1 ( DRC-A.1 ). CCS may be seen as the index to systems audit under DRC.

2 Documents

2.1 Controlled Document List

This CCS creates a list of Primary or "root" documents known as Policies. Primary documents may authorise other secondary documents into the list, or "practices" outside the list.

The controlled documents list contains numbers, locations and versions of all controlled documents. The list is part of this CCS, and is located at Policy Officer is to manage the list. Policy Officer is to log the changes at

2.2 Change

Change to the documents is as specified by Policy on Policy (PoP).

The following would possibly be better off in PoP (when a change cycle comes around), or a practices manual.

Policies in effect (DRAFT and POLICY status) are to be under change control. Fully approved documents (POLICY status) are published on the CAcert website at in plain HTML format, under the same control as critical source code under Security Policy (SP). Pre-final work (DRAFT status) and working documents (work-in-progress status) are made available on community-controlled version management systems (rooted at Subversion: wiki: Documents of lower status (work-in-progress or DRAFT) must not be confusable with documents of higher status (DRAFT or POLICY). Copies should be eliminated where not being worked on.

2.3 Control

CAcert policies are required to be owned / transferred to CAcert. See PoP 6.2.

3 Hardware

3.1 Controlled Hardware List

Critical systems are defined by Security Policy.

3.2 Change

See Security Policy.

3.3 Control

Security Policy places executive responsibility for Hardware with the Board of CAcert Inc. Access is delegated to Access Engineers (SP 2) and Systems Administrators (SP 3). Legal ownership may be delegated by agreement to other organisations (SP 9.4).

Control of Hardware is the ultimate responsibility of the Board of CAcert Inc. The responsibility for acts with hardware is delegated to Access Engineers and Systems Administrators as per Security Policy. The ownership responsibility is delegated by agreement to Oophaga.

4 Software

4.1 Controlled Software List

Critical software is defined by Security Policy.

4.2 Change

See Security Policy.

4.3 Control

CAcert owns its code, or requires control over open source code in use by means of an approved free and open licence. Such code must be identified and managed by Software Assessment.

Developers transfer full rights to CAcert (in a similar fashion to documents), or organise their contributions under a proper free and open source code regime, as approved by Board. Where code is published (beyond scope of this document) care must be taken not to infringe licence conditions. For example, mingling issues with GPL.

The Software Assessment Team Leader maintains a registry of assignments of title or full licence, and a registry of software under approved open source licences.

5 Certificates

This section applies to Root and Sub-root certificates, not to End-entity (subscriber, member) certificates.

5.1 Certificates List

Certificates (Root and sub-root) are to be listed in the CPS.

5.2 Changes

Creation and handling of Certificates is controlled by Security Policy. Usage of Certificates is controlled by Certification Practice Statement.

5.3 Archive

See Security Policy.

6 Logs

6.1 Controlled Logs List

Logs are defined by Security Policy.

6.2 Changes

Changes to Hardware, Software and Root Certificates are logged according to Security Policy.

6.3 Archive

See Security Policy.

7 Data

7.1 Types of Data

Types of critical member data is defined by Assurance Policy.

7.2 Changes

Changes and access to critical member data is as defined under Assurance Policy, CAcert Community Agreement and Dispute Resolution Policy. Implementation of collection and storage of critical member data (user interface software and databases) is defined by Security Policy.

7.3 Archive

Data retention is controlled by Security Policy and CAcert Community Agreement.

Valid XHTML 1.1