-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <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 {
- font-family : courier, monospace;
-}
-
-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;
-}
-
-a:hover {
- color : gray;
-}
--->
-</style>
-
-
-</head>
-<body>
-
-<h1>CAcert CPS and CP</h1>
-
-<a href="PolicyOnPolicy.html"><img src="cacert-draft.png" alt="CAcert Policy Status" height="31" width="88" style="border-style: none;" /></a><br />
-Creation date: 20060726<br />
-Status: DRAFT p20091108<br />
-<!-- $Id: CertificationPracticeStatement.html,v 1.3 2012-07-27 16:00:29 wytze Exp $ -->
-
-
-<font size="-1">
-
-<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&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&A for Re-key Requests</a> </li>
- <li><a href="#p3.4">3.4. I&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>
-
-</font>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p1" id="p1">1. INTRODUCTION</a></h2>
-
-<h3><a name="p1.1" 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>
-</p>
-
-<h3><a name="p1.2" 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 <i>David E. Ross</i> ("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>)
- <p class="q"> .x will change to .1 in the first approved instance.</p>
- </li>
- <li>
- © 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="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
- PolicyDrafts/DocumentLicence</a>.
- <ul class="q">
- <li> The cited page discusses 2 options: CCau Attribute-Share-alike and GNU Free Document License. Refer to that. </li>
- <li> Note that the noun Licence in Australian English has two Cs. The verb License is spelt the same way as American English. </li>
- </ul>
- </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="q">green text</span>
- refers to questions that seek answers,
- </li><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>
- <span class="q">
- None is to be considered part of the policy,
- and they should disappear in the DRAFT
- and must disappear in the POLICY.
- </span>
- </li>
-<!--
- <li>
- Some content is incorporated under
-<!-- <a href="http://xkcd.com/license.html">Creative Commons license</a> -->
-<!-- from <a href="http://xkcd.com/">xkcd.com</a>. -->
-<!-- 198 177 515
- </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 name="p1.3" 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="http://wiki.cacert.org/wiki/CAcertIncorporated">CAcert wiki</a>.
-</p>
-
-<p>
-CAcert is a Community formed of Members who agree to the
-<a href="http://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 <i>Association Members</i>, which latter are
-not referred to anywhere in this CPS.)
-</p>
-
-<h4><a name="p1.3.1" 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 name="p1.3.2" id="p1.3.2">1.3.2. Registration authorities</a></h4>
-<p>
-Registration Authorities (RAs) are controlled under Assurance Policy
-(<a href="http://www.cacert.org/policy/AssurancePolicy.html">COD13</a>).
-</p>
-
-<h4><a name="p1.3.3" 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 name="p1.3.4" 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="http://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 name="p1.3.5" id="p1.3.5">1.3.5. Other participants</a></h4>
-
-<p>
-<b>Member.</b>
-Membership of the Community is as defined in the
-<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>.
-Only Members may RELY or may become Subscribers.
-Membership is free.
-</p>
-
-<p>
-<b>Arbitrator.</b>
-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="http://www.cacert.org/policy/DisputeResolutionPolicy.html">COD7</a>).
-</p>
-
-<p>
-<b>Vendor.</b>
-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.
-<span class="q">
-At the time of writing, the
-"3rd Party Vendor - Disclaimer and Licence"
-is being worked upon, but is neither approved nor offered.
-</span>
-</p>
-
-<p>
-<b>Non-Related Persons</b> (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
-Non-related Persons - Disclaimer and Licence
-(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.html">COD4</a>).
-No other rights nor relationship is implied or offered.
-</p>
-
-
-<h3><a name="p1.4" 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">§1.4.1</a>.
-Prohibited applications are defined in <a href="#p1.4.2">§1.4.2</a>.
-Specialist uses may be agreed by contract or within
-a specific environment, as described in
-<a href="#p1.4.4">§1.4.4</a>.
-Note also the
-unreliable applications in
-<a href="#p1.4.3">§1.4.3</a>
-and risks, liabilities and obligations in
-<a href="#p9">§9</a>.
-</p>
-
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
- <td colspan="2"><center><i>Type</i></center></td>
- <td colspan="2"><center><i>Appropriate Certificate uses</i></center></td>
- </tr>
- <tr>
- <th>General</th>
- <th>Protocol</th>
- <th><center>Description</center></th>
- <th><center>Comments</center></th>
- </tr>
- <tr>
- <td rowspan="2"><center>Server</center></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"><center>Client</center></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">§1.4.3</a>. </td>
- </tr>
- <tr>
- <td> "Digital Signing" </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">§1.4.4</a>.
- </td>
- </tr>
- <tr>
- <td><center>Code</center></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><center>PGP</center></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><center>Special</center></td>
- <td> X.509 </td>
- <td> OCSP, Timestamping </td>
- <td> Only available to CAcert Systems Administrators, as controlled by Security Policy </td>
- </tr>
-</table>
-
-<span class="figure">Table 1.4. Types of Certificate</span>
-</center>
-
-<h4><a name="p1.4.1" 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">§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 name="p1.4.2" 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 name="p1.4.3" 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>
- <b>Signing within Protocols.</b>
- Digital signatures made by CAcert certificates carry
- <u>NO default legal or human meaning</u>.
- See <a href="#p9.15.1">§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>
- <b>Non-repudiation applications.</b>
- 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>
- <b>Ecommerce applications.</b>
- 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>
-
-<!-- <center><a href="http://xkcd.com/341/"> <img src="http://imgs.xkcd.com/comics/1337_part_1.png"> </a> </center> -->
-
-<h4><a name="p1.4.4" 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>
- <b>Digital signing applications.</b>
- 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 name="p1.4.5" id="p1.4.5">1.4.5. Roots and Names</a></h4>
-
-<p>
-<b>Named Certificates.</b>
-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>
-<b>Anonymous Certificates.</b>
-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>
-<b>Psuedonymous Certificates.</b>
-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>
-<b>Advanced Certificates.</b>
-Members who are as yet unassured are not permitted to create
-advanced forms such as wildcard or subjectAltName
-certificates.
-</p>
-
-
-<p>
-<b> Roots.</b>
-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>
- <b>(Top-level) Root.</b>
- Used to sign on-line CAcert SubRoots only.
- This Root is kept offline.
- </li><li>
- <b>Member SubRoot.</b>
- 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>
- <b>Assured SubRoot.</b>
- 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>
- <b>Organisation SubRoot.</b>
- Only available for Assured Organisation Members.
- Suitable for Reliance under this and other policies.
- Approximates the type known as Organisational Validation.
-
-</li></ul>
-
-
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
- <td></td>
- <td colspan="5"><center><i>Level of Assurance</i></center></td>
- <th> </th>
- </tr>
- <tr>
- <th></th>
- <th colspan="2"><center> Members † </center></th>
- <th colspan="2"><center> Assured Members</center></th>
- <th colspan="1"><center> Assurers </center></th>
- <th colspan="1"><center> </center></th>
- </tr>
- <tr>
- <td><i>Class of Root</i></td>
- <th>Anon</th>
- <td>Name</td>
- <td>Anon</td>
- <th>Name</th>
- <td>Name+Anon</td>
- <td colspan="1"><center><i>Remarks</i></center></td>
- </tr>
- <tr>
- <td><center>Top level<br><big><b>Root</b></big></center></td>
- <td> <center> <font title="pass." color="green" size="+3"> • </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> • </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> • </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> • </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> • </font> </center> </td>
- <td> Signs other CAcert SubRoots only. </td>
- </tr>
- <tr>
- <td><center><big><b>Member</b></big><br>SubRoot</center></td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> † For Members meeting basic checks in <a href="#p4.2.2">§4.2.2</a><br>(Reliance is undefined.) </td>
- </tr>
- <tr>
- <td><center><big><b>Assured</b></big><br>SubRoot</center></td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> Assured Members only.<br>Fully intended for reliance. </td>
- </tr>
- <tr>
- <td><center><big><b>Organisation</b></big><br>SubRoot</center></td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> Assured Organisation Members only.<br>Fully intended for reliance. </td>
- </tr>
- <tr>
- <th>Expiry of Certificates</th>
- <td colspan="2"><center>6 months</center></td>
- <td colspan="3"><center>24 months</center></td>
- </tr>
- <tr>
- <th>Types</th>
- <td colspan="2"><center>client, server</center></td>
- <td colspan="2"><center>wildcard, subjectAltName</center></td>
- <td colspan="1"><center>code-signing</center></td>
- <td> (Inclusive to the left.) </td>
- </tr>
-</table>
-
-<span class="figure">Table 1.4.5.b Certificate under Audit Roots</span>
-</center>
-
-
-<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>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
- <td></td>
- <td colspan="4"><center><i>Level of Assurance</i></center></td>
- <th> </th>
- </tr>
- <tr>
- <th></th>
- <th colspan="2"><center>Members</center></th>
- <th colspan="2"><center>Assured Members</center></th>
- <th colspan="1"><center> </center></th>
- </tr>
- <tr>
- <td><i>Class of Root</i></td>
- <th>Anonymous</th>
- <td>Named</td>
- <td>Anonymous</td>
- <th>Named</th>
- <td colspan="1"><center><i>Remarks</i></center></td>
- </tr>
- <tr>
- <td><center>Class<br><big><b>1</b></big></center></td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> Available for all Members,<br>reliance is undefined.</td>
- </tr>
- <tr>
- <td><center>Class<br><big><b>3</b></big></center></td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> <center> <font title="pass." color="green" size="+3"> ✔ </font> </center> </td>
- <td> Assured Members only.<br> Intended for Reliance. </td>
- </tr>
- <tr>
- <th>Expiry of Certificates</th>
- <td colspan="2"><center>6 months</center></td>
- <td colspan="2"><center>24 months</center></td>
- </tr>
- <tr>
- <th>Types available</th>
- <td colspan="2"><center>simple only</center></td>
- <td colspan="2"><center>wildcard, subjectAltName</center></td>
- </tr>
-</table>
-
-<span class="figure">Table 1.4.5. Certificates under Old Roots - <b>Audit Fail</b> </span>
-</center>
-
-<p>
-<b> Old Roots.</b>
-The old CAcert root layout is as below. These roots are <b>Audit Fail</b>
-and will only be used where new roots do not serve:
-</p>
-<ul><li>
- (old) <b>Class 1 root.</b>
- Used primarily for certificates with no names and by
- unassured Members.
- For compatibility only,
- Assured Members may also use this root.
- </li><li>
- (old) <b>Class 3 root.</b>
- 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>
-
- <ul class="q">
- <li> Current Mozilla position has drifted from Class 1,2,3s to DV, IV+OV and EV posture. Except, the actual posture is either unstated or difficult to fathom.</li>
- <li> scheme for future roots is at <a href="http://wiki.cacert.org/wiki/Roots/NewRootsTaskForce">NewRootsTaskForce</a>.</li>
- <li>END OLD ROOTS </li>
- </ul>
-
-<h3><a name="p1.5" 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 name="p1.5.1" 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="http://www.cacert.org/policy/PolicyOnPolicy.html">COD1</a>).
-</p>
-
-<h4><a name="p1.5.2" 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="http://lists.cacert.org/mailman/listinfo">
- lists.cacert.org</a> . </li>
- <li>Send email to < support AT cacert DOT org > </li>
- <li>IRC: irc.cacert.org #CAcert (ssl port 7000, non-ssl port 6667)</li>
-</ul>
-
-<h4><a name="p1.5.3" 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 name="p1.5.4" 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="http://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 name="p1.5.5" id="p1.5.5">1.5.5 CPS updates</a></h4>
-
-<p>
-As per above.
-</p>
-
-
-<h3><a name="p1.6" id="p1.6">1.6. Definitions and acronyms</a></h3>
-<p>
-<b><a name="d_cert" id="d_cert">Certificate</a></b>.
- A certificate is a piece of cryptographic data used
- to validate certain statements, especially those of
- identity and membership.
-</p>
-<p>
-<b><a name="d_cacert" id="d_cacert">CAcert</a></b>.
- CAcert is a Community certificate authority as defined under
- <a href="#p1.2">§1.2 Identification</a>.
-</p>
-<p>
-<b><a name="d_member" id="d_member">Member</a></b>.
- Everyone who agrees to the
- CAcert Community Agreement
- (<a href="http://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>
-<b><a name="d_community" id="d_community">Community</a></b>.
- The group of Members who agree to the
- CAcert Community Agreement
- (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>)
- or equivalent agreements.
-</p>
-<p>
-<b><a name="d_unassured" id="d_unassured">Unassured Member</a></b>.
- A Member who has not yet been Assured.
-</p>
-<p>
-<b><a name="d_subscriber" id="d_subscriber">Subscriber</a></b>.
- A Member who requests and receives a certificate.
-</p>
-<p>
-<b><a name="d_assured" id="d_assured">Assured Member</a></b>.
- A Member whose identity has been sufficiently
- verified by Assurers or other
- approved methods under Assurance Policy.
-</p>
-<p>
-<b><a name="d_assurer" id="d_assurer">Assurer</a></b>.
- An Assured Member who is authorised under Assurance Policy
- to verify the identity of other Members.
-</p>
-<p>
-<b><a name="d_name" id="d_name">Name</a></b>.
- As defined in the
- Assurance Policy
- (<a href="http://www.cacert.org/policy/AssurancePolicy.html">COD13</a>),
- to describe a name of a Member
- that is verified by the Assurance process.
-<p>
-<b><a name="d_oadmin" id="d_oadmin">Organisation Administrator</a></b>.
- ("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>
-<b><a name="d_org_ass" id="d_org_ass">Organisation Assurer</a></b>.
- An Assurer who is authorised to conduct assurances on
- organisations.
-</p>
-<p>
-<b><a name="d_user" id="d_user">Non-Related Persons</a></b>.
- ("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
- Non-Related Persons - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.html">COD4</a>).
-</p>
-<p>
-<b><a name="rel" id="d_reliance">Reliance</a></b>.
- 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>
-<b><a name="rel" id="rel">Relying Party</a></b>.
- 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>
- <b>Subscriber Naming.</b>
- 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>
-<b><a name="ver" id="d_verification">Verification</a></b>.
- An industry term referring to
- the act of checking and controlling
- the accuracy and utility of a single claim.
-</p>
-<p>
-<b><a name="ver" id="d_validation">Validation</a></b>.
- An industry term referring to the process of
- inspecting and verifying the information and
- subsidiary claims behind a claim.
-</p>
-<p>
-<b><a name="rel" id="rel">Usage</a></b>.
- 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>
-<b><a name="drel" id="drel">CAcert Relying Party</a></b>.
- 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>
-<b><a name="ddst" id="ddst">Vendors</a></b>.
- 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.
- <span class="q"> As of the moment, this licence is not written.</span>
-</p>
-<p>
-<b><a name="d_ccs" id="d_ccs">Configuration-Control Specification</a></b> "CCS".
- The audit criteria that controls this CPS.
- The CCS is documented in COD2, itself a controlled document under CCS.
-</p>
-<p>
-<p>
-<b><a name="d_cod" id="d_cod">CAcert Official Document</a></b> (COD).
- Controlled Documents that are part of the CCS.
-</p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p2" id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</a></h2>
-
-
-<h3><a name="p2.1" 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="http://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 name="p2.2" 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 name="p2.3" 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 name="p2.4" id="p2.4">2.4. Access controls on repositories</a></h3>
-<p> No stipulation. </p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p3" id="p3">3. IDENTIFICATION AND AUTHENTICATION</a></h2>
-
-<h3><a name="p3.1" id="p3.1">3.1. Naming</a></h3>
-
-<h4><a name="p3.1.1" id="p3.1.1">3.1.1. Types of names</a></h4>
-
-<p>
-<b>Client Certificates.</b>
-The Subscriber Naming consists of:
-</p>
-<ul>
- <li><tt>subjectAltName=</tt>
- One, or more, of the Subscriber's verified email addresses,
- in rfc822Name format.
-
- <ul class="q">
- <li>SSO in subjectAltName?.</li>
- </ul>
- <li><tt>EmailAddress=</tt>
- 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><tt>CN=</tt> The common name takes its value from one of:
- <ul><li>
- For all Members,
- the string "<tt>CAcert WoT Member</tt>" 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>
-
- <ul class="q">
- <li> <a href="http://bugs.cacert.org/view.php?id=672"> bug 672</a> filed on subjectAltName.</li>
- <li> O-Admin must verify as per <a href="http://wiki.cacert.org/wiki/PolicyDecisions">p20081016</a>. </li>
- <li> it is a wip for OAP to state how this is done. </li>
- <li> curiously, (RFC5280) verification is only mandated for subjectAltName not subject field. </li>
- <li> what Directory String is used in above? UTF8String is specified by RFC52804.1.2.6? is this important for the CPS to state?</li>
- </ul>
-
-<p>
-<b>Individual Server Certificates.</b>
-The Subscriber Naming consists of:
-</p>
-<ul>
- <li><tt>CN=</tt>
- The common name is the host name out of a domain
- for which the Member is a domain master.
- </li> <li>
- <tt>subjectAltName=</tt>
- 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>
-<b>Certificates for Organisations.</b>
-In addition to the above, the following applies:
-</p>
-
-<ul>
- <li><tt>OU=</tt>
- organizationalUnitName (set by O-Admin, must be verified by O-Admin).</li>
- <li><tt>O=</tt>
- organizationName is the fixed name of the Organisation.</li>
- <li><tt>L=</tt>
- localityName</li>
- <li><tt>ST=</tt>
- stateOrProvinceName</li>
- <li><tt>C=</tt>
- countryName</li>
- <li><tt>contact=</tt>
- 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 name="p3.1.2" id="p3.1.2">3.1.2. Need for names to be meaningful</a></h4>
-
-<p>
-Each Member's Name (<tt>CN=</tt> field)
-is assured under the Assurance Policy (<a href="http://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">§1.4.5.</a>.
-</p>
-
-<p>
-Email addresses are verified according to
-<a href="#p4.2.2">§4.2.2.</a>
-</p>
-
-<!-- <center><a href="http://xkcd.com/327/"> <img src="http://imgs.xkcd.com/comics/exploits_of_a_mom.png"> </a> </center> -->
-
-<h4><a name="p3.1.3" id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</a></h4>
-
-<p>
-See <a href="#p1.4.5">§1.4.5</a>.
-</p>
-
-<h4><a name="p3.1.4" 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 name="p3.1.5" 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="http://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 name="p3.1.6" id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</a></h4>
-
-<p>
-Organisation Assurance Policy
-(<a href="http://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">§9.13</a>.
-</p>
-
-<h4><a name="p3.1.7" 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.php?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.php">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=&sp=&loc=en">Registry</a></td>
- <td><a href="http://www.domreg.lt/public?pg=8A7FB6&sp=idn&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 name="p3.2" id="p3.2">3.2. Initial Identity Verification</a></h3>
-
-<p>
-Identity verification is controlled by the
-<a href="http://svn.cacert.org/CAcert/Policies/AssurancePolicy.html">
-Assurance Policy</a> (<a href="http://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 name="p3.2.1" 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 name="p3.2.2" id="p3.2.2">3.2.2. Authentication of Individual Identity</a></h4>
-
-<p>
-<b>Agreement.</b>
-An Internet user becomes a Member by agreeing to the
-CAcert Community Agreement
-(<a href="http://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>
-<b>Assurance.</b>
-Each Member is assured according to Assurance Policy
-(<a href="http://www.cacert.org/policy/AssurancePolicy.html">COD13</a>).
-</p>
-
-<!-- <center><a href="http://xkcd.com/364/"> <img src="http://imgs.xkcd.com/comics/responsible_behavior.png"> </a> </center> -->
-
-
-
-<p>
-<b>Certificates.</b>
-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">§1.4.5</a>.
-See Table 3.2.b.
-When Members have 50 or more points, they
-become <i>Assured Members</i> and may then request
-certificates that state their Assured Name(s).
-</p>
-
-
-<br><br>
-<center>
-
-<table border="1" cellpadding="5">
- <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 rowspan="1">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 rowspan="2">100++</td>
- <td rowspan="2">Assurer</td>
- <td>Code-signing</td>
- <td>Can create Code-signing certificates </td>
- </tr>
-</table>
-
-<span class="figure">Table 3.2.b - How Assurance Points are used in Certificates</span>
-
-</center>
-<br>
-
-
-
-<h4><a name="p3.2.3" 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="http://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="http://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="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance">documented bugs</a>. </li>
- <li> Therefore Organisations will not participate in the current audit cycle of roots. </li>
- <li> See <a href="http://wiki.cacert.org/wiki/OrganisationAssurance">wiki</a> for any progress on this. </li>
- </ul>
-
-
-<h4><a name="p3.2.4" 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, §4.5.2.
-</p>
-
-
-<h4><a name="p3.2.5" 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>
-<b>Addresses.</b>
-The member claims authority over a domain or email address
-when adding the address, <a href="#p4.1.2">§4.1.2</a>.
-(Control is tested by means described in <a href="#p4.2.2">§4.2.2</a>.)
-</p>
-
-<p>
-<b>Individuals.</b>
-The authority to participate as a Member is established
-by the CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>).
-Assurances are requested by means of the signed CAP form.
-</p>
-
-<p>
-<b>Organisations.</b>
-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 name="p3.2.6" 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 name="p3.3" id="p3.3">3.3. Re-key Requests</a></h3>
-
-<p>
-Via the Member's account.
-</p>
-
-<h3><a name="p3.4" 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 name="p4" 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 name="p4.1" id="p4.1">4.1. Certificate Application</a></h3>
-
-<h4><a name="p4.1.1" 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 name="p4.1.2" 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 name="p4.1.3" id="p4.1.3">4.1.3. Preparing CSR </a></h4>
-
-<p>
-Members generate their own key-pairs.
-The CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>)
-obliges the Member as responsible for security.
-See CCA2.5, §9.6.
-</p>
-
-<p>
-The Certificate Signing Request (CSR) is prepared by the
-Member for presentation to the automated system.
-</p>
-
-<h3><a name="p4.2" 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 name="p4.2.1" 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 name="p4.2.2" 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>
-<b><a name="ping">Email-Ping</a>.</b>
-Email addresses are verified by means of an
-<i><a name="ping">Email-Ping test</a></i>:
-</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>
-<b><a name="email">Email Control</a>.</b>
-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>
-<b><a name="domain">Domain Control</a>.</b>
-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 <i>whois</i>
- 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>
-
-
- <ul class="q">
- <li> As of the time of writing, only a singular Email-ping is implemented in the technical system. </li>
- <li> A further approved check is the 1 pt Assurance. </li>
- <li> Practically, this would mean that certificates can only be issued under Audit Roots to Members with 1 point. </li>
- <li> Criteria DRC C.7.f, A.2.q, A.2.i indicate registry whois reading. Also A.2.h. </li>
- <li> Current view is that this will be resolved in BirdShack. </li>
- </ul>
-
-<h4><a name="p4.2.3" 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 name="p4.2.4" 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 name="p4.2.5" 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 name="p4.2.6" 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 name="p4.2.7" 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>
-
- <ul class="q">
- <li> As of time of writing, there is no Handbook for Organisation Assurers or for the Organisation, and the policy needs rework; so (audit) roots will not have OA certs .... </li>
- <li> <a href="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance"> Drafts </a> for ongoing story. </li>
- </ul>
-
-<h3><a name="p4.3" id="p4.3">4.3. Certificate issuance</a></h3>
-
-
-<!-- <a href="http://xkcd.com/153/"> <img align="right" src="http://imgs.xkcd.com/comics/cryptography.png"> </a> -->
-<h4><a name="p4.3.1" id="p4.3.1">4.3.1. CA actions during certificate issuance</a></h4>
-
-<p>
-<b>Key Sizes.</b>
-Members may request keys of any size permitted by the key algorithm.
-Many older hardware devices require small keys.
-</p>
-
-<p>
-<b>Algorithms.</b>
-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>
-<b>Process for Certificates:</b>
-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 §3.1, </li>
- <li> Email address <a href="#p4.2.2">§4.2.2</a>, </li>
- <li> Domain address <a href="#p4.2.2">§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>
-<b>Process for OpenPGP key signatures:</b>
-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>
-
-<center>
-<table border="1" align="center" valign="top" cellpadding="5"><tbody>
- <tr>
- <td><br></td>
- <td>Verified Name</td>
- <td valign="top">Unverified Name<br></td>
- <td>Empty Name<br></td>
- </tr>
- <tr>
- <td>Verified email<br></td>
- <td><center> <font title="pass." color="green" size="+3"> ✔ </font> </center></td>
- <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
- <td><center> <font title="pass." color="green" size="+3"> ✔ </font> </center></td>
- </tr>
- <tr>
- <td>Unverified email</td>
- <td><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
- <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
- <td><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td></tr><tr><td valign="top">Empty email<br></td>
- <td valign="top"><center> <font title="pass." color="green" size="+3"> ✔ </font> </center></td>
- <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
- <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
- </tr>
-</tbody></table><br>
-
-<span class="figure">Table 4.3.1. Permitted Data in Signed OpenPgp Keys</span>
-</center>
-
-<h4><a name="p4.3.2" 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>
-
-<h3><a name="p4.4" id="p4.4">4.4. Certificate acceptance</a></h3>
-
-<h4><a name="p4.4.1" id="p4.4.1">4.4.1. Conduct constituting certificate acceptance</a></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>
-
-<h4><a name="p4.4.2" id="p4.4.2">4.4.2. Publication of the certificate by the CA</a></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 §2.2.
-</p>
-
-<h4><a name="p4.4.3" id="p4.4.3">4.4.3. Notification of certificate issuance by the CA to other entities</a></h4>
-
-<p>
-There are no external entities that are notified about issued certificates.
-</p>
-
-<h3><a name="p4.5" id="p4.5">4.5. Key pair and certificate usage</a></h3>
-
-<p>
-All Members (subscribers and relying parties)
-are obliged according to the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>)
-See especially 2.3 through 2.5.
-</p>
-<h4><a name="p4.5.1" id="p4.5.1">4.5.1. Subscriber Usage and Responsibilities</a></h4>
-
-<p>
-Subscribers should use keys only for their proper purpose,
-as indicated by the certificate, or by wider agreement with
-others.
-</p>
-
-<h4><a name="p4.5.2" id="p4.5.2">4.5.2. Relying Party Usage and Responsibilities</a></h4>
-
-
-<p>
-Relying parties (Members) may rely on the following.
-</p>
-
-<center>
- <table border="1" cellpadding="25"><tr><td>
- <p align="center">
- <big><b>Relying Party Statement</b></big>
- <p>
- Certificates are issued to Members only.<br><br>
- All information in a certificate is verified.
- </p>
- </td></tr></table>
-</center>
-
-
-<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" cellpadding="5"><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 §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 §7.1</td>
-</tr></table>
-
-<h5>4.5.2.b Who may rely</h5>
-<p>
-<b>Members may rely.</b>
-Relying parties are Members,
-and as such are bound by this CPS and the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>).
-The licence and permission to rely is not assignable.
-</p>
-
-<p>
-<b>Suppliers of Software.</b>
-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 <span class="q"> ...WIP comment:</span>
-they agree to dispute resolution
-within CAcert's forum.
-</p>
-
- <ul class="q">
- <li> Just exactly what the 3PV-DaL says is unclear.</li>
- <li> The document itself is more a collection of ideas.</li>
- </ul>
-
-
-<p>
-<b>NRPs may not rely.</b>
-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
-NRP - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.html">COD4</a>).
-</p>
-
-<h5>4.5.2.c The Act of Reliance </h5>
-
-<p>
-<b>Decision making.</b>
-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>
-<b>Examining the Certificate.</b>
-A Relying Party must make her own decision in using
-each certificate. She must examine the certificate,
-a process called <i>validation</i>.
-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>
-<b>Keeping Records.</b>
-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>
-<b>Wider Protocol.</b>
-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>
-<b>As Compared to Usage</b>.
-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>
-<b>Roots and Naming.</b>
-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>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
- <td></td>
- <td colspan="4"><center><i>Statements of Reliance for Members</i></center></td>
- </tr>
- <tr>
- <td><i>Class of Root</i></td>
- <td><center><b>Anonymous</b><br>(all Members)</center></td>
- <td><center><b>Named</b><br>(Assured Members only)</center></td>
- </tr>
- <tr>
- <td><center>Class<br><big><b>1</b></big></center></td>
- <td rowspan="2" bgcolor="red">
- <b>Do not rely.</b><BR>
- Relying party must use other methods to check. </td>
- <td rowspan="2" bgcolor="orange">
- 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><center><big><b>Member</b></big><br>SubRoot</center></td>
- </tr>
- <tr>
- <td><center>Class<br><big><b>3</b></big></center></td>
- <td rowspan="2" bgcolor="orange">
- 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><center><big><b>Assured</b></big><br>SubRoot</center></td>
- </tr>
-</table>
-
-<span class="figure">Table 4.5.2. Statements of Reliance</span>
-</center>
-
-<p>
-<b>Software Agent.</b>
-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>
-<b>Malware.</b>
-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 <b>to file dispute under DRP</b>.
-See <a href="#p9.13">§9.13</a>.
-<!-- DRC_A§A.4.d -->
-For this purpose, the certificate (and other evidence) should be preserved.
-</p>
-
-<p>
-<b>Which person?</b>
-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>
-
-<!-- <a href="http://xkcd.com/424/"> <img align="right" src="http://imgs.xkcd.com/comics/security_holes.png"> </a> -->
-<p>
-<b>Software Agent.</b>
-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>
-
-<h3><a name="p4.6" id="p4.6">4.6. Certificate renewal</a></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>
-
-<h3><a name="p4.7" id="p4.7">4.7. Certificate re-key</a></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>
-
-<h3><a name="p4.8" id="p4.8">4.8. Certificate modification</a></h3>
-
-<p>
-Certificate "modifications" are not offered nor supported.
-A new certificate has to be requested and issued instead.
-</p>
-
-<h3><a name="p4.9" id="p4.9">4.9. Certificate revocation and suspension</a></h3>
-
-<h4><a name="p4.9.1" id="p4.9.1">4.9.1. Circumstances for revocation</a></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>
-
-<h4><a name="p4.9.2" id="p4.9.2">4.9.2. Who can request revocation</a></h4>
-
-<p>
-As above.
-</p>
-
-<h4><a name="p4.9.3" id="p4.9.3">4.9.3. Procedure for revocation request</a></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
- < support AT cacert DOT org >
-</p>
-
-<h4><a name="p4.9.4" id="p4.9.4">4.9.4. Revocation request grace period</a></h4>
-
-<p>No stipulation.</p>
-
-<h4><a name="p4.9.5" id="p4.9.5">4.9.5. Time within which CA must process the revocation request</a></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>
-
-<h4><a name="p4.9.6" id="p4.9.6">4.9.6. Revocation checking requirement for relying parties</a></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>
-
-<h4><a name="p4.9.7" id="p4.9.7">4.9.7. CRL issuance frequency (if applicable)</a></h4>
-
-<p>
-A new CRL is issued after every certificate revocation.
-</p>
-
-<h4><a name="p4.9.8" id="p4.9.8">4.9.8. Maximum latency for CRLs (if applicable)</a></h4>
-
-<p>
-The maximum latency between revocation and issuance of the CRL is 1 hour.
-</p>
-
-<h4><a name="p4.9.9" id="p4.9.9">4.9.9. On-line revocation/status checking availability</a></h4>
-
-<p>
-OCSP is available at
-http://ocsp.cacert.org/ .
-</p>
-
-<h4><a name="p4.9.10" id="p4.9.10">4.9.10. On-line revocation checking requirements</a></h4>
-<p>
-Relying parties must check up-to-date status before relying.
-</p>
-
-<h4><a name="p4.9.11" id="p4.9.11">4.9.11. Other forms of revocation advertisements available</a></h4>
-<p>
-None.
-</p>
-
-<h4><a name="p4.9.12" id="p4.9.12">4.9.12. Special requirements re key compromise</a></h4>
-<p>
-Subscribers are obliged to revoke certificates at the earliest opportunity.
-</p>
-
-<h4><a name="p4.9.13" id="p4.9.13">4.9.13. Circumstances for suspension</a></h4>
-
-<p>
-Suspension of certificates is not available.
-</p>
-
-<h4><a name="p4.9.14" id="p4.9.14">4.9.14. Who can request suspension</a></h4>
-<p>
-Not applicable.
-</p>
-
-<h4><a name="p4.9.15" id="p4.9.15">4.9.15. Procedure for suspension request</a></h4>
-<p>
-Not applicable.
-</p>
-
-<h4><a name="p4.9.16" id="p4.9.16">4.9.16. Limits on suspension period</a></h4>
-<p>
-Not applicable.
-</p>
-
-
-
-<h3><a name="p4.10" id="p4.10">4.10. Certificate status services</a></h3>
-
-<h4><a name="p4.10.1" id="p4.10.1">4.10.1. Operational characteristics</a></h4>
-<p>
-OCSP is available
-at http://ocsp.cacert.org/ .
-</p>
-
-<h4><a name="p4.10.2" id="p4.10.2">4.10.2. Service availability</a></h4>
-
-<p>
-OCSP is made available on an experimental basis.
-</p>
-
-<h4><a name="p4.10.3" id="p4.10.3">4.10.3. Optional features</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p4.11" id="p4.11">4.11. End of subscription</a></h3>
-
-<p>
-Certificates include expiry dates.
-</p>
-
-<h3><a name="p4.12" id="p4.12">4.12. Key escrow and recovery</a></h3>
-
-<h4><a name="p4.12.1" id="p4.12.1">4.12.1. Key escrow and recovery policy and practices</a></h4>
-
-<p>
-CAcert does not generate nor escrow subscriber keys.
-</p>
-
-<h4><a name="p4.12.2" id="p4.12.2">4.12.2. Session key encapsulation and recovery policy and practices</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p5" id="p5">5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a></h2>
-
-<!-- <a href="http://xkcd.com/87/"> <img align="right" src="http://imgs.xkcd.com/comics/velociraptors.jpg"> </a> -->
-
-<h3><a name="p5.1" id="p5.1">5.1. Physical controls</a></h3>
-
-<p>
-Refer to Security Policy (<a href="http://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>
-
-
-
-<h4><a name="p5.1.3" id="p5.1.3">5.1.3. Power and air conditioning</a></h4>
-<p>
-Refer to Security Policy 2.1.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.4" id="p5.1.4">5.1.4. Water exposures</a></h4>
-<p>
-Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.5" id="p5.1.5">5.1.5. Fire prevention and protection</a></h4>
-<p>
-Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.6" id="p5.1.6">5.1.6. Media storage</a></h4>
-<p>
-Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.7" id="p5.1.7">5.1.7. Waste disposal</a></h4>
-<p>
-No stipulation.
-</p>
-<h4><a name="p5.1.8" id="p5.1.8">5.1.8. Off-site backup</a></h4>
-<p>
-Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-
-<h3><a name="p5.2" id="p5.2">5.2. Procedural controls</a></h3>
-
-<h4><a name="p5.2.1" id="p5.2.1">5.2.1. Trusted roles</a></h4>
-
-<ul>
- <li><b> Technical teams:</b>
- <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="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-
- </li>
-
- <li><b>Assurance:</b>
- <ul>
- <li>Assurers</li>
- <li> Any others authorised under COD13 </li>
- </ul>
- Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.html">COD13</a>)
- </li>
-
- <li><b>Governance:</b>
- <ul>
- <li>Directors (members of the CAcert Inc. committee, or "Board") </li>
- <li>Internal Auditor</li>
- <li>Arbitrator</li>
- </ul>
- </li>
-</ul>
-
-
-<h4><a name="p5.2.2" id="p5.2.2">5.2.2. Number of persons required per task</a></h4>
-<p>
-CAcert operates to the principles of <i>four eyes</i> and <i>dual control</i>.
-All important roles require a minimum of two persons.
-The people may be tasked to operate
-with an additional person observing (<i>four eyes</i>),
-or with two persons controlling (<i>dual control</i>).
-</p>
-
-<h4><a name="p5.2.3" id="p5.2.3">5.2.3. Identification and authentication for each role</a></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="http://www.cacert.org/policy/AssurancePolicy.html">COD13</a>).
-</p>
-
-<p>
-<b>Technical.</b>
-Refer to Security Policy 9.1 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-
-<h4><a name="p5.2.4" id="p5.2.4">5.2.4. Roles requiring separation of duties</a></h4>
-
-<p>
-Roles strive in general for separation of duties, either along the lines of
-<i>four eyes principle</i> or <i>dual control</i>.
-</p>
-
-<h3><a name="p5.3" id="p5.3">5.3. Personnel controls</a></h3>
-
-<h4><a name="p5.3.1" id="p5.3.1">5.3.1. Qualifications, experience, and clearance requirements</a></h4>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
- <td><b>Role</b></td> <td><b>Policy</b></td> <td><b>Comments</b></td>
- </tr><tr>
- <td>Assurer</td>
- <td><a href="http://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="http://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="http://www.cacert.org/policy/DisputeResolutionPolicy.html">COD7</a></td>
- <td>
- Experienced Assurers.
- </td>
- </tr>
-</table>
-
-<span class="figure">Table 5.3.1. Controls on Roles</span>
-</center>
-
-
-<h4><a name="p5.3.2" id="p5.3.2">5.3.2. Background check procedures</a></h4>
-
-<p>
-Refer to Security Policy 9.1.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-<!-- <a href="http://xkcd.com/538/"> <img align="right" src="http://imgs.xkcd.com/comics/security.png"> </a> -->
-
-<h4><a name="p5.3.3" id="p5.3.3">5.3.3. Training requirements</a></h4>
-<p>No stipulation.</p>
-<h4><a name="p5.3.4" id="p5.3.4">5.3.4. Retraining frequency and requirements</a></h4>
-<p>No stipulation.</p>
-
-<h4><a name="p5.3.5" id="p5.3.5">5.3.5. Job rotation frequency and sequence</a></h4>
-<p>No stipulation.</p>
-
-<h4><a name="p5.3.6" id="p5.3.6">5.3.6. Sanctions for unauthorized actions</a></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>
-
-<h4><a name="p5.3.7" id="p5.3.7">5.3.7. Independent contractor requirements</a></h4>
-<p>No stipulation.</p>
-
-<h4><a name="p5.3.8" id="p5.3.8">5.3.8. Documentation supplied to personnel</a></h4>
-<p>No stipulation.</p>
-
-<h3><a name="p5.4" id="p5.4">5.4. Audit logging procedures</a></h3>
-
-<p>
-Refer to Security Policy 4.2, 5 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-
-<h3><a name="p5.5" id="p5.5">5.5. Records archival</a></h3>
-<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>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
- <td><b>Record</b></td>
- <td><b>Nature</b></td>
- <td><b>Exceptions</b></td>
- <td><b>Documentation</b></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>
-
-<span class="figure">Table 5.5. Documents and Retention </span>
-</center>
-
-
-<h3><a name="p5.6" id="p5.6">5.6. Key changeover</a></h3>
-
-<p>
-Refer to Security Policy 9.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-
-<h3><a name="p5.7" id="p5.7">5.7. Compromise and disaster recovery</a></h3>
-
-<p>
-Refer to Security Policy 5, 6 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-(Refer to <a href="#p1.4">§1.4</a> for limitations to service.)
-</p>
-
-
-<h3><a name="p5.8" id="p5.8">5.8. CA or RA termination</a></h3>
-
-<h4><a name="p5.8.1" id="p5.8.1">5.8.1 CA termination</a></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>
-<span class="change">
-The CA cannot be transferrred to another organisation.
-</span>
-</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 §9.10.2.
-Members will have reasonable time in which to file a related
-dispute after notification
-(at least one month).
-See §9.13.
-</s>
-</p>
-<s>
- <ul class="error">
- <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>
-</s>
-
-<p>
-<span class="change">
-<s>
-New root keys and certificates will be made available
-by the new organisation as soon as reasonably practical.
-</s>
-</span>
-</p>
-
-<h4><a name="p5.8.2" id="p5.8.2">5.8.2 RA termination</a></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>
-
-
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p6" id="p6">6. TECHNICAL SECURITY CONTROLS</a></h2>
-
-
-<!-- <a href="http://xkcd.com/221/"> <img align="right" src="http://imgs.xkcd.com/comics/random_number.png"> </a> -->
-
-<h3><a name="p6.1" id="p6.1">6.1. Key Pair Generation and Installation</a></h3>
-
-<h4><a name="p6.1.1" id="p6.1.1">6.1.1. Key Pair Generation</a></h4>
-
-<p>
-Subscribers generate their own Key Pairs.
-</p>
-
-<h4><a name="p6.1.2" id="p6.1.2">6.1.2. Subscriber Private key security</a></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">§9.6</a>.
-</p>
-
-<h4><a name="p6.1.3" id="p6.1.3">6.1.3. Public Key Delivery to Certificate Issuer</a></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>
-
-<h4><a name="p6.1.4" id="p6.1.4">6.1.4. CA Public Key delivery to Relying Parties</a></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>
-
-<p class="q"> Third Party Vendor Agreement is early wip, only </p>
-
-<h4><a name="p6.1.5" id="p6.1.5">6.1.5. Key sizes</a></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">§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>
-
- <ul class="q">
- <li> old Class 3 SubRoot is signed with MD5 </li>
- <li> likely this will clash with future plans of vendors to drop acceptance of MD5</li>
- <li> Is this a concern? </li>
- <li> to users who have these certs, a lot? </li>
- <li> to audit, not much? </li>
- </ul>
-
-
-<h4><a name="p6.1.6" id="p6.1.6">6.1.6. Public key parameters generation and quality checking</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p6.1.7" id="p6.1.7">6.1.7. Key Usage Purposes</a></h4>
-
-
- <ul class="q">
- <li> This section probably needs to detail the key usage bits in the certs. </li>
- </ul>
-
-
-<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>
-
-
-
-<!-- <a href="http://xkcd.com/257/"> <img align="right" src="http://imgs.xkcd.com/comics/code_talkers.png"> </a> -->
-
-<h3><a name="p6.2" id="p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a></h3>
-
-
-
-
-<h4><a name="p6.2.1" id="p6.2.1">6.2.1. Cryptographic module standards and controls</a></h4>
-
-<p>
-SubRoot keys are stored on a single machine which acts
-as a Cryptographic Module, or <i>signing server</i>.
-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 §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>
-
-<ol class="q"><li>
- What document is responsible for architecture? CPS? SM?
- <a href="http://www.cacert.org/help.php?id=7">website</a>?
- SM punts it to CPS, so above stays.
- </li><li>
- There is no criteria on Architecture.
- </li><li>
- Old questions moved to SM.
- </li><li>
- See
- <a href="http://www.cacert.org/help.php?id=7">
- CAcert Root key protection</a> which should be deprecated by this CPS.
-</li></ol>
-
-
-<h3><a name="p6.3" id="p6.3">6.3. Other aspects of key pair management</a></h3>
-<h4><a name="p6.3.1" id="p6.3.1">6.3.1. Public key archival</a></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 §2.
-They are backed-up by CAcert's normal backup procedure,
-but their availability is a subscriber responsibility.
-</p>
-
-<h4><a name="p6.3.2" id="p6.3.2">6.3.2. Certificate operational periods and key pair usage periods</a></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">§1.4.5</a> and Assurance Policy (<a href="http://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>
-
-<h3><a name="p6.4" id="p6.4">6.4. Activation data</a></h3>
-<p> No stipulation. </p>
-
-<h3><a name="p6.5" id="p6.5">6.5. Computer security controls</a></h3>
-<p>
-Refer to Security Policy.
-</p>
-
-<h3><a name="p6.6" id="p6.6">6.6. Life cycle technical controls</a></h3>
-<p>
-Refer to SM7 "Software Development".
-</p>
-
-<h3><a name="p6.7" id="p6.7">6.7. Network security controls</a></h3>
-<p>
-Refer to SM3.1 "Logical Security - Network".
-</p>
-
-<h3><a name="p6.8" id="p6.8">6.8. Time-stamping</a></h3>
-<p>
-Each server synchronises with NTP.
-No "timestamping" service is currently offered.
-</p>
-
- <ul class="q">
- <li> How does the signing server syncronise if only connected over serial?</li>
- <li> How is timestamping done on records?</li>
- </ul>
-
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p7" id="p7">7. CERTIFICATE, CRL, AND OCSP PROFILES</a></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>
-
-<h3><a name="p7.1" id="p7.1">7.1. Certificate profile</a></h3>
-<h4><a name="p7.1.1" id="p7.1.1">7.1.1. Version number(s)</a></h4>
-<p class="q"> What versions of PGP are signed? v3? v4? </p>
-
-<p>
-Issued X.509 certificates are of v3 form.
-The form of the PGP signatures depends on several factors, therefore no stipulation.
-</p>
-
-<h4><a name="p7.1.2" id="p7.1.2">7.1.2. Certificate extensions</a></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:<crlUri> where <crlUri> 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">§3.1.1.</a>).</li>
-</ul>
- <ul class="q">
- <li> what about Client Certificates Adobe Signing extensions ?</li>
- <li> SubjectAltName should become critical if DN is removed http://tools.ietf.org/html/rfc5280#section-4.2.1.6</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:<crlUri> where <crlUri> 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">§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:<crlUri> where <crlUri> 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">§3.1.1.</a>).</li>
-</ul>
- <ul class="q">
- <li> what about subjectAltName for Code-signing</li>
- </ul>
-
-<p>
-OpenPGP key signatures currently do not include extensions.
-In the future, a serial number might be included as an extension.
-</p>
-
-
-<h4><a name="p7.1.3" id="p7.1.3">7.1.3. Algorithm object identifiers</a></h4>
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p7.1.4" id="p7.1.4">7.1.4. Name forms</a></h4>
-<p>
-Refer to <a href="#p3.1.1">§3.1.1</a>.
-</p>
-
-<h4><a name="p7.1.5" id="p7.1.5">7.1.5. Name constraints</a></h4>
-<p>
-Refer to <a href="#p3.1.1">§3.1.1</a>.
-</p>
-
-<h4><a name="p7.1.6" id="p7.1.6">7.1.6. Certificate policy object identifier</a></h4>
-<p>
-The following OIDs are defined and should be incorporated
-into certificates:
-</p>
-
-<table border="1" cellpadding="5">
- <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>
-
-<h4><a name="p7.1.7" id="p7.1.7">7.1.7. Usage of Policy Constraints extension</a></h4>
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p7.1.8" id="p7.1.8">7.1.8. Policy qualifiers syntax and semantics</a></h4>
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p7.1.9" id="p7.1.9">7.1.9. Processing semantics for the critical Certificate Policies extension</a></h4>
-<p>
-No stipulation.
-</p>
-
-
-<h3><a name="p7.2" id="p7.2">7.2. CRL profile</a></h3>
-<h4><a name="p7.2.1" id="p7.2.1">7.2.1. Version number(s)</a></h4>
-<p>
-CRLs are created in X.509 v2 format.
-</p>
-
-<h4><a name="p7.2.2" id="p7.2.2">7.2.2. CRL and CRL entry extensions</a></h4>
-
-<p>
-No extensions.
-</p>
-
-<h3><a name="p7.3" id="p7.3">7.3. OCSP profile</a></h3>
-<h4><a name="p7.3.1" id="p7.3.1">7.3.1. Version number(s)</a></h4>
-<p>
-The OCSP responder operates in Version 1.
-</p>
-<h4><a name="p7.3.2" id="p7.3.2">7.3.2. OCSP extensions</a></h4>
-<p>
-No stipulation.
-</p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p8" id="p8">8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS</a></h2>
-
-<p>
-There are two major threads of assessment:
-</p>
-
-<ul><li>
- <b>Systems Audit</b>.
- 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>
- <b>Code Audit</b>.
- 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="http://wiki.cacert.org/wiki/Audit/">
-wiki.cacert.org/wiki/Audit/</a>
-for more information.
-</p>
-
-<h3><a name="p8.1" id="p8.1">8.1. Frequency or circumstances of assessment</a></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>
- <b>Systems Audit</b>.
- <span class="q">
- The first phase of the first audit is nearing completion.
- The second phase starts in earnest when documentation is in
- effect, at lease as DRAFT under PoP.
- As the second phase is dependent on
- this CPS and the Security Policy, they will
- be in effect as DRAFT at least
- before the first audit is completed.
- Only prior and completed audits can be reported here.
- </span>
- </li><li>
- <b>Code Audit</b>.
- <span class="q">
- A complete review of entire source code has not yet been completed.
- </span>
-</li></ul>
-
-<h3><a name="p8.2" id="p8.2">8.2. Identity/qualifications of assessor</a></h3>
-
-<p>
-<b>Systems Auditors.</b>
-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>
-
-<!-- <center><a href="http://xkcd.com/511/"> <img src="http://imgs.xkcd.com/comics/sleet.png"> </a> </center> -->
-
-<p>
-<b>Code Auditors.</b>
-See Security Policy, sections 7, 9.1.
-</p>
-
-<h3><a name="p8.3" id="p8.3">8.3. Assessor's relationship to assessed entity</a></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>
-
-<h3><a name="p8.4" id="p8.4">8.4. Topics covered by assessment</a></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>
-
-<h3><a name="p8.5" id="p8.5">8.5. Actions taken as a result of deficiency</a></h3>
-<p>
-See the current
-<a href="http://wiki.cacert.org/wiki/Audit/Done">Audit Done list</a>
-for work completed, and
-<a href="http://wiki.cacert.org/wiki/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="http://wiki.cacert.org/wiki/AuditDirectives">
-wiki.cacert.org/wiki/AuditDirectives</a>
-documents issued directives and actions.
-</p>
-
-<h3><a name="p8.6" id="p8.6">8.6. Communication of results</a></h3>
-
-<p>
-Current and past Audit information is available at
-<a href="http://wiki.cacert.org/wiki/Audit/">wiki.CAcert.org/wiki/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="http://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>
-
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p9" id="p9">9. OTHER BUSINESS AND LEGAL MATTERS</a></h2>
-<h3><a name="p9.1" id="p9.1">9.1. Fees</a></h3>
-
-
-<p>
-The current fees structure is posted at
-<a href="http://wiki.cacert.org/wiki/Price">wiki.cacert.org/wiki/Price</a>.
-Changes to the fees structure will be announced
-from time to time on the <a href="http://blog.cacert.org/">blog</a>.
-CAcert retains the right to charge fees for services.
-All fees are non-refundable.
-</p>
-
-
-<h3><a name="p9.2" id="p9.2">9.2. Financial responsibility</a></h3>
-
-<p>
-Financial risks are dealt with primarily by
-the Dispute Resolution Policy
-(<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.html">COD7</a>).
-</p>
-
-<h4><a name="p9.2.1" id="p9.2.1">9.2.1. Insurance coverage</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.2.2" id="p9.2.2">9.2.2. Other assets</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.2.3" id="p9.2.3">9.2.3. Insurance or warranty coverage for end-entities</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p9.3" id="p9.3">9.3. Confidentiality of business information</a></h3>
-
-<h4><a name="p9.3.1" id="p9.3.1">9.3.1. Scope of confidential information</a></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>
-
-<h3><a name="p9.4" id="p9.4">9.4. Privacy of personal information</a></h3>
-
-<!-- <center><a href="http://xkcd.com/46/"> <img src="http://imgs.xkcd.com/comics/secrets.jpg"> </a> </center> -->
-<p>
-Privacy is covered by the
-CCA (COD9)
-and the Privacy Policy
-(<a href="PrivacyPolicy.html">COD5</a>).
-</p>
-
-<h4><a name="p9.4.1" id="p9.4.1">9.4.1. Privacy plan</a></h4>
-<p> No stipulation. </p>
-<h4><a name="p9.4.2" id="p9.4.2">9.4.2. Information treated as private</a></h4>
-<p>
-Member's Date of Birth and "Lost Password" questions are treated as fully private.
-</p>
-<h4><a name="p9.4.3" id="p9.4.3">9.4.3. Information not deemed private</a></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="http://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>
-<h4><a name="p9.4.4" id="p9.4.4">9.4.4. Responsibility to protect private information</a></h4>
-<p>
-CAcert is a privacy organisation
-and takes privacy more seriously.
-Any privacy issue may be referred to dispute resolution.
-</p>
-<h4><a name="p9.4.5" 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>
-<h4><a name="p9.4.6" id="p9.4.6">9.4.6. Disclosure pursuant to judicial or administrative process</a></h4>
-<p>
-Any disclosure pursuant to process from foreign courts
-(or similar)
-is controlled by the Arbitrator.
-</p>
-<h4><a name="p9.4.7" id="p9.4.7">9.4.7. Other information disclosure circumstances</a></h4>
-<p>
-None.
-</p>
-
-<h3><a name="p9.5" id="p9.5">9.5. Intellectual property rights</a></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>
-
-<!-- <center><a href="http://xkcd.com/225/"> <img src="http://imgs.xkcd.com/comics/open_source.png"> </a> </center> -->
-
-<h4><a name="p9.5.1" id="p9.5.1">9.5.1. Ownership and Licence</a></h4>
-
-<p>
-Assets that fall under the control of CCS
-must be transferred to CAcert.
-See PoP 6.2
-(<a href="http://www.cacert.org/policy/PolicyOnPolicy.html#6.2">COD1</a>),
-CCA 1.3
-(<a href="http://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>
-
-<h4><a name="p9.5.2" id="p9.5.2">9.5.2. Brand</a></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="http://wiki.cacert.org/wiki/TopMinutes-20070917">
-m20070917.5</a>.
-</p>
-
-<h4><a name="p9.5.3" id="p9.5.3">9.5.3. Documents</a></h4>
-
-<p>
-CAcert owns or requires full control over its documents,
-especially those covered by CCS.
-See PoP 6.2
-(<a href="http://www.cacert.org/policy/PolicyOnPolicy.html#6.2">COD1</a>).
-Contributors transfer the rights,
-see CCA 1.3
-(<a href="http://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="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
-wiki.cacert.org/wiki/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="http://www.cacert.org/policy/PolicyOnPolicy.html#6.4">COD1</a>),
-CCA 1.3
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html#1.3">COD9</a>).
-</p>
-
-<h4><a name="p9.5.4" id="p9.5.4">9.5.4. Code</a></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 class="q">
-See the (new, wip)
-<a href="http://svn.cacert.cl/Documents/SourceCodeManifesto.html">
-SourceCodeManifesto</a>.
-Maybe this can replace these two paras?
-</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>
-
-<h4><a name="p9.5.5" id="p9.5.5">9.5.5. Certificates and Roots</a></h4>
-
-<p>
-CAcert asserts its intellectual property rights over certificates
-issued to Members and over roots.
-See CCA 4.4
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html#4.4">COD9</a>),
-CCS.
-The certificates may only be used by Members under
-<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html#4.4">COD9</a>,
-and,
-by others under the licences offered,
-such as
-Non-Related Persons - Disclaimer and Licence
-(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.html">COD4</a>).
-</p>
-
-<h3><a name="p9.6" id="p9.6">9.6. Representations and warranties</a></h3>
-
-
-<p>
-<b>Members.</b>
-All Members of the Community agree to the
-CAcert Community Agreement
-(<a href="http://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>
-<b>RAs.</b>
-Registration Agents are obliged additionally by Assurance Policy,
-especially 3.1, 4.1
-(<a href="http://www.cacert.org/policy/AssurancePolicy.html">COD13</a>).
-</p>
-
-<p>
-<b>CA.</b>
-The CA is obliged additionally by the CCS.
-</p>
-
-<p>
-<b>Third Party Vendors.</b>
-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>
-
-<h3><a name="p9.7" id="p9.7">9.7. Disclaimers of Warranties</a></h3>
-
-<p>
-Persons who have not accepted the above Agreements are offered the
-Non-Related Persons - Disclaimer and Licence
-(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.html">COD4</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">§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="http://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>
-
-<h3><a name="p9.8" id="p9.8">9.8. Limitations of liability</a></h3>
-
-<h3><a name="p9.8.1" id="p9.8.1">9.8.1 Non-Related Persons </a></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="http://www.cacert.org/policy/NRPDisclaimerAndLicence.html">COD4</a>.
-</p>
-
-<h3><a name="p9.8.2" id="p9.8.2">9.8.2 Liabilities Between Members</a></h3>
-
-<p>
-Liabilities between Members
-are dealt with by internal dispute resolution,
-which rules on liability and any limits.
-See
-<a href="#9.13">§9.13</a>.
-</p>
-
-
-<h3><a name="p9.9" id="p9.9">9.9. Indemnities</a></h3>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p9.10" id="p9.10">9.10. Term and termination</a></h3>
-<h4><a name="p9.10.1" id="p9.10.1">9.10.1. Term</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.10.2" id="p9.10.2">9.10.2. Termination</a></h4>
-
-<p>
-Members file a dispute to terminate their agreement.
-See <a href="#p9.13">§9.13</a> and CCA 3.3
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html#3.3">COD9</a>).
-</p>
-
-<p>
-Documents are varied (including terminated) under <a href="http://www.cacert.org/policy/PolicyOnPolicy.html">COD1</a>.
-</p>
-
-<p>
-For termination of the CA, see <a href="#p5.8.1">§5.8.1</a>.
-</p>
-
-<h4><a name="p9.10.3" id="p9.10.3">9.10.3. Effect of termination and survival</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p9.11" id="p9.11">9.11. Individual notices and communications with participants</a></h3>
-
-<p>
-All participants are obliged to keep their listed
-primary email addresses in good working order.
-See CCA 3.5
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html#3.5">COD9</a>).
-</p>
-
-
-<h3><a name="p9.12" id="p9.12">9.12. Amendments</a></h3>
-
-<p>
-Amendments to the CPS are controlled by <a href="http://www.cacert.org/policy/PolicyOnPolicy.html">COD1</a>.
-Any changes in Member's Agreements are notified under CCA 3.4
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html#3.4">COD9</a>).
-</p>
-
-<h3><a name="p9.13" id="p9.13">9.13. Dispute resolution provisions</a></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="http://www.cacert.org/policy/DisputeResolutionPolicy.html">COD7</a>)
- includes rules for dispute resolution.
- </li><li>
- Filing is done via email to
- < support AT cacert DOT org >
-</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>
-
-
-<h3><a name="p9.14" id="p9.14">9.14. Governing law</a></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>
-
-<h3><a name="p9.15" id="p9.15">9.15. Compliance with Applicable Law</a></h3>
-
-<h3><a name="p9.15.1" id="p9.15.1">9.15.1 Digital Signature Law</a></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">§1.4.3</a>.
-However, certificates may play a part in larger signing
-applications. See <a href="#p1.4.1">§1.4.1</a> for "digital signing" certificates.
-These applications may impose significant
-obligations, risks and liabilities on the parties.
-</p>
-
-<h3><a name="p9.15.2" id="p9.15.2">9.15.2 Privacy Law</a></h3>
-
-<p>
-See the Privacy Policy
-(<a href="PrivacyPolicy.html">COD5</a>).
-</p>
-
-<h3><a name="p9.15.3" id="p9.15.3">9.15.3 Legal Process from External Forums</a></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">§9.13</a>
-and
-<a href="http://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>
-
-<h3><a name="p9.16" id="p9.16">9.16. Miscellaneous provisions</a></h3>
-<h4><a name="p9.16.1" id="p9.16.1">9.16.1. Entire agreement</a></h4>
-
-<p>
-All Members of the Community agree to the
-CAcert Community Agreement
-(<a href="http://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="http://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.
-</p>
-
-<h4><a name="p9.16.2" id="p9.16.2">9.16.2. Assignment</a></h4>
-
-<p>
-The rights within CCA may not be ordinarily assigned.
-</p>
-
-<h4><a name="p9.16.3" id="p9.16.3">9.16.3. Severability</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.16.4" id="p9.16.4">9.16.4. Enforcement (attorneys' fees and waiver of rights)</a></h4>
-
-<p>
-The Arbitrator will specify fees and remedies, if any.
-</p>
-
-<h4><a name="p9.16.5" id="p9.16.5">9.16.5. Force Majeure</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h2>---This is the end of the Policy---</h2>
-
-
-</body>
-</html>
projects / gigi.git / blobdiff