bug 1131: Convert line endings in CPS from DOS to UNIX
authorMichael Tänzer <neo@nhng.de>
Tue, 16 Jul 2013 23:58:37 +0000 (01:58 +0200)
committerMichael Tänzer <neo@nhng.de>
Tue, 16 Jul 2013 23:58:37 +0000 (01:58 +0200)
Signed-off-by: Michael Tänzer <neo@nhng.de>
www/policy/CertificationPracticeStatement.html

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