You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
cacert-policies/CertificationPracticeStatem...

4146 lines
132 KiB
HTML

<!-- !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<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;
}
.strike {
color : blue;
text-decoration:line-through;
}
a:hover {
color : gray;
}
-->
</style>
</head>
<body>
<p>
<span class="center">
<big>
<br /><b>WARNING:</b><br />
The proper policy document is located<br />
<a href="https://www.cacert.org/policy/CertificationPracticeStatement.html">
on the CAcert website </a>.<br />
</big><br />
This document is a <b>working draft</b> to include<br />
future revisions only, and is currently<br />
only relevant for the [policy] group.<br />
Suggested <span class="change">additions in BLUE</span>, <span class="strike">strikes in blue</span>.<br />
</span>
Michael T&auml;nzer <span class="change">20111113</span>: CPS #7.1.2 "Certificate Extensions" adjustments<br />
Ulrich Schroeter <span class="change">20130309</span>: several minor fixes according to <a href="https://svn.cacert.org/CAcert/Policies/PolicyOnPolicy.html">PoP 2.5</a> and <a href="https://bugs.cacert.org/view.php?id=1131">Bug #1131</a></p>
<ul>
<li><span class="change">20111113</span> changes are still incorporated in the revision on main website but not in the svn revision, so therefor copied over CPS revision from CAcert main website to SVN policy working directory as source of changes</li>
<li>header reformated to reflect new header style</li>
<li>http to https fixes</li>
<li>full url fixes</li>
<li>wiki.cacert.org/wiki/ to wiki.cacert.org/ fixes</li>
<li>wiki redirects to redirected link fixes</li>
<li>img src images/ fixes</li>
<li>.php to .html fixes per <a href="https://bugs.cacert.org/view.php?id=1131">Bug #1131</a></li>
<li>replace all NRP-DaL references with text Root Distribution License and RootDistributionLicense.html link</li>
<li>fix of ~65 html errors and ~14 html warnings</li>
</ul>
<hr />
<table width="100%">
<tr>
<td>Name: CAcert CPS and CP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD6</a><br />
Status: DRAFT&nbsp;<a href="https://wiki.cacert.org/PolicyDecisions#p20091108">p20091108</a>, DRAFT&nbsp;<a href="https://wiki.cacert.org/PolicyDecisions#p20111113">p20111113</a><br />
Caveat: this document is already <a href="https://www.cacert.org/policy/CertificationPracticeStatement.html">on the main website in DRAFT</a>. p20111113.<br />
Creation date: 20060726<br />
Changes: <span class="change">p20111113, 20130309</span><br />
Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP. More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a>
</td>
<td align="right">
<a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-draft.png" alt="CPS Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
</td>
</tr>
</table>
<p><br /></p>
<h1>CAcert CPS and CP</h1>
<!-- $Id: CertificationPracticeStatement.html,v 1.3 2012-07-27 16:00:29 wytze Exp $ -->
<div style="font size:-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&amp;A)</a>
<ul>
<li><a href="#p3.1">3.1. Naming</a> </li>
<li><a href="#p3.2">3.2. Initial Identity Verification</a> </li>
<li><a href="#p3.3">3.3. I&amp;A for Re-key Requests</a> </li>
<li><a href="#p3.4">3.4. I&amp;A for Revocation Request</a></li>
</ul>
</li>
<li><a href="#p4">CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a>
<ul>
<li><a href="#p4.1">4.1. Certificate Application</a> </li>
<li><a href="#p4.2">4.2. Certificate application processing</a> </li>
<li><a href="#p4.3">4.3. Certificate issuance</a> </li>
<li><a href="#p4.4">4.4. Certificate acceptance</a> </li>
<li><a href="#p4.5">4.5. Key pair and certificate usage</a> </li>
<li><a href="#p4.6">4.6. Certificate renewal</a> </li>
<li><a href="#p4.7">4.7. Certificate re-key</a> </li>
<li><a href="#p4.8">4.8. Certificate modification</a> </li>
<li><a href="#p4.9">4.9. Certificate revocation and suspension</a> </li>
<li><a href="#p4.10">4.10. Certificate status services</a> </li>
<li><a href="#p4.11">4.11. End of subscription</a></li>
<li><a href="#p4.12">4.12. Key escrow and recovery</a> </li>
</ul>
</li>
<li><a href="#p5">FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a>
<ul>
<li><a href="#p5.1">5.1. Physical controls</a> </li>
<li><a href="#p5.2">5.2. Procedural controls</a> </li>
<li><a href="#p5.3">5.3. Personnel controls</a> </li>
<li><a href="#p5.4">5.4. Audit logging procedures</a> </li>
<li><a href="#p5.5">5.5. Records archival</a> </li>
<li><a href="#p5.6">5.6. Key changeover</a></li>
<li><a href="#p5.7">5.7. Compromise and disaster recovery</a> </li>
<li><a href="#p5.8">5.8. CA or RA termination</a></li>
</ul>
</li>
<li><a href="#p6">TECHNICAL SECURITY CONTROLS</a>
<ul>
<li><a href="#p6.1">6.1. Key pair generation and installation</a> </li>
<li><a href="#p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a> </li>
<li><a href="#p6.3">6.3. Other aspects of key pair management</a> </li>
<li><a href="#p6.4">6.4. Activation data</a> </li>
<li><a href="#p6.5">6.5. Computer security controls</a> </li>
<li><a href="#p6.6">6.6. Life cycle technical controls</a> </li>
<li><a href="#p6.7">6.7. Network security controls</a></li>
<li><a href="#p6.8">6.8. Time-stamping</a></li>
</ul>
</li>
<li><a href="#p7">CERTIFICATE, CRL, AND OCSP PROFILES</a>
<ul>
<li><a href="#p7.1">7.1. Certificate profile</a> </li>
<li><a href="#p7.2">7.2. CRL profile</a> </li>
<li><a href="#p7.3">7.3. OCSP profile</a> </li>
</ul>
</li>
<li><a href="#p8">COMPLIANCE AUDIT AND OTHER ASSESSMENTS</a>
<ul>
<li><a href="#p8.1">8.1. Frequency or circumstances of assessment</a></li>
<li><a href="#p8.2">8.2. Identity/qualifications of assessor</a></li>
<li><a href="#p8.3">8.3. Assessor's relationship to assessed entity</a></li>
<li><a href="#p8.4">8.4. Topics covered by assessment</a></li>
<li><a href="#p8.5">8.5. Actions taken as a result of deficiency</a></li>
<li><a href="#p8.6">8.6. Communication of results</a></li>
</ul>
</li>
<li><a href="#p9">OTHER BUSINESS AND LEGAL MATTERS</a>
<ul>
<li><a href="#p9.1">9.1. Fees</a> </li>
<li><a href="#p9.2">9.2. Financial responsibility</a> </li>
<li><a href="#p9.3">9.3. Confidentiality of business information</a> </li>
<li><a href="#p9.4">9.4. Privacy of personal information</a> </li>
<li><a href="#p9.5">9.5. Intellectual property rights</a></li>
<li><a href="#p9.6">9.6. Representations and warranties</a> </li>
<li><a href="#p9.7">9.7. Disclaimers of warranties</a></li>
<li><a href="#p9.8">9.8. Limitations of liability</a></li>
<li><a href="#p9.9">9.9. Indemnities</a></li>
<li><a href="#p9.10">9.10. Term and termination</a> </li>
<li><a href="#p9.11">9.11. Individual notices and communications with participants</a></li>
<li><a href="#p9.12">9.12. Amendments</a> </li>
<li><a href="#p9.13">9.13. Dispute resolution provisions</a></li>
<li><a href="#p9.14">9.14. Governing law</a></li>
<li><a href="#p9.15">9.15. Compliance with applicable law</a></li>
<li><a href="#p9.16">9.16. Miscellaneous provisions</a> </li>
</ul>
</li>
</ol>
</div>
<!-- *************************************************************** -->
<h2><a 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><br />
</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>
&copy; CAcert Inc. 2006-2009.
<!-- note that CCS policies must be controlled by CAcert Inc. -->
</li>
<li>
Issued under the CAcert document licence policy,
as and when made policy.
See <a href="https://wiki.cacert.org/PolicyDrafts/DocumentLicence">
PolicyDrafts/DocumentLicence</a>.
<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="https://wiki.cacert.org/CAcertInc">CAcert wiki</a>.
</p>
<p>
CAcert is a Community formed of Members who agree to the
<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">
CAcert Community Agreement</a>.
The CA is technically operated by the Community,
under the direction of the Board of CAcert Incorporated.
(The Members of the Community are not to be confused
with the <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="https://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="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>),
who, in the act of using a CAcert certificate,
makes a decision on the basis of that certificate.
</p>
<h4><a 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="https://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="https://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
Root Distribution License
(<a href="https://www.cacert.org/policy/RootDistributionLicense.html">COD14</a>).
No other rights nor relationship is implied or offered.
</p>
<h3><a 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">&sect;1.4.1</a>.
Prohibited applications are defined in <a href="#p1.4.2">&sect;1.4.2</a>.
Specialist uses may be agreed by contract or within
a specific environment, as described in
<a href="#p1.4.4">&sect;1.4.4</a>.
Note also the
unreliable applications in
<a href="#p1.4.3">&sect;1.4.3</a>
and risks, liabilities and obligations in
<a href="#p9">&sect;9</a>.
</p>
<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">&sect;1.4.3</a>. </td>
</tr>
<tr>
<td> &quot;Digital Signing&quot; </td>
<td> for human signing over documents </td>
<td> Only within a wider application and rules
such as by separate policy,
as agreed by contract, etc.
See <a href="#p1.4.4">&sect;1.4.4</a>.
</td>
</tr>
<tr>
<td><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">&sect;1.4.3</a> for caveat on signatures.)
</li><li>
CAcert client certificates can be used to replace password-based
authentication to web servers.
</li><li>
OpenPGP keys with CAcert signatures can be used
to encrypt and sign files and emails,
using software compatible with OpenPGP.
</li><li>
CAcert client certificates can be used in web-based
authentication applications.
</li><li>
CAcert code signing certificates can be used to sign code
for distribution to other people.
</li><li>
Time stamping can be used to attach a time record
to a digital document.
</li></ul>
<h4><a 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">&sect;9.15.1</a>.
Especially, protocols such as S/MIME commonly will automatically
apply digital signatures as part of their protocol needs.
The purpose of the cryptographic signature in S/MIME
and similar protocols is limited by default to strictly
protocol security purposes:
to provide some confirmation that a familiar certificate
is in use, to enable encryption, and to ensure the integrity
of the email in transit.
</li><li>
<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 &dagger; </center></th>
<th colspan="2"><center> Assured Members</center></th>
<th colspan="1"><center> Assurers </center></th>
<th colspan="1"><center>&nbsp; </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"> &bull; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &bull; </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"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> &dagger; For Members meeting basic checks in <a href="#p4.2.2">&sect;4.2.2</a><br>(Reliance is undefined.) </td>
</tr>
<tr>
<td><center><big><b>Assured</b></big><br>SubRoot</center></td>
<td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </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"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </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>&nbsp; </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"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </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"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
<td> <center> Assured Members only.<br> Intended for Reliance. </center> </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="https://wiki.cacert.org/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="https://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="https://lists.cacert.org/wws/lists">
lists.cacert.org</a> . </li>
<li>Send email to &lt; support AT cacert DOT org &gt; </li>
<li>IRC: irc.cacert.org #CAcert (ssl port 7000, non-ssl port 6667)</li>
</ul>
<h4><a 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="https://www.cacert.org/policy/PolicyOnPolicy.html">COD1</a>)
which is part of
Configuration-Control Specification (COD2).
</p>
<p>
In brief, the policy forum prepares and discusses.
After a last call, the document moves to DRAFT status
for a defined period.
If no challenges have been received in the defined period,
it moves to POLICY status.
The process is modelled after some elements of
the RFC process by the IETF.
</p>
<h4><a 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">&sect;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="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>).
This generally implies having an account registered
at CAcert and making use of CAcert's data, programs or services.
A Member may be an individual ("natural person")
or an organisation (sometimes, "legal person").
</p>
<p>
<b><a name="d_community" id="d_community">Community</a></b>.
The group of Members who agree to the
CAcert Community Agreement
(<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>)
or equivalent agreements.
</p>
<p>
<b><a name="d_unassured" id="d_unassured">Unassured Member</a></b>.
A Member who has not yet been Assured.
<