AssurancePolicy
---------------
4.4. Experience Points
Additional Experience Points may be granted temporarily or permanently to an Assurer by CAcert Inc.'s Committee (board), on recommendation from the Assurance Officer.
5. The Assurance Officer
The Committee (board) of CAcert Inc. appoints an Assurance Officer with the following responsibilities:
 * Reporting to the Committee and advising on all matters to do with Assurance;
 
OrganisationAssurancePolicy
---------------------------
2.1 Assurance Officer
The Assurance Officer ("AO") manages this policy and reports to the CAcert Inc. Committee ("Board").

The AO manages all OAs and is responsible for process, the CAcert Organisation Assurance Programme ("COAP") form, OA training and testing, manuals, quality control. In these responsibilities, other Officers will assist.

The OA is appointed by the Board. Where the OA is failing the Board decides. 

TTPAssistedAssurancePolicy
---------------------------
4. Assurance Officer ("AO")
The Board routinely delegates its responsibilities to the Assurance Officer (and this section assumes that, but does not require it).

4.2 Deserts
The Assurance Officer maintains a list of regions that are designated as 'deserts,' being areas that are so short of Assurers as to render face-to-face Assurance impractical. In each region, approved types of TTP are listed (e.g., Notary). The list is expected to vary according to the different juridical traditions of different regions. Changes to the regional lists are prepared by either an Organisation Assurer for that region (as described by OAP) or by two Assurers familiar with the traditions in that region. Changes are then submitted to the Board for approval. 
Use of a type of TTP not on the list must be approved by AO and notified to Board. It is an explicit goal to reduce the usage of TTP-assisted assurances in favour of face-to-face Assurance. 
In coordination with internal and external auditors, the Assurance Officer shall design and implement a suitable programme to meet the needs of audit. Where approved by auditors or Board, the Assurance Officer may document and implement minor variations to this policy. 




CertificationPracticeStatement
------------------------------
1.3. PKI participants
The CA is technically operated by the Community, under the direction of the Board of CAcert Incorporated.

3.1.7. International Domain Names
The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list.

5.2.1. Trusted roles
Governance: 
 * Directors (members of the CAcert Inc. committee, or "Board") 
 * internal Auditor
 * Aribtrator

8.3. Assessor's relationship to assessed entity
An Auditor may convene an audit team. The same restrictions apply in general to all members of the team, but may be varied. Any deviations must be documented and approved by the CAcert Inc. Board. 

8.5. Actions taken as a result of deficiency
Auditor may issue directives instructing changes, where essential to audit success or other extreme situations. Directives should be grounded on criteria, on established minimum or safe practices, or clearly described logic. Adequate discussion with Community (e.g., CAcert Inc. Board and with Policy Group) should precede any directive. They should be presented to the same standard as the criteria, above.

9.5.2. Brand
The brand of CAcert is made up of its logo, name, trademark, service marks, etc. Use of the brand is strictly limited by the Board, and permission is required. See m20070917.5. 


Configuration-Control Specification
-----------------------------------
Hardware 
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). 

Software
Control
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.

DisputeResolutionPolicy
-----------------------
2.1. Authority
The Board of CAcert Inc. and the Members of the Community vest in Arbitrators full authority to hear disputes and deliver rulings which are binding on CAcert Inc. and the Members. 

3.2. Process 
Only under exceptional circumstances can the Arbitrator declare the Ruling private under seal. Such a declaration must be reviewed in its entirety by the Board, and the Board must confirm or deny that declaration.

3.5 Liability
The above provisions may only be overridden by appeal process (by means of a new dispute causing referral to the Board).

3.6. Remedies 
The Arbitrator is not limited within the general domain of CAcert, and may instruct novel remedies as seen fit. Novel remedies outside the domain may be routinely confirmed by the Board by way of appeal process, in order to establish precedent.

4.2. The Disadvantages of this Forum 
* Membersmay have their rights trampled over. In such a case, the community should strive to re-open the case and refer it to the board. 


PolicyOnPolicy
--------------
4. DRAFT status
4.6 During the period of DRAFT, CAcert Inc. retains a veto over policies that effect the running of CAcert Inc. 

SecurityPolicy
--------------
1. INTRODUCTION
1.1. Motivation and Scope
The Committee of CAcert, Inc. (hereafter, "Board") may add additional components into the Security Manual. 

3. LOGICAL SECURITY
3.2. Operating System 
3.2.3. Patching
3.2.3.1. “emergency” patching 
Declaration of an emergency patching situation should not occur with any regularity. Emergency patch events must be documented within the regular summaries by the team leader to Board independent of filed disputes. 

3.4. Access control 
3.4.2. Special Authorisation 
All changes of personnel to the above lists are subject to Board approval. 

4. OPERATIONAL SECURITY
4.1. System administration 
4.1.3. Change management procedures
All changes made to system configuration must be recorded and reported in regular summaries to the Board of CAcert. 


5. INCIDENT RESPONSE
5.3. Immediate Action 
5.3.3. Escalation
A process of escalation should be established for oversight and management purposes, proportional to severity and priority. Oversight starts with four eyes and ends with the Arbitrator. Management starts with the team leader and ends with the Board. 

6. DISASTER RECOVERY
Disaster Recovery is the responsibility of the Board of CAcert Inc. 

6.1. Business Processes
Board must develop and maintain documentation on Business Processes. From this list, Core Processes for business continuity / disaster recovery purposes must be identified. 

6.2. Recovery Times
Board should identify standard process times for all processes, and must designate Maximum Acceptable Outages and Recovery Time Objectives for the Core Processes. 

6.3. Plan
Board must have a basic plan to recover. 

6.4. Key Persons List
Board must maintain a Key Persons List with all the contact information needed. See §10.1. The list shall be accessible even if CAcert's infrastructure is not available. 

7. SOFTWARE ASSESSMENT
7.1. Authority
The source code is under CCS. Additions to the team are subject to Board approval. See §3.4.2. 

8. SUPPORT
8.1. Authority
The software interface gives features to Support Engineer. Access to the special features is under tight control. Additions to the team are subject to Board approval, and the software features are under CCS. See §3.4.2. 

9. ADMINISTRATIVE
9.1. Staffing
9.1.1. Roles and responsibilities
* Team leaders: coordinate with teams, report to Board.
* All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.
* Board: authorise new individuals and accesses. Coordinate overall.

9.1.2. Staffing levels
One individual in each team is designated team leader and reports to Board. 

9.1.3. Process of new Team Members
New team members need:
* Recommendation by team leader
* Arbitrated Background Check ("ABC")
* Authorisation by Board

9.1.5. Authorisation
Individuals and access (both) must be authorised by the Board. Only the Board may approve new individuals or any access to the systems. Each individual should be proposed to the Board, with the relevant supporting information as above.
The Board should deliberate directly and in full. Board members who are also active in the area should abstain from the vote, but should support the deliberations. Deliberations and decisions should be documented. All conflicts of interest should be examined. 

9.1.7. Termination of staff
Termination of access may be for resignation, Arbitration ruling, or decision of Board or team leader. On termination (for any reason), access and information must be secured. See §3.4.4. 

9.2. Root Key Management
9.2.1. Root Key generation
Root keys are generated only on instruction from Board. They must be generated to a fully documented and reviewed procedure. The procedure must include:
[...]
* Dual control over all phases, including by Board.
[...]

9.2.2. Backup and escrow
The top-level root must be escrowed under Board control. Subroots may be escrowed by either Board or Systems Administration Team. 

9.3. Legal
9.3.1. Responsibility
Board is responsible to the Community to manage the CA at the executive level. 

9.3.2. Response to external (legal) inquiry
All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP. Board and applicable team leaders must be notified. 
Only the Arbitrator has the authority to deal with external requests and/or create a procedure. Access Engineers, Systems Administrators, support engineers, Board members and other key roles do not have the authority to answer legal inquiry. The Arbitrator's ruling may instruct individuals, and becomes your authority to act. 

9.4. Outsourcing 
Contracts should be written with the above in mind. Outsourcing of critical components must be approved by the Board.









Money
Complaint rule 12/13
Association membership
contracts