e2de6e8f7e
"Rename _all_ Policies from .php to .html and fix all links (was: Rename PolicyOnPolicy.php to .html)"
4698 lines
110 KiB
HTML
4698 lines
110 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
|
|
<title>Certification Practice Statement (CPS)</title>
|
|
<style type="text/css">
|
|
<!--
|
|
body {
|
|
font-family : verdana, helvetica, arial, sans-serif;
|
|
}
|
|
.comment {
|
|
color : steelblue;
|
|
}
|
|
.figure {
|
|
text-align : center;
|
|
color : gray;
|
|
margin-top : 0.5em;
|
|
}
|
|
|
|
a:hover {
|
|
color : gray;
|
|
}
|
|
-->
|
|
</style>
|
|
</head>
|
|
<body>
|
|
|
|
<h1>CAcert CPS and CP</h1>
|
|
<div class="comment">
|
|
<table width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="2">
|
|
Name: CPS <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD6</a>
|
|
<br>
|
|
Creation Date : 20060726, drafted at 20091108
|
|
<br>
|
|
Editor: NN
|
|
<br>
|
|
Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
|
|
<br>
|
|
Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © 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" valign="top">
|
|
<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
|
|
<img src="images/cacert-policy.png" alt="CPS Status - POLICY" style="border-style: none;" height="31" width="88">
|
|
</a>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
|
|
<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 id="p1">1. INTRODUCTION</h2>
|
|
|
|
<h3 id="p1.1">1.1. Overview</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 id="p1.2">1.2. Document name and identification</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>)
|
|
|
|
</li>
|
|
|
|
<li>
|
|
© CAcert Inc. 2006-2009.
|
|
<!-- note that CCS policies must be controlled by CAcert Inc. -->
|
|
</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>
|
|
</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 id="p1.3">1.3. PKI participants</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.php">
|
|
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 id="p1.3.1">1.3.1. Certification authorities</h4>
|
|
<p>
|
|
CAcert does not issue certificates to external
|
|
intermediate CAs under the present CPS.
|
|
</p>
|
|
|
|
<h4 id="p1.3.2">1.3.2. Registration authorities</h4>
|
|
<p>
|
|
Registration Authorities (RAs) are controlled under Assurance Policy
|
|
(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
|
|
</p>
|
|
|
|
<h4 id="p1.3.3">1.3.3. Subscribers</h4>
|
|
|
|
<p>
|
|
CAcert issues certificates to Members only.
|
|
Such Members then become Subscribers.
|
|
</p>
|
|
|
|
|
|
<h4 id="p1.3.4">1.3.4. Relying parties</h4>
|
|
|
|
<p>
|
|
A relying party is a Member,
|
|
having agreed to the
|
|
CAcert Community Agreement
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
|
|
who, in the act of using a CAcert certificate,
|
|
makes a decision on the basis of that certificate.
|
|
</p>
|
|
|
|
<h4 id="p1.3.5">1.3.5. Other participants</h4>
|
|
|
|
<p>
|
|
<b>Member.</b>
|
|
Membership of the Community is as defined in the
|
|
<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">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.php">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.
|
|
</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.php">COD4</a>).
|
|
No other rights nor relationship is implied or offered.
|
|
</p>
|
|
|
|
|
|
<h3 id="p1.4">1.4. Certificate usage</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">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</table>
|
|
|
|
<span class="figure">Table 1.4. Types of Certificate</span>
|
|
</center>
|
|
|
|
<h4 id="p1.4.1">1.4.1. Appropriate certificate uses</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 id="p1.4.2">1.4.2. Prohibited certificate uses</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 id="p1.4.3">1.4.3. Unreliable Applications</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>
|
|
|
|
|
|
<h4 id="p1.4.4">1.4.4. Limited certificate uses</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 id="p1.4.5">1.4.5. Roots and Names</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 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">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</table>
|
|
|
|
<span class="figure">Table 1.4.5.b Certificate under Audit Roots</span>
|
|
</center>
|
|
|
|
<center>
|
|
<table border="1" cellpadding="5">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</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>
|
|
|
|
<h3 id="p1.5">1.5. Policy administration</h3>
|
|
|
|
<p>See <a href="#p1.2">1.2 Document Name and Identification</a>
|
|
for general scope of this document.</p>
|
|
|
|
<h4 id="p1.5.1">1.5.1. Organization administering the document</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.php">COD1</a>).
|
|
</p>
|
|
|
|
<h4 id="p1.5.2">1.5.2. Contact person</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 id="p1.5.3">1.5.3. Person determining CPS suitability for the policy</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 id="p1.5.4">1.5.4. CPS approval procedures</h4>
|
|
<p>
|
|
CPS is controlled and updated according to the
|
|
Policy on Policy
|
|
(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">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 id="p1.5.5">1.5.5. CPS updates</h4>
|
|
|
|
<p>
|
|
As per above.
|
|
</p>
|
|
|
|
|
|
<h3 id="p1.6">1.6. Definitions and acronyms</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.php">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.php">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></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.php">COD13</a>),
|
|
to describe a name of a Member
|
|
that is verified by the Assurance process.
|
|
</p>
|
|
<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.php">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.
|
|
</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>
|
|
<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 id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</h2>
|
|
|
|
|
|
<h3 id="p2.1">2.1. Repositories</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.php">COD13</a>),
|
|
there are means for Members to search, retrieve
|
|
and verify certain data about themselves and others.
|
|
</p>
|
|
|
|
<h3 id="p2.2">2.2. Publication of certification information</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 id="p2.3">2.3. Time or frequency of publication</h3>
|
|
|
|
<p>
|
|
Root and Intermediate Certificates and CRLs are
|
|
made available on issuance.
|
|
</p>
|
|
|
|
<h3 id="p2.4">2.4. Access controls on repositories</h3>
|
|
<p> No stipulation. </p>
|
|
|
|
|
|
|
|
<!-- *************************************************************** -->
|
|
<h2 id="p3">3. IDENTIFICATION AND AUTHENTICATION</h2>
|
|
|
|
<h3 id="p3.1">3.1. Naming</h3>
|
|
|
|
<h4 id="p3.1.1">3.1.1. Types of names</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.
|
|
|
|
</li>
|
|
<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
|
|
.2.1.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>
|
|
</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.
|
|
</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 id="p3.1.2">3.1.2. Need for names to be meaningful</h4>
|
|
|
|
<p>
|
|
Each Member's Name (<tt>CN=</tt> field)
|
|
is assured under the Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">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>
|
|
|
|
<h4 id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</h4>
|
|
|
|
<p>
|
|
See <a href="#p1.4.5">§1.4.5</a>.
|
|
</p>
|
|
|
|
<h4 id="p3.1.4">3.1.4. Rules for interpreting various name forms</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 id="p3.1.5">3.1.5. Uniqueness of names</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.php">COD13</a>).
|
|
</p>
|
|
|
|
<p>
|
|
Domain names and email address
|
|
can only be registered to one Member.
|
|
</p>
|
|
|
|
<h4 id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</h4>
|
|
|
|
<p>
|
|
Organisation Assurance Policy
|
|
(<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">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 id="p3.1.7">3.1.7. International Domain Names</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></p>
|
|
|
|
<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>
|
|
<tbody>
|
|
|
|
<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>
|
|
|
|
</tbody>
|
|
</table>
|
|
<p></p>
|
|
|
|
<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 id="p3.2">3.2. Initial Identity Verification</h3>
|
|
|
|
<p>
|
|
Identity verification is controlled by the
|
|
<a href="https://www.cacert.org/policy/AssurancePolicy.html">
|
|
Assurance Policy</a> (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
|
|
The reader is refered to the Assurance Policy,
|
|
the following is representative and brief only.
|
|
</p>
|
|
|
|
|
|
<h4 id="p3.2.1">3.2.1. Method to prove possession of private key</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 id="p3.2.2">3.2.2. Authentication of Individual Identity</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.php">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.php">COD13</a>).
|
|
</p>
|
|
|
|
<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">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</table>
|
|
|
|
<span class="figure">Table 3.2.b - How Assurance Points are used in Certificates</span>
|
|
|
|
</center>
|
|
<br>
|
|
|
|
|
|
|
|
<h4 id="p3.2.3">3.2.3. Authentication of organization identity</h4>
|
|
|
|
|
|
<p>
|
|
Verification of organisations is delegated by
|
|
the Assurance Policy to the
|
|
Organisation Assurance Policy
|
|
(<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">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.php">COD9</a>),
|
|
and is therefore subject to Arbitration.
|
|
</li>
|
|
</ol>
|
|
|
|
<h4 id="p3.2.4">3.2.4. Non-verified subscriber information</h4>
|
|
|
|
<p>
|
|
All information in the certificate is verified,
|
|
see Relying Party Statement, §4.5.2.
|
|
</p>
|
|
|
|
|
|
<h4 id="p3.2.5">3.2.5. Validation of authority</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.php">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 id="p3.2.6">3.2.6. Criteria for interoperation</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 id="p3.3">3.3. Re-key Requests</h3>
|
|
|
|
<p>
|
|
Via the Member's account.
|
|
</p>
|
|
|
|
<h3 id="p3.4">3.4. Revocations Requests</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 id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</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></p>
|
|
|
|
<p>
|
|
(Some steps are not applicable, such as anonymous certificates.)
|
|
</p>
|
|
|
|
|
|
<h3 id="p4.1">4.1. Certificate Application</h3>
|
|
|
|
<h4 id="p4.1.1">4.1.1. Who can submit a certificate application</h4>
|
|
|
|
<p>
|
|
Members may submit certificate applications.
|
|
On issuance of certificates, Members become Subscribers.
|
|
</p>
|
|
|
|
<h4 id="p4.1.2">4.1.2. Adding Addresses</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>
|
|
<p></p>
|
|
|
|
<h4 id="p4.1.3">4.1.3. Preparing CSR </h4>
|
|
|
|
<p>
|
|
Members generate their own key-pairs.
|
|
The CAcert Community Agreement
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">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 id="p4.2">4.2. Certificate application processing</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 id="p4.2.1">4.2.1. Authentication </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 id="p4.2.2">4.2.2. Verifying Control</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>
|
|
<p></p>
|
|
|
|
|
|
|
|
<h4 id="p4.2.3">4.2.3. Options Available</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 id="p4.2.4">4.2.4. Client Certificate Procedures</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>
|
|
<p></p>
|
|
|
|
<h4 id="p4.2.5">4.2.5. Server Certificate Procedures</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>
|
|
|
|
<p></p>
|
|
|
|
<h4 id="p4.2.6">4.2.6. Code-signing Certificate Procedures</h4>
|
|
|
|
<p>
|
|
Code-signing certificates are made available to Assurers only.
|
|
They are processed in a similar manner to client certificates.
|
|
</p>
|
|
|
|
<h4 id="p4.2.7">4.2.7. Organisation Domain Verification</h4>
|
|
|
|
<p>
|
|
Organisation Domains are handled under the Organisation Assurance Policy
|
|
and the Organisation Handbook.
|
|
</p>
|
|
|
|
<h3 id="p4.3">4.3. Certificate issuance</h3>
|
|
|
|
|
|
<h4 id="p4.3.1">4.3.1. CA actions during certificate issuance</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 valign="top" align="center" border="1" 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 id="p4.3.2">4.3.2. Notification to subscriber by the CA of issuance of certificate</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 id="p4.4">4.4. Certificate acceptance</h3>
|
|
|
|
<h4 id="p4.4.1">4.4.1. Conduct constituting certificate acceptance</h4>
|
|
|
|
<p>
|
|
There is no need for the Member to explicitly accept the certificate.
|
|
In case the Member does not accept the certificate,
|
|
the certificate has to be revoked and made again.
|
|
</p>
|
|
|
|
<h4 id="p4.4.2">4.4.2. Publication of the certificate by the CA</h4>
|
|
|
|
<p>
|
|
CAcert does not currently publish the issued certificates
|
|
in any repository.
|
|
In the event that CAcert will run a repository,
|
|
the publication of certificates and signatures
|
|
there will be at the Member's options.
|
|
However note that certificates that are issued
|
|
and delivered to the Member are presumed to be
|
|
published. See §2.2.
|
|
</p>
|
|
|
|
<h4 id="p4.4.3">4.4.3. Notification of certificate issuance by the CA to other entities</h4>
|
|
|
|
<p>
|
|
There are no external entities that are notified about issued certificates.
|
|
</p>
|
|
|
|
<h3 id="p4.5">4.5. Key pair and certificate usage</h3>
|
|
|
|
<p>
|
|
All Members (subscribers and relying parties)
|
|
are obliged according to the
|
|
CAcert Community Agreement
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
|
|
See especially 2.3 through 2.5.
|
|
</p>
|
|
<h4 id="p4.5.1">4.5.1. Subscriber Usage and Responsibilities</h4>
|
|
|
|
<p>
|
|
Subscribers should use keys only for their proper purpose,
|
|
as indicated by the certificate, or by wider agreement with
|
|
others.
|
|
</p>
|
|
|
|
<h4 id="p4.5.2">4.5.2. Relying Party Usage and Responsibilities</h4>
|
|
|
|
|
|
<p>
|
|
Relying parties (Members) may rely on the following.
|
|
</p>
|
|
|
|
<center>
|
|
|
|
<table border="1" cellpadding="25">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
|
|
<p align="center">
|
|
<big><b>Relying Party Statement</b></big>
|
|
</p>
|
|
<p>
|
|
Certificates are issued to Members only.
|
|
<br>
|
|
|
|
<br>
|
|
All information in a certificate is verified.
|
|
</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</center>
|
|
|
|
|
|
<p>
|
|
The following notes are in addition to the Relying Party Statement,
|
|
and can be seen as limitations on it.
|
|
</p>
|
|
|
|
<h5 id="p4.5.2.1">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">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h5 id="p4.5.2.2">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.php">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
|
|
they agree to dispute resolution
|
|
within CAcert's forum.
|
|
</p>
|
|
|
|
<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.php">COD4</a>).
|
|
</p>
|
|
|
|
<h5 id="p4.5.2.3">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 id="p4.5.2.4">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">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</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 id="p4.5.2.5">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>.
|
|
|
|
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>
|
|
|
|
<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 id="p4.6">4.6. Certificate renewal</h3>
|
|
|
|
<p>
|
|
A certificate can be renewed at any time.
|
|
The procedure of certificate renewal is the same
|
|
as for the initial certificate issuance.
|
|
</p>
|
|
|
|
<h3 id="p4.7">4.7. Certificate re-key</h3>
|
|
|
|
<p>
|
|
Certificate "re-keyings" are not offered nor supported.
|
|
A new certificate with a new key has to be requested and issued instead,
|
|
and the old one revoked.
|
|
</p>
|
|
|
|
<h3 id="p4.8">4.8. Certificate modification</h3>
|
|
|
|
<p>
|
|
Certificate "modifications" are not offered nor supported.
|
|
A new certificate has to be requested and issued instead.
|
|
</p>
|
|
|
|
<h3 id="p4.9">4.9. Certificate revocation and suspension</h3>
|
|
|
|
<h4 id="p4.9.1">4.9.1. Circumstances for revocation</h4>
|
|
<p>
|
|
Certificates may be revoked under the following circumstances:
|
|
</p>
|
|
|
|
<ol>
|
|
<li>
|
|
As initiated by the Subscriber through her online account.
|
|
</li>
|
|
<li>
|
|
As initiated in an emergency action by a
|
|
support team member.
|
|
Such action will immediately be referred to dispute resolution
|
|
for ratification.
|
|
</li>
|
|
<li>
|
|
Under direction from the Arbitrator in a duly ordered ruling
|
|
from a filed dispute.
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
These are the only three circumstances under which a
|
|
revocation occurs.
|
|
</p>
|
|
|
|
<h4 id="p4.9.2">4.9.2. Who can request revocation</h4>
|
|
|
|
<p>
|
|
As above.
|
|
</p>
|
|
|
|
<h4 id="p4.9.3">4.9.3. Procedure for revocation request</h4>
|
|
<p>
|
|
The Subscriber logs in to her online account through
|
|
the website at http://www.cacert.org/ .
|
|
</p>
|
|
|
|
<p>
|
|
In any other event such as lost passwords or fraud,
|
|
a dispute should be filed
|
|
by email at
|
|
< support AT cacert DOT org >
|
|
</p>
|
|
|
|
<h4 id="p4.9.4">4.9.4. Revocation request grace period</h4>
|
|
|
|
<p>No stipulation.</p>
|
|
|
|
<h4 id="p4.9.5">4.9.5. Time within which CA must process the revocation request</h4>
|
|
|
|
<p>
|
|
The revocation automated in the Web Interface for subscribers,
|
|
and is handled generally in less than a minute.
|
|
</p>
|
|
|
|
<p>
|
|
A filed dispute that requests a revocation should be handled
|
|
within a five business days, however the Arbitrator has discretion.
|
|
</p>
|
|
|
|
<h4 id="p4.9.6">4.9.6. Revocation checking requirement for relying parties</h4>
|
|
|
|
<p>
|
|
Each revoked certificate is recorded in the
|
|
certificate revocation list (CRL).
|
|
Relying Parties must check a certificate against
|
|
the most recent CRL issued, in order to validate
|
|
the certificate for the intended reliance.
|
|
</p>
|
|
|
|
<h4 id="p4.9.7">4.9.7. CRL issuance frequency (if applicable)</h4>
|
|
|
|
<p>
|
|
A new CRL is issued after every certificate revocation.
|
|
</p>
|
|
|
|
<h4 id="p4.9.8">4.9.8. Maximum latency for CRLs (if applicable)</h4>
|
|
|
|
<p>
|
|
The maximum latency between revocation and issuance of the CRL is 1 hour.
|
|
</p>
|
|
|
|
<h4 id="p4.9.9">4.9.9. On-line revocation/status checking availability</h4>
|
|
|
|
<p>
|
|
OCSP is available at
|
|
http://ocsp.cacert.org/ .
|
|
</p>
|
|
|
|
<h4 id="p4.9.10">4.9.10. On-line revocation checking requirements</h4>
|
|
<p>
|
|
Relying parties must check up-to-date status before relying.
|
|
</p>
|
|
|
|
<h4 id="p4.9.11">4.9.11. Other forms of revocation advertisements available</h4>
|
|
<p>
|
|
None.
|
|
</p>
|
|
|
|
<h4 id="p4.9.12">4.9.12. Special requirements re key compromise</h4>
|
|
<p>
|
|
Subscribers are obliged to revoke certificates at the earliest opportunity.
|
|
</p>
|
|
|
|
<h4 id="p4.9.13">4.9.13. Circumstances for suspension</h4>
|
|
|
|
<p>
|
|
Suspension of certificates is not available.
|
|
</p>
|
|
|
|
<h4 id="p4.9.14">4.9.14. Who can request suspension</h4>
|
|
<p>
|
|
Not applicable.
|
|
</p>
|
|
|
|
<h4 id="p4.9.15">4.9.15. Procedure for suspension request</h4>
|
|
<p>
|
|
Not applicable.
|
|
</p>
|
|
|
|
<h4 id="p4.9.16">4.9.16. Limits on suspension period</h4>
|
|
<p>
|
|
Not applicable.
|
|
</p>
|
|
|
|
|
|
|
|
<h3 id="p4.10">4.10. Certificate status services</h3>
|
|
|
|
<h4 id="p4.10.1">4.10.1. Operational characteristics</h4>
|
|
<p>
|
|
OCSP is available
|
|
at http://ocsp.cacert.org/ .
|
|
</p>
|
|
|
|
<h4 id="p4.10.2">4.10.2. Service availability</h4>
|
|
|
|
<p>
|
|
OCSP is made available on an experimental basis.
|
|
</p>
|
|
|
|
<h4 id="p4.10.3">4.10.3. Optional features</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h3 id="p4.11">4.11. End of subscription</h3>
|
|
|
|
<p>
|
|
Certificates include expiry dates.
|
|
</p>
|
|
|
|
<h3 id="p4.12">4.12. Key escrow and recovery</h3>
|
|
|
|
<h4 id="p4.12.1">4.12.1. Key escrow and recovery policy and practices</h4>
|
|
|
|
<p>
|
|
CAcert does not generate nor escrow subscriber keys.
|
|
</p>
|
|
|
|
<h4 id="p4.12.2">4.12.2. Session key encapsulation and recovery policy and practices</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
|
|
|
|
<!-- *************************************************************** -->
|
|
<h2 id="p5">5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</h2>
|
|
|
|
<!-- <a href="http://xkcd.com/87/">
|
|
<img align="right" src="http://imgs.xkcd.com/comics/velociraptors.jpg">
|
|
</a> -->
|
|
|
|
<h3 id="p5.1">5.1. Physical controls</h3>
|
|
|
|
<p>
|
|
Refer to Security Policy (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
Site location and construction - SP2.1
|
|
</li>
|
|
<li>
|
|
Physical access - SP2.3
|
|
</li>
|
|
</ul>
|
|
<p></p>
|
|
|
|
|
|
<h4 id="p5.1.1">5.1.1. Power and air conditioning</h4>
|
|
<p>
|
|
Refer to Security Policy 2.1.2 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
|
|
</p>
|
|
<h4 id="p5.1.2">5.1.2. Water exposures</h4>
|
|
<p>
|
|
Refer to Security Policy 2.1.4 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
|
|
</p>
|
|
<h4 id="p5.1.3">5.1.3. Fire prevention and protection</h4>
|
|
<p>
|
|
Refer to Security Policy 2.1.4 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
|
|
</p>
|
|
<h4 id="p5.1.4">5.1.4. Media storage</h4>
|
|
<p>
|
|
Refer to Security Policy 4.3 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
|
|
</p>
|
|
<h4 id="p5.1.5">5.1.5. Waste disposal</h4>
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
<h4 id="p5.1.6">5.1.6. Off-site backup</h4>
|
|
<p>
|
|
Refer to Security Policy 4.3 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
|
|
</p>
|
|
|
|
<h3 id="p5.2">5.2. Procedural controls</h3>
|
|
|
|
<h4 id="p5.2.1">5.2.1. Trusted roles</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://www.cacert.org/policy/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.php">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 id="p5.2.2">5.2.2. Number of persons required per task</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 id="p5.2.3">5.2.3. Identification and authentication for each role</h4>
|
|
|
|
<p>
|
|
All important roles are generally required to be assured
|
|
at least to the level of Assurer, as per AP.
|
|
Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
|
|
</p>
|
|
|
|
<p>
|
|
<b>Technical.</b>
|
|
Refer to Security Policy 9.1 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
|
|
</p>
|
|
|
|
<h4 id="p5.2.4">5.2.4. Roles requiring separation of duties</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 id="p5.3">5.3. Personnel controls</h3>
|
|
|
|
<h4 id="p5.3.1">5.3.1. Qualifications, experience, and clearance requirements</h4>
|
|
|
|
<center>
|
|
<table border="1" cellpadding="5">
|
|
<tbody>
|
|
<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.php"> 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.php">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.php">COD7</a></td>
|
|
|
|
<td>
|
|
Experienced Assurers.
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<span class="figure">Table 5.3.1. Controls on Roles</span>
|
|
</center>
|
|
|
|
|
|
<h4 id="p5.3.2">5.3.2. Background check procedures</h4>
|
|
|
|
<p>
|
|
Refer to Security Policy 9.1.3 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
|
|
</p>
|
|
|
|
<h4 id="p5.3.3">5.3.3. Training requirements</h4>
|
|
<p>No stipulation.</p>
|
|
<h4 id="p5.3.4">5.3.4. Retraining frequency and requirements</h4>
|
|
<p>No stipulation.</p>
|
|
|
|
<h4 id="p5.3.5">5.3.5. Job rotation frequency and sequence</h4>
|
|
<p>No stipulation.</p>
|
|
|
|
<h4 id="p5.3.6">5.3.6. Sanctions for unauthorized actions</h4>
|
|
<p>
|
|
Any actions that are questionable
|
|
- whether uncertain or grossly negligent -
|
|
may be filed as a dispute.
|
|
The Arbitrator has wide discretion in
|
|
ruling on loss of points, retraining,
|
|
or termination of access or status.
|
|
Refer to DRP.
|
|
</p>
|
|
|
|
<h4 id="p5.3.7">5.3.7. Independent contractor requirements</h4>
|
|
<p>No stipulation.</p>
|
|
|
|
<h4 id="p5.3.8">5.3.8. Documentation supplied to personnel</h4>
|
|
<p>No stipulation.</p>
|
|
|
|
<h3 id="p5.4">5.4. Audit logging procedures</h3>
|
|
|
|
<p>
|
|
Refer to Security Policy 4.2, 5 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
|
|
</p>
|
|
|
|
<h3 id="p5.5">5.5. Records archival</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">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</table>
|
|
|
|
<span class="figure">Table 5.5. Documents and Retention </span>
|
|
</center>
|
|
|
|
|
|
<h3 id="p5.6">5.6. Key changeover</h3>
|
|
|
|
<p>
|
|
Refer to Security Policy 9.2 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
|
|
</p>
|
|
|
|
<h3 id="p5.7">5.7. Compromise and disaster recovery</h3>
|
|
|
|
<p>
|
|
Refer to Security Policy 5, 6 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
|
|
(Refer to <a href="#p1.4">§1.4</a> for limitations to service.)
|
|
</p>
|
|
|
|
<p></p>
|
|
|
|
<h3 id="p5.8">5.8. CA or RA termination</h3>
|
|
|
|
<h4 id="p5.8.1">5.8.1. CA termination</h4>
|
|
|
|
<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>
|
|
|
|
|
|
<h4 id="p5.8.2">5.8.2. RA termination</h4>
|
|
|
|
<p>
|
|
When an Assurer desires to voluntarily terminates
|
|
her responsibilities, she does this by filing a dispute,
|
|
and following the instructions of the Arbitrator.
|
|
</p>
|
|
|
|
<p>
|
|
In the case of involuntary termination, the process is
|
|
the same, save for some other party filing the dispute.
|
|
</p>
|
|
|
|
|
|
<!-- *************************************************************** -->
|
|
<h2 id="p6">6. TECHNICAL SECURITY CONTROLS</h2>
|
|
|
|
<h3 id="p6.1">6.1. Key Pair Generation and Installation</h3>
|
|
|
|
<h4 id="p6.1.1">6.1.1. Key Pair Generation</h4>
|
|
|
|
<p>
|
|
Subscribers generate their own Key Pairs.
|
|
</p>
|
|
|
|
<h4 id="p6.1.2">6.1.2. Subscriber Private key security</h4>
|
|
|
|
<p>
|
|
There is no technical stipulation on how Subscribers generate
|
|
and keep safe their private keys,
|
|
however, CCA 2.5 provides for general security obligations.
|
|
See <a href="#p9.6">§9.6</a>.
|
|
</p>
|
|
|
|
<h4 id="p6.1.3">6.1.3. Public Key Delivery to Certificate Issuer</h4>
|
|
|
|
<p>
|
|
Members login to their online account.
|
|
Public Keys are delivered by cut-and-pasting
|
|
them into the appropriate window.
|
|
Public Keys are delivered in signed-CSR form
|
|
for X.509 and in self-signed form for OpenPGP.
|
|
</p>
|
|
|
|
<h4 id="p6.1.4">6.1.4. CA Public Key delivery to Relying Parties</h4>
|
|
|
|
<p>
|
|
The CA root certificates are distributed by these means:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
Published on the website of CAcert,
|
|
in both HTTP and HTTPS.
|
|
</li>
|
|
<li>
|
|
Included in Third-Party Software such as
|
|
Browsers, Email-Clients.
|
|
Such suppliers are subject to the Third Party Vendor Agreement.
|
|
</li>
|
|
</ul>
|
|
|
|
<h4 id="p6.1.5">6.1.5. Key sizes</h4>
|
|
|
|
<p>
|
|
No limitation is placed on Subscriber key sizes.
|
|
</p>
|
|
|
|
<p>
|
|
CAcert X.509 root and intermediate keys are currently 4096 bits.
|
|
X.509 roots use RSA and sign with the SHA-1 message digest algorithm.
|
|
See <a href="#p4.3.1">§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>
|
|
|
|
|
|
<h4 id="p6.1.6">6.1.6. Public key parameters generation and quality checking</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p6.1.7">6.1.7. Key Usage Purposes</h4>
|
|
|
|
|
|
<p>
|
|
CAcert roots are general purpose.
|
|
Each root key may sign all of the general purposes
|
|
- client, server, code.
|
|
</p>
|
|
|
|
<p>
|
|
The website controls the usage purposes that may be signed.
|
|
This is effected by means of the 'template' system.
|
|
</p>
|
|
|
|
|
|
<h3 id="p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</h3>
|
|
|
|
|
|
|
|
|
|
<h4 id="p6.2.1">6.2.1. Cryptographic module standards and controls</h4>
|
|
|
|
<p>
|
|
SubRoot keys are stored on a single machine which acts
|
|
as a Cryptographic Module, or <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>
|
|
|
|
|
|
<h3 id="p6.3">6.3. Other aspects of key pair management</h3>
|
|
<h4 id="p6.3.1">6.3.1. Public key archival</h4>
|
|
|
|
<p>
|
|
Subscriber certificates, including public keys,
|
|
are stored in the database backing the online system.
|
|
They are not made available in a public- or subscriber-accessible
|
|
archive, see §2.
|
|
They are backed-up by CAcert's normal backup procedure,
|
|
but their availability is a subscriber responsibility.
|
|
</p>
|
|
|
|
<h4 id="p6.3.2">6.3.2. Certificate operational periods and key pair usage periods</h4>
|
|
|
|
<p>
|
|
The operational period of a certificate and its key pair
|
|
depends on the Assurance status of the Member,
|
|
see <a href="#p1.4.5">§1.4.5</a> and Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">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 id="p6.4">6.4. Activation data</h3>
|
|
<p> No stipulation. </p>
|
|
|
|
<h3 id="p6.5">6.5. Computer security controls</h3>
|
|
<p>
|
|
Refer to Security Policy.
|
|
</p>
|
|
|
|
<h3 id="p6.6">6.6. Life cycle technical controls</h3>
|
|
<p>
|
|
Refer to SM7 "Software Development".
|
|
</p>
|
|
|
|
<h3 id="p6.7">6.7. Network security controls</h3>
|
|
<p>
|
|
Refer to SM3.1 "Logical Security - Network".
|
|
</p>
|
|
|
|
<h3 id="p6.8">6.8. Time-stamping</h3>
|
|
<p>
|
|
Each server synchronises with NTP.
|
|
No "timestamping" service is currently offered.
|
|
</p>
|
|
|
|
<!-- *************************************************************** -->
|
|
<h2 id="p7">CERTIFICATE, CRL, AND OCSP PROFILES</h2>
|
|
|
|
<p>
|
|
CAcert defines all the meanings, semantics and profiles
|
|
applicable to issuance of certificates and signatures
|
|
in its policies, handbooks and other documents.
|
|
Meanings that may be written in external standards or documents
|
|
or found in wider conventions are not
|
|
incorporated, are not used by CAcert, and must not be implied
|
|
by the Member or the Non-related Person.
|
|
</p>
|
|
|
|
<h3 id="p7.1">7.1. Certificate profile</h3>
|
|
<h4 id="p7.1.1">7.1.1. Version number(s)</h4>
|
|
|
|
<p>
|
|
Issued X.509 certificates are of v3 form.
|
|
The form of the PGP signatures depends on several factors, therefore no stipulation.
|
|
</p>
|
|
|
|
<h4 id="p7.1.2">7.1.2. Certificate extensions</h4>
|
|
|
|
<p>
|
|
Client certificates include the following extensions:
|
|
</p>
|
|
<ul>
|
|
|
|
<li>basicConstraints=CA:FALSE (critical)</li>
|
|
|
|
<li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
|
|
|
|
<li>extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC</li>
|
|
|
|
<li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
|
|
|
|
<li>crlDistributionPoints=URI:<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>
|
|
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>
|
|
|
|
<p>
|
|
OpenPGP key signatures currently do not include extensions.
|
|
In the future, a serial number might be included as an extension.
|
|
</p>
|
|
|
|
|
|
<h4 id="p7.1.3">7.1.3. Algorithm object identifiers</h4>
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p7.1.4">7.1.4. Name forms</h4>
|
|
<p>
|
|
Refer to <a href="#p3.1.1">§3.1.1</a>.
|
|
</p>
|
|
|
|
<h4 id="p7.1.5">7.1.5. Name constraints</h4>
|
|
<p>
|
|
Refer to <a href="#p3.1.1">§3.1.1</a>.
|
|
</p>
|
|
|
|
<h4 id="p7.1.6">7.1.6. Certificate policy object identifier</h4>
|
|
<p>
|
|
The following OIDs are defined and should be incorporated
|
|
into certificates:
|
|
</p>
|
|
|
|
<table border="1" cellpadding="5">
|
|
<tbody>
|
|
<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>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>
|
|
Versions are defined by additional numbers appended such as .1.
|
|
</p>
|
|
|
|
<h4 id="p7.1.7">7.1.7. Usage of Policy Constraints extension</h4>
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p7.1.8">7.1.8. Policy qualifiers syntax and semantics</h4>
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p7.1.9">7.1.9. Processing semantics for the critical Certificate Policies extension</h4>
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
|
|
<h3 id="p7.2">7.2. CRL profile</h3>
|
|
<h4 id="p7.2.1">7.2.1. Version number(s)</h4>
|
|
<p>
|
|
CRLs are created in X.509 v2 format.
|
|
</p>
|
|
|
|
<h4 id="p7.2.2">7.2.2. CRL and CRL entry extensions</h4>
|
|
|
|
<p>
|
|
No extensions.
|
|
</p>
|
|
|
|
<h3 id="p7.3">7.3. OCSP profile</h3>
|
|
<h4 id="p7.3.1">7.3.1. Version number(s)</h4>
|
|
<p>
|
|
The OCSP responder operates in Version 1.
|
|
</p>
|
|
<h4 id="p7.3.2">7.3.2. OCSP extensions</h4>
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
|
|
|
|
<!-- *************************************************************** -->
|
|
<h2 id="p8">8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS</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 id="p8.1">8.1. Frequency or circumstances of assessment</h3>
|
|
<p>
|
|
The first audits started in late 2005,
|
|
and since then, assessments have been an
|
|
ongoing task.
|
|
Even when completed, they are expected to
|
|
be permanent features.
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<b>Systems Audit</b>.
|
|
</li>
|
|
<li>
|
|
<b>Code Audit</b>.
|
|
</li>
|
|
</ul>
|
|
|
|
<h3 id="p8.2">8.2. Identity/qualifications of assessor</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>
|
|
|
|
|
|
<p>
|
|
<b>Code Auditors.</b>
|
|
See Security Policy, sections 7, 9.1.
|
|
</p>
|
|
|
|
<h3 id="p8.3">8.3. Assessor's relationship to assessed entity</h3>
|
|
|
|
<p>
|
|
Specific internal restrictions on audit personnel:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
Must be Assured by CAcert Assurers
|
|
and must be background checked.
|
|
</li>
|
|
<li>
|
|
Must not have been active in any (other) role in CAcert.
|
|
Specifically, must not be an Assurer, a member of the association,
|
|
or in any other defined role or office.
|
|
</li>
|
|
<li>
|
|
Although the Auditor may be expected to undertake various
|
|
of the activities (Assurance, Training)
|
|
during the process of the audit, any results are frozen
|
|
until resignation as auditor is effected.
|
|
</li>
|
|
<li>
|
|
The Auditor is required to declare to CAcert all
|
|
potential conflicts of interest on an ongoing basis.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Specific external restrictions on audit personnel:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
Should have a verifiable and lengthy history in
|
|
user privacy and user security.
|
|
</li>
|
|
<li>
|
|
Must not have worked for a competitive organisation.
|
|
</li>
|
|
<li>
|
|
Must not have worked for national security, intelligence,
|
|
LEO or similar agencies.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
An Auditor may convene an audit team.
|
|
The same restrictions apply in general
|
|
to all members of the team, but may be varied.
|
|
Any deviations must be documented and approved
|
|
by the CAcert Inc. Board.
|
|
</p>
|
|
|
|
<h3 id="p8.4">8.4. Topics covered by assessment</h3>
|
|
|
|
<p>
|
|
Systems Audits are generally conducted to criteria.
|
|
CAcert requires that the criteria are open:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
Published.
|
|
The criteria must be reviewable by all interested parties.
|
|
</li>
|
|
<li>
|
|
Understandable.
|
|
They should be understandable, in that they provide the
|
|
sufficient information in a readable form for interested
|
|
parties to follow the gist and importance.
|
|
(Arcane security criteria may stretch this requirement.)
|
|
</li>
|
|
<li>
|
|
Complete.
|
|
There must be sufficent background information that the
|
|
whole story is there. Especially, criteria that refer
|
|
to undocumented practices or conventions deliberately
|
|
kept secret must be avoided.
|
|
</li>
|
|
<li>
|
|
Applicable. The criteria should relate directly
|
|
and unambiguously to a need of the identified interested parties
|
|
(Members, Relying Parties, Subscribers, Assurers).
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
See
|
|
<a href="http://rossde.com/CA_review/">DRC</a>
|
|
for the current criteria.
|
|
If Auditor determines that a criteria fails to
|
|
follow the meet the above requirements, then the criteria
|
|
should be reworked to conform, or should be dropped
|
|
(both with explanatory notes).
|
|
</p>
|
|
|
|
<h3 id="p8.5">8.5. Actions taken as a result of deficiency</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 id="p8.6">8.6. Communication of results</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.php">COD1</a>).
|
|
Audits cover the overall processes more
|
|
than any one document, and documents may vary
|
|
even as Audit reports are delivered.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<!-- *************************************************************** -->
|
|
<h2 id="p9">9. OTHER BUSINESS AND LEGAL MATTERS</h2>
|
|
<h3 id="p9.1">9.1. Fees</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 id="p9.2">9.2. Financial responsibility</h3>
|
|
|
|
<p>
|
|
Financial risks are dealt with primarily by
|
|
the Dispute Resolution Policy
|
|
(<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>).
|
|
</p>
|
|
|
|
<h4 id="p9.2.1">9.2.1. Insurance coverage</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p9.2.2">9.2.2. Other assets</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p9.2.3">9.2.3. Insurance or warranty coverage for end-entities</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h3 id="p9.3">9.3. Confidentiality of business information</h3>
|
|
|
|
<h4 id="p9.3.1">9.3.1. Scope of confidential information</h4>
|
|
|
|
<p>
|
|
CAcert has a policy of transparency and openness.
|
|
The default posture is that information is public
|
|
to the extent possible,
|
|
unless covered by specific policy provisions
|
|
(for example, passwords)
|
|
or rulings by Arbitrator.
|
|
</p>
|
|
|
|
<h3 id="p9.4">9.4. Privacy of personal information</h3>
|
|
|
|
<p>
|
|
Privacy is covered by the
|
|
CCA (COD9)
|
|
and the Privacy Policy
|
|
(<a href="https://www.cacert.org/policy/PrivacyPolicy.html">COD5</a>).
|
|
</p>
|
|
|
|
<h4 id="p9.4.1">9.4.1. Privacy plan</h4>
|
|
<p> No stipulation. </p>
|
|
<h4 id="p9.4.2">9.4.2. Information treated as private</h4>
|
|
<p>
|
|
Member's Date of Birth and "Lost Password" questions are treated as fully private.
|
|
</p>
|
|
<h4 id="p9.4.3">9.4.3. Information not deemed private</h4>
|
|
<p>
|
|
To the extent that information is put into an issued certificate,
|
|
that information is not deemed private,
|
|
as it is expected to be published by the Member as part of routine use of
|
|
the certificate.
|
|
Such information generally includes
|
|
Names, domains, email addresses, and certificate serial numbers.
|
|
</p>
|
|
<p>
|
|
Under Assurance Policy
|
|
(<a href="http://www.cacert.org/policy/AssurancePolicy.php">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 id="p9.4.4">9.4.4. Responsibility to protect private information</h4>
|
|
<p>
|
|
CAcert is a privacy organisation
|
|
and takes privacy more seriously.
|
|
Any privacy issue may be referred to dispute resolution.
|
|
</p>
|
|
<h4 id="p9.4.5">9.4.5. Notice and consent to use private information</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 id="p9.4.6">9.4.6. Disclosure pursuant to judicial or administrative process</h4>
|
|
<p>
|
|
Any disclosure pursuant to process from foreign courts
|
|
(or similar)
|
|
is controlled by the Arbitrator.
|
|
</p>
|
|
<h4 id="p9.4.7">9.4.7. Other information disclosure circumstances</h4>
|
|
<p>
|
|
None.
|
|
</p>
|
|
|
|
<h3 id="p9.5">9.5. Intellectual property rights</h3>
|
|
|
|
<p>
|
|
CAcert is committed to the philosophy of
|
|
an open and free Internet,
|
|
broadly as encapsulated by open and free source.
|
|
However, due to the strict control provisions
|
|
imposed by the audit criteria (CCS),
|
|
and the general environment and role of CAs,
|
|
and the commitment to security of Members,
|
|
some deviations are necessary.
|
|
</p>
|
|
|
|
|
|
<h4 id="p9.5.1">9.5.1. Ownership and Licence</h4>
|
|
|
|
<p>
|
|
Assets that fall under the control of CCS
|
|
must be transferred to CAcert.
|
|
See PoP 6.2
|
|
(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>),
|
|
CCA 1.3
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#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 id="p9.5.2">9.5.2. Brand</h4>
|
|
<p>
|
|
The brand of CAcert
|
|
is made up of its logo, name, trademark, service marks, etc.
|
|
Use of the brand is strictly limited by the Board,
|
|
and permission is required.
|
|
See <a href="http://wiki.cacert.org/wiki/TopMinutes-20070917">
|
|
m20070917.5</a>.
|
|
</p>
|
|
|
|
<h4 id="p9.5.3">9.5.3. Documents</h4>
|
|
|
|
<p>
|
|
CAcert owns or requires full control over its documents,
|
|
especially those covered by CCS.
|
|
See PoP 6.2
|
|
(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>).
|
|
Contributors transfer the rights,
|
|
see CCA 1.3
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#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.php#6.4">COD1</a>),
|
|
CCA 1.3
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
|
|
</p>
|
|
|
|
<h4 id="p9.5.4">9.5.4. Code</h4>
|
|
|
|
<p>
|
|
CAcert owns its code or requires full control over code in use
|
|
by means of a free and open licence.
|
|
See CCS.
|
|
</p>
|
|
|
|
|
|
<p>
|
|
CAcert licenses its code under GPL.
|
|
CAcert extends back to contributors a
|
|
non-exclusive, unrestricted perpetual
|
|
licence, permitting them to to re-use
|
|
their original work freely.
|
|
</p>
|
|
|
|
<h4 id="p9.5.5">9.5.5. Certificates and Roots</h4>
|
|
|
|
<p>
|
|
CAcert asserts its intellectual property rights over certificates
|
|
issued to Members and over roots.
|
|
See CCA 4.4
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#4.4">COD9</a>),
|
|
CCS.
|
|
The certificates may only be used by Members under
|
|
<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#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.php">COD4</a>).
|
|
</p>
|
|
|
|
<h3 id="p9.6">9.6. Representations and warranties</h3>
|
|
|
|
|
|
<p>
|
|
<b>Members.</b>
|
|
All Members of the Community agree to the
|
|
CAcert Community Agreement
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">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.php">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
|
|
|
|
3rd-Party Vendors - Disclaimer and Licence
|
|
(3PV-DaL => CODx)
|
|
and are offered
|
|
|
|
the same deal as Members to the extent that they agree
|
|
to be Members in the Community.
|
|
|
|
</p>
|
|
|
|
<h3 id="p9.7">9.7. Disclaimers of Warranties</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.php">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 id="p9.8">9.8. Limitations of liability</h3>
|
|
|
|
<h3 id="p9.9">9.9. Non-Related Persons </h3>
|
|
|
|
<p>
|
|
CAcert on behalf of related parties
|
|
(RAs, Subscribers, etc) and itself
|
|
disclaims all liability to NRPs
|
|
in their usage of CA's certificates.
|
|
See <a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>.
|
|
</p>
|
|
|
|
<h3 id="p9.10">9.10. Liabilities Between Members</h3>
|
|
|
|
<p>
|
|
Liabilities between Members
|
|
are dealt with by internal dispute resolution,
|
|
which rules on liability and any limits.
|
|
See
|
|
<a href="#9.13">§9.13</a>.
|
|
</p>
|
|
|
|
|
|
<h3 id="p9.11">9.11. Indemnities</h3>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h3 id="p9.12">9.12. Term and termination</h3>
|
|
<h4 id="p9.12.1">9.12.1. Term</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p9.12.2">9.12.2. Termination</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.php#3.3">COD9</a>).
|
|
</p>
|
|
|
|
<p>
|
|
Documents are varied (including terminated) under <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
|
|
</p>
|
|
|
|
<p>
|
|
For termination of the CA, see <a href="#p5.8.1">§5.8.1</a>.
|
|
</p>
|
|
|
|
<h4 id="p9.12.3">9.12.3. Effect of termination and survival</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h3 id="p9.13">9.13. Individual notices and communications with participants</h3>
|
|
|
|
<p>
|
|
All participants are obliged to keep their listed
|
|
primary email addresses in good working order.
|
|
See CCA 3.5
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.5">COD9</a>).
|
|
</p>
|
|
|
|
|
|
<h3 id="p9.14">9.14. Amendments</h3>
|
|
|
|
<p>
|
|
Amendments to the CPS are controlled by <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
|
|
Any changes in Member's Agreements are notified under CCA 3.4
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.4">COD9</a>).
|
|
</p>
|
|
|
|
<h3 id="p9.15">9.15. Dispute resolution provisions</h3>
|
|
|
|
<p>
|
|
CAcert provides a forum and facility for any Member
|
|
or other related party to file a dispute.
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
The CAcert
|
|
Dispute Resolution Policy
|
|
(<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">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 id="p9.16">9.16. Governing law</h3>
|
|
|
|
<p>
|
|
The governing law is that of New South Wales, Australia.
|
|
Disputes are generally heard before the Arbitrator
|
|
under this law.
|
|
Exceptionally, the Arbitrator may elect to apply the
|
|
law of the parties and events, where in common,
|
|
but this is unlikely because it may create results
|
|
that are at odds with the Community.
|
|
</p>
|
|
|
|
<h3 id="p9.17">9.17. Compliance with Applicable Law</h3>
|
|
|
|
<h3 id="p9.18">9.18. Digital Signature Law</h3>
|
|
<p>
|
|
The Commonwealth and States of Australia have passed
|
|
various Electronic Transactions Acts that speak to
|
|
digital signatures. In summary, these acts follow
|
|
the "technology neutral" model and permit but do not
|
|
regulate the use of digital signatures.
|
|
</p>
|
|
|
|
<p>
|
|
This especially means that the signatures created by
|
|
certificates issued by CAcert are not in and of themselves
|
|
legally binding human signatures, at least according to
|
|
the laws of Australia.
|
|
See <a href="#p1.4.3">§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 id="p9.19">9.19. Privacy Law</h3>
|
|
|
|
<p>
|
|
See the Privacy Policy
|
|
(<a href="https://www.cacert.org/policy/PrivacyPolicy.html">COD5</a>).
|
|
</p>
|
|
|
|
<h3 id="p9.20">9.20. Legal Process from External Forums</h3>
|
|
|
|
<p>
|
|
CAcert will provide information about
|
|
its Members only under legal subpoena or
|
|
equivalent process
|
|
from a court of competent jurisdiction.
|
|
Any requests made by legal subpoena are
|
|
treated as under the Dispute Resolution Policy
|
|
See
|
|
<a href="#p9.13">§9.13</a>
|
|
and
|
|
<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">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>
|
|
|
|
</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 id="p9.21">9.21. Miscellaneous provisions</h3>
|
|
<h4 id="p9.21.1">9.21.1. Entire agreement</h4>
|
|
|
|
<p>
|
|
All Members of the Community agree to the
|
|
CAcert Community Agreement
|
|
(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">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 id="p9.21.2">9.21.2. Assignment</h4>
|
|
|
|
<p>
|
|
The rights within CCA may not be ordinarily assigned.
|
|
</p>
|
|
|
|
<h4 id="p9.21.3">9.21.3. Severability</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h4 id="p9.21.4">9.21.4. Enforcement (attorneys' fees and waiver of rights)</h4>
|
|
|
|
<p>
|
|
The Arbitrator will specify fees and remedies, if any.
|
|
</p>
|
|
|
|
<h4 id="p9.21.5">9.21.5. Force Majeure</h4>
|
|
|
|
<p>
|
|
No stipulation.
|
|
</p>
|
|
|
|
<h2 id="p10">---This is the end of the Policy---</h2>
|
|
|
|
|
|
</body>
|
|
</html>
|