summaryrefslogtreecommitdiff
path: root/www/policy/CertificationPracticeStatement.html
diff options
context:
space:
mode:
Diffstat (limited to 'www/policy/CertificationPracticeStatement.html')
-rw-r--r--www/policy/CertificationPracticeStatement.html122
1 files changed, 61 insertions, 61 deletions
diff --git a/www/policy/CertificationPracticeStatement.html b/www/policy/CertificationPracticeStatement.html
index fed7001..21c3903 100644
--- a/www/policy/CertificationPracticeStatement.html
+++ b/www/policy/CertificationPracticeStatement.html
@@ -290,9 +290,9 @@ Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licenc
<!-- *************************************************************** -->
-<h2><a id="p1">1. INTRODUCTION</a></h2>
+<h2 id="p1">1. INTRODUCTION</h2>
-<h3><a id="p1.1">1.1. Overview</a></h3>
+<h3 id="p1.1">1.1. Overview</h3>
<p>
This document is the Certification Practice Statement (CPS) of
@@ -304,7 +304,7 @@ including Assurers, Members, and CAcert itself.
</p>
-<h3><a id="p1.2">1.2. Document name and identification</a></h3>
+<h3 id="p1.2">1.2. Document name and identification</h3>
<p>
This document is the Certification Practice Statement (CPS) of CAcert.
@@ -363,7 +363,7 @@ except where explicitly deferred to.
See also <a href="#p1.5.1">1.5.1 Organisation Administering the Document</a>.
</p>
-<h3><a id="p1.3">1.3. PKI participants</a></h3>
+<h3 id="p1.3">1.3. PKI participants</h3>
<p>
The CA is legally operated by CAcert Incorporated,
an Association registered in 2002 in
@@ -383,19 +383,19 @@ with the <em>Association Members</em>, which latter are
not referred to anywhere in this CPS.)
</p>
-<h4><a id="p1.3.1">1.3.1. Certification authorities</a></h4>
+<h4 id="p1.3.1">1.3.1. Certification authorities</h4>
<p>
CAcert does not issue certificates to external
intermediate CAs under the present CPS.
</p>
-<h4><a id="p1.3.2">1.3.2. Registration authorities</a></h4>
+<h4 id="p1.3.2">1.3.2. Registration authorities</h4>
<p>
Registration Authorities (RAs) are controlled under Assurance Policy
(<a href="https://www.cacert.org/policy/AssurancePolicy.html">COD13</a>).
</p>
-<h4><a id="p1.3.3">1.3.3. Subscribers</a></h4>
+<h4 id="p1.3.3">1.3.3. Subscribers</h4>
<p>
CAcert issues certificates to Members only.
@@ -403,7 +403,7 @@ Such Members then become Subscribers.
</p>
-<h4><a id="p1.3.4">1.3.4. Relying parties</a></h4>
+<h4 id="p1.3.4">1.3.4. Relying parties</h4>
<p>
A relying party is a Member,
@@ -414,7 +414,7 @@ who, in the act of using a CAcert certificate,
makes a decision on the basis of that certificate.
</p>
-<h4><a id="p1.3.5">1.3.5. Other participants</a></h4>
+<h4 id="p1.3.5">1.3.5. Other participants</h4>
<p>
<strong>Member.</strong>
@@ -453,7 +453,7 @@ No other rights nor relationship is implied or offered.
</p>
-<h3><a id="p1.4">1.4. Certificate usage</a></h3>
+<h3 id="p1.4">1.4. Certificate usage</h3>
<p>CAcert serves as issuer of certificates for
individuals, businesses, governments, charities,
@@ -552,7 +552,7 @@ and risks, liabilities and obligations in
<div class="c figure">Table 1.4. Types of Certificate</div>
-<h4><a id="p1.4.1">1.4.1. Appropriate certificate uses</a></h4>
+<h4 id="p1.4.1">1.4.1. Appropriate certificate uses</h4>
<p>
General uses.
@@ -589,7 +589,7 @@ General uses.
</li></ul>
-<h4><a id="p1.4.2">1.4.2. Prohibited certificate uses</a></h4>
+<h4 id="p1.4.2">1.4.2. Prohibited certificate uses</h4>
<p>
CAcert certificates are not designed, intended, or authorised for
the following applications:
@@ -603,7 +603,7 @@ the following applications:
or severe environmental damage.
</li></ul>
-<h4><a id="p1.4.3">1.4.3. Unreliable Applications</a></h4>
+<h4 id="p1.4.3">1.4.3. Unreliable Applications</h4>
<p>
CAcert certificates are not designed nor intended for use in
@@ -639,7 +639,7 @@ for these applications:
</li></ul>
-<h4><a id="p1.4.4">1.4.4. Limited certificate uses</a></h4>
+<h4 id="p1.4.4">1.4.4. Limited certificate uses</h4>
<p>
By contract or within a specific environment
@@ -663,7 +663,7 @@ any harm or liability caused by such usage.
policy or other external regime agreed by the parties.
</p>
-<h4><a id="p1.4.5">1.4.5. Roots and Names</a></h4>
+<h4 id="p1.4.5">1.4.5. Roots and Names</h4>
<p>
<strong>Named Certificates.</strong>
@@ -811,19 +811,19 @@ and will be submitted to vendors via the (Top-level) Root.
<div class="c figure">Table 1.4.5.b Certificate under Audit Roots</div>
-<h3><a id="p1.5">1.5. Policy administration</a></h3>
+<h3 id="p1.5">1.5. Policy administration</h3>
<p>See <a href="#p1.2">1.2 Document Name and Identification</a>
for general scope of this document.</p>
-<h4><a id="p1.5.1">1.5.1. Organization administering the document</a></h4>
+<h4 id="p1.5.1">1.5.1. Organization administering the document</h4>
<p>
This document is administered by the policy group of
the CAcert Community under Policy on Policy (<a href="https://www.cacert.org/policy/PolicyOnPolicy.html">COD1</a>).
</p>
-<h4><a id="p1.5.2">1.5.2. Contact person</a></h4>
+<h4 id="p1.5.2">1.5.2. Contact person</h4>
<p>
For questions including about this document:
</p>
@@ -836,14 +836,14 @@ For questions including about this document:
<li>IRC: irc.cacert.org #CAcert (ssl port 7000, non-ssl port 6667)</li>
</ul>
-<h4><a id="p1.5.3">1.5.3. Person determining CPS suitability for the policy</a></h4>
+<h4 id="p1.5.3">1.5.3. Person determining CPS suitability for the policy</h4>
<p>
This CPS and all other policy documents are managed by
the policy group, which is a group of Members of the
Community found at policy forum. See discussion forums above.
</p>
-<h4><a id="p1.5.4">1.5.4. CPS approval procedures</a></h4>
+<h4 id="p1.5.4">1.5.4. CPS approval procedures</h4>
<p>
CPS is controlled and updated according to the
Policy on Policy
@@ -862,14 +862,14 @@ The process is modelled after some elements of
the RFC process by the IETF.
</p>
-<h4><a id="p1.5.5">1.5.5 CPS updates</a></h4>
+<h4 id="p1.5.5">1.5.5 CPS updates</h4>
<p>
As per above.
</p>
-<h3><a id="p1.6">1.6. Definitions and acronyms</a></h3>
+<h3 id="p1.6">1.6. Definitions and acronyms</h3>
<p>
<strong><a id="d_cert">Certificate</a></strong>.
@@ -1040,10 +1040,10 @@ As per above.
<!-- *************************************************************** -->
-<h2><a id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</a></h2>
+<h2 id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</h2>
-<h3><a id="p2.1">2.1. Repositories</a></h3>
+<h3 id="p2.1">2.1. Repositories</h3>
<p>
CAcert operates no repositories in the sense
@@ -1057,7 +1057,7 @@ there are means for Members to search, retrieve
and verify certain data about themselves and others.
</p>
-<h3><a id="p2.2">2.2. Publication of certification information</a></h3>
+<h3 id="p2.2">2.2. Publication of certification information</h3>
<p>
CAcert publishes:
@@ -1076,24 +1076,24 @@ certificates is presumed to be public and published, once
issued and delivered to the Member.
</p>
-<h3><a id="p2.3">2.3. Time or frequency of publication</a></h3>
+<h3 id="p2.3">2.3. Time or frequency of publication</h3>
<p>
Root and Intermediate Certificates and CRLs are
made available on issuance.
</p>
-<h3><a id="p2.4">2.4. Access controls on repositories</a></h3>
+<h3 id="p2.4">2.4. Access controls on repositories</h3>
<p> No stipulation. </p>
<!-- *************************************************************** -->
-<h2><a id="p3">3. IDENTIFICATION AND AUTHENTICATION</a></h2>
+<h2 id="p3">3. IDENTIFICATION AND AUTHENTICATION</h2>
-<h3><a id="p3.1">3.1. Naming</a></h3>
+<h3 id="p3.1">3.1. Naming</h3>
-<h4><a id="p3.1.1">3.1.1. Types of names</a></h4>
+<h4 id="p3.1.1">3.1.1. Types of names</h4>
<p>
<strong>Client Certificates.</strong>
@@ -1201,13 +1201,13 @@ Email addresses are verified according to
<a href="#p4.2.2">&sect;4.2.2.</a>
</p>
-<h4><a id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</a></h4>
+<h4 id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</h4>
<p>
See <a href="#p1.4.5">&sect;1.4.5</a>.
</p>
-<h4><a id="p3.1.4">3.1.4. Rules for interpreting various name forms</a></h4>
+<h4 id="p3.1.4">3.1.4. Rules for interpreting various name forms</h4>
<p>
Interpretation of Names is controlled by the Assurance Policy,
is administered by means of the Member's account,
@@ -1217,7 +1217,7 @@ should be expected as fraud (e.g., phishing)
may move too quickly for policies to fully document rules.
</p>
-<h4><a id="p3.1.5">3.1.5. Uniqueness of names</a></h4>
+<h4 id="p3.1.5">3.1.5. Uniqueness of names</h4>
<p>
Uniqueness of Names within certificates is not guaranteed.
@@ -1232,7 +1232,7 @@ Domain names and email address
can only be registered to one Member.
</p>
-<h4><a id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</a></h4>
+<h4 id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</h4>
<p>
Organisation Assurance Policy
@@ -1243,7 +1243,7 @@ See
<a href="#p9.13">&sect;9.13</a>.
</p>
-<h4><a id="p3.1.7">3.1.7. International Domain Names</a></h4>
+<h4 id="p3.1.7">3.1.7. International Domain Names</h4>
<p>
Certificates containing International Domain Names, being those containing a
@@ -1476,7 +1476,7 @@ This criteria will apply to the email address and server host name fields for al
The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list.
</p>
-<h3><a id="p3.2">3.2. Initial Identity Verification</a></h3>
+<h3 id="p3.2">3.2. Initial Identity Verification</h3>
<p>
Identity verification is controlled by the
@@ -1486,7 +1486,7 @@ the following is representative and brief only.
</p>
-<h4><a id="p3.2.1">3.2.1. Method to prove possession of private key</a></h4>
+<h4 id="p3.2.1">3.2.1. Method to prove possession of private key</h4>
<p>
CAcert uses industry-standard techniques to
@@ -1504,7 +1504,7 @@ ActiveX uses a challenge-response protocol
to check the private key dynamically.
</p>
-<h4><a id="p3.2.2">3.2.2. Authentication of Individual Identity</a></h4>
+<h4 id="p3.2.2">3.2.2. Authentication of Individual Identity</h4>
<p>
<strong>Agreement.</strong>
@@ -1591,7 +1591,7 @@ certificates that state their Assured Name(s).
-<h4><a id="p3.2.3">3.2.3. Authentication of organization identity</a></h4>
+<h4 id="p3.2.3">3.2.3. Authentication of organization identity</h4>
<p>
@@ -1631,7 +1631,7 @@ stated in the OAP, briefly presented here:
</li></ol>
-<h4><a id="p3.2.4">3.2.4. Non-verified subscriber information</a></h4>
+<h4 id="p3.2.4">3.2.4. Non-verified subscriber information</h4>
<p>
All information in the certificate is verified,
@@ -1639,7 +1639,7 @@ see Relying Party Statement, <a href="#p4.5.2">&sect;4.5.2</a>.
</p>
-<h4><a id="p3.2.5">3.2.5. Validation of authority</a></h4>
+<h4 id="p3.2.5">3.2.5. Validation of authority</h4>
<p>
The authorisation to obtain a certificate is established as follows:
@@ -1673,7 +1673,7 @@ See Organisation Assurance Policy.
</p>
-<h4><a id="p3.2.6">3.2.6. Criteria for interoperation</a></h4>
+<h4 id="p3.2.6">3.2.6. Criteria for interoperation</h4>
<p>
CAcert does not currently issue certificates to subordinate CAs
@@ -1682,13 +1682,13 @@ Other CAs may become Members, and are then subject to the
same reliance provisions as all Members.
</p>
-<h3><a id="p3.3">3.3. Re-key Requests</a></h3>
+<h3 id="p3.3">3.3. Re-key Requests</h3>
<p>
Via the Member's account.
</p>
-<h3><a id="p3.4">3.4. Revocations Requests</a></h3>
+<h3 id="p3.4">3.4. Revocations Requests</h3>
<p>
Via the Member's account.
@@ -1701,7 +1701,7 @@ process or file a dispute.
<!-- *************************************************************** -->
-<h2><a id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a></h2>
+<h2 id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</h2>
<p>
The general life-cycle for a new certificate for an Individual Member is:</p>
@@ -1732,16 +1732,16 @@ The general life-cycle for a new certificate for an Individual Member is:</p>
</p>
-<h3><a id="p4.1">4.1. Certificate Application</a></h3>
+<h3 id="p4.1">4.1. Certificate Application</h3>
-<h4><a id="p4.1.1">4.1.1. Who can submit a certificate application</a></h4>
+<h4 id="p4.1.1">4.1.1. Who can submit a certificate application</h4>
<p>
Members may submit certificate applications.
On issuance of certificates, Members become Subscribers.
</p>
-<h4><a id="p4.1.2">4.1.2. Adding Addresses</a></h4>
+<h4 id="p4.1.2">4.1.2. Adding Addresses</h4>
<p>
The Member can claim ownership or authorised control of
@@ -1760,7 +1760,7 @@ There are these controls:</p>
</li></ul>
-<h4><a id="p4.1.3">4.1.3. Preparing CSR </a></h4>
+<h4 id="p4.1.3">4.1.3. Preparing CSR </h4>
<p>
Members generate their own key-pairs.
@@ -1775,7 +1775,7 @@ The Certificate Signing Request (CSR) is prepared by the
Member for presentation to the automated system.
</p>
-<h3><a id="p4.2">4.2. Certificate application processing</a></h3>
+<h3 id="p4.2">4.2. Certificate application processing</h3>
<p>
The CA's certificate application process is completely automated.
@@ -1788,7 +1788,7 @@ purpose, the requirements for each purpose must be
fulfilled.
</p>
-<h4><a id="p4.2.1">4.2.1. Authentication </a></h4>
+<h4 id="p4.2.1">4.2.1. Authentication </h4>
<p>
The Member logs in to her account on the CAcert website
@@ -1796,7 +1796,7 @@ fulfilled.
and passphrase or with her CAcert client-side digital certificate.
</p>
-<h4><a id="p4.2.2">4.2.2. Verifying Control</a></h4>
+<h4 id="p4.2.2">4.2.2. Verifying Control</h4>
<p>
In principle, at least two controls are placed on each address.
@@ -1879,7 +1879,7 @@ Notes.</p>
-<h4><a id="p4.2.3">4.2.3. Options Available</a></h4>
+<h4 id="p4.2.3">4.2.3. Options Available</h4>
<p>
The Member has options available:
@@ -1902,7 +1902,7 @@ The Member has options available:
</li>
</ul>
-<h4><a id="p4.2.4">4.2.4. Client Certificate Procedures</a></h4>
+<h4 id="p4.2.4">4.2.4. Client Certificate Procedures</h4>
<p>
For an individual client certificate, the following is required.</p>
@@ -1918,7 +1918,7 @@ For an individual client certificate, the following is required.</p>
</ul>
-<h4><a id="p4.2.5">4.2.5. Server Certificate Procedures</a></h4>
+<h4 id="p4.2.5">4.2.5. Server Certificate Procedures</h4>
<p>
For a server certificate, the following is required:</p>
@@ -1933,14 +1933,14 @@ For a server certificate, the following is required:</p>
-<h4><a id="p4.2.6">4.2.6. Code-signing Certificate Procedures</a></h4>
+<h4 id="p4.2.6">4.2.6. Code-signing Certificate Procedures</h4>
<p>
Code-signing certificates are made available to Assurers only.
They are processed in a similar manner to client certificates.
</p>
-<h4><a id="p4.2.7">4.2.7. Organisation Domain Verification</a></h4>
+<h4 id="p4.2.7">4.2.7. Organisation Domain Verification</h4>
<p>
Organisation Domains are handled under the Organisation Assurance Policy
@@ -1948,9 +1948,9 @@ and the Organisation Handbook.
</p>
-<h3><a id="p4.3">4.3. Certificate issuance</a></h3>
+<h3 id="p4.3">4.3. Certificate issuance</h3>
-<h4><a id="p4.3.1">4.3.1. CA actions during certificate issuance</a></h4>
+<h4 id="p4.3.1">4.3.1. CA actions during certificate issuance</h4>
<p>
<strong>Key Sizes.</strong>
@@ -2047,7 +2047,7 @@ algorithm following the process:
<div class="c figure">Table 4.3.1. Permitted Data in Signed OpenPgp Keys</div>
-<h4><a id="p4.3.2">4.3.2. Notification to subscriber by the CA of issuance of certificate</a></h4>
+<h4 id="p4.3.2">4.3.2. Notification to subscriber by the CA of issuance of certificate</h4>
<p>
Once signed, the certificate is
@@ -3493,7 +3493,7 @@ and takes privacy more seriously.
Any privacy issue may be referred to dispute resolution.
</p>
-<h4><a id="p9.4.5">9.4.5. Notice and consent to use private information</a></h4>
+<h4 id="p9.4.5">9.4.5. Notice and consent to use private information</h4>
<p>
Members are permitted to rely on certificates of other Members.
As a direct consequence of the general right to rely,