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