Merge remote-tracking branch 'magu/bug-1131' into bug-1131
authorMichael Tänzer <neo@nhng.de>
Fri, 18 Oct 2013 13:23:33 +0000 (15:23 +0200)
committerMichael Tänzer <neo@nhng.de>
Fri, 18 Oct 2013 13:23:33 +0000 (15:23 +0200)
Conflicts:
www/policy/CertificationPracticeStatement.html

Signed-off-by: Michael Tänzer <neo@nhng.de>
1  2 
www/policy/CertificationPracticeStatement.html

 -<!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 4em 0em 4em;\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
 -<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
 -<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>\r
 -The CA cannot be transferrred to another organisation.\r
 -</p>\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;
++    margin: 1em 4em 0em 4em;
 +}
 +.importend div {
 +    margin-top: 3em;
 +    margin-bottom: 3em;
 +}
 +    .importend-header {
 +    border: 1px solid red;
 +    border-width: 1px 2px 2px 1px;
-     margin-top: -1.6em;
++    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.
++The CA cannot be transferrred to another organisation.
 +</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>