diff --git a/CertificationPracticeStatement.html b/CertificationPracticeStatement.html
old mode 100755
new mode 100644
diff --git a/CertificationPracticeStatement.md b/CertificationPracticeStatement.md
new file mode 100644
index 0000000..2a1232b
--- /dev/null
+++ b/CertificationPracticeStatement.md
@@ -0,0 +1,3041 @@
+
+**WARNING:**
+The proper policy document is located
+[on the CAcert
+website](https://www.cacert.org/policy/CertificationPracticeStatement.html)
+.
+
+This document is a **working draft** to include
+future revisions only, and is currently
+only relevant for the \[policy\] group.
+Suggested additions in BLUE, strikes in blue.
+ Michael Tänzer 20111113: CPS \#7.1.2
+"Certificate Extensions" adjustments
+Ulrich Schroeter 20130309: several minor
+fixes according to [PoP
+2.5](https://svn.cacert.org/CAcert/Policies/PolicyOnPolicy.html) and
+[Bug \#1131](https://bugs.cacert.org/view.php?id=1131)
+
+- 20111113 changes are still incorporated
+ in the revision on main website but not in the svn revision, so
+ therefor copied over CPS revision from CAcert main website to SVN
+ policy working directory as source of changes
+- header reformated to reflect new header style
+- http to https fixes
+- full url fixes
+- wiki.cacert.org/wiki/ to wiki.cacert.org/ fixes
+- wiki redirects to redirected link fixes
+- img src images/ fixes
+- .php to .html fixes per [Bug
+ \#1131](https://bugs.cacert.org/view.php?id=1131)
+- replace all NRP-DaL references with text Root Distribution License
+ and RootDistributionLicense.html link
+- fix of ~65 html errors and ~14 html warnings
+
+------------------------------------------------------------------------
+
+
+
+
+
+# CAcert CPS and CP
+
+
+
+1. [INTRODUCTION](#p1)
+ - [1.1. Overview](#p1.1)
+ - [1.2. Document name and identification](#p1.2)
+ - [1.3. PKI participants](#p1.3)
+ - [1.4. Certificate usage](#p1.4)
+ - [1.5. Policy administration](#p1.5)
+ - [1.6. Definitions and acronyms](#p1.6)
+2. [PUBLICATION AND REPOSITORY RESPONSIBILITIES](#p2)
+ - [2.1. Repositories](#p2.1)
+ - [2.2. Publication of certification information](#p2.2)
+ - [2.3. Time or frequency of publication](#p2.3)
+ - [2.4. Access controls on repositories](#p2.4)
+3. [IDENTIFICATION AND AUTHENTICATION (I&A)](#p3)
+ - [3.1. Naming](#p3.1)
+ - [3.2. Initial Identity Verification](#p3.2)
+ - [3.3. I&A for Re-key Requests](#p3.3)
+ - [3.4. I&A for Revocation Request](#p3.4)
+4. [CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS](#p4)
+ - [4.1. Certificate Application](#p4.1)
+ - [4.2. Certificate application processing](#p4.2)
+ - [4.3. Certificate issuance](#p4.3)
+ - [4.4. Certificate acceptance](#p4.4)
+ - [4.5. Key pair and certificate usage](#p4.5)
+ - [4.6. Certificate renewal](#p4.6)
+ - [4.7. Certificate re-key](#p4.7)
+ - [4.8. Certificate modification](#p4.8)
+ - [4.9. Certificate revocation and suspension](#p4.9)
+ - [4.10. Certificate status services](#p4.10)
+ - [4.11. End of subscription](#p4.11)
+ - [4.12. Key escrow and recovery](#p4.12)
+5. [FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS](#p5)
+ - [5.1. Physical controls](#p5.1)
+ - [5.2. Procedural controls](#p5.2)
+ - [5.3. Personnel controls](#p5.3)
+ - [5.4. Audit logging procedures](#p5.4)
+ - [5.5. Records archival](#p5.5)
+ - [5.6. Key changeover](#p5.6)
+ - [5.7. Compromise and disaster recovery](#p5.7)
+ - [5.8. CA or RA termination](#p5.8)
+6. [TECHNICAL SECURITY CONTROLS](#p6)
+ - [6.1. Key pair generation and installation](#p6.1)
+ - [6.2. Private Key Protection and Cryptographic Module
+ Engineering Controls](#p6.2)
+ - [6.3. Other aspects of key pair management](#p6.3)
+ - [6.4. Activation data](#p6.4)
+ - [6.5. Computer security controls](#p6.5)
+ - [6.6. Life cycle technical controls](#p6.6)
+ - [6.7. Network security controls](#p6.7)
+ - [6.8. Time-stamping](#p6.8)
+7. [CERTIFICATE, CRL, AND OCSP PROFILES](#p7)
+ - [7.1. Certificate profile](#p7.1)
+ - [7.2. CRL profile](#p7.2)
+ - [7.3. OCSP profile](#p7.3)
+8. [COMPLIANCE AUDIT AND OTHER ASSESSMENTS](#p8)
+ - [8.1. Frequency or circumstances of assessment](#p8.1)
+ - [8.2. Identity/qualifications of assessor](#p8.2)
+ - [8.3. Assessor's relationship to assessed entity](#p8.3)
+ - [8.4. Topics covered by assessment](#p8.4)
+ - [8.5. Actions taken as a result of deficiency](#p8.5)
+ - [8.6. Communication of results](#p8.6)
+9. [OTHER BUSINESS AND LEGAL MATTERS](#p9)
+ - [9.1. Fees](#p9.1)
+ - [9.2. Financial responsibility](#p9.2)
+ - [9.3. Confidentiality of business information](#p9.3)
+ - [9.4. Privacy of personal information](#p9.4)
+ - [9.5. Intellectual property rights](#p9.5)
+ - [9.6. Representations and warranties](#p9.6)
+ - [9.7. Disclaimers of warranties](#p9.7)
+ - [9.8. Limitations of liability](#p9.8)
+ - [9.9. Indemnities](#p9.9)
+ - [9.10. Term and termination](#p9.10)
+ - [9.11. Individual notices and communications with
+ participants](#p9.11)
+ - [9.12. Amendments](#p9.12)
+ - [9.13. Dispute resolution provisions](#p9.13)
+ - [9.14. Governing law](#p9.14)
+ - [9.15. Compliance with applicable law](#p9.15)
+ - [9.16. Miscellaneous provisions](#p9.16)
+
+
+
+## 1. INTRODUCTION
+
+### 1.1. Overview
+
+This document is the Certification Practice Statement (CPS) of CAcert,
+the Community Certification Authority (CA). It describes rules and
+procedures used by CAcert for operating its CA, and applies to all
+CAcert PKI Participants, including Assurers, Members, and CAcert itself.
+
+
+
+### 1.2. Document name and identification
+
+This document is the Certification Practice Statement (CPS) of CAcert.
+The CPS also fulfills the role of the Certificate Policy (CP) for each
+class of certificate.
+
+- This document is COD6 under CAcert Official Documents numbering
+ scheme.
+
+- The document is structured according to Chokhani, et al,
+ [RFC3647](http://www.ietf.org/rfc/rfc3647.txt), [chapter
+ 4](http://tools.ietf.org/html/rfc3647#section-4). All headings
+ derive from that Chapter.
+
+- It has been improved and reviewed (or will be reviewed) to meet or
+ exceed the criteria of the Certificate Authority Review Checklist
+ from *David E. Ross* ("DRC") and Mozilla Foundation's CA policy.
+
+- OID assigned to this document: 1.3.6.1.4.1.18506.4.4.x (x=approved
+ Version)
+ ([iana.org](http://www.iana.org/assignments/enterprise-numbers))
+
+ .x will change to .1 in the first approved instance.
+
+- © CAcert Inc. 2006-2009.
+
+- Issued under the CAcert document licence policy, as and when made
+ policy. See
+ [PolicyDrafts/DocumentLicence](https://wiki.cacert.org/PolicyDrafts/DocumentLicence).
+ - The cited page discusses 2 options: CCau Attribute-Share-alike
+ and GNU Free Document License. Refer to that.
+ - Note that the noun Licence in Australian English has two Cs. The
+ verb License is spelt the same way as American English.
+
+- Earlier notes were written by Christian Barmala in a document placed
+ under GNU Free Document License and under FSF copyright. However
+ this clashed with the control provisions of Configuration-Control
+ Specification (COD2) within Audit criteria.
+
+- In this document:
+ - green text refers to questions that seek
+ answers,
+ - red text refers to probably audit
+ fails or serious errors.
+ - blue text refers to changes written
+ after the document got seriously reviewed.
+
+ None is to be considered part of the policy, and
+ they should disappear in the DRAFT and must disappear in the POLICY.
+
+
+The CPS is an authoritive document, and rules other documents except
+where explicitly deferred to. See also [1.5.1 Organisation Administering
+the Document](#p1.5.1).
+
+### 1.3. PKI participants
+
+The CA is legally operated by CAcert Incorporated, an Association
+registered in 2002 in New South Wales, Australia, on behalf of the wider
+Community of Members of CAcert. The Association details are at the
+[CAcert wiki](https://wiki.cacert.org/CAcertInc).
+
+CAcert is a Community formed of Members who agree to the [CAcert
+Community
+Agreement](https://www.cacert.org/policy/CAcertCommunityAgreement.html).
+The CA is technically operated by the Community, under the direction of
+the Board of CAcert Incorporated. (The Members of the Community are not
+to be confused with the *Association Members*, which latter are not
+referred to anywhere in this CPS.)
+
+#### 1.3.1. Certification authorities
+
+CAcert does not issue certificates to external intermediate CAs under
+the present CPS.
+
+#### 1.3.2. Registration authorities
+
+Registration Authorities (RAs) are controlled under Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
+
+#### 1.3.3. Subscribers
+
+CAcert issues certificates to Members only. Such Members then become
+Subscribers.
+
+#### 1.3.4. Relying parties
+
+A relying party is a Member, having agreed to the CAcert Community
+Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)),
+who, in the act of using a CAcert certificate, makes a decision on the
+basis of that certificate.
+
+#### 1.3.5. Other participants
+
+**Member.** Membership of the Community is as defined in the
+[COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html).
+Only Members may RELY or may become Subscribers. Membership is free.
+
+**Arbitrator.** A senior and experienced Member of the CAcert Community
+who resolves disputes between Members, including ones of certificate
+reliance, under Dispute Resolution Policy
+([COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html)).
+
+**Vendor.** Software suppliers who integrate the root certificates of
+CAcert into their software also assume a proxy role of Relying Parties,
+and are subject to another licence. At the time of
+writing, the "3rd Party Vendor - Disclaimer and Licence" is being worked
+upon, but is neither approved nor offered.
+
+**Non-Related Persons** (NRPs). These are users of browsers and similar
+software who are unaware of the CAcert certificates they may use, and
+are unaware of the ramifications of usage. Their relationship with
+CAcert is described by the Root Distribution License
+([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
+No other rights nor relationship is implied or offered.
+
+### 1.4. Certificate usage
+
+CAcert serves as issuer of certificates for individuals, businesses,
+governments, charities, associations, churches, schools,
+non-governmental organisations or other groups. CAcert certificates are
+intended for low-cost community applications especially where volunteers
+can become Assurers and help CAcert to help the Community.
+
+Types of certificates and their appropriate and corresponding
+applications are defined in [§1.4.1](#p1.4.1). Prohibited applications
+are defined in [§1.4.2](#p1.4.2). Specialist uses may be agreed by
+contract or within a specific environment, as described in
+[§1.4.4](#p1.4.4). Note also the unreliable applications in
+[§1.4.3](#p1.4.3) and risks, liabilities and obligations in [§9](#p9).
+
+
+
+
+| Type |
+Appropriate Certificate uses |
+
+
+| General |
+Protocol |
+Description |
+Comments |
+
+
+| Server |
+TLS |
+web server encryption |
+enables encryption |
+
+
+| embedded |
+embedded server authentication |
+mail servers, IM-servers |
+
+
+| Client |
+S/MIME |
+email encryption |
+"digital signatures" employed in S/MIME are not legal / human
+signatures, but instead enable the encryption mode of S/MIME |
+
+
+| TLS |
+client authentication |
+the nodes must be secure |
+
+
+| TLS |
+web based signature applications |
+the certificate authenticates only. See §1.4.3. |
+
+
+| "Digital Signing" |
+for human signing over documents |
+Only within a wider application and rules such as by separate
+policy, as agreed by contract, etc. See §1.4.4. |
+
+
+| Code |
+Authenticode, ElfSign, Java |
+Code Signing |
+Signatures on packages are evidence of their Membership and
+indicative of Identity |
+
+
+| PGP |
+OpenPGP |
+Key Signing |
+Signatures on Member Keys are evidence of their Membership and
+indicative of Identity |
+
+
+| Special |
+X.509 |
+OCSP, Timestamping |
+Only available to CAcert Systems Administrators, as controlled by
+Security Policy |
+
+
+
+
+Table 1.4. Types of Certificate
+
+#### 1.4.1. Appropriate certificate uses
+
+General uses.
+
+- CAcert server certificates can be used to enable encryption
+ protection in web servers. Suitable applications include webmail and
+ chat forums.
+- CAcert server certificates can be used to enable encryption in
+ SSL/TLS links in embedded protocols such as mail servers and
+ IM-servers.
+- CAcert client certificates can be used to enable encryption
+ protection in email clients. (See [§1.4.3](#p1.4.3) for caveat on
+ signatures.)
+- CAcert client certificates can be used to replace password-based
+ authentication to web servers.
+- OpenPGP keys with CAcert signatures can be used to encrypt and sign
+ files and emails, using software compatible with OpenPGP.
+- CAcert client certificates can be used in web-based authentication
+ applications.
+- CAcert code signing certificates can be used to sign code for
+ distribution to other people.
+- Time stamping can be used to attach a time record to a digital
+ document.
+
+#### 1.4.2. Prohibited certificate uses
+
+CAcert certificates are not designed, intended, or authorised for the
+following applications:
+
+- Use or resale as control equipment in hazardous circumstances or for
+ uses requiring fail-safe performance such as the operation of
+ nuclear facilities, aircraft navigation or communication systems,
+ air traffic control systems, or weapons control systems, where
+ failure could lead directly to death, personal injury, or severe
+ environmental damage.
+
+#### 1.4.3. Unreliable Applications
+
+CAcert certificates are not designed nor intended for use in the
+following applications, and may not be reliable enough for these
+applications:
+
+- **Signing within Protocols.** Digital signatures made by CAcert
+ certificates carry NO default legal or human meaning. See
+ [§9.15.1](#p9.15.1). Especially, protocols such as S/MIME commonly
+ will automatically apply digital signatures as part of their
+ protocol needs. The purpose of the cryptographic signature in S/MIME
+ and similar protocols is limited by default to strictly protocol
+ security purposes: to provide some confirmation that a familiar
+ certificate is in use, to enable encryption, and to ensure the
+ integrity of the email in transit.
+- **Non-repudiation applications.** Non-repudiation is not to be
+ implied from use of CAcert certificates. Rather, certificates may
+ provide support or evidence of actions, but that evidence is
+ testable in any dispute.
+- **Ecommerce applications.** Financial transactions or payments or
+ valuable e-commerce.
+- Use of anonymous (Class 1 or Member SubRoot) certificates in any
+ application that requires or expects identity.
+
+#### 1.4.4. Limited certificate uses
+
+By contract or within a specific environment (e.g. internal to a
+company), CAcert Members are permitted to use Certificates for higher
+security, customised or experimental applications. Any such usage,
+however, is limited to such entities and these entities take on the
+whole responsible for any harm or liability caused by such usage.
+
+**Digital signing applications.** CAcert client certificates may be used
+by Assured Members in applications that provide or support the human
+signing of documents (known here as "digital signing"). This must be
+part of a wider framework and set of rules. Usage and reliance must be
+documented either under a separate CAcert digital signing policy or
+other external regime agreed by the parties.
+
+#### 1.4.5. Roots and Names
+
+**Named Certificates.** Assured Members may be issued certificates with
+their verified names in the certificate. In this role, CAcert operates
+and supports a network of Assurers who verify the identity of the
+Members. All Names are verified, either by Assurance or another defined
+method under policy (c.f. Organisations).
+
+**Anonymous Certificates.** Members can be issued certificates that are
+anonymous, which is defined as the certificate with no Name included, or
+a shared name such as "Community Member". These may be considered to be
+somewhere between Named certificates and self-signed certificates. They
+have serial numbers in them which is ultimately traceable via dispute to
+a Member, but reliance is undefined. In this role, CAcert provides the
+infrastructure, saving the Members from managing a difficult and messy
+process in order to get manufactured certificates.
+
+**Psuedonymous Certificates.** Note that CAcert does not currently issue
+pseudonymous certificates, being those with a name chosen by the Member
+and not verifiable according to documents.
+
+**Advanced Certificates.** Members who are as yet unassured are not
+permitted to create advanced forms such as wildcard or subjectAltName
+certificates.
+
+**Roots.** The (new) CAcert root layout is as
+below. These roots are pending Audit, and will be submitted to vendors
+via the (Top-level) Root.
+
+- **(Top-level) Root.** Used to sign on-line CAcert SubRoots only.
+ This Root is kept offline.
+- **Member SubRoot.** For Community Members who are new and unassured
+ (some restrictions exist). Reliance is undefined. (Replacement for
+ the Class 1 root, matches "Domain Validation" type.)
+- **Assured SubRoot.** Only available for Assured individual Members,
+ intended to sign certificates with Names. Suitable for Reliance
+ under this and other policies. Approximates the type known as
+ Individual Validation.
+- **Organisation SubRoot.** Only available for Assured Organisation
+ Members. Suitable for Reliance under this and other policies.
+ Approximates the type known as Organisational Validation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ |
+Level of Assurance |
+ |
+ |
+
+
+ |
+Members † |
+Assured Members |
+Assurers |
+ |
+
+
+| Class of Root |
+Anon |
+Name |
+Anon |
+Name |
+Name+Anon |
+Remarks |
+
+
+Top level
+Root |
+• |
+• |
+• |
+• |
+• |
+Signs other CAcert SubRoots only. |
+
+
+Member
+SubRoot |
+✔ |
+✘ |
+✔ |
+✔ |
+✔ |
+† For Members meeting basic checks in §4.2.2
+(Reliance is undefined.) |
+
+
+Assured
+SubRoot |
+✘ |
+✘ |
+✔ |
+✔ |
+✔ |
+Assured Members only.
+Fully intended for reliance. |
+
+
+Organisation
+SubRoot |
+✘ |
+✘ |
+✔ |
+✔ |
+✔ |
+Assured Organisation Members only.
+Fully intended for reliance. |
+
+
+| Expiry of Certificates |
+6 months |
+24 months |
+ |
+ |
+
+
+| Types |
+client, server |
+wildcard, subjectAltName |
+code-signing |
+(Inclusive to the left.) |
+
+
+
+
+Table 1.4.5.b Certificate under Audit Roots
+
+Following information on OLD roots here for descriptive and historical
+purposes only. When CPS goes to DRAFT, this needs to be converted into a
+short summary of the way OLD roots are used and its relationship to this
+CPS. E.g., "OLD roots are used for testing and other purposes outside
+this CPS." Because ... they still exist, and people will look at the CPS
+to figure it out.
+
+
+
+
+
+
+
+
+
+
+
+
+ |
+Level of Assurance |
+ |
+ |
+
+
+ |
+Members |
+Assured Members |
+ |
+ |
+
+
+| Class of Root |
+Anonymous |
+Named |
+Anonymous |
+Named |
+Remarks |
+
+
+Class
+1 |
+✔ |
+✘ |
+✔ |
+✔ |
+Available for all Members,
+reliance is undefined. |
+
+
+Class
+3 |
+✘ |
+✘ |
+✔ |
+✔ |
+Assured Members only.
+Intended for Reliance. |
+
+
+| Expiry of Certificates |
+6 months |
+24 months |
+ |
+ |
+
+
+| Types available |
+simple only |
+wildcard, subjectAltName |
+ |
+ |
+
+
+
+
+Table 1.4.5. Certificates under Old Roots - **Audit
+Fail**
+
+**Old Roots.** The old CAcert root layout is as below. These roots are
+**Audit Fail** and will only be used where new roots do not serve:
+
+- (old) **Class 1 root.** Used primarily for certificates with no
+ names and by unassured Members. For compatibility only, Assured
+ Members may also use this root.
+- (old) **Class 3 root.** Used primarily for certificates including
+ the names of Assured Members. Signed by Class 1 root. Members can
+ decide to rely on these certificates for Assured Members by
+ selecting the Class 3 root for Assured Members as trust anchor.
+
+
+
+- Current Mozilla position has drifted from Class 1,2,3s to DV, IV+OV
+ and EV posture. Except, the actual posture is either unstated or
+ difficult to fathom.
+- scheme for future roots is at
+ [NewRootsTaskForce](https://wiki.cacert.org/Roots/NewRootsTaskForce).
+- END OLD ROOTS
+
+### 1.5. Policy administration
+
+See [1.2 Document Name and Identification](#p1.2) for general scope of
+this document.
+
+#### 1.5.1. Organization administering the document
+
+This document is administered by the policy group of the CAcert
+Community under Policy on Policy
+([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html)).
+
+#### 1.5.2. Contact person
+
+For questions including about this document:
+
+- Join the policy group, by means of the discussion forum at
+ [lists.cacert.org](https://lists.cacert.org/wws/lists) .
+- Send email to \< support AT cacert DOT org \>
+- IRC: irc.cacert.org \#CAcert (ssl port 7000, non-ssl port 6667)
+
+#### 1.5.3. Person determining CPS suitability for the policy
+
+This CPS and all other policy documents are managed by the policy group,
+which is a group of Members of the Community found at policy forum. See
+discussion forums above.
+
+#### 1.5.4. CPS approval procedures
+
+CPS is controlled and updated according to the Policy on Policy
+([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html)) which is
+part of Configuration-Control Specification (COD2).
+
+In brief, the policy forum prepares and discusses. After a last call,
+the document moves to DRAFT status for a defined period. If no
+challenges have been received in the defined period, it moves to POLICY
+status. The process is modelled after some elements of the RFC process
+by the IETF.
+
+#### 1.5.5 CPS updates
+
+As per above.
+
+### 1.6. Definitions and acronyms
+
+**Certificate**. A certificate is a piece of
+cryptographic data used to validate certain statements, especially those
+of identity and membership.
+
+**CAcert**. CAcert is a Community certificate
+authority as defined under [§1.2 Identification](#p1.2).
+
+**Member**. Everyone who agrees to the CAcert
+Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
+This generally implies having an account registered at CAcert and making
+use of CAcert's data, programs or services. A Member may be an
+individual ("natural person") or an organisation (sometimes, "legal
+person").
+
+****. The group of Members who
+agree to the CAcert Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)) or
+equivalent agreements.
+
+**Unassured Member**. A Member who has not
+yet been Assured.
+
+**Subscriber**. A Member who requests and
+receives a certificate.
+
+**Assured Member**. A Member whose identity
+has been sufficiently verified by Assurers or other approved methods
+under Assurance Policy.
+
+**Assurer**. An Assured Member who is
+authorised under Assurance Policy to verify the identity of other
+Members.
+
+**Name**. As defined in the Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)), to
+describe a name of a Member that is verified by the Assurance process.
+
+**Organisation Administrator**. ("O-Admin")
+An Assurer who is authorised to act for an Organisation. The O-Admin is
+authorised by an organisation to vouch for the identity of other users
+of the organisation.
+
+**Organisation Assurer**. An Assurer who is
+authorised to conduct assurances on organisations.
+
+**Non-Related Persons**. ("NRPs") are general
+users of browsers and similar software. The NRPs are generally unaware
+of CAcert or the certificates that they may use, and are unaware of the
+ramifications of usage. They are not permitted to RELY, but may USE,
+under the Root Distribution License
+([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
+
+**Reliance**. An industry term referring to
+the act of making a decision, including taking a risk, which decision is
+in part or in whole informed or on the basis of the contents of a
+certificate.
+
+**Relying Party**. An industry term
+refering to someone who relies (that is, makes decisions or takes risks)
+in part or in whole on a certificate.
+
+**Subscriber Naming.** The term used in this CPS to describe all naming
+data within a certificate. Approximately similar terms from Industry
+such as "Subject naming" and "Distinguished Name" are not used here.
+
+**Verification**. An industry term
+referring to the act of checking and controlling the accuracy and
+utility of a single claim.
+
+**Validation**. An industry term
+referring to the process of inspecting and verifying the information and
+subsidiary claims behind a claim.
+
+**Usage**. The event of allowing a certificate
+to participate in a protocol, as decided and facilitated by a user's
+software. Generally, Usage does not require significant input, if any,
+on the part of the user. This defers all decisions to the user software,
+thus elevating the software as user's only and complete Validation
+Authority or Agent.
+
+**CAcert Relying Party**. CAcert Members who make
+decisions based in part or in whole on a certificate issued by CAcert.
+Only CAcert Members are permitted to Rely on CAcert certificates,
+subject to the CAcert Community Agreement.
+
+**Vendors**. Non-members who distribute CAcert's
+root or intermediate certificates in any way, including but not limited
+to delivering these certificates with their products, e.g. browsers,
+mailers or servers. Vendors are covered under a separate licence. As of the moment, this licence is not written.
+
+**Configuration-Control Specification** "CCS".
+The audit criteria that controls this CPS. The CCS is documented in
+COD2, itself a controlled document under CCS.
+
+**CAcert Official Document** (COD). Controlled
+Documents that are part of the CCS.
+
+## 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
+
+### 2.1. Repositories
+
+CAcert operates no repositories in the sense of lookup for
+non-certificate-related information for the general public.
+
+Under the Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)), there are
+means for Members to search, retrieve and verify certain data about
+themselves and others.
+
+### 2.2. Publication of certification information
+
+CAcert publishes:
+
+- A repository of CRLs. An OCSP responder is in operation.
+- The root certificate and intermediate certificates.
+
+CAcert does not expressly publish information on issued certificates.
+However, due to the purpose of certificates, and the essential public
+nature of Names and email addresses, all information within certificates
+is presumed to be public and published, once issued and delivered to the
+Member.
+
+### 2.3. Time or frequency of publication
+
+Root and Intermediate Certificates and CRLs are made available on
+issuance.
+
+### 2.4. Access controls on repositories
+
+No stipulation.
+
+## 3. IDENTIFICATION AND AUTHENTICATION
+
+### 3.1. Naming
+
+#### 3.1.1. Types of names
+
+**Client Certificates.** The Subscriber Naming consists of:
+
+- subjectAltName= One, or more, of the Subscriber's verified email
+ addresses, in rfc822Name format.
+ - SSO in subjectAltName?.
+- EmailAddress= One, or more, of the Subscriber's verified email
+ addresses. This is deprecated under RFC5280 [4
+ .1.2.6](http://tools.ietf.org/html/rfc5280#section-4.2.1.6) and is
+ to be phased out. Also includes a SHA1 hash of a random number if
+ the member selects SSO (Single Sign On ID) during submission of CSR.
+- CN= The common name takes its value from one of:
+ - For all Members, the string "CAcert WoT Member" may be used for
+ anonymous certificates.
+ - For individual Members, a Name of the Subscriber, as Assured
+ under AP.
+ - For Organisation Members, an organisation-chosen name, as
+ verified under OAP.
+
+
+
+- [bug 672](https://bugs.cacert.org/view.html?id=672) filed on
+ subjectAltName.
+- O-Admin must verify as per
+ [p20081016](https://wiki.cacert.org/PolicyDecisions#p20081016).
+- it is a wip for OAP to state how this is done.
+- curiously, (RFC5280) verification is only mandated for
+ subjectAltName not subject field.
+- what Directory String is used in above? UTF8String is specified by
+ RFC52804.1.2.6? is this important for the CPS to state?
+
+**Individual Server Certificates.** The Subscriber Naming consists of:
+
+- CN= The common name is the host name out of a domain for which the
+ Member is a domain master.
+- subjectAltName= Additional host names for which the Member is a
+ domain master may be added to permit the certificate to serve
+ multiple domains on one IP number.
+- All other fields are optional and must either match the CN or they
+ must be empty
+
+**Certificates for Organisations.** In addition to the above, the
+following applies:
+
+- OU= organizationalUnitName (set by O-Admin, must be verified by
+ O-Admin).
+- O= organizationName is the fixed name of the Organisation.
+- L= localityName
+- ST= stateOrProvinceName
+- C= countryName
+- contact= EMail Address of Contact.
+
+Except for the OU and CN, fields are taken from the Member's account and
+are as verified by the Organisation Assurance process. Other Subscriber
+information that is collected and/or retained does not go into the
+certificate.
+
+#### 3.1.2. Need for names to be meaningful
+
+Each Member's Name (CN= field) is assured under the Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)) or
+subsidiary policies (such as Organisation Assurance Policy). Refer to
+those documents for meanings and variations.
+
+Anonymous certificates have the same `subject` field common name. See
+[§1.4.5.](#p1.4.5).
+
+Email addresses are verified according to [§4.2.2.](#p4.2.2)
+
+#### 3.1.3. Anonymity or pseudonymity of subscribers
+
+See [§1.4.5](#p1.4.5).
+
+#### 3.1.4. Rules for interpreting various name forms
+
+Interpretation of Names is controlled by the Assurance Policy, is
+administered by means of the Member's account, and is subject to change
+by the Arbitrator. Changes to the interpretation by means of Arbitration
+should be expected as fraud (e.g., phishing) may move too quickly for
+policies to fully document rules.
+
+#### 3.1.5. Uniqueness of names
+
+Uniqueness of Names within certificates is not guaranteed. Each
+certificate has a unique serial number which maps to a unique account,
+and thus maps to a unique Member. See the Assurance Statement within
+Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
+
+Domain names and email address can only be registered to one Member.
+
+#### 3.1.6. Recognition, authentication, and role of trademarks
+
+Organisation Assurance Policy
+([COD11](https://www.cacert.org/policy/OrganisationAssurancePolicy.html))
+controls issues such as trademarks where applicable. A trademark can be
+disputed by filing a dispute. See [§9.13](#adr).
+
+#### 3.1.7. International Domain Names
+
+Certificates containing International Domain Names, being those
+containing a ACE prefix ([RFC3490 Section
+5](http://www.ietf.org/rfc/rfc3490#section-5)), will only be issued to
+domains satisfying one or more of the following conditions:
+
+- The Top Level Domain (TLD) Registrar associated with the domain has
+ a policy that has taken measures to prevent two homographic domains
+ being registered to different entities down to an accepted level.
+- Domains contain only code points from a single unicode character
+ script, excluding the "Common" script, with the additionally allowed
+ numberic characters \[0-9\], and an ACSII hyphen '-'.
+
+Email address containing International Domain Names in the domain
+portion of the email address will also be required to satisfy one of the
+above conditions.
+
+The following is a list of accepted TLD Registrars:
+
+
+
+This criteria will apply to the email address and server host name
+fields for all certificate types.
+
+The CAcert Inc. Board has the authority to decide to add or remove
+accepted TLD Registrars on this list.
+
+### 3.2. Initial Identity Verification
+
+Identity verification is controlled by the [Assurance
+Policy](https://www.cacert.org/policy/AssurancePolicy.html)
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)). The
+reader is refered to the Assurance Policy, the following is
+representative and brief only.
+
+#### 3.2.1. Method to prove possession of private key
+
+CAcert uses industry-standard techniques to prove the possession of the
+private key.
+
+For X.509 server certificates, the stale digital signature of the CSR is
+verified. For X.509 client certificates for "Netscape" browsers, SPKAC
+uses a challenge-response protocol to check the private key dynamically.
+For X.509 client certificates for "explorer" browsers, ActiveX uses a
+challenge-response protocol to check the private key dynamically.
+
+#### 3.2.2. Authentication of Individual Identity
+
+**Agreement.** An Internet user becomes a Member by agreeing to the
+CAcert Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html))
+and registering an account on the online website. During the
+registration process Members are asked to supply information about
+themselves:
+
+- A valid working email.
+- Full Name and Date of Birth such as is found on Identity documents.
+- Personal Questions used only for Password Retrieval.
+
+The online account establishes the method of authentication for all
+service requests such as certificates.
+
+**Assurance.** Each Member is assured according to Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
+
+**Certificates.** Based on the total number of Assurance Points that a
+Member (Name) has, the Member can get different levels of certificates.
+See [§1.4.5](#p1.4.5). See Table 3.2.b. When Members have 50 or more
+points, they become *Assured Members* and may then request certificates
+that state their Assured Name(s).
+
+
+
+
+
+
+
+
+
+
+| 0 |
+Unassured Member |
+Anonymous |
+Certificates with no Name, under Class 1 Root. Limited to 6 months
+expiry. |
+
+
+| 1-49 |
+Unassured Member |
+Anonymous |
+Certificates with no Name under Member SubRoot. Limited to 6 months
+expiry. |
+
+
+| 50-99 |
+Assured Member |
+Verified |
+Certificates with Verified Name for S/MIME, web servers, "digital
+signing." Expiry after 24 months is available. |
+
+
+| 100++ |
+Assurer |
+Code-signing |
+Can create Code-signing certificates |
+
+
+
+
+Table 3.2.b - How Assurance Points are used in
+Certificates
+
+
+
+#### 3.2.3. Authentication of organization identity
+
+Verification of organisations is delegated by the Assurance Policy to
+the Organisation Assurance Policy
+([COD11](https://www.cacert.org/policy/OrganisationAssurancePolicy.html)).
+The reader is refered to the Organisation Assurance Policy, the
+following is representative and brief only.
+
+Organisations present special challenges. The Assurance process for
+Organisations is intended to permit the organisational Name to appear in
+certificates. The process relies heavily on the Individual process
+described above.
+
+Organisation Assurance achieves the standard stated in the OAP, briefly
+presented here:
+
+1. the organisation exists,
+2. the organisation name is correct and consistent,
+3. signing rights: requestor can sign on behalf of the organisation,
+ and
+4. the organisation has agreed to the terms of the CAcert Community
+ Agreement
+ ([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)),
+ and is therefore subject to Arbitration.
+
+- As of the current time of writing, OA lacks critical documentation
+ and there are bugs identified with no response.
+- [documented
+ bugs](https://wiki.cacert.org/PolicyDrafts/OrganisationAssurance).
+- Therefore Organisations will not participate in the current audit
+ cycle of roots.
+- See [wiki](https://wiki.cacert.org/OrganisationAssurance) for any
+ progress on this.
+
+#### 3.2.4. Non-verified subscriber information
+
+All information in the certificate is verified, see Relying Party
+Statement, §4.5.2.
+
+#### 3.2.5. Validation of authority
+
+The authorisation to obtain a certificate is established as follows:
+
+**Addresses.** The member claims authority over a domain or email
+address when adding the address, [§4.1.2](#p4.1.2). (Control is tested
+by means described in [§4.2.2](#p4.2.2).)
+
+**Individuals.** The authority to participate as a Member is established
+by the CAcert Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
+Assurances are requested by means of the signed CAP form.
+
+**Organisations.** The authority for Organisation Assurance is
+established in the COAP form, as signed by an authorised representative
+of the organisation. The authority for the Organisation Administrator
+(O-Admin) is also established on the COAP form. See Organisation
+Assurance Policy.
+
+#### 3.2.6. Criteria for interoperation
+
+CAcert does not currently issue certificates to subordinate CAs or other
+PKIs. Other CAs may become Members, and are then subject to the same
+reliance provisions as all Members.
+
+### 3.3. Re-key Requests
+
+Via the Member's account.
+
+### 3.4. Revocations Requests
+
+Via the Member's account. In the event that the Member has lost the
+password, or similar, the Member emails the support team who either work
+through the lost-password questions process or file a dispute.
+
+## 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
+
+The general life-cycle for a new certificate for an Individual Member
+is:
+
+1. Member adds claim to an address (domain/email).
+2. System probes address for control.
+3. Member creates key pair.
+4. Member submits CSR with desired options (Anonymous Certificate, SSO,
+ Root Certificate) .
+5. System validates and accepts CSR based on known information: claims,
+ assurance, controls, technicalities.
+6. System signs certificate.
+7. System makes signed certificate available to Member.
+8. Member accepts certificate.
+
+(Some steps are not applicable, such as anonymous certificates.)
+
+### 4.1. Certificate Application
+
+#### 4.1.1. Who can submit a certificate application
+
+Members may submit certificate applications. On issuance of
+certificates, Members become Subscribers.
+
+#### 4.1.2. Adding Addresses
+
+The Member can claim ownership or authorised control of a domain or
+email address on the online system. This is a necessary step towards
+issuing a certificate. There are these controls:
+
+- The claim of ownership or control is legally significant and may be
+ referred to dispute resolution.
+- Each unique address can be handled by one account only.
+- When the Member makes the claim, the certificate application system
+ automatically initiates the check of control, as below.
+
+#### 4.1.3. Preparing CSR
+
+Members generate their own key-pairs. The CAcert Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html))
+obliges the Member as responsible for security. See CCA2.5, §9.6.
+
+The Certificate Signing Request (CSR) is prepared by the Member for
+presentation to the automated system.
+
+### 4.2. Certificate application processing
+
+The CA's certificate application process is completely automated.
+Requests, approvals and rejections are handled by the website system.
+Each application should be processed in less than a minute.
+
+Where certificates are requested for more than one purpose, the
+requirements for each purpose must be fulfilled.
+
+#### 4.2.1. Authentication
+
+The Member logs in to her account on the CAcert website and thereby
+authenticates herself with username and passphrase or with her CAcert
+client-side digital certificate.
+
+#### 4.2.2. Verifying Control
+
+In principle, at least two controls are placed on each address.
+
+**Email-Ping.** Email addresses are verified by
+means of an *Email-Ping test*:
+
+- The system generates a cookie (a random, hard-to-guess code) and
+ formats it as a string.
+- The system sends the cookie to the Member in an email.
+- Once the Member receives the email, she enters the cookie into the
+ website.
+- The entry of the code verifies control of that email account.
+
+**Email Control.** Email addresses for client
+certificates are verified by passing the following checks:
+
+1. An Email-ping test is done on the email address.
+2. The Member must have signed a CAP form or equivalent, and been
+ awarded at least one Assurance point.
+
+**Domain Control.** Domains addresses for
+server certificates are verified by passing two of the following checks:
+
+1. An Email-ping test is done on an email address chosen from *whois*
+ or interpolated from the domain name.
+2. The system generates a cookie which is then placed in DNS by the
+ Member.
+3. The system generates a cookie which is then placed in HTTP headers
+ or a text file on the website by the Member.
+4. Statement by at least 2 Assurers about ownership/control of the
+ domain name.
+5. The system generates a cookie which is then placed in whois registry
+ information by the Member.
+
+Notes.
+
+- Other methods can be added from time to time by CAcert.
+- Static cookies should remain for the duration of a certificate for
+ occasional re-testing.
+- Dynamic tests can be repeated at a later time of CAcert's choosing.
+- Domain control checks may be extended to apply to email control in
+ the future.
+
+
+
+- As of the time of writing, only a singular Email-ping is implemented
+ in the technical system.
+- A further approved check is the 1 pt Assurance.
+- Practically, this would mean that certificates can only be issued
+ under Audit Roots to Members with 1 point.
+- Criteria DRC C.7.f, A.2.q, A.2.i indicate registry whois reading.
+ Also A.2.h.
+- Current view is that this will be resolved in BirdShack.
+
+#### 4.2.3. Options Available
+
+The Member has options available:
+
+- Each Email address that is verified is available for Client
+ Certificates.
+- Each Domain address that is verified is available for Server
+ Certificates.
+- If the Member is unassured then only the Member SubRoot is
+ available.
+- If the Member is Assured then both Assured Member and Member
+ SubRoots are available.
+- If a Name is Assured then it may be put in a client certificate or
+ an OpenPGP signature.
+
+#### 4.2.4. Client Certificate Procedures
+
+For an individual client certificate, the following is required.
+
+- The email address is claimed and added.
+- The email address is ping-tested.
+- For the Member Subroot, the Member must have at least one point of
+ Assurance and have signed a CAP form.
+- For the Assured Subroot, the Member must have at least fifty points
+ of Assurance.
+- To include a Name, the Name must be assured to at least fifty
+ points.
+
+#### 4.2.5. Server Certificate Procedures
+
+For a server certificate, the following is required:
+
+- The domain is claimed and added.
+- The domain is checked twice as above.
+- For the Member SubRoot, the Member must have at least one point of
+ Assurance and have signed a CAP form.
+- For the Assured SubRoot, the Member must have at least fifty points
+ of Assurance.
+
+#### 4.2.6. Code-signing Certificate Procedures
+
+Code-signing certificates are made available to Assurers only. They are
+processed in a similar manner to client certificates.
+
+#### 4.2.7. Organisation Domain Verification
+
+Organisation Domains are handled under the Organisation Assurance Policy
+and the Organisation Handbook.
+
+- As of time of writing, there is no Handbook for Organisation
+ Assurers or for the Organisation, and the policy needs rework; so
+ (audit) roots will not have OA certs ....
+- [Drafts](https://wiki.cacert.org/PolicyDrafts/OrganisationAssurance)
+ for ongoing story.
+
+### 4.3. Certificate issuance
+
+#### 4.3.1. CA actions during certificate issuance
+
+**Key Sizes.** Members may request keys of any size permitted by the key
+algorithm. Many older hardware devices require small keys.
+
+**Algorithms.** CAcert currently only supports the RSA algorithm for
+X.509 keys. X.509 signing uses the SHA-1 message digest algorithm.
+OpenPGP Signing uses RSA signing over RSA and DSA keys.
+
+**Process for Certificates:** All details in each certificate are
+verified by the website issuance system. Issuance is based on a
+'template' system that selects profiles for certificate lifetime, size,
+algorithm.
+
+1. The CSR is verified.
+2. Data is extracted from CSR and verified:
+ - Name §3.1,
+ - Email address [§4.2.2](#p4.2.2),
+ - Domain address [§4.2.2](#p4.2.2).
+3. Certificate is generated from template.
+4. Data is copied from CSR.
+5. Certificate is signed.
+6. Certificate is stored as well as mailed.
+
+**Process for OpenPGP key signatures:** All details in each Sub-ID are
+verified by the website issuance system. Issuance is based on the
+configuration that selects the profile for signature lifetime, size,
+algorithm following the process:
+
+1. The public key is verified.
+2. Data is extracted from the key and verified (Name, Emails). Only the
+ combinations of data in Table 4.3.1 are permitted.
+3. OpenPGP Key Signature is generated.
+4. Key Signature is applied to the key.
+5. The signed key is stored as well as mailed.
+
+
+
+
+
+
+
+
+
+
+
+ |
+Verified Name |
+Unverified Name
+ |
+Empty Name
+ |
+
+
+Verified email
+ |
+✔ |
+✘ |
+✔ |
+
+
+| Unverified email |
+✘ |
+✘ |
+✘ |
+
+
+Empty email
+ |
+✔ |
+✘ |
+✘ |
+
+
+
+
+
+Table 4.3.1. Permitted Data in Signed OpenPgp
+Keys
+
+#### 4.3.2. Notification to subscriber by the CA of issuance of certificate
+
+Once signed, the certificate is made available via the Member's account,
+and emailed to the Member. It is also archived internally.
+
+### 4.4. Certificate acceptance
+
+#### 4.4.1. Conduct constituting certificate acceptance
+
+There is no need for the Member to explicitly accept the certificate. In
+case the Member does not accept the certificate, the certificate has to
+be revoked and made again.
+
+#### 4.4.2. Publication of the certificate by the CA
+
+CAcert does not currently publish the issued certificates in any
+repository. In the event that CAcert will run a repository, the
+publication of certificates and signatures there will be at the Member's
+options. However note that certificates that are issued and delivered to
+the Member are presumed to be published. See §2.2.
+
+#### 4.4.3. Notification of certificate issuance by the CA to other entities
+
+There are no external entities that are notified about issued
+certificates.
+
+### 4.5. Key pair and certificate usage
+
+All Members (subscribers and relying parties) are obliged according to
+the CAcert Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html))
+See especially 2.3 through 2.5.
+
+#### 4.5.1. Subscriber Usage and Responsibilities
+
+Subscribers should use keys only for their proper purpose, as indicated
+by the certificate, or by wider agreement with others.
+
+#### 4.5.2. Relying Party Usage and Responsibilities
+
+Relying parties (Members) may rely on the following.
+
+
+
+
+
+
+
+Relying Party Statement
+Certificates are issued to Members only.
+
+All information in a certificate is verified. |
+
+
+
+
+The following notes are in addition to the Relying Party Statement, and
+can be seen as limitations on it.
+
+##### 4.5.2.a Methods of Verification
+
+The term Verification as used in the Relying Party Statement means one
+of
+
+
+
+
+
+
+
+| Assurance |
+under CAcert Assurance Programme (CAP) |
+Assurance Policy |
+only information assured to 50 points under CAP is placed in the
+certificate |
+
+
+| Evaluation |
+under automated domain and email checks |
+this CPS |
+see §4.2.2 |
+
+
+| Controlled |
+programs or "profiles" that check the information within the
+CSR |
+this CPS |
+see §7.1 |
+
+
+
+
+##### 4.5.2.b Who may rely
+
+**Members may rely.** Relying parties are Members, and as such are bound
+by this CPS and the CAcert Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
+The licence and permission to rely is not assignable.
+
+**Suppliers of Software.** CAcert roots may be distributed in software,
+and those providers may enter into agreement with CAcert by means of the
+Third Party Vendor - Disclaimer and Licence (wip). This licence brings
+the supplier in to the Community to the extent that
+...WIP comment: they agree to dispute resolution within CAcert's
+forum.
+
+- Just exactly what the 3PV-DaL says is unclear.
+- The document itself is more a collection of ideas.
+
+**NRPs may not rely.** If not related to CAcert by means of an agreement
+that binds the parties to dispute resolution within CAcert's forum, a
+person is a Non-Related-Person (NRP). An NRP is not permitted to rely
+and is not a Relying Party. For more details, see the Root Distribution
+License
+([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
+
+##### 4.5.2.c The Act of Reliance
+
+**Decision making.** Reliance means taking a decision that is in part or
+in whole based on the information in the certificate. A Relying Party
+may incorporate the information in the certificate, and the implied
+information such as Membership, into her decision-making. In making a
+decision, a Relying Party should also:
+
+- include her own overall risk equation,
+- include the general limitations of the Assurance process,
+ certificates, and wider security considerations,
+- make additional checks to provide more information,
+- consider any wider agreement with the other Member, and
+- use an appropriate protocol or custom of reliance (below).
+
+**Examining the Certificate.** A Relying Party must make her own
+decision in using each certificate. She must examine the certificate, a
+process called *validation*. Certificate-related information includes,
+but is not limited to:
+
+- Name,
+- expiry time of certificate,
+- current certificate revocation list (CRL),
+- certificate chain and the validity check of the certificates in the
+ chain,
+- issuer of certificate (CAcert),
+- SubRoot is intended for reliance (Assured, Organisation and Class 3)
+- purpose of certificate.
+
+**Keeping Records.** Records should be kept, appropriate to the import
+of the decision. The certificate should be preserved. This should
+include sufficient evidence to establish who the parties are
+(especially, the certificate relied upon), to establish the transaction
+in question, and to establish the wider agreement that defines the act.
+
+**Wider Protocol.** In principle, reliance will be part of a wider
+protocol (customary method in reaching and preserving agreement) that
+presents and preserves sufficient of the evidence for dispute resolution
+under CAcert's forum of Arbitration. The protocol should be agreed
+amongst the parties, and tuned to the needs. This CPS does not define
+any such protocol. In the absence of such a protocol, reliance will be
+weakened; a dispute without sufficient evidence may be dismissed by an
+Arbitrator.
+
+**As Compared to Usage**. Reliance goes beyond Usage. The latter is
+limited to letting the software act as the total and only Validation
+Authority. When relying, the Member also augments the algorithmic
+processing of the software with her own checks of the business,
+technical and certificate aspect.
+
+##### 4.5.2.d Risks and Limitations of Reliance
+
+**Roots and Naming.** Where the Class 1 root is used, this Subscriber
+may be a new Member including one with zero points. Where the Name is
+not provided, this indicates it is not available. In these
+circumstances, reliance is not defined, and Relying parties should take
+more care. See Table 4.5.2.
+
+
+
+
+
+
+
+
+
+
+
+ |
+Statements of Reliance for Members |
+
+
+| Class of Root |
+Anonymous
+(all Members) |
+Named
+(Assured Members only) |
+ |
+ |
+
+
+Class
+1 |
+Do not rely.
+Relying party must use other methods to check. |
+Do not rely. Although the named
+Member has been Assured by CAcert, reliance is not defined with Class 1
+root.
+(issued for compatibility only). |
+ |
+ |
+
+
+Member
+SubRoot |
+ |
+ |
+
+
+Class
+3 |
+Do not rely on the Name (being
+available). The Member has been Assured by CAcert, but reliance is
+undefined. |
+The Member named in the certificate has been Assured by
+CAcert. |
+ |
+ |
+
+
+Assured
+SubRoot |
+ |
+ |
+
+
+
+
+Table 4.5.2. Statements of Reliance
+
+**Software Agent.** When relying on a certificate, relying parties
+should note that your software is responsible for the way it shows you
+the information in a certificate. If your software agent hides parts of
+the information, your sole remedy may be to choose another software
+agent.
+
+**Malware.** When relying on a certificate, relying parties should note
+that platforms that are vulnerable to viruses or trojans or other
+weaknesses may not process any certificates properly and may give
+deceptive or fraudulent results. It is your responsibility to ensure you
+are using a platform that is secured according to the needs of the
+application.
+
+##### 4.5.2.e When something goes wrong
+
+In the event that an issue arises out of the Member's reliance, her sole
+avenue is **to file dispute under DRP**. See [§9.13](#p9.13). For this
+purpose, the certificate (and other evidence) should be preserved.
+
+**Which person?** Members may install certificates for other individuals
+or in servers, but the Member to whom the certificate is issued remains
+the responsible person. E.g., under Organisation Assurance, an
+organisation is issued a certificate for the use by individuals or
+servers within that organisation, but the Organisation is the
+responsible person.
+
+**Software Agent.** If a Member is relying on a CAcert root embedded in
+the software as supplied by a vendor, the risks, liabilities and
+obligations of the Member do not automatically transfer to the vendor.
+
+### 4.6. Certificate renewal
+
+A certificate can be renewed at any time. The procedure of certificate
+renewal is the same as for the initial certificate issuance.
+
+### 4.7. Certificate re-key
+
+Certificate "re-keyings" are not offered nor supported. A new
+certificate with a new key has to be requested and issued instead, and
+the old one revoked.
+
+### 4.8. Certificate modification
+
+Certificate "modifications" are not offered nor supported. A new
+certificate has to be requested and issued instead.
+
+### 4.9. Certificate revocation and suspension
+
+#### 4.9.1. Circumstances for revocation
+
+Certificates may be revoked under the following circumstances:
+
+1. As initiated by the Subscriber through her online account.
+2. As initiated in an emergency action by a support team member. Such
+ action will immediately be referred to dispute resolution for
+ ratification.
+3. Under direction from the Arbitrator in a duly ordered ruling from a
+ filed dispute.
+
+These are the only three circumstances under which a revocation occurs.
+
+#### 4.9.2. Who can request revocation
+
+As above.
+
+#### 4.9.3. Procedure for revocation request
+
+The Subscriber logs in to her online account through the website at
+http://www.cacert.org/ .
+
+In any other event such as lost passwords or fraud, a dispute should be
+filed by email at \< support AT cacert DOT org \>
+
+#### 4.9.4. Revocation request grace period
+
+No stipulation.
+
+#### 4.9.5. Time within which CA must process the revocation request
+
+The revocation automated in the Web Interface for subscribers, and is
+handled generally in less than a minute.
+
+A filed dispute that requests a revocation should be handled within a
+five business days, however the Arbitrator has discretion.
+
+#### 4.9.6. Revocation checking requirement for relying parties
+
+Each revoked certificate is recorded in the certificate revocation list
+(CRL). Relying Parties must check a certificate against the most recent
+CRL issued, in order to validate the certificate for the intended
+reliance.
+
+#### 4.9.7. CRL issuance frequency (if applicable)
+
+A new CRL is issued after every certificate revocation.
+
+#### 4.9.8. Maximum latency for CRLs (if applicable)
+
+The maximum latency between revocation and issuance of the CRL is 1
+hour.
+
+#### 4.9.9. On-line revocation/status checking availability
+
+OCSP is available at http://ocsp.cacert.org/ .
+
+#### 4.9.10. On-line revocation checking requirements
+
+Relying parties must check up-to-date status before relying.
+
+#### 4.9.11. Other forms of revocation advertisements available
+
+None.
+
+#### 4.9.12. Special requirements re key compromise
+
+Subscribers are obliged to revoke certificates at the earliest
+opportunity.
+
+#### 4.9.13. Circumstances for suspension
+
+Suspension of certificates is not available.
+
+#### 4.9.14. Who can request suspension
+
+Not applicable.
+
+#### 4.9.15. Procedure for suspension request
+
+Not applicable.
+
+#### 4.9.16. Limits on suspension period
+
+Not applicable.
+
+### 4.10. Certificate status services
+
+#### 4.10.1. Operational characteristics
+
+OCSP is available at http://ocsp.cacert.org/ .
+
+#### 4.10.2. Service availability
+
+OCSP is made available on an experimental basis.
+
+#### 4.10.3. Optional features
+
+No stipulation.
+
+### 4.11. End of subscription
+
+Certificates include expiry dates.
+
+### 4.12. Key escrow and recovery
+
+#### 4.12.1. Key escrow and recovery policy and practices
+
+CAcert does not generate nor escrow subscriber keys.
+
+#### 4.12.2. Session key encapsulation and recovery policy and practices
+
+No stipulation.
+
+## 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
+
+### 5.1. Physical controls
+
+Refer to Security Policy
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
+
+- Site location and construction - SP2.1
+- Physical access - SP2.3
+
+#### 5.1.3. Power and air conditioning
+
+Refer to Security Policy 2.1.2
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
+
+#### 5.1.4. Water exposures
+
+Refer to Security Policy 2.1.4
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
+
+#### 5.1.5. Fire prevention and protection
+
+Refer to Security Policy 2.1.4
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
+
+#### 5.1.6. Media storage
+
+Refer to Security Policy 4.3
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
+
+#### 5.1.7. Waste disposal
+
+No stipulation.
+
+#### 5.1.8. Off-site backup
+
+Refer to Security Policy 4.3
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
+
+### 5.2. Procedural controls
+
+#### 5.2.1. Trusted roles
+
+- **Technical teams:**
+ - User support personnel
+ - Systems Administrators -- critical and non-critical
+ - Softare Developers
+ - controllers of keys
+
+ Refer to Security Policy 9.1
+ ([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
+- **Assurance:**
+ - Assurers
+ - Any others authorised under COD13
+
+ Refer to Assurance Policy
+ ([COD13](https://www.cacert.org/policy/AssurancePolicy.html))
+- **Governance:**
+ - Directors (members of the CAcert Inc. committee, or "Board")
+ - Internal Auditor
+ - Arbitrator
+
+#### 5.2.2. Number of persons required per task
+
+CAcert operates to the principles of *four eyes* and *dual control*. All
+important roles require a minimum of two persons. The people may be
+tasked to operate with an additional person observing (*four eyes*), or
+with two persons controlling (*dual control*).
+
+#### 5.2.3. Identification and authentication for each role
+
+All important roles are generally required to be assured at least to the
+level of Assurer, as per AP. Refer to Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
+
+**Technical.** Refer to Security Policy 9.1
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
+
+#### 5.2.4. Roles requiring separation of duties
+
+Roles strive in general for separation of duties, either along the lines
+of *four eyes principle* or *dual control*.
+
+### 5.3. Personnel controls
+
+#### 5.3.1. Qualifications, experience, and clearance requirements
+
+
+
+
+| Role |
+Policy |
+Comments |
+
+
+| Assurer |
+COD13 |
+Passes Challenge, Assured to 100 points. |
+
+
+| Organisation Assurer |
+COD11 |
+Trained and tested by two supervising OAs. |
+
+
+| Technical |
+SM => COD08 |
+Teams responsible for testing. |
+
+
+| Arbitrator |
+COD7 |
+Experienced Assurers. |
+
+
+
+
+Table 5.3.1. Controls on Roles
+
+#### 5.3.2. Background check procedures
+
+Refer to Security Policy 9.1.3
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
+
+#### 5.3.3. Training requirements
+
+No stipulation.
+
+#### 5.3.4. Retraining frequency and requirements
+
+No stipulation.
+
+#### 5.3.5. Job rotation frequency and sequence
+
+No stipulation.
+
+#### 5.3.6. Sanctions for unauthorized actions
+
+Any actions that are questionable - whether uncertain or grossly
+negligent - may be filed as a dispute. The Arbitrator has wide
+discretion in ruling on loss of points, retraining, or termination of
+access or status. Refer to DRP.
+
+#### 5.3.7. Independent contractor requirements
+
+No stipulation.
+
+#### 5.3.8. Documentation supplied to personnel
+
+No stipulation.
+
+### 5.4. Audit logging procedures
+
+Refer to Security Policy 4.2, 5
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
+
+### 5.5. Records archival
+
+The standard retention period is 7 years. Once archived, records can
+only be obtained and verified by means of a filed dispute. Following
+types of records are archived:
+
+
+
+
+
+
+
+
+
+
+| Record |
+Nature |
+Exceptions |
+Documentation |
+
+
+| Member |
+username, primary and added addresses, security questions, Date of
+Birth |
+resigned non-subscribers: 0 years. |
+Security Policy and Privacy Policy |
+
+
+| Assurance |
+CAP forms |
+"at least 7 years."
+as per subsidiary policies |
+Assurance Policy 4.5 |
+
+
+| Organisation Assurance |
+COAP forms |
+as per subsidiary policies |
+Organisation Assurance Policy |
+
+
+| certificates and revocations |
+for reliance |
+7 years after termination |
+this CPS |
+
+
+| critical roles |
+background check worksheets |
+under direct Arbitrator control |
+Security Policy 9.1.3 |
+
+
+
+
+Table 5.5. Documents and Retention
+
+### 5.6. Key changeover
+
+Refer to Security Policy 9.2
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
+
+### 5.7. Compromise and disaster recovery
+
+Refer to Security Policy 5, 6
+([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
+(Refer to [§1.4](#p1.4) for limitations to service.)
+
+### 5.8. CA or RA termination
+
+#### 5.8.1 CA termination
+
+If CAcert should terminate its operation or be taken over by another
+organisation, the actions will be conducted according to a plan approved
+by the CAcert Inc. Board.
+
+In the event of operational termination, the Roots (including SubRoots)
+and all private Member information will be secured. The Roots will be
+handed over to a responsible party for the sole purpose of issuing
+revocations. Member information will be securely destroyed.
+
+ The CA cannot be transferrred to another
+organisation.
+
+In the event of takeover, the Board will decide if it is in the
+interest of the Members to be converted to the new organisation. Members
+will be notified about the conversion and transfer of the Member
+information. Such takeover, conversion or transfer may involve
+termination of this CPS and other documents. See §9.10.2. Members will
+have reasonable time in which to file a related dispute after
+notification (at least one month). See §9.13.
+
+- The ability to transfer is not given in any of CCA, PP or AP!
+- The Board does not have the power to terminate a policy, that is the
+ role of policy group!
+- The right to transfer was against the principles of the CAcert?
+- Check Association Statutes....
+
+ New root keys and certificates will be made
+available by the new organisation as soon as reasonably
+practical.
+
+#### 5.8.2 RA termination
+
+When an Assurer desires to voluntarily terminates her responsibilities,
+she does this by filing a dispute, and following the instructions of the
+Arbitrator.
+
+In the case of involuntary termination, the process is the same, save
+for some other party filing the dispute.
+
+## 6. TECHNICAL SECURITY CONTROLS
+
+### 6.1. Key Pair Generation and Installation
+
+#### 6.1.1. Key Pair Generation
+
+Subscribers generate their own Key Pairs.
+
+#### 6.1.2. Subscriber Private key security
+
+There is no technical stipulation on how Subscribers generate and keep
+safe their private keys, however, CCA 2.5 provides for general security
+obligations. See [§9.6](#p9.6).
+
+#### 6.1.3. Public Key Delivery to Certificate Issuer
+
+Members login to their online account. Public Keys are delivered by
+cut-and-pasting them into the appropriate window. Public Keys are
+delivered in signed-CSR form for X.509 and in self-signed form for
+OpenPGP.
+
+#### 6.1.4. CA Public Key delivery to Relying Parties
+
+The CA root certificates are distributed by these means:
+
+- Published on the website of CAcert, in both HTTP and HTTPS.
+- Included in Third-Party Software such as Browsers, Email-Clients.
+ Such suppliers are subject to the Third Party Vendor Agreement.
+
+Third Party Vendor Agreement is early wip, only
+
+#### 6.1.5. Key sizes
+
+No limitation is placed on Subscriber key sizes.
+
+CAcert X.509 root and intermediate keys are currently 4096 bits. X.509
+roots use RSA and sign with the SHA-1 message digest algorithm. See
+[§4.3.1](#p4.3.1).
+
+OpenPGP Signing uses both RSA and DSA (1024 bits).
+
+CAcert adds larger keys and hashes in line with general cryptographic
+trends, and as supported by major software suppliers.
+
+- old Class 3 SubRoot is signed with MD5
+- likely this will clash with future plans of vendors to drop
+ acceptance of MD5
+- Is this a concern?
+- to users who have these certs, a lot?
+- to audit, not much?
+
+#### 6.1.6. Public key parameters generation and quality checking
+
+No stipulation.
+
+#### 6.1.7. Key Usage Purposes
+
+- This section probably needs to detail the key usage bits in the
+ certs.
+
+CAcert roots are general purpose. Each root key may sign all of the
+general purposes - client, server, code.
+
+The website controls the usage purposes that may be signed. This is
+effected by means of the 'template' system.
+
+### 6.2. Private Key Protection and Cryptographic Module Engineering Controls
+
+#### 6.2.1. Cryptographic module standards and controls
+
+SubRoot keys are stored on a single machine which acts as a
+Cryptographic Module, or *signing server*. It operates a single daemon
+for signing only. The signing server has these security features:
+
+- It is connected only by one dedicated (serial USB) link to the
+ online account server. It is not connected to the network, nor to
+ any internal LAN (ethernet), nor to a console switch.
+- The protocol over the dedicated link is a custom, simple request
+ protocol that only handles certificate signing requests.
+- The daemon is designed not to reveal the key.
+- The daemon incorporates a dead-man switch that monitors the one
+ webserver machine that requests access.
+- The daemon shuts down if a bad request is detected.
+- The daemon resides on an encrypted partition.
+- The signing server can only be (re)started with direct systems
+ administration access.
+- Physical Access to the signing server is under dual control.
+
+See §5. and the Security Policy 9.3.1.
+
+(Hardware-based, commercial and standards-based cryptographic modules
+have been tried and tested, and similar have been tested, but have been
+found wanting, e.g., for short key lengths and power restrictions.)
+
+1. What document is responsible for architecture? CPS? SM?
+ [website](https://wiki.cacert.org/HELP/7)? SM punts it to CPS, so
+ above stays.
+2. There is no criteria on Architecture.
+3. Old questions moved to SM.
+4. See [CAcert Root key protection](https://wiki.cacert.org/HELP/7)
+ which should be deprecated by this CPS.
+
+### 6.3. Other aspects of key pair management
+
+#### 6.3.1. Public key archival
+
+Subscriber certificates, including public keys, are stored in the
+database backing the online system. They are not made available in a
+public- or subscriber-accessible archive, see §2. They are backed-up by
+CAcert's normal backup procedure, but their availability is a subscriber
+responsibility.
+
+#### 6.3.2. Certificate operational periods and key pair usage periods
+
+The operational period of a certificate and its key pair depends on the
+Assurance status of the Member, see [§1.4.5](#p1.4.5) and Assurance
+Policy ([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
+
+The CAcert (top-level) Root certificate has a 30 year expiry. SubRoots
+have 10 years, and are to be rolled over more quickly. The keysize of
+the root certificates are chosen in order to ensure an optimum security
+to CAcert Members based on current recommendations from the
+[cryptographic community](http://www.keylength.com/) and maximum limits
+in generally available software. At time of writing this is 4096 bits.
+
+### 6.4. Activation data
+
+No stipulation.
+
+### 6.5. Computer security controls
+
+Refer to Security Policy.
+
+### 6.6. Life cycle technical controls
+
+Refer to SM7 "Software Development".
+
+### 6.7. Network security controls
+
+Refer to SM3.1 "Logical Security - Network".
+
+### 6.8. Time-stamping
+
+Each server synchronises with NTP. No "timestamping" service is
+currently offered.
+
+- How does the signing server syncronise if only connected over
+ serial?
+- How is timestamping done on records?
+
+## 7. CERTIFICATE, CRL, AND OCSP PROFILES
+
+CAcert defines all the meanings, semantics and profiles applicable to
+issuance of certificates and signatures in its policies, handbooks and
+other documents. Meanings that may be written in external standards or
+documents or found in wider conventions are not incorporated, are not
+used by CAcert, and must not be implied by the Member or the Non-related
+Person.
+
+### 7.1. Certificate profile
+
+#### 7.1.1. Version number(s)
+
+What versions of PGP are signed? v3? v4?
+
+Issued X.509 certificates are of v3 form. The form of the PGP signatures
+depends on several factors, therefore no stipulation.
+
+#### 7.1.2. Certificate extensions
+
+Client certificates include the following extensions:
+
+- basicConstraints=CA:FALSE (critical)
+- keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
+- extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC
+- authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org
+- crlDistributionPoints=URI:\ where \ is replaced
+ with the URI where the certificate revocation list relating to the
+ certificate is found
+- subjectAltName=(as per [§3.1.1.](#p3.1.1)).
+
+
+
+- what about Client Certificates Adobe Signing extensions ?
+- SubjectAltName should become critical if DN is removed
+ http://tools.ietf.org/html/rfc5280#section-4.2.1.6
+
+Server certificates include the following extensions:
+
+- basicConstraints=CA:FALSE (critical)
+- keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
+- extendedKeyUsage=clientAuth,serverAuth,nsSGC,msSGC
+- authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org
+- crlDistributionPoints=URI:\ where \ is replaced
+ with the URI where the certificate revocation list relating to the
+ certificate is found
+- subjectAltName=(as per [§3.1.1.](#p3.1.1)).
+
+Code-Signing certificates include the following extensions:
+
+- basicConstraints=CA:FALSE (critical)
+- keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
+- extendedKeyUsage=emailProtection,clientAuth,codeSigning,msCodeInd,msCodeCom,msEFS,msSGC,nsSGC
+- authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org
+- crlDistributionPoints=URI:\ where \ is replaced
+ with the URI where the certificate revocation list relating to the
+ certificate is found
+- subjectAltName=(as per [§3.1.1.](#p3.1.1)).
+
+
+
+- what about subjectAltName for Code-signing
+
+OpenPGP key signatures currently do not include extensions. In the
+future, a serial number might be included as an extension.
+
+#### 7.1.3. Algorithm object identifiers
+
+No stipulation.
+
+#### 7.1.4. Name forms
+
+Refer to [§3.1.1](#p3.1.1).
+
+#### 7.1.5. Name constraints
+
+Refer to [§3.1.1](#p3.1.1).
+
+#### 7.1.6. Certificate policy object identifier
+
+The following OIDs are defined and should be incorporated into
+certificates:
+
+
+
+
+| OID |
+Type/Meaning |
+Comment |
+
+
+| 1.3.6.1.4.1.18506.4.4 |
+Certification Practice Statement |
+(this present document) |
+
+
+
+
+Versions are defined by additional numbers appended such as .1.
+
+#### 7.1.7. Usage of Policy Constraints extension
+
+No stipulation.
+
+#### 7.1.8. Policy qualifiers syntax and semantics
+
+No stipulation.
+
+#### 7.1.9. Processing semantics for the critical Certificate Policies extension
+
+No stipulation.
+
+### 7.2. CRL profile
+
+#### 7.2.1. Version number(s)
+
+CRLs are created in X.509 v2 format.
+
+#### 7.2.2. CRL and CRL entry extensions
+
+No extensions.
+
+### 7.3. OCSP profile
+
+#### 7.3.1. Version number(s)
+
+The OCSP responder operates in Version 1.
+
+#### 7.3.2. OCSP extensions
+
+No stipulation.
+
+## 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
+
+There are two major threads of assessment:
+
+- **Systems Audit**. Analyses the CA for business and operations
+ security. This is conducted in two phases: documents for compliance
+ with criteria, and operations for compliance with documentation.
+- **Code Audit**. Analyses the source code. This is conducted at two
+ levels: Security concepts at the web applications level, and source
+ code security and bugs review.
+
+See the Audit page at
+[wiki.cacert.org/Audit/](https://wiki.cacert.org/Audit/) for more
+information.
+
+### 8.1. Frequency or circumstances of assessment
+
+The first audits started in late 2005, and since then, assessments have
+been an ongoing task. Even when completed, they are expected to be
+permanent features.
+
+- **Systems Audit**. The first phase of the first
+ audit is nearing completion. The second phase starts in earnest when
+ documentation is in effect, at lease as DRAFT under PoP. As the
+ second phase is dependent on this CPS and the Security Policy, they
+ will be in effect as DRAFT at least before the first audit is
+ completed. Only prior and completed audits can be reported here.
+
+- **Code Audit**. A complete review of entire source
+ code has not yet been completed.
+
+### 8.2. Identity/qualifications of assessor
+
+**Systems Auditors.** CAcert uses business systems auditors with broad
+experience across the full range of business, information systems and
+security fields. In selecting a business systems auditor, CAcert looks
+for experience that includes but is not limited to cryptography, PKI,
+governance, auditing, compliance and regulatory environments, business
+strategy, software engineering, networks, law (including
+multijurisdictional issues), identity systems, fraud, IT management.
+
+**Code Auditors.** See Security Policy, sections 7, 9.1.
+
+### 8.3. Assessor's relationship to assessed entity
+
+Specific internal restrictions on audit personnel:
+
+- Must be Assured by CAcert Assurers and must be background checked.
+- Must not have been active in any (other) role in CAcert.
+ Specifically, must not be an Assurer, a member of the association,
+ or in any other defined role or office.
+- Although the Auditor may be expected to undertake various of the
+ activities (Assurance, Training) during the process of the audit,
+ any results are frozen until resignation as auditor is effected.
+- The Auditor is required to declare to CAcert all potential conflicts
+ of interest on an ongoing basis.
+
+Specific external restrictions on audit personnel:
+
+- Should have a verifiable and lengthy history in user privacy and
+ user security.
+- Must not have worked for a competitive organisation.
+- Must not have worked for national security, intelligence, LEO or
+ similar agencies.
+
+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.4. Topics covered by assessment
+
+Systems Audits are generally conducted to criteria. CAcert requires that
+the criteria are open:
+
+- Published. The criteria must be reviewable by all interested
+ parties.
+- Understandable. They should be understandable, in that they provide
+ the sufficient information in a readable form for interested parties
+ to follow the gist and importance. (Arcane security criteria may
+ stretch this requirement.)
+- Complete. There must be sufficent background information that the
+ whole story is there. Especially, criteria that refer to
+ undocumented practices or conventions deliberately kept secret must
+ be avoided.
+- Applicable. The criteria should relate directly and unambiguously to
+ a need of the identified interested parties (Members, Relying
+ Parties, Subscribers, Assurers).
+
+See [DRC](http://rossde.com/CA_review/) for the current criteria. If
+Auditor determines that a criteria fails to follow the meet the above
+requirements, then the criteria should be reworked to conform, or should
+be dropped (both with explanatory notes).
+
+### 8.5. Actions taken as a result of deficiency
+
+See the current [Audit Done list](https://wiki.cacert.org/Audit/Done)
+for work completed, and [Audit Todo
+list](https://wiki.cacert.org/AuditToDo) for work in progress.
+
+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.
+
+The
+[wiki.cacert.org/AuditDirectives](https://wiki.cacert.org/AuditDirectives)
+documents issued directives and actions.
+
+### 8.6. Communication of results
+
+Current and past Audit information is available at
+[wiki.CAcert.org/Audit/](https://wiki.cacert.org/Audit/). CAcert runs an
+open disclosure policy and Audit is no exception.
+
+This CPS and other documents are subject to the process in Policy on
+Policy ([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html)).
+Audits cover the overall processes more than any one document, and
+documents may vary even as Audit reports are delivered.
+
+## 9. OTHER BUSINESS AND LEGAL MATTERS
+
+### 9.1. Fees
+
+The current fees structure is posted at
+[wiki.cacert.org/Price](https://wiki.cacert.org/Price). Changes to the
+fees structure will be announced from time to time on the
+[blog](https://blog.cacert.org/). CAcert retains the right to charge
+fees for services. All fees are non-refundable.
+
+### 9.2. Financial responsibility
+
+Financial risks are dealt with primarily by the Dispute Resolution
+Policy
+([COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html)).
+
+#### 9.2.1. Insurance coverage
+
+No stipulation.
+
+#### 9.2.2. Other assets
+
+No stipulation.
+
+#### 9.2.3. Insurance or warranty coverage for end-entities
+
+No stipulation.
+
+### 9.3. Confidentiality of business information
+
+#### 9.3.1. Scope of confidential information
+
+CAcert has a policy of transparency and openness. The default posture is
+that information is public to the extent possible, unless covered by
+specific policy provisions (for example, passwords) or rulings by
+Arbitrator.
+
+### 9.4. Privacy of personal information
+
+Privacy is covered by the CCA (COD9) and the Privacy Policy
+([COD5](https://www.cacert.org/policy/PrivacyPolicy.html)).
+
+#### 9.4.1. Privacy plan
+
+No stipulation.
+
+#### 9.4.2. Information treated as private
+
+Member's Date of Birth and "Lost Password" questions are treated as
+fully private.
+
+#### 9.4.3. Information not deemed private
+
+To the extent that information is put into an issued certificate, that
+information is not deemed private, as it is expected to be published by
+the Member as part of routine use of the certificate. Such information
+generally includes Names, domains, email addresses, and certificate
+serial numbers.
+
+Under Assurance Policy
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)) the
+Member's status (as Assured, Assurer, etc) is available to other
+Members.
+
+Information placed in forums outside the online system (wiki, blogs,
+policies, etc) is not deemed private, and is generally deemed to be
+published as contributions by Members. See CCA1.3 (COD9).
+
+#### 9.4.4. Responsibility to protect private information
+
+CAcert is a privacy organisation and takes privacy more seriously. Any
+privacy issue may be referred to dispute resolution.
+
+#### 9.4.5. Notice and consent to use private information
+
+Members are permitted to rely on certificates of other Members. As a
+direct consequence of the general right to rely, Members may read and
+store the certificates and/or the information within them, where duly
+presented in a relationship, and to the extent necessary for the agreed
+relationship.
+
+#### 9.4.6. Disclosure pursuant to judicial or administrative process
+
+Any disclosure pursuant to process from foreign courts (or similar) is
+controlled by the Arbitrator.
+
+#### 9.4.7. Other information disclosure circumstances
+
+None.
+
+### 9.5. Intellectual property rights
+
+CAcert is committed to the philosophy of an open and free Internet,
+broadly as encapsulated by open and free source. However, due to the
+strict control provisions imposed by the audit criteria (CCS), and the
+general environment and role of CAs, and the commitment to security of
+Members, some deviations are necessary.
+
+#### 9.5.1. Ownership and Licence
+
+Assets that fall under the control of CCS must be transferred to CAcert.
+See PoP 6.2
+([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html#6.2)), CCA 1.3
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#1.3)).
+That is, CAcert is free to use, modify, distribute, and otherwise
+conduct the business of the CA as CAcert sees fit with the asset.
+
+#### 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](https://wiki.cacert.org/TopMinutes-20070917).
+
+#### 9.5.3. Documents
+
+CAcert owns or requires full control over its documents, especially
+those covered by CCS. See PoP 6.2
+([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html#6.2)).
+Contributors transfer the rights, see CCA 1.3
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#1.3)).
+Contributors warrant that they have the right to transfer.
+
+Documents are generally licensed under free and open licence. See
+[wiki.cacert.org/PolicyDrafts/DocumentLicence](https://wiki.cacert.org/PolicyDrafts/DocumentLicence).
+Except where explicitly negotiated, CAcert extends back to contributors
+a non-exclusive, unrestricted perpetual licence, permitting them to to
+re-use their original work freely. See PoP 6.4
+([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html#6.4)), CCA 1.3
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#1.3)).
+
+#### 9.5.4. Code
+
+CAcert owns its code or requires full control over code in use by means
+of a free and open licence. See CCS.
+
+See the (new, wip)
+[SourceCodeManifesto](https://svn.cacert.org/CAcert/Software/BirdShack/Documents/SourceCodeManifesto.html).
+Maybe this can replace these two paras?
+
+CAcert licenses its code under GPL. CAcert extends back to contributors
+a non-exclusive, unrestricted perpetual licence, permitting them to to
+re-use their original work freely.
+
+#### 9.5.5. Certificates and Roots
+
+CAcert asserts its intellectual property rights over certificates issued
+to Members and over roots. See CCA 4.4
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#4.4)),
+CCS. The certificates may only be used by Members under
+[COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#4.4),
+and, by others under the licences offered, such as Root Distribution
+License
+([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
+
+### 9.6. Representations and warranties
+
+**Members.** All Members of the Community agree to the CAcert Community
+Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)),
+which is the primary document for representations and warranties.
+Members include Subscribers, Relying Parties, Registration Agents and
+the CA itself.
+
+**RAs.** Registration Agents are obliged additionally by Assurance
+Policy, especially 3.1, 4.1
+([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
+
+**CA.** The CA is obliged additionally by the CCS.
+
+**Third Party Vendors.** Distributors of the roots are offered the wip 3rd-Party Vendors - Disclaimer and Licence (3PV-DaL
+=\> CODx) and are offered wip the same deal as
+Members to the extent that they agree to be Members in the Community.
+wip
+
+### 9.7. Disclaimers of Warranties
+
+Persons who have not accepted the above Agreements are offered the Root
+Distribution License
+([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
+Any representations and warranties are strictly limited to nominal
+usage. In essence, NRPs may USE but must not RELY.
+
+In today's aggressive fraud environment, and within the context of
+CAcert as a community CA, all parties should understand that CAcert and
+its Subscribers, Assurers and other roles provide service on a Best
+Efforts basis. See [§1.4](#p1.4). CAcert seeks to provide an adequate
+minimum level of quality in operations for its Members without undue
+risks to NRPs. See
+[Principles](https://svn.cacert.org/CAcert/principles.html).
+
+CAcert on behalf of the Community and itself makes no Warranty nor
+Guarantee nor promise that the service or certificates are adequate for
+the needs and circumstances.
+
+### 9.8. Limitations of liability
+
+### 9.8.1 Non-Related Persons
+
+CAcert on behalf of related parties (RAs, Subscribers, etc) and itself
+disclaims all liability to NRPs in their usage of CA's certificates. See
+[COD4](https://www.cacert.org/policy/RootDistributionLicense.html).
+
+### 9.8.2 Liabilities Between Members
+
+Liabilities between Members are dealt with by internal dispute
+resolution, which rules on liability and any limits. See [§9.13](#9.13).
+
+### 9.9. Indemnities
+
+No stipulation.
+
+### 9.10. Term and termination
+
+#### 9.10.1. Term
+
+No stipulation.
+
+#### 9.10.2. Termination
+
+Members file a dispute to terminate their agreement. See [§9.13](#p9.13)
+and CCA 3.3
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#3.3)).
+
+Documents are varied (including terminated) under
+[COD1](https://www.cacert.org/policy/PolicyOnPolicy.html).
+
+For termination of the CA, see [§5.8.1](#p5.8.1).
+
+#### 9.10.3. Effect of termination and survival
+
+No stipulation.
+
+### 9.11. Individual notices and communications with participants
+
+All participants are obliged to keep their listed primary email
+addresses in good working order. See CCA 3.5
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#3.5)).
+
+### 9.12. Amendments
+
+Amendments to the CPS are controlled by
+[COD1](https://www.cacert.org/policy/PolicyOnPolicy.html). Any changes
+in Member's Agreements are notified under CCA 3.4
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#3.4)).
+
+### 9.13. Dispute resolution provisions
+
+CAcert provides a forum and facility for any Member or other related
+party to file a dispute.
+
+- The CAcert Dispute Resolution Policy
+ ([COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html))
+ includes rules for dispute resolution.
+- Filing is done via email to \< support AT cacert DOT org \>
+
+Members agree to file all disputes through CAcert's forum for dispute
+resolution. The rules include specific provisions to assist non-Members,
+etc, to file dispute in this forum.
+
+### 9.14. Governing law
+
+The governing law is that of New South Wales, Australia. Disputes are
+generally heard before the Arbitrator under this law. Exceptionally, the
+Arbitrator may elect to apply the law of the parties and events, where
+in common, but this is unlikely because it may create results that are
+at odds with the Community.
+
+### 9.15. Compliance with Applicable Law
+
+### 9.15.1 Digital Signature Law
+
+The Commonwealth and States of Australia have passed various Electronic
+Transactions Acts that speak to digital signatures. In summary, these
+acts follow the "technology neutral" model and permit but do not
+regulate the use of digital signatures.
+
+This especially means that the signatures created by certificates issued
+by CAcert are not in and of themselves legally binding human signatures,
+at least according to the laws of Australia. See [§1.4.3](#p1.4.3).
+However, certificates may play a part in larger signing applications.
+See [§1.4.1](#p1.4.1) for "digital signing" certificates. These
+applications may impose significant obligations, risks and liabilities
+on the parties.
+
+### 9.15.2 Privacy Law
+
+See the Privacy Policy
+([COD5](https://www.cacert.org/policy/PrivacyPolicy.html)).
+
+### 9.15.3 Legal Process from External Forums
+
+CAcert will provide information about its Members only under legal
+subpoena or equivalent process from a court of competent jurisdiction.
+Any requests made by legal subpoena are treated as under the Dispute
+Resolution Policy See [§9.13](#p9.13) and
+[COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html). That
+is, all requests are treated as disputes, as only a duly empanelled
+Arbitrator has the authorisation and authority to rule on the such
+requests.
+
+A subpoena should include sufficient legal basis to support an
+Arbitrator in ruling that information be released pursuant to the
+filing, including the names of claimants in any civil case and an
+indication as to whether the claimants are Members or not (and are
+therefore subject to Dispute Resolution Policy).
+
+### 9.16. Miscellaneous provisions
+
+#### 9.16.1. Entire agreement
+
+All Members of the Community agree to the CAcert Community Agreement
+([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
+This agreement also incorporates other key documents, being this CPS,
+DRP and PP. See CCA 4.2.
+
+The Configuration-Control Specification is the set of policies that rule
+over the Community, of which the above documents are part. See COD2.
+Documents that have reached full POLICY status are located at
+[www.cacert.org/policy/](https://www.cacert.org/policy/). Although
+detailed practices may be found in other places on the website and on
+the wiki, the CCS documents that have reached DRAFT and POLICY status
+are the ruling documents.
+
+2nd half of this section can be transfered over to PoP,
+only a reference to PoP 5.4 to remain (see [Changes to PoP
+p20130223](https://wiki.cacert.org/PolicyDecisions#p20130223))
+
+
+#### 9.16.2. Assignment
+
+The rights within CCA may not be ordinarily assigned.
+
+#### 9.16.3. Severability
+
+No stipulation.
+
+#### 9.16.4. Enforcement (attorneys' fees and waiver of rights)
+
+The Arbitrator will specify fees and remedies, if any.
+
+#### 9.16.5. Force Majeure
+
+No stipulation.
+
+## ---This is the end of the Policy---