|
|
<span class="center">
|
|
|
**WARNING:**
|
|
|
The proper policy document is located
|
|
|
[on the CAcert
|
|
|
website](https://www.cacert.org/policy/CertificationPracticeStatement.html)
|
|
|
.
|
|
|
|
|
|
This document is a **working draft** to include
|
|
|
future revisions only, and is currently
|
|
|
only relevant for the \[policy\] group.
|
|
|
Suggested <span class="change">additions in BLUE</span>, <span
|
|
|
class="strike">strikes in blue</span>.
|
|
|
</span> Michael Tänzer <span class="change">20111113</span>: CPS \#7.1.2
|
|
|
"Certificate Extensions" adjustments
|
|
|
Ulrich Schroeter <span class="change">20130309</span>: several minor
|
|
|
fixes according to [PoP
|
|
|
2.5](https://svn.cacert.org/CAcert/Policies/PolicyOnPolicy.html) and
|
|
|
[Bug \#1131](https://bugs.cacert.org/view.php?id=1131)
|
|
|
|
|
|
- <span class="change">20111113</span> changes are still incorporated
|
|
|
in the revision on main website but not in the svn revision, so
|
|
|
therefor copied over CPS revision from CAcert main website to SVN
|
|
|
policy working directory as source of changes
|
|
|
- header reformated to reflect new header style
|
|
|
- http to https fixes
|
|
|
- full url fixes
|
|
|
- wiki.cacert.org/wiki/ to wiki.cacert.org/ fixes
|
|
|
- wiki redirects to redirected link fixes
|
|
|
- img src images/ fixes
|
|
|
- .php to .html fixes per [Bug
|
|
|
\#1131](https://bugs.cacert.org/view.php?id=1131)
|
|
|
- replace all NRP-DaL references with text Root Distribution License
|
|
|
and RootDistributionLicense.html link
|
|
|
- fix of ~65 html errors and ~14 html warnings
|
|
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
|
|
<table width="100%">
|
|
|
<colgroup>
|
|
|
<col style="width: 50%" />
|
|
|
<col style="width: 50%" />
|
|
|
</colgroup>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td>Name: CAcert CPS and CP <a
|
|
|
href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html"
|
|
|
style="color: steelblue">COD6</a><br />
|
|
|
Status: DRAFT <a
|
|
|
href="https://wiki.cacert.org/PolicyDecisions#p20091108">p20091108</a>,
|
|
|
DRAFT <a
|
|
|
href="https://wiki.cacert.org/PolicyDecisions#p20111113">p20111113</a><br />
|
|
|
Caveat: this document is already <a
|
|
|
href="https://www.cacert.org/policy/CertificationPracticeStatement.html">on
|
|
|
the main website in DRAFT</a>. p20111113.<br />
|
|
|
Creation date: 20060726<br />
|
|
|
Changes: <span class="change">p20111113, 20130309</span><br />
|
|
|
Licence: <a href="https://wiki.cacert.org/Policy#Licence"
|
|
|
style="color: steelblue"
|
|
|
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 style="text-align: right;"><a
|
|
|
href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img
|
|
|
src="images/cacert-draft.png" style="border-style: none;" width="88"
|
|
|
height="31" alt="CPS Status - DRAFT" /></a></td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
|
|
# CAcert CPS and CP
|
|
|
|
|
|
<div style="font size:-1;">
|
|
|
|
|
|
1. [INTRODUCTION](#p1)
|
|
|
- [1.1. Overview](#p1.1)
|
|
|
- [1.2. Document name and identification](#p1.2)
|
|
|
- [1.3. PKI participants](#p1.3)
|
|
|
- [1.4. Certificate usage](#p1.4)
|
|
|
- [1.5. Policy administration](#p1.5)
|
|
|
- [1.6. Definitions and acronyms](#p1.6)
|
|
|
2. [PUBLICATION AND REPOSITORY RESPONSIBILITIES](#p2)
|
|
|
- [2.1. Repositories](#p2.1)
|
|
|
- [2.2. Publication of certification information](#p2.2)
|
|
|
- [2.3. Time or frequency of publication](#p2.3)
|
|
|
- [2.4. Access controls on repositories](#p2.4)
|
|
|
3. [IDENTIFICATION AND AUTHENTICATION (I&A)](#p3)
|
|
|
- [3.1. Naming](#p3.1)
|
|
|
- [3.2. Initial Identity Verification](#p3.2)
|
|
|
- [3.3. I&A for Re-key Requests](#p3.3)
|
|
|
- [3.4. I&A for Revocation Request](#p3.4)
|
|
|
4. [CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS](#p4)
|
|
|
- [4.1. Certificate Application](#p4.1)
|
|
|
- [4.2. Certificate application processing](#p4.2)
|
|
|
- [4.3. Certificate issuance](#p4.3)
|
|
|
- [4.4. Certificate acceptance](#p4.4)
|
|
|
- [4.5. Key pair and certificate usage](#p4.5)
|
|
|
- [4.6. Certificate renewal](#p4.6)
|
|
|
- [4.7. Certificate re-key](#p4.7)
|
|
|
- [4.8. Certificate modification](#p4.8)
|
|
|
- [4.9. Certificate revocation and suspension](#p4.9)
|
|
|
- [4.10. Certificate status services](#p4.10)
|
|
|
- [4.11. End of subscription](#p4.11)
|
|
|
- [4.12. Key escrow and recovery](#p4.12)
|
|
|
5. [FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS](#p5)
|
|
|
- [5.1. Physical controls](#p5.1)
|
|
|
- [5.2. Procedural controls](#p5.2)
|
|
|
- [5.3. Personnel controls](#p5.3)
|
|
|
- [5.4. Audit logging procedures](#p5.4)
|
|
|
- [5.5. Records archival](#p5.5)
|
|
|
- [5.6. Key changeover](#p5.6)
|
|
|
- [5.7. Compromise and disaster recovery](#p5.7)
|
|
|
- [5.8. CA or RA termination](#p5.8)
|
|
|
6. [TECHNICAL SECURITY CONTROLS](#p6)
|
|
|
- [6.1. Key pair generation and installation](#p6.1)
|
|
|
- [6.2. Private Key Protection and Cryptographic Module
|
|
|
Engineering Controls](#p6.2)
|
|
|
- [6.3. Other aspects of key pair management](#p6.3)
|
|
|
- [6.4. Activation data](#p6.4)
|
|
|
- [6.5. Computer security controls](#p6.5)
|
|
|
- [6.6. Life cycle technical controls](#p6.6)
|
|
|
- [6.7. Network security controls](#p6.7)
|
|
|
- [6.8. Time-stamping](#p6.8)
|
|
|
7. [CERTIFICATE, CRL, AND OCSP PROFILES](#p7)
|
|
|
- [7.1. Certificate profile](#p7.1)
|
|
|
- [7.2. CRL profile](#p7.2)
|
|
|
- [7.3. OCSP profile](#p7.3)
|
|
|
8. [COMPLIANCE AUDIT AND OTHER ASSESSMENTS](#p8)
|
|
|
- [8.1. Frequency or circumstances of assessment](#p8.1)
|
|
|
- [8.2. Identity/qualifications of assessor](#p8.2)
|
|
|
- [8.3. Assessor's relationship to assessed entity](#p8.3)
|
|
|
- [8.4. Topics covered by assessment](#p8.4)
|
|
|
- [8.5. Actions taken as a result of deficiency](#p8.5)
|
|
|
- [8.6. Communication of results](#p8.6)
|
|
|
9. [OTHER BUSINESS AND LEGAL MATTERS](#p9)
|
|
|
- [9.1. Fees](#p9.1)
|
|
|
- [9.2. Financial responsibility](#p9.2)
|
|
|
- [9.3. Confidentiality of business information](#p9.3)
|
|
|
- [9.4. Privacy of personal information](#p9.4)
|
|
|
- [9.5. Intellectual property rights](#p9.5)
|
|
|
- [9.6. Representations and warranties](#p9.6)
|
|
|
- [9.7. Disclaimers of warranties](#p9.7)
|
|
|
- [9.8. Limitations of liability](#p9.8)
|
|
|
- [9.9. Indemnities](#p9.9)
|
|
|
- [9.10. Term and termination](#p9.10)
|
|
|
- [9.11. Individual notices and communications with
|
|
|
participants](#p9.11)
|
|
|
- [9.12. Amendments](#p9.12)
|
|
|
- [9.13. Dispute resolution provisions](#p9.13)
|
|
|
- [9.14. Governing law](#p9.14)
|
|
|
- [9.15. Compliance with applicable law](#p9.15)
|
|
|
- [9.16. Miscellaneous provisions](#p9.16)
|
|
|
|
|
|
</div>
|
|
|
|
|
|
## <span id="p1">1. INTRODUCTION</span>
|
|
|
|
|
|
### <span id="p1.1">1.1. Overview</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
### <span id="p1.2">1.2. Document name and identification</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
- This document is COD6 under CAcert Official Documents numbering
|
|
|
scheme.
|
|
|
|
|
|
- The document is structured according to Chokhani, et al,
|
|
|
[RFC3647](http://www.ietf.org/rfc/rfc3647.txt), [chapter
|
|
|
4](http://tools.ietf.org/html/rfc3647#section-4). All headings
|
|
|
derive from that Chapter.
|
|
|
|
|
|
- It has been improved and reviewed (or will be reviewed) to meet or
|
|
|
exceed the criteria of the Certificate Authority Review Checklist
|
|
|
from *David E. Ross* ("DRC") and Mozilla Foundation's CA policy.
|
|
|
|
|
|
- OID assigned to this document: 1.3.6.1.4.1.18506.4.4.x (x=approved
|
|
|
Version)
|
|
|
([iana.org](http://www.iana.org/assignments/enterprise-numbers))
|
|
|
|
|
|
.x will change to .1 in the first approved instance.
|
|
|
|
|
|
- © CAcert Inc. 2006-2009.
|
|
|
|
|
|
- Issued under the CAcert document licence policy, as and when made
|
|
|
policy. See
|
|
|
[PolicyDrafts/DocumentLicence](https://wiki.cacert.org/PolicyDrafts/DocumentLicence).
|
|
|
- The cited page discusses 2 options: CCau Attribute-Share-alike
|
|
|
and GNU Free Document License. Refer to that.
|
|
|
- Note that the noun Licence in Australian English has two Cs. The
|
|
|
verb License is spelt the same way as American English.
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
- <span class="q">In this document:</span>
|
|
|
- <span class="q">green text</span> refers to questions that seek
|
|
|
answers,
|
|
|
- <span class="error">red text</span> refers to probably audit
|
|
|
fails or serious errors.
|
|
|
- <span class="change">blue text</span> refers to changes written
|
|
|
after the document got seriously reviewed.
|
|
|
|
|
|
<span class="q"> None is to be considered part of the policy, and
|
|
|
they should disappear in the DRAFT and must disappear in the POLICY.
|
|
|
</span>
|
|
|
|
|
|
The CPS is an authoritive document, and rules other documents except
|
|
|
where explicitly deferred to. See also [1.5.1 Organisation Administering
|
|
|
the Document](#p1.5.1).
|
|
|
|
|
|
### <span id="p1.3">1.3. PKI participants</span>
|
|
|
|
|
|
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
|
|
|
[CAcert wiki](https://wiki.cacert.org/CAcertInc).
|
|
|
|
|
|
CAcert is a Community formed of Members who agree to the [CAcert
|
|
|
Community
|
|
|
Agreement](https://www.cacert.org/policy/CAcertCommunityAgreement.html).
|
|
|
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 *Association Members*, which latter are not
|
|
|
referred to anywhere in this CPS.)
|
|
|
|
|
|
#### <span id="p1.3.1">1.3.1. Certification authorities</span>
|
|
|
|
|
|
CAcert does not issue certificates to external intermediate CAs under
|
|
|
the present CPS.
|
|
|
|
|
|
#### <span id="p1.3.2">1.3.2. Registration authorities</span>
|
|
|
|
|
|
Registration Authorities (RAs) are controlled under Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
|
|
|
|
|
|
#### <span id="p1.3.3">1.3.3. Subscribers</span>
|
|
|
|
|
|
CAcert issues certificates to Members only. Such Members then become
|
|
|
Subscribers.
|
|
|
|
|
|
#### <span id="p1.3.4">1.3.4. Relying parties</span>
|
|
|
|
|
|
A relying party is a Member, having agreed to the CAcert Community
|
|
|
Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)),
|
|
|
who, in the act of using a CAcert certificate, makes a decision on the
|
|
|
basis of that certificate.
|
|
|
|
|
|
#### <span id="p1.3.5">1.3.5. Other participants</span>
|
|
|
|
|
|
**Member.** Membership of the Community is as defined in the
|
|
|
[COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html).
|
|
|
Only Members may RELY or may become Subscribers. Membership is free.
|
|
|
|
|
|
**Arbitrator.** A senior and experienced Member of the CAcert Community
|
|
|
who resolves disputes between Members, including ones of certificate
|
|
|
reliance, under Dispute Resolution Policy
|
|
|
([COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html)).
|
|
|
|
|
|
**Vendor.** Software suppliers who integrate the root certificates of
|
|
|
CAcert into their software also assume a proxy role of Relying Parties,
|
|
|
and are subject to another licence. <span class="q"> At the time of
|
|
|
writing, the "3rd Party Vendor - Disclaimer and Licence" is being worked
|
|
|
upon, but is neither approved nor offered. </span>
|
|
|
|
|
|
**Non-Related Persons** (NRPs). These are users of browsers and similar
|
|
|
software who are unaware of the CAcert certificates they may use, and
|
|
|
are unaware of the ramifications of usage. Their relationship with
|
|
|
CAcert is described by the Root Distribution License
|
|
|
([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
|
|
|
No other rights nor relationship is implied or offered.
|
|
|
|
|
|
### <span id="p1.4">1.4. Certificate usage</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
Types of certificates and their appropriate and corresponding
|
|
|
applications are defined in [§1.4.1](#p1.4.1). Prohibited applications
|
|
|
are defined in [§1.4.2](#p1.4.2). Specialist uses may be agreed by
|
|
|
contract or within a specific environment, as described in
|
|
|
[§1.4.4](#p1.4.4). Note also the unreliable applications in
|
|
|
[§1.4.3](#p1.4.3) and risks, liabilities and obligations in [§9](#p9).
|
|
|
|
|
|
<table data-border="1" data-cellpadding="5">
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<th colspan="2"><em>Type</em></th>
|
|
|
<th colspan="2"><em>Appropriate Certificate uses</em></th>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>General</th>
|
|
|
<th>Protocol</th>
|
|
|
<th>Description</th>
|
|
|
<th>Comments</th>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th rowspan="2">Server</th>
|
|
|
<th>TLS</th>
|
|
|
<th>web server encryption</th>
|
|
|
<th>enables encryption</th>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>embedded</th>
|
|
|
<th>embedded server authentication</th>
|
|
|
<th>mail servers, IM-servers</th>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th rowspan="4">Client</th>
|
|
|
<th>S/MIME</th>
|
|
|
<th>email encryption</th>
|
|
|
<th>"digital signatures" employed in S/MIME are not legal / human
|
|
|
signatures, but instead enable the encryption mode of S/MIME</th>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>TLS</th>
|
|
|
<th>client authentication</th>
|
|
|
<th>the nodes must be secure</th>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th>TLS</th>
|
|
|
<th>web based signature applications</th>
|
|
|
<th>the certificate authenticates only. See <a
|
|
|
href="#p1.4.3">§1.4.3</a>.</th>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>"Digital Signing"</th>
|
|
|
<th>for human signing over documents</th>
|
|
|
<th>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>.</th>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th>Code</th>
|
|
|
<th>Authenticode, ElfSign, Java</th>
|
|
|
<th>Code Signing</th>
|
|
|
<th>Signatures on packages are evidence of their Membership and
|
|
|
indicative of Identity</th>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>PGP</th>
|
|
|
<th>OpenPGP</th>
|
|
|
<th>Key Signing</th>
|
|
|
<th>Signatures on Member Keys are evidence of their Membership and
|
|
|
indicative of Identity</th>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th>Special</th>
|
|
|
<th>X.509</th>
|
|
|
<th>OCSP, Timestamping</th>
|
|
|
<th>Only available to CAcert Systems Administrators, as controlled by
|
|
|
Security Policy</th>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
<span class="figure">Table 1.4. Types of Certificate</span>
|
|
|
|
|
|
#### <span id="p1.4.1">1.4.1. Appropriate certificate uses</span>
|
|
|
|
|
|
General uses.
|
|
|
|
|
|
- CAcert server certificates can be used to enable encryption
|
|
|
protection in web servers. Suitable applications include webmail and
|
|
|
chat forums.
|
|
|
- CAcert server certificates can be used to enable encryption in
|
|
|
SSL/TLS links in embedded protocols such as mail servers and
|
|
|
IM-servers.
|
|
|
- CAcert client certificates can be used to enable encryption
|
|
|
protection in email clients. (See [§1.4.3](#p1.4.3) for caveat on
|
|
|
signatures.)
|
|
|
- CAcert client certificates can be used to replace password-based
|
|
|
authentication to web servers.
|
|
|
- OpenPGP keys with CAcert signatures can be used to encrypt and sign
|
|
|
files and emails, using software compatible with OpenPGP.
|
|
|
- CAcert client certificates can be used in web-based authentication
|
|
|
applications.
|
|
|
- CAcert code signing certificates can be used to sign code for
|
|
|
distribution to other people.
|
|
|
- Time stamping can be used to attach a time record to a digital
|
|
|
document.
|
|
|
|
|
|
#### <span id="p1.4.2">1.4.2. Prohibited certificate uses</span>
|
|
|
|
|
|
CAcert certificates are not designed, intended, or authorised for the
|
|
|
following applications:
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
#### <span id="p1.4.3">1.4.3. Unreliable Applications</span>
|
|
|
|
|
|
CAcert certificates are not designed nor intended for use in the
|
|
|
following applications, and may not be reliable enough for these
|
|
|
applications:
|
|
|
|
|
|
- **Signing within Protocols.** Digital signatures made by CAcert
|
|
|
certificates carry <u>NO default legal or human meaning</u>. See
|
|
|
[§9.15.1](#p9.15.1). 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.
|
|
|
- **Non-repudiation applications.** 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.
|
|
|
- **Ecommerce applications.** Financial transactions or payments or
|
|
|
valuable e-commerce.
|
|
|
- Use of anonymous (Class 1 or Member SubRoot) certificates in any
|
|
|
application that requires or expects identity.
|
|
|
|
|
|
#### <span id="p1.4.4">1.4.4. Limited certificate uses</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
**Digital signing applications.** 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.
|
|
|
|
|
|
#### <span id="p1.4.5">1.4.5. Roots and Names</span>
|
|
|
|
|
|
**Named Certificates.** 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).
|
|
|
|
|
|
**Anonymous Certificates.** 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.
|
|
|
|
|
|
**Psuedonymous Certificates.** Note that CAcert does not currently issue
|
|
|
pseudonymous certificates, being those with a name chosen by the Member
|
|
|
and not verifiable according to documents.
|
|
|
|
|
|
**Advanced Certificates.** Members who are as yet unassured are not
|
|
|
permitted to create advanced forms such as wildcard or subjectAltName
|
|
|
certificates.
|
|
|
|
|
|
**Roots.** The <span class="q"> (new) </span> CAcert root layout is as
|
|
|
below. These roots are pending Audit, and will be submitted to vendors
|
|
|
via the (Top-level) Root.
|
|
|
|
|
|
- **(Top-level) Root.** Used to sign on-line CAcert SubRoots only.
|
|
|
This Root is kept offline.
|
|
|
- **Member SubRoot.** For Community Members who are new and unassured
|
|
|
(some restrictions exist). Reliance is undefined. (Replacement for
|
|
|
the Class 1 root, matches "Domain Validation" type.)
|
|
|
- **Assured SubRoot.** 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.
|
|
|
- **Organisation SubRoot.** Only available for Assured Organisation
|
|
|
Members. Suitable for Reliance under this and other policies.
|
|
|
Approximates the type known as Organisational Validation.
|
|
|
|
|
|
<table style="width:100%;" data-border="1" data-cellpadding="5">
|
|
|
<colgroup>
|
|
|
<col style="width: 14%" />
|
|
|
<col style="width: 14%" />
|
|
|
<col style="width: 14%" />
|
|
|
<col style="width: 14%" />
|
|
|
<col style="width: 14%" />
|
|
|
<col style="width: 14%" />
|
|
|
<col style="width: 14%" />
|
|
|
</colgroup>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<th></th>
|
|
|
<th colspan="4"><em>Level of Assurance</em></th>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th></th>
|
|
|
<th colspan="2">Members †</th>
|
|
|
<th colspan="2">Assured Members</th>
|
|
|
<td>Assurers</td>
|
|
|
<td> </td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th><em>Class of Root</em></th>
|
|
|
<th>Anon</th>
|
|
|
<th>Name</th>
|
|
|
<th>Anon</th>
|
|
|
<th>Name</th>
|
|
|
<td>Name+Anon</td>
|
|
|
<td><em>Remarks</em></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>Top level<br />
|
|
|
<strong>Root</strong></th>
|
|
|
<th>•</th>
|
|
|
<th>•</th>
|
|
|
<th>•</th>
|
|
|
<th>•</th>
|
|
|
<td>•</td>
|
|
|
<td>Signs other CAcert SubRoots only.</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th><strong>Member</strong><br />
|
|
|
SubRoot</th>
|
|
|
<th>✔</th>
|
|
|
<th>✘</th>
|
|
|
<th>✔</th>
|
|
|
<th>✔</th>
|
|
|
<td>✔</td>
|
|
|
<td>† For Members meeting basic checks in <a
|
|
|
href="#p4.2.2">§4.2.2</a><br />
|
|
|
(Reliance is undefined.)</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th><strong>Assured</strong><br />
|
|
|
SubRoot</th>
|
|
|
<th>✘</th>
|
|
|
<th>✘</th>
|
|
|
<th>✔</th>
|
|
|
<th>✔</th>
|
|
|
<td>✔</td>
|
|
|
<td>Assured Members only.<br />
|
|
|
Fully intended for reliance.</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th><strong>Organisation</strong><br />
|
|
|
SubRoot</th>
|
|
|
<th>✘</th>
|
|
|
<th>✘</th>
|
|
|
<th>✔</th>
|
|
|
<th>✔</th>
|
|
|
<td>✔</td>
|
|
|
<td>Assured Organisation Members only.<br />
|
|
|
Fully intended for reliance.</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>Expiry of Certificates</th>
|
|
|
<th colspan="2">6 months</th>
|
|
|
<th colspan="2">24 months</th>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th>Types</th>
|
|
|
<th colspan="2">client, server</th>
|
|
|
<th colspan="2">wildcard, subjectAltName</th>
|
|
|
<td>code-signing</td>
|
|
|
<td>(Inclusive to the left.)</td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
<span class="figure">Table 1.4.5.b Certificate under Audit Roots</span>
|
|
|
|
|
|
Following information on OLD roots here for descriptive and historical
|
|
|
purposes only. When CPS goes to DRAFT, this needs to be converted into a
|
|
|
short summary of the way OLD roots are used and its relationship to this
|
|
|
CPS. E.g., "OLD roots are used for testing and other purposes outside
|
|
|
this CPS." Because ... they still exist, and people will look at the CPS
|
|
|
to figure it out.
|
|
|
|
|
|
<table style="width:100%;" data-border="1" data-cellpadding="5">
|
|
|
<colgroup>
|
|
|
<col style="width: 16%" />
|
|
|
<col style="width: 16%" />
|
|
|
<col style="width: 16%" />
|
|
|
<col style="width: 16%" />
|
|
|
<col style="width: 16%" />
|
|
|
<col style="width: 16%" />
|
|
|
</colgroup>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<th></th>
|
|
|
<th colspan="3"><em>Level of Assurance</em></th>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th></th>
|
|
|
<th colspan="2">Members</th>
|
|
|
<th>Assured Members</th>
|
|
|
<td> </td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th><em>Class of Root</em></th>
|
|
|
<th>Anonymous</th>
|
|
|
<th>Named</th>
|
|
|
<th>Anonymous</th>
|
|
|
<td>Named</td>
|
|
|
<td><em>Remarks</em></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>Class<br />
|
|
|
<strong>1</strong></th>
|
|
|
<th>✔</th>
|
|
|
<th>✘</th>
|
|
|
<th>✔</th>
|
|
|
<td>✔</td>
|
|
|
<td>Available for all Members,<br />
|
|
|
reliance is undefined.</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th>Class<br />
|
|
|
<strong>3</strong></th>
|
|
|
<th>✘</th>
|
|
|
<th>✘</th>
|
|
|
<th>✔</th>
|
|
|
<td>✔</td>
|
|
|
<td>Assured Members only.<br />
|
|
|
Intended for Reliance.</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<th>Expiry of Certificates</th>
|
|
|
<th colspan="2">6 months</th>
|
|
|
<th>24 months</th>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<th>Types available</th>
|
|
|
<th colspan="2">simple only</th>
|
|
|
<th>wildcard, subjectAltName</th>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
<span class="figure">Table 1.4.5. Certificates under Old Roots - **Audit
|
|
|
Fail** </span>
|
|
|
|
|
|
**Old Roots.** The old CAcert root layout is as below. These roots are
|
|
|
**Audit Fail** and will only be used where new roots do not serve:
|
|
|
|
|
|
- (old) **Class 1 root.** Used primarily for certificates with no
|
|
|
names and by unassured Members. For compatibility only, Assured
|
|
|
Members may also use this root.
|
|
|
- (old) **Class 3 root.** 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.
|
|
|
|
|
|
<!-- -->
|
|
|
|
|
|
- Current Mozilla position has drifted from Class 1,2,3s to DV, IV+OV
|
|
|
and EV posture. Except, the actual posture is either unstated or
|
|
|
difficult to fathom.
|
|
|
- scheme for future roots is at
|
|
|
[NewRootsTaskForce](https://wiki.cacert.org/Roots/NewRootsTaskForce).
|
|
|
- END OLD ROOTS
|
|
|
|
|
|
### <span id="p1.5">1.5. Policy administration</span>
|
|
|
|
|
|
See [1.2 Document Name and Identification](#p1.2) for general scope of
|
|
|
this document.
|
|
|
|
|
|
#### <span id="p1.5.1">1.5.1. Organization administering the document</span>
|
|
|
|
|
|
This document is administered by the policy group of the CAcert
|
|
|
Community under Policy on Policy
|
|
|
([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html)).
|
|
|
|
|
|
#### <span id="p1.5.2">1.5.2. Contact person</span>
|
|
|
|
|
|
For questions including about this document:
|
|
|
|
|
|
- Join the policy group, by means of the discussion forum at
|
|
|
[lists.cacert.org](https://lists.cacert.org/wws/lists) .
|
|
|
- Send email to \< support AT cacert DOT org \>
|
|
|
- IRC: irc.cacert.org \#CAcert (ssl port 7000, non-ssl port 6667)
|
|
|
|
|
|
#### <span id="p1.5.3">1.5.3. Person determining CPS suitability for the policy</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p1.5.4">1.5.4. CPS approval procedures</span>
|
|
|
|
|
|
CPS is controlled and updated according to the Policy on Policy
|
|
|
([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html)) which is
|
|
|
part of Configuration-Control Specification (COD2).
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p1.5.5">1.5.5 CPS updates</span>
|
|
|
|
|
|
As per above.
|
|
|
|
|
|
### <span id="p1.6">1.6. Definitions and acronyms</span>
|
|
|
|
|
|
**<span id="d_cert">Certificate</span>**. A certificate is a piece of
|
|
|
cryptographic data used to validate certain statements, especially those
|
|
|
of identity and membership.
|
|
|
|
|
|
**<span id="d_cacert">CAcert</span>**. CAcert is a Community certificate
|
|
|
authority as defined under [§1.2 Identification](#p1.2).
|
|
|
|
|
|
**<span id="d_member">Member</span>**. Everyone who agrees to the CAcert
|
|
|
Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
|
|
|
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").
|
|
|
|
|
|
**<span id="d_community">Community</span>**. The group of Members who
|
|
|
agree to the CAcert Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)) or
|
|
|
equivalent agreements.
|
|
|
|
|
|
**<span id="d_unassured">Unassured Member</span>**. A Member who has not
|
|
|
yet been Assured.
|
|
|
|
|
|
**<span id="d_subscriber">Subscriber</span>**. A Member who requests and
|
|
|
receives a certificate.
|
|
|
|
|
|
**<span id="d_assured">Assured Member</span>**. A Member whose identity
|
|
|
has been sufficiently verified by Assurers or other approved methods
|
|
|
under Assurance Policy.
|
|
|
|
|
|
**<span id="d_assurer">Assurer</span>**. An Assured Member who is
|
|
|
authorised under Assurance Policy to verify the identity of other
|
|
|
Members.
|
|
|
|
|
|
**<span id="d_name">Name</span>**. As defined in the Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)), to
|
|
|
describe a name of a Member that is verified by the Assurance process.
|
|
|
|
|
|
**<span id="d_oadmin">Organisation Administrator</span>**. ("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.
|
|
|
|
|
|
**<span id="d_org_ass">Organisation Assurer</span>**. An Assurer who is
|
|
|
authorised to conduct assurances on organisations.
|
|
|
|
|
|
**<span id="d_user">Non-Related Persons</span>**. ("NRPs") are general
|
|
|
users of browsers and similar software. The NRPs are generally unaware
|
|
|
of CAcert or the certificates that they may use, and are unaware of the
|
|
|
ramifications of usage. They are not permitted to RELY, but may USE,
|
|
|
under the Root Distribution License
|
|
|
([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
|
|
|
|
|
|
**<span id="d_reliance">Reliance</span>**. 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.
|
|
|
|
|
|
**<span id="d_relparty">Relying Party</span>**. An industry term
|
|
|
refering to someone who relies (that is, makes decisions or takes risks)
|
|
|
in part or in whole on a certificate.
|
|
|
|
|
|
**Subscriber Naming.** 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.
|
|
|
|
|
|
**<span id="d_verification">Verification</span>**. An industry term
|
|
|
referring to the act of checking and controlling the accuracy and
|
|
|
utility of a single claim.
|
|
|
|
|
|
**<span id="d_validation">Validation</span>**. An industry term
|
|
|
referring to the process of inspecting and verifying the information and
|
|
|
subsidiary claims behind a claim.
|
|
|
|
|
|
**<span id="usage">Usage</span>**. 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.
|
|
|
|
|
|
**<span id="drel">CAcert Relying Party</span>**. 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.
|
|
|
|
|
|
**<span id="ddst">Vendors</span>**. Non-members who distribute CAcert's
|
|
|
root or intermediate certificates in any way, including but not limited
|
|
|
to delivering these certificates with their products, e.g. browsers,
|
|
|
mailers or servers. Vendors are covered under a separate licence. <span
|
|
|
class="q"> As of the moment, this licence is not written.</span>
|
|
|
|
|
|
**<span id="d_ccs">Configuration-Control Specification</span>** "CCS".
|
|
|
The audit criteria that controls this CPS. The CCS is documented in
|
|
|
COD2, itself a controlled document under CCS.
|
|
|
|
|
|
**<span id="d_cod">CAcert Official Document</span>** (COD). Controlled
|
|
|
Documents that are part of the CCS.
|
|
|
|
|
|
## <span id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</span>
|
|
|
|
|
|
### <span id="p2.1">2.1. Repositories</span>
|
|
|
|
|
|
CAcert operates no repositories in the sense of lookup for
|
|
|
non-certificate-related information for the general public.
|
|
|
|
|
|
Under the Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)), there are
|
|
|
means for Members to search, retrieve and verify certain data about
|
|
|
themselves and others.
|
|
|
|
|
|
### <span id="p2.2">2.2. Publication of certification information</span>
|
|
|
|
|
|
CAcert publishes:
|
|
|
|
|
|
- A repository of CRLs. An OCSP responder is in operation.
|
|
|
- The root certificate and intermediate certificates.
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p2.3">2.3. Time or frequency of publication</span>
|
|
|
|
|
|
Root and Intermediate Certificates and CRLs are made available on
|
|
|
issuance.
|
|
|
|
|
|
### <span id="p2.4">2.4. Access controls on repositories</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
## <span id="p3">3. IDENTIFICATION AND AUTHENTICATION</span>
|
|
|
|
|
|
### <span id="p3.1">3.1. Naming</span>
|
|
|
|
|
|
#### <span id="p3.1.1">3.1.1. Types of names</span>
|
|
|
|
|
|
**Client Certificates.** The Subscriber Naming consists of:
|
|
|
|
|
|
- subjectAltName= One, or more, of the Subscriber's verified email
|
|
|
addresses, in rfc822Name format.
|
|
|
- SSO in subjectAltName?.
|
|
|
- EmailAddress= One, or more, of the Subscriber's verified email
|
|
|
addresses. This is deprecated under RFC5280 [4
|
|
|
.1.2.6](http://tools.ietf.org/html/rfc5280#section-4.2.1.6) 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.
|
|
|
- CN= The common name takes its value from one of:
|
|
|
- For all Members, the string "CAcert WoT Member" may be used for
|
|
|
anonymous certificates.
|
|
|
- For individual Members, a Name of the Subscriber, as Assured
|
|
|
under AP.
|
|
|
- For Organisation Members, an organisation-chosen name, as
|
|
|
verified under OAP.
|
|
|
|
|
|
<!-- -->
|
|
|
|
|
|
- [bug 672](https://bugs.cacert.org/view.html?id=672) filed on
|
|
|
subjectAltName.
|
|
|
- O-Admin must verify as per
|
|
|
[p20081016](https://wiki.cacert.org/PolicyDecisions#p20081016).
|
|
|
- it is a wip for OAP to state how this is done.
|
|
|
- curiously, (RFC5280) verification is only mandated for
|
|
|
subjectAltName not subject field.
|
|
|
- what Directory String is used in above? UTF8String is specified by
|
|
|
RFC52804.1.2.6? is this important for the CPS to state?
|
|
|
|
|
|
**Individual Server Certificates.** The Subscriber Naming consists of:
|
|
|
|
|
|
- CN= The common name is the host name out of a domain for which the
|
|
|
Member is a domain master.
|
|
|
- subjectAltName= 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.
|
|
|
- All other fields are optional and must either match the CN or they
|
|
|
must be empty
|
|
|
|
|
|
**Certificates for Organisations.** In addition to the above, the
|
|
|
following applies:
|
|
|
|
|
|
- OU= organizationalUnitName (set by O-Admin, must be verified by
|
|
|
O-Admin).
|
|
|
- O= organizationName is the fixed name of the Organisation.
|
|
|
- L= localityName
|
|
|
- ST= stateOrProvinceName
|
|
|
- C= countryName
|
|
|
- contact= EMail Address of Contact.
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p3.1.2">3.1.2. Need for names to be meaningful</span>
|
|
|
|
|
|
Each Member's Name (CN= field) is assured under the Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)) or
|
|
|
subsidiary policies (such as Organisation Assurance Policy). Refer to
|
|
|
those documents for meanings and variations.
|
|
|
|
|
|
Anonymous certificates have the same `subject` field common name. See
|
|
|
[§1.4.5.](#p1.4.5).
|
|
|
|
|
|
Email addresses are verified according to [§4.2.2.](#p4.2.2)
|
|
|
|
|
|
#### <span id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</span>
|
|
|
|
|
|
See [§1.4.5](#p1.4.5).
|
|
|
|
|
|
#### <span id="p3.1.4">3.1.4. Rules for interpreting various name forms</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p3.1.5">3.1.5. Uniqueness of names</span>
|
|
|
|
|
|
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
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
|
|
|
|
|
|
Domain names and email address can only be registered to one Member.
|
|
|
|
|
|
#### <span id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</span>
|
|
|
|
|
|
Organisation Assurance Policy
|
|
|
([COD11](https://www.cacert.org/policy/OrganisationAssurancePolicy.html))
|
|
|
controls issues such as trademarks where applicable. A trademark can be
|
|
|
disputed by filing a dispute. See [§9.13](#adr).
|
|
|
|
|
|
#### <span id="p3.1.7">3.1.7. International Domain Names</span>
|
|
|
|
|
|
Certificates containing International Domain Names, being those
|
|
|
containing a ACE prefix ([RFC3490 Section
|
|
|
5](http://www.ietf.org/rfc/rfc3490#section-5)), will only be issued to
|
|
|
domains satisfying one or more of the following conditions:
|
|
|
|
|
|
- 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.
|
|
|
- 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 '-'.
|
|
|
|
|
|
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.
|
|
|
|
|
|
The following is a list of accepted TLD Registrars:
|
|
|
|
|
|
<table>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<td>.dk</td>
|
|
|
<td><a href="http://www.dk-hostmaster.dk/">Registry</a></td>
|
|
|
<td><a
|
|
|
href="http://www.dk-hostmaster.dk/index.html?id=151">Policy</a></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<td>.is</td>
|
|
|
<td><a href="http://www.isnic.is/">Registry</a></td>
|
|
|
<td><a
|
|
|
href="http://www.isnic.is/english/domain/rules.html">Policy</a></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<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>
|
|
|
|
|
|
This criteria will apply to the email address and server host name
|
|
|
fields for all certificate types.
|
|
|
|
|
|
The CAcert Inc. Board has the authority to decide to add or remove
|
|
|
accepted TLD Registrars on this list.
|
|
|
|
|
|
### <span id="p3.2">3.2. Initial Identity Verification</span>
|
|
|
|
|
|
Identity verification is controlled by the [Assurance
|
|
|
Policy](https://www.cacert.org/policy/AssurancePolicy.html)
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)). The
|
|
|
reader is refered to the Assurance Policy, the following is
|
|
|
representative and brief only.
|
|
|
|
|
|
#### <span id="p3.2.1">3.2.1. Method to prove possession of private key</span>
|
|
|
|
|
|
CAcert uses industry-standard techniques to prove the possession of the
|
|
|
private key.
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p3.2.2">3.2.2. Authentication of Individual Identity</span>
|
|
|
|
|
|
**Agreement.** An Internet user becomes a Member by agreeing to the
|
|
|
CAcert Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html))
|
|
|
and registering an account on the online website. During the
|
|
|
registration process Members are asked to supply information about
|
|
|
themselves:
|
|
|
|
|
|
- A valid working email.
|
|
|
- Full Name and Date of Birth such as is found on Identity documents.
|
|
|
- Personal Questions used only for Password Retrieval.
|
|
|
|
|
|
The online account establishes the method of authentication for all
|
|
|
service requests such as certificates.
|
|
|
|
|
|
**Assurance.** Each Member is assured according to Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
|
|
|
|
|
|
**Certificates.** Based on the total number of Assurance Points that a
|
|
|
Member (Name) has, the Member can get different levels of certificates.
|
|
|
See [§1.4.5](#p1.4.5). See Table 3.2.b. When Members have 50 or more
|
|
|
points, they become *Assured Members* and may then request certificates
|
|
|
that state their Assured Name(s).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<table data-border="1" data-cellpadding="5">
|
|
|
<thead>
|
|
|
<tr class="header">
|
|
|
<th>Assurance Points</th>
|
|
|
<th>Level</th>
|
|
|
<th>Service</th>
|
|
|
<th>Comments</th>
|
|
|
</tr>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<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 class="even">
|
|
|
<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 class="odd">
|
|
|
<td>50-99</td>
|
|
|
<td>Assured Member</td>
|
|
|
<td>Verified</td>
|
|
|
<td>Certificates with Verified Name for S/MIME, web servers, "digital
|
|
|
signing." Expiry after 24 months is available.</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td>100++</td>
|
|
|
<td>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>
|
|
|
|
|
|
|
|
|
|
|
|
#### <span id="p3.2.3">3.2.3. Authentication of organization identity</span>
|
|
|
|
|
|
Verification of organisations is delegated by the Assurance Policy to
|
|
|
the Organisation Assurance Policy
|
|
|
([COD11](https://www.cacert.org/policy/OrganisationAssurancePolicy.html)).
|
|
|
The reader is refered to the Organisation Assurance Policy, the
|
|
|
following is representative and brief only.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Organisation Assurance achieves the standard stated in the OAP, briefly
|
|
|
presented here:
|
|
|
|
|
|
1. the organisation exists,
|
|
|
2. the organisation name is correct and consistent,
|
|
|
3. signing rights: requestor can sign on behalf of the organisation,
|
|
|
and
|
|
|
4. the organisation has agreed to the terms of the CAcert Community
|
|
|
Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)),
|
|
|
and is therefore subject to Arbitration.
|
|
|
|
|
|
- As of the current time of writing, OA lacks critical documentation
|
|
|
and there are bugs identified with no response.
|
|
|
- [documented
|
|
|
bugs](https://wiki.cacert.org/PolicyDrafts/OrganisationAssurance).
|
|
|
- Therefore Organisations will not participate in the current audit
|
|
|
cycle of roots.
|
|
|
- See [wiki](https://wiki.cacert.org/OrganisationAssurance) for any
|
|
|
progress on this.
|
|
|
|
|
|
#### <span id="p3.2.4">3.2.4. Non-verified subscriber information</span>
|
|
|
|
|
|
All information in the certificate is verified, see Relying Party
|
|
|
Statement, §4.5.2.
|
|
|
|
|
|
#### <span id="p3.2.5">3.2.5. Validation of authority</span>
|
|
|
|
|
|
The authorisation to obtain a certificate is established as follows:
|
|
|
|
|
|
**Addresses.** The member claims authority over a domain or email
|
|
|
address when adding the address, [§4.1.2](#p4.1.2). (Control is tested
|
|
|
by means described in [§4.2.2](#p4.2.2).)
|
|
|
|
|
|
**Individuals.** The authority to participate as a Member is established
|
|
|
by the CAcert Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
|
|
|
Assurances are requested by means of the signed CAP form.
|
|
|
|
|
|
**Organisations.** 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.
|
|
|
|
|
|
#### <span id="p3.2.6">3.2.6. Criteria for interoperation</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p3.3">3.3. Re-key Requests</span>
|
|
|
|
|
|
Via the Member's account.
|
|
|
|
|
|
### <span id="p3.4">3.4. Revocations Requests</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
## <span id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</span>
|
|
|
|
|
|
The general life-cycle for a new certificate for an Individual Member
|
|
|
is:
|
|
|
|
|
|
1. Member adds claim to an address (domain/email).
|
|
|
2. System probes address for control.
|
|
|
3. Member creates key pair.
|
|
|
4. Member submits CSR with desired options (Anonymous Certificate, SSO,
|
|
|
Root Certificate) .
|
|
|
5. System validates and accepts CSR based on known information: claims,
|
|
|
assurance, controls, technicalities.
|
|
|
6. System signs certificate.
|
|
|
7. System makes signed certificate available to Member.
|
|
|
8. Member accepts certificate.
|
|
|
|
|
|
(Some steps are not applicable, such as anonymous certificates.)
|
|
|
|
|
|
### <span id="p4.1">4.1. Certificate Application</span>
|
|
|
|
|
|
#### <span id="p4.1.1">4.1.1. Who can submit a certificate application</span>
|
|
|
|
|
|
Members may submit certificate applications. On issuance of
|
|
|
certificates, Members become Subscribers.
|
|
|
|
|
|
#### <span id="p4.1.2">4.1.2. Adding Addresses</span>
|
|
|
|
|
|
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:
|
|
|
|
|
|
- The claim of ownership or control is legally significant and may be
|
|
|
referred to dispute resolution.
|
|
|
- Each unique address can be handled by one account only.
|
|
|
- When the Member makes the claim, the certificate application system
|
|
|
automatically initiates the check of control, as below.
|
|
|
|
|
|
#### <span id="p4.1.3">4.1.3. Preparing CSR</span>
|
|
|
|
|
|
Members generate their own key-pairs. The CAcert Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html))
|
|
|
obliges the Member as responsible for security. See CCA2.5, §9.6.
|
|
|
|
|
|
The Certificate Signing Request (CSR) is prepared by the Member for
|
|
|
presentation to the automated system.
|
|
|
|
|
|
### <span id="p4.2">4.2. Certificate application processing</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
Where certificates are requested for more than one purpose, the
|
|
|
requirements for each purpose must be fulfilled.
|
|
|
|
|
|
#### <span id="p4.2.1">4.2.1. Authentication</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p4.2.2">4.2.2. Verifying Control</span>
|
|
|
|
|
|
In principle, at least two controls are placed on each address.
|
|
|
|
|
|
**<span id="ping">Email-Ping</span>.** Email addresses are verified by
|
|
|
means of an *<span id="pingtest">Email-Ping test</span>*:
|
|
|
|
|
|
- The system generates a cookie (a random, hard-to-guess code) and
|
|
|
formats it as a string.
|
|
|
- The system sends the cookie to the Member in an email.
|
|
|
- Once the Member receives the email, she enters the cookie into the
|
|
|
website.
|
|
|
- The entry of the code verifies control of that email account.
|
|
|
|
|
|
**<span id="email">Email Control</span>.** Email addresses for client
|
|
|
certificates are verified by passing the following checks:
|
|
|
|
|
|
1. An Email-ping test is done on the email address.
|
|
|
2. The Member must have signed a CAP form or equivalent, and been
|
|
|
awarded at least one Assurance point.
|
|
|
|
|
|
**<span id="domain">Domain Control</span>.** Domains addresses for
|
|
|
server certificates are verified by passing two of the following checks:
|
|
|
|
|
|
1. An Email-ping test is done on an email address chosen from *whois*
|
|
|
or interpolated from the domain name.
|
|
|
2. The system generates a cookie which is then placed in DNS by the
|
|
|
Member.
|
|
|
3. The system generates a cookie which is then placed in HTTP headers
|
|
|
or a text file on the website by the Member.
|
|
|
4. Statement by at least 2 Assurers about ownership/control of the
|
|
|
domain name.
|
|
|
5. The system generates a cookie which is then placed in whois registry
|
|
|
information by the Member.
|
|
|
|
|
|
Notes.
|
|
|
|
|
|
- Other methods can be added from time to time by CAcert.
|
|
|
- Static cookies should remain for the duration of a certificate for
|
|
|
occasional re-testing.
|
|
|
- Dynamic tests can be repeated at a later time of CAcert's choosing.
|
|
|
- Domain control checks may be extended to apply to email control in
|
|
|
the future.
|
|
|
|
|
|
<!-- -->
|
|
|
|
|
|
- As of the time of writing, only a singular Email-ping is implemented
|
|
|
in the technical system.
|
|
|
- A further approved check is the 1 pt Assurance.
|
|
|
- Practically, this would mean that certificates can only be issued
|
|
|
under Audit Roots to Members with 1 point.
|
|
|
- Criteria DRC C.7.f, A.2.q, A.2.i indicate registry whois reading.
|
|
|
Also A.2.h.
|
|
|
- Current view is that this will be resolved in BirdShack.
|
|
|
|
|
|
#### <span id="p4.2.3">4.2.3. Options Available</span>
|
|
|
|
|
|
The Member has options available:
|
|
|
|
|
|
- Each Email address that is verified is available for Client
|
|
|
Certificates.
|
|
|
- Each Domain address that is verified is available for Server
|
|
|
Certificates.
|
|
|
- If the Member is unassured then only the Member SubRoot is
|
|
|
available.
|
|
|
- If the Member is Assured then both Assured Member and Member
|
|
|
SubRoots are available.
|
|
|
- If a Name is Assured then it may be put in a client certificate or
|
|
|
an OpenPGP signature.
|
|
|
|
|
|
#### <span id="p4.2.4">4.2.4. Client Certificate Procedures</span>
|
|
|
|
|
|
For an individual client certificate, the following is required.
|
|
|
|
|
|
- The email address is claimed and added.
|
|
|
- The email address is ping-tested.
|
|
|
- For the Member Subroot, the Member must have at least one point of
|
|
|
Assurance and have signed a CAP form.
|
|
|
- For the Assured Subroot, the Member must have at least fifty points
|
|
|
of Assurance.
|
|
|
- To include a Name, the Name must be assured to at least fifty
|
|
|
points.
|
|
|
|
|
|
#### <span id="p4.2.5">4.2.5. Server Certificate Procedures</span>
|
|
|
|
|
|
For a server certificate, the following is required:
|
|
|
|
|
|
- The domain is claimed and added.
|
|
|
- The domain is checked twice as above.
|
|
|
- For the Member SubRoot, the Member must have at least one point of
|
|
|
Assurance and have signed a CAP form.
|
|
|
- For the Assured SubRoot, the Member must have at least fifty points
|
|
|
of Assurance.
|
|
|
|
|
|
#### <span id="p4.2.6">4.2.6. Code-signing Certificate Procedures</span>
|
|
|
|
|
|
Code-signing certificates are made available to Assurers only. They are
|
|
|
processed in a similar manner to client certificates.
|
|
|
|
|
|
#### <span id="p4.2.7">4.2.7. Organisation Domain Verification</span>
|
|
|
|
|
|
Organisation Domains are handled under the Organisation Assurance Policy
|
|
|
and the Organisation Handbook.
|
|
|
|
|
|
- As of time of writing, there is no Handbook for Organisation
|
|
|
Assurers or for the Organisation, and the policy needs rework; so
|
|
|
(audit) roots will not have OA certs ....
|
|
|
- [Drafts](https://wiki.cacert.org/PolicyDrafts/OrganisationAssurance)
|
|
|
for ongoing story.
|
|
|
|
|
|
### <span id="p4.3">4.3. Certificate issuance</span>
|
|
|
|
|
|
#### <span id="p4.3.1">4.3.1. CA actions during certificate issuance</span>
|
|
|
|
|
|
**Key Sizes.** Members may request keys of any size permitted by the key
|
|
|
algorithm. Many older hardware devices require small keys.
|
|
|
|
|
|
**Algorithms.** 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.
|
|
|
|
|
|
**Process for Certificates:** 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.
|
|
|
|
|
|
1. The CSR is verified.
|
|
|
2. Data is extracted from CSR and verified:
|
|
|
- Name §3.1,
|
|
|
- Email address [§4.2.2](#p4.2.2),
|
|
|
- Domain address [§4.2.2](#p4.2.2).
|
|
|
3. Certificate is generated from template.
|
|
|
4. Data is copied from CSR.
|
|
|
5. Certificate is signed.
|
|
|
6. Certificate is stored as well as mailed.
|
|
|
|
|
|
**Process for OpenPGP key signatures:** 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:
|
|
|
|
|
|
1. The public key is verified.
|
|
|
2. Data is extracted from the key and verified (Name, Emails). Only the
|
|
|
combinations of data in Table 4.3.1 are permitted.
|
|
|
3. OpenPGP Key Signature is generated.
|
|
|
4. Key Signature is applied to the key.
|
|
|
5. The signed key is stored as well as mailed.
|
|
|
|
|
|
<table style="border:1; align:center; valign:top; cellpadding:5;">
|
|
|
<colgroup>
|
|
|
<col style="width: 25%" />
|
|
|
<col style="width: 25%" />
|
|
|
<col style="width: 25%" />
|
|
|
<col style="width: 25%" />
|
|
|
</colgroup>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td><br />
|
|
|
</td>
|
|
|
<td>Verified Name</td>
|
|
|
<td data-valign="top">Unverified Name<br />
|
|
|
</td>
|
|
|
<td>Empty Name<br />
|
|
|
</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td>Verified email<br />
|
|
|
</td>
|
|
|
<td>✔</td>
|
|
|
<td data-valign="top">✘</td>
|
|
|
<td>✔</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td>Unverified email</td>
|
|
|
<td>✘</td>
|
|
|
<td data-valign="top">✘</td>
|
|
|
<td>✘</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td data-valign="top">Empty email<br />
|
|
|
</td>
|
|
|
<td data-valign="top">✔</td>
|
|
|
<td data-valign="top">✘</td>
|
|
|
<td data-valign="top">✘</td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
|
|
|
<span class="figure">Table 4.3.1. Permitted Data in Signed OpenPgp
|
|
|
Keys</span>
|
|
|
|
|
|
#### <span id="p4.3.2">4.3.2. Notification to subscriber by the CA of issuance of certificate</span>
|
|
|
|
|
|
Once signed, the certificate is made available via the Member's account,
|
|
|
and emailed to the Member. It is also archived internally.
|
|
|
|
|
|
### <span id="p4.4">4.4. Certificate acceptance</span>
|
|
|
|
|
|
#### <span id="p4.4.1">4.4.1. Conduct constituting certificate acceptance</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p4.4.2">4.4.2. Publication of the certificate by the CA</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p4.4.3">4.4.3. Notification of certificate issuance by the CA to other entities</span>
|
|
|
|
|
|
There are no external entities that are notified about issued
|
|
|
certificates.
|
|
|
|
|
|
### <span id="p4.5">4.5. Key pair and certificate usage</span>
|
|
|
|
|
|
All Members (subscribers and relying parties) are obliged according to
|
|
|
the CAcert Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html))
|
|
|
See especially 2.3 through 2.5.
|
|
|
|
|
|
#### <span id="p4.5.1">4.5.1. Subscriber Usage and Responsibilities</span>
|
|
|
|
|
|
Subscribers should use keys only for their proper purpose, as indicated
|
|
|
by the certificate, or by wider agreement with others.
|
|
|
|
|
|
#### <span id="p4.5.2">4.5.2. Relying Party Usage and Responsibilities</span>
|
|
|
|
|
|
Relying parties (Members) may rely on the following.
|
|
|
|
|
|
<table data-border="1" data-cellpadding="25">
|
|
|
<colgroup>
|
|
|
<col style="width: 100%" />
|
|
|
</colgroup>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td><p><strong>Relying Party Statement</strong></p>
|
|
|
<p>Certificates are issued to Members only.<br />
|
|
|
<br />
|
|
|
All information in a certificate is verified.</p></td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
The following notes are in addition to the Relying Party Statement, and
|
|
|
can be seen as limitations on it.
|
|
|
|
|
|
##### 4.5.2.a Methods of Verification
|
|
|
|
|
|
The term Verification as used in the Relying Party Statement means one
|
|
|
of
|
|
|
|
|
|
<table data-border="1" data-cellpadding="5">
|
|
|
<thead>
|
|
|
<tr class="header">
|
|
|
<th>Type</th>
|
|
|
<th>How</th>
|
|
|
<th>Authority</th>
|
|
|
<th>remarks</th>
|
|
|
</tr>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<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 class="even">
|
|
|
<th>Evaluation</th>
|
|
|
<td>under automated domain and email checks</td>
|
|
|
<td>this CPS</td>
|
|
|
<td>see §4.2.2</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<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>
|
|
|
|
|
|
##### 4.5.2.b Who may rely
|
|
|
|
|
|
**Members may rely.** Relying parties are Members, and as such are bound
|
|
|
by this CPS and the CAcert Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
|
|
|
The licence and permission to rely is not assignable.
|
|
|
|
|
|
**Suppliers of Software.** CAcert roots may be distributed in software,
|
|
|
and those providers may enter into agreement with CAcert by means of the
|
|
|
Third Party Vendor - Disclaimer and Licence (wip). This licence brings
|
|
|
the supplier in to the Community to the extent that <span class="q">
|
|
|
...WIP comment:</span> they agree to dispute resolution within CAcert's
|
|
|
forum.
|
|
|
|
|
|
- Just exactly what the 3PV-DaL says is unclear.
|
|
|
- The document itself is more a collection of ideas.
|
|
|
|
|
|
**NRPs may not rely.** If not related to CAcert by means of an agreement
|
|
|
that binds the parties to dispute resolution within CAcert's forum, a
|
|
|
person is a Non-Related-Person (NRP). An NRP is not permitted to rely
|
|
|
and is not a Relying Party. For more details, see the Root Distribution
|
|
|
License
|
|
|
([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
|
|
|
|
|
|
##### 4.5.2.c The Act of Reliance
|
|
|
|
|
|
**Decision making.** 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:
|
|
|
|
|
|
- include her own overall risk equation,
|
|
|
- include the general limitations of the Assurance process,
|
|
|
certificates, and wider security considerations,
|
|
|
- make additional checks to provide more information,
|
|
|
- consider any wider agreement with the other Member, and
|
|
|
- use an appropriate protocol or custom of reliance (below).
|
|
|
|
|
|
**Examining the Certificate.** A Relying Party must make her own
|
|
|
decision in using each certificate. She must examine the certificate, a
|
|
|
process called *validation*. Certificate-related information includes,
|
|
|
but is not limited to:
|
|
|
|
|
|
- Name,
|
|
|
- expiry time of certificate,
|
|
|
- current certificate revocation list (CRL),
|
|
|
- certificate chain and the validity check of the certificates in the
|
|
|
chain,
|
|
|
- issuer of certificate (CAcert),
|
|
|
- SubRoot is intended for reliance (Assured, Organisation and Class 3)
|
|
|
- purpose of certificate.
|
|
|
|
|
|
**Keeping Records.** 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.
|
|
|
|
|
|
**Wider Protocol.** 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.
|
|
|
|
|
|
**As Compared to Usage**. 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.
|
|
|
|
|
|
##### 4.5.2.d Risks and Limitations of Reliance
|
|
|
|
|
|
**Roots and Naming.** 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.
|
|
|
|
|
|
<table data-border="1" data-cellpadding="5">
|
|
|
<colgroup>
|
|
|
<col style="width: 20%" />
|
|
|
<col style="width: 20%" />
|
|
|
<col style="width: 20%" />
|
|
|
<col style="width: 20%" />
|
|
|
<col style="width: 20%" />
|
|
|
</colgroup>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td></td>
|
|
|
<td colspan="4"><em>Statements of Reliance for Members</em></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td><em>Class of Root</em></td>
|
|
|
<td><strong>Anonymous</strong><br />
|
|
|
(all Members)</td>
|
|
|
<td><strong>Named</strong><br />
|
|
|
(Assured Members only)</td>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td>Class<br />
|
|
|
<strong>1</strong></td>
|
|
|
<td rowspan="2" data-bgcolor="red"><strong>Do not rely.</strong><br />
|
|
|
Relying party must use other methods to check.</td>
|
|
|
<td rowspan="2" data-bgcolor="#FFA500">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>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td><strong>Member</strong><br />
|
|
|
SubRoot</td>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td>Class<br />
|
|
|
<strong>3</strong></td>
|
|
|
<td rowspan="2" data-bgcolor="#FFA500">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>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td><strong>Assured</strong><br />
|
|
|
SubRoot</td>
|
|
|
<td></td>
|
|
|
<td></td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
<span class="figure">Table 4.5.2. Statements of Reliance</span>
|
|
|
|
|
|
**Software Agent.** 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.
|
|
|
|
|
|
**Malware.** 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.
|
|
|
|
|
|
##### 4.5.2.e When something goes wrong
|
|
|
|
|
|
In the event that an issue arises out of the Member's reliance, her sole
|
|
|
avenue is **to file dispute under DRP**. See [§9.13](#p9.13). For this
|
|
|
purpose, the certificate (and other evidence) should be preserved.
|
|
|
|
|
|
**Which person?** 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.
|
|
|
|
|
|
**Software Agent.** 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.
|
|
|
|
|
|
### <span id="p4.6">4.6. Certificate renewal</span>
|
|
|
|
|
|
A certificate can be renewed at any time. The procedure of certificate
|
|
|
renewal is the same as for the initial certificate issuance.
|
|
|
|
|
|
### <span id="p4.7">4.7. Certificate re-key</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p4.8">4.8. Certificate modification</span>
|
|
|
|
|
|
Certificate "modifications" are not offered nor supported. A new
|
|
|
certificate has to be requested and issued instead.
|
|
|
|
|
|
### <span id="p4.9">4.9. Certificate revocation and suspension</span>
|
|
|
|
|
|
#### <span id="p4.9.1">4.9.1. Circumstances for revocation</span>
|
|
|
|
|
|
Certificates may be revoked under the following circumstances:
|
|
|
|
|
|
1. As initiated by the Subscriber through her online account.
|
|
|
2. As initiated in an emergency action by a support team member. Such
|
|
|
action will immediately be referred to dispute resolution for
|
|
|
ratification.
|
|
|
3. Under direction from the Arbitrator in a duly ordered ruling from a
|
|
|
filed dispute.
|
|
|
|
|
|
These are the only three circumstances under which a revocation occurs.
|
|
|
|
|
|
#### <span id="p4.9.2">4.9.2. Who can request revocation</span>
|
|
|
|
|
|
As above.
|
|
|
|
|
|
#### <span id="p4.9.3">4.9.3. Procedure for revocation request</span>
|
|
|
|
|
|
The Subscriber logs in to her online account through the website at
|
|
|
http://www.cacert.org/ .
|
|
|
|
|
|
In any other event such as lost passwords or fraud, a dispute should be
|
|
|
filed by email at \< support AT cacert DOT org \>
|
|
|
|
|
|
#### <span id="p4.9.4">4.9.4. Revocation request grace period</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p4.9.5">4.9.5. Time within which CA must process the revocation request</span>
|
|
|
|
|
|
The revocation automated in the Web Interface for subscribers, and is
|
|
|
handled generally in less than a minute.
|
|
|
|
|
|
A filed dispute that requests a revocation should be handled within a
|
|
|
five business days, however the Arbitrator has discretion.
|
|
|
|
|
|
#### <span id="p4.9.6">4.9.6. Revocation checking requirement for relying parties</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p4.9.7">4.9.7. CRL issuance frequency (if applicable)</span>
|
|
|
|
|
|
A new CRL is issued after every certificate revocation.
|
|
|
|
|
|
#### <span id="p4.9.8">4.9.8. Maximum latency for CRLs (if applicable)</span>
|
|
|
|
|
|
The maximum latency between revocation and issuance of the CRL is 1
|
|
|
hour.
|
|
|
|
|
|
#### <span id="p4.9.9">4.9.9. On-line revocation/status checking availability</span>
|
|
|
|
|
|
OCSP is available at http://ocsp.cacert.org/ .
|
|
|
|
|
|
#### <span id="p4.9.10">4.9.10. On-line revocation checking requirements</span>
|
|
|
|
|
|
Relying parties must check up-to-date status before relying.
|
|
|
|
|
|
#### <span id="p4.9.11">4.9.11. Other forms of revocation advertisements available</span>
|
|
|
|
|
|
None.
|
|
|
|
|
|
#### <span id="p4.9.12">4.9.12. Special requirements re key compromise</span>
|
|
|
|
|
|
Subscribers are obliged to revoke certificates at the earliest
|
|
|
opportunity.
|
|
|
|
|
|
#### <span id="p4.9.13">4.9.13. Circumstances for suspension</span>
|
|
|
|
|
|
Suspension of certificates is not available.
|
|
|
|
|
|
#### <span id="p4.9.14">4.9.14. Who can request suspension</span>
|
|
|
|
|
|
Not applicable.
|
|
|
|
|
|
#### <span id="p4.9.15">4.9.15. Procedure for suspension request</span>
|
|
|
|
|
|
Not applicable.
|
|
|
|
|
|
#### <span id="p4.9.16">4.9.16. Limits on suspension period</span>
|
|
|
|
|
|
Not applicable.
|
|
|
|
|
|
### <span id="p4.10">4.10. Certificate status services</span>
|
|
|
|
|
|
#### <span id="p4.10.1">4.10.1. Operational characteristics</span>
|
|
|
|
|
|
OCSP is available at http://ocsp.cacert.org/ .
|
|
|
|
|
|
#### <span id="p4.10.2">4.10.2. Service availability</span>
|
|
|
|
|
|
OCSP is made available on an experimental basis.
|
|
|
|
|
|
#### <span id="p4.10.3">4.10.3. Optional features</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
### <span id="p4.11">4.11. End of subscription</span>
|
|
|
|
|
|
Certificates include expiry dates.
|
|
|
|
|
|
### <span id="p4.12">4.12. Key escrow and recovery</span>
|
|
|
|
|
|
#### <span id="p4.12.1">4.12.1. Key escrow and recovery policy and practices</span>
|
|
|
|
|
|
CAcert does not generate nor escrow subscriber keys.
|
|
|
|
|
|
#### <span id="p4.12.2">4.12.2. Session key encapsulation and recovery policy and practices</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
## <span id="p5">5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</span>
|
|
|
|
|
|
### <span id="p5.1">5.1. Physical controls</span>
|
|
|
|
|
|
Refer to Security Policy
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
|
|
|
|
|
|
- Site location and construction - SP2.1
|
|
|
- Physical access - SP2.3
|
|
|
|
|
|
#### <span id="p5.1.3">5.1.3. Power and air conditioning</span>
|
|
|
|
|
|
Refer to Security Policy 2.1.2
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
|
|
|
|
|
|
#### <span id="p5.1.4">5.1.4. Water exposures</span>
|
|
|
|
|
|
Refer to Security Policy 2.1.4
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
|
|
|
|
|
|
#### <span id="p5.1.5">5.1.5. Fire prevention and protection</span>
|
|
|
|
|
|
Refer to Security Policy 2.1.4
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
|
|
|
|
|
|
#### <span id="p5.1.6">5.1.6. Media storage</span>
|
|
|
|
|
|
Refer to Security Policy 4.3
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
|
|
|
|
|
|
#### <span id="p5.1.7">5.1.7. Waste disposal</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p5.1.8">5.1.8. Off-site backup</span>
|
|
|
|
|
|
Refer to Security Policy 4.3
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
|
|
|
|
|
|
### <span id="p5.2">5.2. Procedural controls</span>
|
|
|
|
|
|
#### <span id="p5.2.1">5.2.1. Trusted roles</span>
|
|
|
|
|
|
- **Technical teams:**
|
|
|
- User support personnel
|
|
|
- Systems Administrators -- critical and non-critical
|
|
|
- Softare Developers
|
|
|
- controllers of keys
|
|
|
|
|
|
Refer to Security Policy 9.1
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html))
|
|
|
- **Assurance:**
|
|
|
- Assurers
|
|
|
- Any others authorised under COD13
|
|
|
|
|
|
Refer to Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html))
|
|
|
- **Governance:**
|
|
|
- Directors (members of the CAcert Inc. committee, or "Board")
|
|
|
- Internal Auditor
|
|
|
- Arbitrator
|
|
|
|
|
|
#### <span id="p5.2.2">5.2.2. Number of persons required per task</span>
|
|
|
|
|
|
CAcert operates to the principles of *four eyes* and *dual control*. All
|
|
|
important roles require a minimum of two persons. The people may be
|
|
|
tasked to operate with an additional person observing (*four eyes*), or
|
|
|
with two persons controlling (*dual control*).
|
|
|
|
|
|
#### <span id="p5.2.3">5.2.3. Identification and authentication for each role</span>
|
|
|
|
|
|
All important roles are generally required to be assured at least to the
|
|
|
level of Assurer, as per AP. Refer to Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
|
|
|
|
|
|
**Technical.** Refer to Security Policy 9.1
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
|
|
|
|
|
|
#### <span id="p5.2.4">5.2.4. Roles requiring separation of duties</span>
|
|
|
|
|
|
Roles strive in general for separation of duties, either along the lines
|
|
|
of *four eyes principle* or *dual control*.
|
|
|
|
|
|
### <span id="p5.3">5.3. Personnel controls</span>
|
|
|
|
|
|
#### <span id="p5.3.1">5.3.1. Qualifications, experience, and clearance requirements</span>
|
|
|
|
|
|
<table data-border="1" data-cellpadding="5">
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td><strong>Role</strong></td>
|
|
|
<td><strong>Policy</strong></td>
|
|
|
<td><strong>Comments</strong></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td>Assurer</td>
|
|
|
<td><a
|
|
|
href="https://www.cacert.org/policy/AssurancePolicy.html">COD13</a></td>
|
|
|
<td>Passes Challenge, Assured to 100 points.</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td>Organisation Assurer</td>
|
|
|
<td><a
|
|
|
href="https://www.cacert.org/policy/OrganisationAssurancePolicy.html">COD11</a></td>
|
|
|
<td>Trained and tested by two supervising OAs.</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td>Technical</td>
|
|
|
<td>SM => COD08</td>
|
|
|
<td>Teams responsible for testing.</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td>Arbitrator</td>
|
|
|
<td><a
|
|
|
href="https://www.cacert.org/policy/DisputeResolutionPolicy.html">COD7</a></td>
|
|
|
<td>Experienced Assurers.</td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
<span class="figure">Table 5.3.1. Controls on Roles</span>
|
|
|
|
|
|
#### <span id="p5.3.2">5.3.2. Background check procedures</span>
|
|
|
|
|
|
Refer to Security Policy 9.1.3
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
|
|
|
|
|
|
#### <span id="p5.3.3">5.3.3. Training requirements</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p5.3.4">5.3.4. Retraining frequency and requirements</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p5.3.5">5.3.5. Job rotation frequency and sequence</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p5.3.6">5.3.6. Sanctions for unauthorized actions</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p5.3.7">5.3.7. Independent contractor requirements</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p5.3.8">5.3.8. Documentation supplied to personnel</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
### <span id="p5.4">5.4. Audit logging procedures</span>
|
|
|
|
|
|
Refer to Security Policy 4.2, 5
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
|
|
|
|
|
|
### <span id="p5.5">5.5. Records archival</span>
|
|
|
|
|
|
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:
|
|
|
|
|
|
<table data-border="1" data-cellpadding="5">
|
|
|
<colgroup>
|
|
|
<col style="width: 25%" />
|
|
|
<col style="width: 25%" />
|
|
|
<col style="width: 25%" />
|
|
|
<col style="width: 25%" />
|
|
|
</colgroup>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td><strong>Record</strong></td>
|
|
|
<td><strong>Nature</strong></td>
|
|
|
<td><strong>Exceptions</strong></td>
|
|
|
<td><strong>Documentation</strong></td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<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 class="odd">
|
|
|
<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 class="even">
|
|
|
<td>Organisation Assurance</td>
|
|
|
<td>COAP forms</td>
|
|
|
<td>as per subsidiary policies</td>
|
|
|
<td>Organisation Assurance Policy</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td>certificates and revocations</td>
|
|
|
<td>for reliance</td>
|
|
|
<td>7 years after termination</td>
|
|
|
<td>this CPS</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<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>
|
|
|
|
|
|
### <span id="p5.6">5.6. Key changeover</span>
|
|
|
|
|
|
Refer to Security Policy 9.2
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
|
|
|
|
|
|
### <span id="p5.7">5.7. Compromise and disaster recovery</span>
|
|
|
|
|
|
Refer to Security Policy 5, 6
|
|
|
([COD8](https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html)).
|
|
|
(Refer to [§1.4](#p1.4) for limitations to service.)
|
|
|
|
|
|
### <span id="p5.8">5.8. CA or RA termination</span>
|
|
|
|
|
|
#### <span id="p5.8.1">5.8.1 CA termination</span>
|
|
|
|
|
|
<s>If CAcert should terminate its operation or be taken over by another
|
|
|
organisation, the actions will be conducted according to a plan approved
|
|
|
by the CAcert Inc. Board.</s>
|
|
|
|
|
|
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.
|
|
|
|
|
|
<span class="change"> The CA cannot be transferrred to another
|
|
|
organisation. </span>
|
|
|
|
|
|
<s>In the event of takeover, the Board will decide if it is in the
|
|
|
interest of the Members to be converted to the new organisation. Members
|
|
|
will be notified about the conversion and transfer of the Member
|
|
|
information. Such takeover, conversion or transfer may involve
|
|
|
termination of this CPS and other documents. See §9.10.2. Members will
|
|
|
have reasonable time in which to file a related dispute after
|
|
|
notification (at least one month). See §9.13.</s>
|
|
|
|
|
|
- The ability to transfer is not given in any of CCA, PP or AP!
|
|
|
- The Board does not have the power to terminate a policy, that is the
|
|
|
role of policy group!
|
|
|
- The right to transfer was against the principles of the CAcert?
|
|
|
- Check Association Statutes....
|
|
|
|
|
|
<span class="strike"> New root keys and certificates will be made
|
|
|
available by the new organisation as soon as reasonably
|
|
|
practical.</span>
|
|
|
|
|
|
#### <span id="p5.8.2">5.8.2 RA termination</span>
|
|
|
|
|
|
When an Assurer desires to voluntarily terminates her responsibilities,
|
|
|
she does this by filing a dispute, and following the instructions of the
|
|
|
Arbitrator.
|
|
|
|
|
|
In the case of involuntary termination, the process is the same, save
|
|
|
for some other party filing the dispute.
|
|
|
|
|
|
## <span id="p6">6. TECHNICAL SECURITY CONTROLS</span>
|
|
|
|
|
|
### <span id="p6.1">6.1. Key Pair Generation and Installation</span>
|
|
|
|
|
|
#### <span id="p6.1.1">6.1.1. Key Pair Generation</span>
|
|
|
|
|
|
Subscribers generate their own Key Pairs.
|
|
|
|
|
|
#### <span id="p6.1.2">6.1.2. Subscriber Private key security</span>
|
|
|
|
|
|
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 [§9.6](#p9.6).
|
|
|
|
|
|
#### <span id="p6.1.3">6.1.3. Public Key Delivery to Certificate Issuer</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p6.1.4">6.1.4. CA Public Key delivery to Relying Parties</span>
|
|
|
|
|
|
The CA root certificates are distributed by these means:
|
|
|
|
|
|
- Published on the website of CAcert, in both HTTP and HTTPS.
|
|
|
- Included in Third-Party Software such as Browsers, Email-Clients.
|
|
|
Such suppliers are subject to the Third Party Vendor Agreement.
|
|
|
|
|
|
Third Party Vendor Agreement is early wip, only
|
|
|
|
|
|
#### <span id="p6.1.5">6.1.5. Key sizes</span>
|
|
|
|
|
|
No limitation is placed on Subscriber key sizes.
|
|
|
|
|
|
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
|
|
|
[§4.3.1](#p4.3.1).
|
|
|
|
|
|
OpenPGP Signing uses both RSA and DSA (1024 bits).
|
|
|
|
|
|
CAcert adds larger keys and hashes in line with general cryptographic
|
|
|
trends, and as supported by major software suppliers.
|
|
|
|
|
|
- old Class 3 SubRoot is signed with MD5
|
|
|
- likely this will clash with future plans of vendors to drop
|
|
|
acceptance of MD5
|
|
|
- Is this a concern?
|
|
|
- to users who have these certs, a lot?
|
|
|
- to audit, not much?
|
|
|
|
|
|
#### <span id="p6.1.6">6.1.6. Public key parameters generation and quality checking</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p6.1.7">6.1.7. Key Usage Purposes</span>
|
|
|
|
|
|
- This section probably needs to detail the key usage bits in the
|
|
|
certs.
|
|
|
|
|
|
CAcert roots are general purpose. Each root key may sign all of the
|
|
|
general purposes - client, server, code.
|
|
|
|
|
|
The website controls the usage purposes that may be signed. This is
|
|
|
effected by means of the 'template' system.
|
|
|
|
|
|
### <span id="p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</span>
|
|
|
|
|
|
#### <span id="p6.2.1">6.2.1. Cryptographic module standards and controls</span>
|
|
|
|
|
|
SubRoot keys are stored on a single machine which acts as a
|
|
|
Cryptographic Module, or *signing server*. It operates a single daemon
|
|
|
for signing only. The signing server has these security features:
|
|
|
|
|
|
- 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.
|
|
|
- The protocol over the dedicated link is a custom, simple request
|
|
|
protocol that only handles certificate signing requests.
|
|
|
- The daemon is designed not to reveal the key.
|
|
|
- The daemon incorporates a dead-man switch that monitors the one
|
|
|
webserver machine that requests access.
|
|
|
- The daemon shuts down if a bad request is detected.
|
|
|
- The daemon resides on an encrypted partition.
|
|
|
- The signing server can only be (re)started with direct systems
|
|
|
administration access.
|
|
|
- Physical Access to the signing server is under dual control.
|
|
|
|
|
|
See §5. and the Security Policy 9.3.1.
|
|
|
|
|
|
(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.)
|
|
|
|
|
|
1. What document is responsible for architecture? CPS? SM?
|
|
|
[website](https://wiki.cacert.org/HELP/7)? SM punts it to CPS, so
|
|
|
above stays.
|
|
|
2. There is no criteria on Architecture.
|
|
|
3. Old questions moved to SM.
|
|
|
4. See [CAcert Root key protection](https://wiki.cacert.org/HELP/7)
|
|
|
which should be deprecated by this CPS.
|
|
|
|
|
|
### <span id="p6.3">6.3. Other aspects of key pair management</span>
|
|
|
|
|
|
#### <span id="p6.3.1">6.3.1. Public key archival</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p6.3.2">6.3.2. Certificate operational periods and key pair usage periods</span>
|
|
|
|
|
|
The operational period of a certificate and its key pair depends on the
|
|
|
Assurance status of the Member, see [§1.4.5](#p1.4.5) and Assurance
|
|
|
Policy ([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
|
|
|
|
|
|
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
|
|
|
[cryptographic community](http://www.keylength.com/) and maximum limits
|
|
|
in generally available software. At time of writing this is 4096 bits.
|
|
|
|
|
|
### <span id="p6.4">6.4. Activation data</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
### <span id="p6.5">6.5. Computer security controls</span>
|
|
|
|
|
|
Refer to Security Policy.
|
|
|
|
|
|
### <span id="p6.6">6.6. Life cycle technical controls</span>
|
|
|
|
|
|
Refer to SM7 "Software Development".
|
|
|
|
|
|
### <span id="p6.7">6.7. Network security controls</span>
|
|
|
|
|
|
Refer to SM3.1 "Logical Security - Network".
|
|
|
|
|
|
### <span id="p6.8">6.8. Time-stamping</span>
|
|
|
|
|
|
Each server synchronises with NTP. No "timestamping" service is
|
|
|
currently offered.
|
|
|
|
|
|
- How does the signing server syncronise if only connected over
|
|
|
serial?
|
|
|
- How is timestamping done on records?
|
|
|
|
|
|
## <span id="p7">7. CERTIFICATE, CRL, AND OCSP PROFILES</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p7.1">7.1. Certificate profile</span>
|
|
|
|
|
|
#### <span id="p7.1.1">7.1.1. Version number(s)</span>
|
|
|
|
|
|
What versions of PGP are signed? v3? v4?
|
|
|
|
|
|
Issued X.509 certificates are of v3 form. The form of the PGP signatures
|
|
|
depends on several factors, therefore no stipulation.
|
|
|
|
|
|
#### <span id="p7.1.2">7.1.2. Certificate extensions</span>
|
|
|
|
|
|
Client certificates include the following extensions:
|
|
|
|
|
|
- basicConstraints=CA:FALSE (critical)
|
|
|
- keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
|
|
|
- extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC
|
|
|
- authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org
|
|
|
- crlDistributionPoints=URI:\<crlUri\> where \<crlUri\> is replaced
|
|
|
with the URI where the certificate revocation list relating to the
|
|
|
certificate is found
|
|
|
- subjectAltName=(as per [§3.1.1.](#p3.1.1)).
|
|
|
|
|
|
<!-- -->
|
|
|
|
|
|
- what about Client Certificates Adobe Signing extensions ?
|
|
|
- SubjectAltName should become critical if DN is removed
|
|
|
http://tools.ietf.org/html/rfc5280#section-4.2.1.6
|
|
|
|
|
|
Server certificates include the following extensions:
|
|
|
|
|
|
- basicConstraints=CA:FALSE (critical)
|
|
|
- keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
|
|
|
- extendedKeyUsage=clientAuth,serverAuth,nsSGC,msSGC
|
|
|
- authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org
|
|
|
- crlDistributionPoints=URI:\<crlUri\> where \<crlUri\> is replaced
|
|
|
with the URI where the certificate revocation list relating to the
|
|
|
certificate is found
|
|
|
- subjectAltName=(as per [§3.1.1.](#p3.1.1)).
|
|
|
|
|
|
Code-Signing certificates include the following extensions:
|
|
|
|
|
|
- basicConstraints=CA:FALSE (critical)
|
|
|
- keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
|
|
|
- extendedKeyUsage=emailProtection,clientAuth,codeSigning,msCodeInd,msCodeCom,msEFS,msSGC,nsSGC
|
|
|
- authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org
|
|
|
- crlDistributionPoints=URI:\<crlUri\> where \<crlUri\> is replaced
|
|
|
with the URI where the certificate revocation list relating to the
|
|
|
certificate is found
|
|
|
- subjectAltName=(as per [§3.1.1.](#p3.1.1)).
|
|
|
|
|
|
<!-- -->
|
|
|
|
|
|
- what about subjectAltName for Code-signing
|
|
|
|
|
|
OpenPGP key signatures currently do not include extensions. In the
|
|
|
future, a serial number might be included as an extension.
|
|
|
|
|
|
#### <span id="p7.1.3">7.1.3. Algorithm object identifiers</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p7.1.4">7.1.4. Name forms</span>
|
|
|
|
|
|
Refer to [§3.1.1](#p3.1.1).
|
|
|
|
|
|
#### <span id="p7.1.5">7.1.5. Name constraints</span>
|
|
|
|
|
|
Refer to [§3.1.1](#p3.1.1).
|
|
|
|
|
|
#### <span id="p7.1.6">7.1.6. Certificate policy object identifier</span>
|
|
|
|
|
|
The following OIDs are defined and should be incorporated into
|
|
|
certificates:
|
|
|
|
|
|
<table data-border="1" data-cellpadding="5">
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td>OID</td>
|
|
|
<td>Type/Meaning</td>
|
|
|
<td>Comment</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td>1.3.6.1.4.1.18506.4.4</td>
|
|
|
<td>Certification Practice Statement</td>
|
|
|
<td>(this present document)</td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
Versions are defined by additional numbers appended such as .1.
|
|
|
|
|
|
#### <span id="p7.1.7">7.1.7. Usage of Policy Constraints extension</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p7.1.8">7.1.8. Policy qualifiers syntax and semantics</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p7.1.9">7.1.9. Processing semantics for the critical Certificate Policies extension</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
### <span id="p7.2">7.2. CRL profile</span>
|
|
|
|
|
|
#### <span id="p7.2.1">7.2.1. Version number(s)</span>
|
|
|
|
|
|
CRLs are created in X.509 v2 format.
|
|
|
|
|
|
#### <span id="p7.2.2">7.2.2. CRL and CRL entry extensions</span>
|
|
|
|
|
|
No extensions.
|
|
|
|
|
|
### <span id="p7.3">7.3. OCSP profile</span>
|
|
|
|
|
|
#### <span id="p7.3.1">7.3.1. Version number(s)</span>
|
|
|
|
|
|
The OCSP responder operates in Version 1.
|
|
|
|
|
|
#### <span id="p7.3.2">7.3.2. OCSP extensions</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
## <span id="p8">8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS</span>
|
|
|
|
|
|
There are two major threads of assessment:
|
|
|
|
|
|
- **Systems Audit**. 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.
|
|
|
- **Code Audit**. Analyses the source code. This is conducted at two
|
|
|
levels: Security concepts at the web applications level, and source
|
|
|
code security and bugs review.
|
|
|
|
|
|
See the Audit page at
|
|
|
[wiki.cacert.org/Audit/](https://wiki.cacert.org/Audit/) for more
|
|
|
information.
|
|
|
|
|
|
### <span id="p8.1">8.1. Frequency or circumstances of assessment</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
- **Systems Audit**. <span class="q"> The first phase of the first
|
|
|
audit is nearing completion. The second phase starts in earnest when
|
|
|
documentation is in effect, at lease as DRAFT under PoP. As the
|
|
|
second phase is dependent on this CPS and the Security Policy, they
|
|
|
will be in effect as DRAFT at least before the first audit is
|
|
|
completed. Only prior and completed audits can be reported here.
|
|
|
</span>
|
|
|
- **Code Audit**. <span class="q"> A complete review of entire source
|
|
|
code has not yet been completed. </span>
|
|
|
|
|
|
### <span id="p8.2">8.2. Identity/qualifications of assessor</span>
|
|
|
|
|
|
**Systems Auditors.** 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.
|
|
|
|
|
|
**Code Auditors.** See Security Policy, sections 7, 9.1.
|
|
|
|
|
|
### <span id="p8.3">8.3. Assessor's relationship to assessed entity</span>
|
|
|
|
|
|
Specific internal restrictions on audit personnel:
|
|
|
|
|
|
- Must be Assured by CAcert Assurers and must be background checked.
|
|
|
- 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.
|
|
|
- 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.
|
|
|
- The Auditor is required to declare to CAcert all potential conflicts
|
|
|
of interest on an ongoing basis.
|
|
|
|
|
|
Specific external restrictions on audit personnel:
|
|
|
|
|
|
- Should have a verifiable and lengthy history in user privacy and
|
|
|
user security.
|
|
|
- Must not have worked for a competitive organisation.
|
|
|
- Must not have worked for national security, intelligence, LEO or
|
|
|
similar agencies.
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p8.4">8.4. Topics covered by assessment</span>
|
|
|
|
|
|
Systems Audits are generally conducted to criteria. CAcert requires that
|
|
|
the criteria are open:
|
|
|
|
|
|
- Published. The criteria must be reviewable by all interested
|
|
|
parties.
|
|
|
- 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.)
|
|
|
- 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.
|
|
|
- Applicable. The criteria should relate directly and unambiguously to
|
|
|
a need of the identified interested parties (Members, Relying
|
|
|
Parties, Subscribers, Assurers).
|
|
|
|
|
|
See [DRC](http://rossde.com/CA_review/) 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).
|
|
|
|
|
|
### <span id="p8.5">8.5. Actions taken as a result of deficiency</span>
|
|
|
|
|
|
See the current [Audit Done list](https://wiki.cacert.org/Audit/Done)
|
|
|
for work completed, and [Audit Todo
|
|
|
list](https://wiki.cacert.org/AuditToDo) for work in progress.
|
|
|
|
|
|
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.
|
|
|
|
|
|
The
|
|
|
[wiki.cacert.org/AuditDirectives](https://wiki.cacert.org/AuditDirectives)
|
|
|
documents issued directives and actions.
|
|
|
|
|
|
### <span id="p8.6">8.6. Communication of results</span>
|
|
|
|
|
|
Current and past Audit information is available at
|
|
|
[wiki.CAcert.org/Audit/](https://wiki.cacert.org/Audit/). CAcert runs an
|
|
|
open disclosure policy and Audit is no exception.
|
|
|
|
|
|
This CPS and other documents are subject to the process in Policy on
|
|
|
Policy ([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html)).
|
|
|
Audits cover the overall processes more than any one document, and
|
|
|
documents may vary even as Audit reports are delivered.
|
|
|
|
|
|
## <span id="p9">9. OTHER BUSINESS AND LEGAL MATTERS</span>
|
|
|
|
|
|
### <span id="p9.1">9.1. Fees</span>
|
|
|
|
|
|
The current fees structure is posted at
|
|
|
[wiki.cacert.org/Price](https://wiki.cacert.org/Price). Changes to the
|
|
|
fees structure will be announced from time to time on the
|
|
|
[blog](https://blog.cacert.org/). CAcert retains the right to charge
|
|
|
fees for services. All fees are non-refundable.
|
|
|
|
|
|
### <span id="p9.2">9.2. Financial responsibility</span>
|
|
|
|
|
|
Financial risks are dealt with primarily by the Dispute Resolution
|
|
|
Policy
|
|
|
([COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html)).
|
|
|
|
|
|
#### <span id="p9.2.1">9.2.1. Insurance coverage</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p9.2.2">9.2.2. Other assets</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p9.2.3">9.2.3. Insurance or warranty coverage for end-entities</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
### <span id="p9.3">9.3. Confidentiality of business information</span>
|
|
|
|
|
|
#### <span id="p9.3.1">9.3.1. Scope of confidential information</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p9.4">9.4. Privacy of personal information</span>
|
|
|
|
|
|
Privacy is covered by the CCA (COD9) and the Privacy Policy
|
|
|
([COD5](https://www.cacert.org/policy/PrivacyPolicy.html)).
|
|
|
|
|
|
#### <span id="p9.4.1">9.4.1. Privacy plan</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p9.4.2">9.4.2. Information treated as private</span>
|
|
|
|
|
|
Member's Date of Birth and "Lost Password" questions are treated as
|
|
|
fully private.
|
|
|
|
|
|
#### <span id="p9.4.3">9.4.3. Information not deemed private</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
Under Assurance Policy
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)) the
|
|
|
Member's status (as Assured, Assurer, etc) is available to other
|
|
|
Members.
|
|
|
|
|
|
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).
|
|
|
|
|
|
#### <span id="p9.4.4">9.4.4. Responsibility to protect private information</span>
|
|
|
|
|
|
CAcert is a privacy organisation and takes privacy more seriously. Any
|
|
|
privacy issue may be referred to dispute resolution.
|
|
|
|
|
|
#### <span id="p9.4.5">9.4.5. Notice and consent to use private information</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p9.4.6">9.4.6. Disclosure pursuant to judicial or administrative process</span>
|
|
|
|
|
|
Any disclosure pursuant to process from foreign courts (or similar) is
|
|
|
controlled by the Arbitrator.
|
|
|
|
|
|
#### <span id="p9.4.7">9.4.7. Other information disclosure circumstances</span>
|
|
|
|
|
|
None.
|
|
|
|
|
|
### <span id="p9.5">9.5. Intellectual property rights</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p9.5.1">9.5.1. Ownership and Licence</span>
|
|
|
|
|
|
Assets that fall under the control of CCS must be transferred to CAcert.
|
|
|
See PoP 6.2
|
|
|
([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html#6.2)), CCA 1.3
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#1.3)).
|
|
|
That is, CAcert is free to use, modify, distribute, and otherwise
|
|
|
conduct the business of the CA as CAcert sees fit with the asset.
|
|
|
|
|
|
#### <span id="p9.5.2">9.5.2. Brand</span>
|
|
|
|
|
|
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
|
|
|
[m20070917.5](https://wiki.cacert.org/TopMinutes-20070917).
|
|
|
|
|
|
#### <span id="p9.5.3">9.5.3. Documents</span>
|
|
|
|
|
|
CAcert owns or requires full control over its documents, especially
|
|
|
those covered by CCS. See PoP 6.2
|
|
|
([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html#6.2)).
|
|
|
Contributors transfer the rights, see CCA 1.3
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#1.3)).
|
|
|
Contributors warrant that they have the right to transfer.
|
|
|
|
|
|
Documents are generally licensed under free and open licence. See
|
|
|
[wiki.cacert.org/PolicyDrafts/DocumentLicence](https://wiki.cacert.org/PolicyDrafts/DocumentLicence).
|
|
|
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
|
|
|
([COD1](https://www.cacert.org/policy/PolicyOnPolicy.html#6.4)), CCA 1.3
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#1.3)).
|
|
|
|
|
|
#### <span id="p9.5.4">9.5.4. Code</span>
|
|
|
|
|
|
CAcert owns its code or requires full control over code in use by means
|
|
|
of a free and open licence. See CCS.
|
|
|
|
|
|
See the (new, wip)
|
|
|
[SourceCodeManifesto](https://svn.cacert.org/CAcert/Software/BirdShack/Documents/SourceCodeManifesto.html).
|
|
|
Maybe this can replace these two paras?
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### <span id="p9.5.5">9.5.5. Certificates and Roots</span>
|
|
|
|
|
|
CAcert asserts its intellectual property rights over certificates issued
|
|
|
to Members and over roots. See CCA 4.4
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#4.4)),
|
|
|
CCS. The certificates may only be used by Members under
|
|
|
[COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#4.4),
|
|
|
and, by others under the licences offered, such as Root Distribution
|
|
|
License
|
|
|
([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
|
|
|
|
|
|
### <span id="p9.6">9.6. Representations and warranties</span>
|
|
|
|
|
|
**Members.** All Members of the Community agree to the CAcert Community
|
|
|
Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)),
|
|
|
which is the primary document for representations and warranties.
|
|
|
Members include Subscribers, Relying Parties, Registration Agents and
|
|
|
the CA itself.
|
|
|
|
|
|
**RAs.** Registration Agents are obliged additionally by Assurance
|
|
|
Policy, especially 3.1, 4.1
|
|
|
([COD13](https://www.cacert.org/policy/AssurancePolicy.html)).
|
|
|
|
|
|
**CA.** The CA is obliged additionally by the CCS.
|
|
|
|
|
|
**Third Party Vendors.** Distributors of the roots are offered the <span
|
|
|
class="q">wip</span> 3rd-Party Vendors - Disclaimer and Licence (3PV-DaL
|
|
|
=\> CODx) and are offered <span class="q">wip</span> the same deal as
|
|
|
Members to the extent that they agree to be Members in the Community.
|
|
|
<span class="q">wip</span>
|
|
|
|
|
|
### <span id="p9.7">9.7. Disclaimers of Warranties</span>
|
|
|
|
|
|
Persons who have not accepted the above Agreements are offered the Root
|
|
|
Distribution License
|
|
|
([COD14](https://www.cacert.org/policy/RootDistributionLicense.html)).
|
|
|
Any representations and warranties are strictly limited to nominal
|
|
|
usage. In essence, NRPs may USE but must not RELY.
|
|
|
|
|
|
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 [§1.4](#p1.4). CAcert seeks to provide an adequate
|
|
|
minimum level of quality in operations for its Members without undue
|
|
|
risks to NRPs. See
|
|
|
[Principles](https://svn.cacert.org/CAcert/principles.html).
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p9.8">9.8. Limitations of liability</span>
|
|
|
|
|
|
### <span id="p9.8.1">9.8.1 Non-Related Persons</span>
|
|
|
|
|
|
CAcert on behalf of related parties (RAs, Subscribers, etc) and itself
|
|
|
disclaims all liability to NRPs in their usage of CA's certificates. See
|
|
|
[COD4](https://www.cacert.org/policy/RootDistributionLicense.html).
|
|
|
|
|
|
### <span id="p9.8.2">9.8.2 Liabilities Between Members</span>
|
|
|
|
|
|
Liabilities between Members are dealt with by internal dispute
|
|
|
resolution, which rules on liability and any limits. See [§9.13](#9.13).
|
|
|
|
|
|
### <span id="p9.9">9.9. Indemnities</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
### <span id="p9.10">9.10. Term and termination</span>
|
|
|
|
|
|
#### <span id="p9.10.1">9.10.1. Term</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p9.10.2">9.10.2. Termination</span>
|
|
|
|
|
|
Members file a dispute to terminate their agreement. See [§9.13](#p9.13)
|
|
|
and CCA 3.3
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#3.3)).
|
|
|
|
|
|
Documents are varied (including terminated) under
|
|
|
[COD1](https://www.cacert.org/policy/PolicyOnPolicy.html).
|
|
|
|
|
|
For termination of the CA, see [§5.8.1](#p5.8.1).
|
|
|
|
|
|
#### <span id="p9.10.3">9.10.3. Effect of termination and survival</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
### <span id="p9.11">9.11. Individual notices and communications with participants</span>
|
|
|
|
|
|
All participants are obliged to keep their listed primary email
|
|
|
addresses in good working order. See CCA 3.5
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#3.5)).
|
|
|
|
|
|
### <span id="p9.12">9.12. Amendments</span>
|
|
|
|
|
|
Amendments to the CPS are controlled by
|
|
|
[COD1](https://www.cacert.org/policy/PolicyOnPolicy.html). Any changes
|
|
|
in Member's Agreements are notified under CCA 3.4
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html#3.4)).
|
|
|
|
|
|
### <span id="p9.13">9.13. Dispute resolution provisions</span>
|
|
|
|
|
|
CAcert provides a forum and facility for any Member or other related
|
|
|
party to file a dispute.
|
|
|
|
|
|
- The CAcert Dispute Resolution Policy
|
|
|
([COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html))
|
|
|
includes rules for dispute resolution.
|
|
|
- Filing is done via email to \< support AT cacert DOT org \>
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p9.14">9.14. Governing law</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
### <span id="p9.15">9.15. Compliance with Applicable Law</span>
|
|
|
|
|
|
### <span id="p9.15.1">9.15.1 Digital Signature Law</span>
|
|
|
|
|
|
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.
|
|
|
|
|
|
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 [§1.4.3](#p1.4.3).
|
|
|
However, certificates may play a part in larger signing applications.
|
|
|
See [§1.4.1](#p1.4.1) for "digital signing" certificates. These
|
|
|
applications may impose significant obligations, risks and liabilities
|
|
|
on the parties.
|
|
|
|
|
|
### <span id="p9.15.2">9.15.2 Privacy Law</span>
|
|
|
|
|
|
See the Privacy Policy
|
|
|
([COD5](https://www.cacert.org/policy/PrivacyPolicy.html)).
|
|
|
|
|
|
### <span id="p9.15.3">9.15.3 Legal Process from External Forums</span>
|
|
|
|
|
|
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 [§9.13](#p9.13) and
|
|
|
[COD7](https://www.cacert.org/policy/DisputeResolutionPolicy.html). 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.
|
|
|
|
|
|
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).
|
|
|
|
|
|
### <span id="p9.16">9.16. Miscellaneous provisions</span>
|
|
|
|
|
|
#### <span id="p9.16.1">9.16.1. Entire agreement</span>
|
|
|
|
|
|
All Members of the Community agree to the CAcert Community Agreement
|
|
|
([COD9](https://www.cacert.org/policy/CAcertCommunityAgreement.html)).
|
|
|
This agreement also incorporates other key documents, being this CPS,
|
|
|
DRP and PP. See CCA 4.2.
|
|
|
|
|
|
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
|
|
|
[www.cacert.org/policy/](https://www.cacert.org/policy/). 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.
|
|
|
|
|
|
<span class="q">2nd half of this section can be transfered over to PoP,
|
|
|
only a reference to PoP 5.4 to remain (see [Changes to PoP
|
|
|
p20130223](https://wiki.cacert.org/PolicyDecisions#p20130223))
|
|
|
</span>
|
|
|
|
|
|
#### <span id="p9.16.2">9.16.2. Assignment</span>
|
|
|
|
|
|
The rights within CCA may not be ordinarily assigned.
|
|
|
|
|
|
#### <span id="p9.16.3">9.16.3. Severability</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
#### <span id="p9.16.4">9.16.4. Enforcement (attorneys' fees and waiver of rights)</span>
|
|
|
|
|
|
The Arbitrator will specify fees and remedies, if any.
|
|
|
|
|
|
#### <span id="p9.16.5">9.16.5. Force Majeure</span>
|
|
|
|
|
|
No stipulation.
|
|
|
|
|
|
## ---This is the end of the Policy---
|