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

3042 lines
108 KiB

<span class="center">
The proper policy document is located
[on the CAcert
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]( and
[Bug \#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
- to fixes
- wiki redirects to redirected link fixes
- img src images/ fixes
- .php to .html fixes per [Bug
- 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%">
<col style="width: 50%" />
<col style="width: 50%" />
<tr class="odd">
<td>Name: CAcert CPS and CP <a
style="color: steelblue">COD6</a><br />
Status: DRAFT <a
href="">p20111113</a><br />
Caveat: this document is already <a
the main website in DRAFT</a>. p20111113.<br />
Creation date: 20060726<br />
Changes: <span class="change">p20111113, 20130309</span><br />
Licence: <a href=""
style="color: steelblue"
title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP. More at">CC-by-sa+DRP</a></td>
<td style="text-align: right;"><a
src="images/cacert-draft.png" style="border-style: none;" width="88"
height="31" alt="CPS Status - DRAFT" /></a></td>
# CAcert CPS and CP
<div style="font size:-1;">
- [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.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.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.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.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.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.1. Certificate profile](#p7.1)
- [7.2. CRL profile](#p7.2)
- [7.3. OCSP profile](#p7.3)
- [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.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
- [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)
## <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
- The document is structured according to Chokhani, et al,
[RFC3647](, [chapter
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: (x=approved
.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
- 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
- <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.
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](
CAcert is a Community formed of Members who agree to the [CAcert
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
#### <span id="p1.3.3">1.3.3. Subscribers</span>
CAcert issues certificates to Members only. Such Members then become
#### <span id="p1.3.4">1.3.4. Relying parties</span>
A relying party is a Member, having agreed to the CAcert Community
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
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
**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
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">
<tr class="odd">
<th colspan="2"><em>Type</em></th>
<th colspan="2"><em>Appropriate Certificate uses</em></th>
<tr class="even">
<tr class="odd">
<th rowspan="2">Server</th>
<th>web server encryption</th>
<th>enables encryption</th>
<tr class="even">
<th>embedded server authentication</th>
<th>mail servers, IM-servers</th>
<tr class="odd">
<th rowspan="4">Client</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 class="even">
<th>client authentication</th>
<th>the nodes must be secure</th>
<tr class="odd">
<th>web based signature applications</th>
<th>the certificate authenticates only. See <a
<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
<tr class="odd">
<th>Authenticode, ElfSign, Java</th>
<th>Code Signing</th>
<th>Signatures on packages are evidence of their Membership and
indicative of Identity</th>
<tr class="even">
<th>Key Signing</th>
<th>Signatures on Member Keys are evidence of their Membership and
indicative of Identity</th>
<tr class="odd">
<th>OCSP, Timestamping</th>
<th>Only available to CAcert Systems Administrators, as controlled by
Security Policy</th>
<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
- CAcert client certificates can be used to enable encryption
protection in email clients. (See [§1.4.3](#p1.4.3) for caveat on
- 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
- 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
#### <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
- **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
**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">
<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%" />
<tr class="odd">
<th colspan="4"><em>Level of Assurance</em></th>
<tr class="even">
<th colspan="2">Members †</th>
<th colspan="2">Assured Members</th>
<td> </td>
<tr class="odd">
<th><em>Class of Root</em></th>
<tr class="even">
<th>Top level<br />
<td>Signs other CAcert SubRoots only.</td>
<tr class="odd">
<th><strong>Member</strong><br />
<td>† For Members meeting basic checks in <a
href="#p4.2.2">§4.2.2</a><br />
(Reliance is undefined.)</td>
<tr class="even">
<th><strong>Assured</strong><br />
<td>Assured Members only.<br />
Fully intended for reliance.</td>
<tr class="odd">
<th><strong>Organisation</strong><br />
<td>Assured Organisation Members only.<br />
Fully intended for reliance.</td>
<tr class="even">
<th>Expiry of Certificates</th>
<th colspan="2">6 months</th>
<th colspan="2">24 months</th>
<tr class="odd">
<th colspan="2">client, server</th>
<th colspan="2">wildcard, subjectAltName</th>
<td>(Inclusive to the left.)</td>
<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">
<col style="width: 16%" />
<col style="width: 16%" />
<col style="width: 16%" />
<col style="width: 16%" />
<col style="width: 16%" />
<col style="width: 16%" />
<tr class="odd">
<th colspan="3"><em>Level of Assurance</em></th>
<tr class="even">
<th colspan="2">Members</th>
<th>Assured Members</th>
<td> </td>
<tr class="odd">
<th><em>Class of Root</em></th>
<tr class="even">
<th>Class<br />
<td>Available for all Members,<br />
reliance is undefined.</td>
<tr class="odd">
<th>Class<br />
<td>Assured Members only.<br />
Intended for Reliance.</td>
<tr class="even">
<th>Expiry of Certificates</th>
<th colspan="2">6 months</th>
<th>24 months</th>
<tr class="odd">
<th>Types available</th>
<th colspan="2">simple only</th>
<th>wildcard, subjectAltName</th>
<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
### <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
#### <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
[]( .
- Send email to \< support AT cacert DOT org \>
- IRC: \#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]( 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
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
**<span id="d_community">Community</span>**. The group of Members who
agree to the CAcert Community Agreement
([COD9]( 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
**<span id="d_name">Name</span>**. As defined in the Assurance Policy
([COD13](, 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
**<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
**<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.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](, 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
### <span id="p2.3">2.3. Time or frequency of publication</span>
Root and Intermediate Certificates and CRLs are made available on
### <span id="p2.4">2.4. Access controls on repositories</span>
No stipulation.
### <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]( 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]( filed on
- O-Admin must verify as per
- 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= 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
#### <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]( 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
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
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
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](, 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:
<tr class="odd">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="even">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<tr class="even">
<td><a href="">Registry</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="even">
<td><a href="">Registry</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<tr class="even">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a> (JET
<tr class="even">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<tr class="even">
<td><a href="">Registry</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<tr class="even">
<tr class="odd">
<td><a href="">Registry</a></td>
(section 2.1.2)</td>
<tr class="even">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="even">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<tr class="even">
<td><a href="">Registry</a></td>
<tr class="odd">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a> (JET
<tr class="even">
<td><a href="">Registry</a></td>
<td><a href="">Policy</a>
(managed by .ch registry)</td>
<tr class="odd">