1 AssurancePolicy
   2 ---------------
   3 4.4. Experience Points
   4 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 5. The Assurance Officer
   6 The Committee (board) of CAcert Inc. appoints an Assurance Officer with the following responsibilities:
   7  * Reporting to the Committee and advising on all matters to do with Assurance;
   8  
   9 OrganisationAssurancePolicy
  10 ---------------------------
  11 2.1 Assurance Officer
  12 The Assurance Officer ("AO") manages this policy and reports to the CAcert Inc. Committee ("Board").
  13 
  14 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.
  15 
  16 The OA is appointed by the Board. Where the OA is failing the Board decides. 
  17 
  18 TTPAssistedAssurancePolicy
  19 ---------------------------
  20 4. Assurance Officer ("AO")
  21 The Board routinely delegates its responsibilities to the Assurance Officer (and this section assumes that, but does not require it).
  22 
  23 4.2 Deserts
  24 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. 
  25 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. 
  26 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. 
  27 
  28 
  29 
  30 
  31 CertificationPracticeStatement
  32 ------------------------------
  33 1.3. PKI participants
  34 The CA is technically operated by the Community, under the direction of the Board of CAcert Incorporated.
  35 
  36 3.1.7. International Domain Names
  37 The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list.
  38 
  39 5.2.1. Trusted roles
  40 Governance: 
  41  * Directors (members of the CAcert Inc. committee, or "Board") 
  42  * internal Auditor
  43  * Aribtrator
  44 
  45 8.3. Assessor's relationship to assessed entity
  46 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. 
  47 
  48 8.5. Actions taken as a result of deficiency
  49 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.
  50 
  51 9.5.2. Brand
  52 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. 
  53 
  54 
  55 Configuration-Control Specification
  56 -----------------------------------
  57 Hardware 
  58 Control
  59 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). 
  60 
  61 Software
  62 Control
  63 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.
  64 
  65 DisputeResolutionPolicy
  66 -----------------------
  67 2.1. Authority
  68 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. 
  69 
  70 3.2. Process 
  71 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.
  72 
  73 3.5 Liability
  74 The above provisions may only be overridden by appeal process (by means of a new dispute causing referral to the Board).
  75 
  76 3.6. Remedies 
  77 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.
  78 
  79 4.2. The Disadvantages of this Forum 
  80 * 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. 
  81 
  82 
  83 PolicyOnPolicy
  84 --------------
  85 4. DRAFT status
  86 4.6 During the period of DRAFT, CAcert Inc. retains a veto over policies that effect the running of CAcert Inc. 
  87 
  88 SecurityPolicy
  89 --------------
  90 1. INTRODUCTION
  91 1.1. Motivation and Scope
  92 The Committee of CAcert, Inc. (hereafter, "Board") may add additional components into the Security Manual. 
  93 
  94 3. LOGICAL SECURITY
  95 3.2. Operating System 
  96 3.2.3. Patching
  97 3.2.3.1. “emergency” patching 
  98 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. 
  99 
 100 3.4. Access control 
 101 3.4.2. Special Authorisation 
 102 All changes of personnel to the above lists are subject to Board approval. 
 103 
 104 4. OPERATIONAL SECURITY
 105 4.1. System administration 
 106 4.1.3. Change management procedures
 107 All changes made to system configuration must be recorded and reported in regular summaries to the Board of CAcert. 
 108 
 109 
 110 5. INCIDENT RESPONSE
 111 5.3. Immediate Action 
 112 5.3.3. Escalation
 113 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. 
 114 
 115 6. DISASTER RECOVERY
 116 Disaster Recovery is the responsibility of the Board of CAcert Inc. 
 117 
 118 6.1. Business Processes
 119 Board must develop and maintain documentation on Business Processes. From this list, Core Processes for business continuity / disaster recovery purposes must be identified. 
 120 
 121 6.2. Recovery Times
 122 Board should identify standard process times for all processes, and must designate Maximum Acceptable Outages and Recovery Time Objectives for the Core Processes. 
 123 
 124 6.3. Plan
 125 Board must have a basic plan to recover. 
 126 
 127 6.4. Key Persons List
 128 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. 
 129 
 130 7. SOFTWARE ASSESSMENT
 131 7.1. Authority
 132 The source code is under CCS. Additions to the team are subject to Board approval. See §3.4.2. 
 133 
 134 8. SUPPORT
 135 8.1. Authority
 136 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. 
 137 
 138 9. ADMINISTRATIVE
 139 9.1. Staffing
 140 9.1.1. Roles and responsibilities
 141 * Team leaders: coordinate with teams, report to Board.
 142 * All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.
 143 * Board: authorise new individuals and accesses. Coordinate overall.
 144 
 145 9.1.2. Staffing levels
 146 One individual in each team is designated team leader and reports to Board. 
 147 
 148 9.1.3. Process of new Team Members
 149 New team members need:
 150 * Recommendation by team leader
 151 * Arbitrated Background Check ("ABC")
 152 * Authorisation by Board
 153 
 154 9.1.5. Authorisation
 155 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.
 156 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. 
 157 
 158 9.1.7. Termination of staff
 159 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. 
 160 
 161 9.2. Root Key Management
 162 9.2.1. Root Key generation
 163 Root keys are generated only on instruction from Board. They must be generated to a fully documented and reviewed procedure. The procedure must include:
 164 [...]
 165 * Dual control over all phases, including by Board.
 166 [...]
 167 
 168 9.2.2. Backup and escrow
 169 The top-level root must be escrowed under Board control. Subroots may be escrowed by either Board or Systems Administration Team. 
 170 
 171 9.3. Legal
 172 9.3.1. Responsibility
 173 Board is responsible to the Community to manage the CA at the executive level. 
 174 
 175 9.3.2. Response to external (legal) inquiry
 176 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. 
 177 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. 
 178 
 179 9.4. Outsourcing 
 180 Contracts should be written with the above in mind. Outsourcing of critical components must be approved by the Board.
 181 
 182 
 183 
 184 
 185 
 186 
 187 
 188 
 189 
 190 Money
 191 Complaint rule 12/13
 192 Association membership
 193 contracts