]> WPIA git - gigi.git/blob - static/policy/CertificationPracticeStatement.html
move policies to *.html
[gigi.git] / static / policy / CertificationPracticeStatement.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <html>
3 <head>
4     <meta name="copyright" content="CAcert Inc http://www.cacert.org/">
5     <title>Certification Practice Statement (CPS)</title>
6
7 <style type="text/css">
8 <!--
9 body {
10         font-family : verdana, helvetica, arial, sans-serif;
11 }
12
13 pre, code, kbd, tt, samp {
14         font-family : courier, monospace;
15 }
16
17 th {
18         text-align : left;
19 }
20
21 .blockpar {
22         text-indent : 2em;
23         margin-top : 0em;
24         margin-bottom : 0.5em;
25         text-align : justify;
26 }
27
28 .figure {
29         text-align : center;
30         color : gray;
31         margin-top : 0.5em;
32 }
33
34 .center {
35         text-align : center;
36 }
37
38 .q {
39         color : green;
40         font-weight: bold;
41         text-align: center;
42         font-style:italic;
43 }
44
45 .error {
46         color : red;
47         font-weight: bold;
48         text-align: center;
49         font-style:italic;
50 }
51
52 .change {
53         color : blue;
54         font-weight: bold;
55 }
56
57 a:hover {
58         color : gray;
59 }
60 -->
61 </style>
62
63
64 </head>
65 <body>
66
67 <h1>CAcert CPS and CP</h1>
68
69 <a href="PolicyOnPolicy.html"><img src="cacert-draft.png" alt="CAcert Policy Status" height="31" width="88" style="border-style: none;" /></a><br />
70 Creation date: 20060726<br />
71 Status: DRAFT p20091108<br />
72 <!-- $Id: CertificationPracticeStatement.php,v 1.3 2012-07-27 16:00:29 wytze Exp $ -->
73
74
75 <font size="-1">
76
77 <ol>
78   <li> <a href="#p1">INTRODUCTION</a>
79    <ul>
80     <li><a href="#p1.1">1.1. Overview</a></li>
81     <li><a href="#p1.2">1.2. Document name and identification</a></li>
82     <li><a href="#p1.3">1.3. PKI participants</a> </li>
83     <li><a href="#p1.4">1.4. Certificate usage</a> </li>
84     <li><a href="#p1.5">1.5. Policy administration</a> </li>
85     <li><a href="#p1.6">1.6. Definitions and acronyms</a></li>
86    </ul>
87   </li>
88   <li> <a href="#p2">PUBLICATION AND REPOSITORY RESPONSIBILITIES</a>
89    <ul>
90     <li><a href="#p2.1">2.1. Repositories</a></li>
91     <li><a href="#p2.2">2.2. Publication of certification information</a></li>
92     <li><a href="#p2.3">2.3. Time or frequency of publication</a></li>
93     <li><a href="#p2.4">2.4. Access controls on repositories</a></li>
94    </ul>
95   </li>
96   <li> <a href="#p3">IDENTIFICATION AND AUTHENTICATION (I&amp;A)</a>
97    <ul>
98     <li><a href="#p3.1">3.1. Naming</a> </li>
99     <li><a href="#p3.2">3.2. Initial Identity Verification</a> </li>
100     <li><a href="#p3.3">3.3. I&amp;A for Re-key Requests</a> </li>
101     <li><a href="#p3.4">3.4. I&amp;A for Revocation Request</a></li>
102    </ul>
103   </li>
104   <li><a href="#p4">CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a>
105    <ul>
106     <li><a href="#p4.1">4.1. Certificate Application</a> </li>
107     <li><a href="#p4.2">4.2. Certificate application processing</a> </li>
108     <li><a href="#p4.3">4.3. Certificate issuance</a> </li>
109     <li><a href="#p4.4">4.4. Certificate acceptance</a> </li>
110     <li><a href="#p4.5">4.5. Key pair and certificate usage</a> </li>
111     <li><a href="#p4.6">4.6. Certificate renewal</a> </li>
112     <li><a href="#p4.7">4.7. Certificate re-key</a> </li>
113     <li><a href="#p4.8">4.8. Certificate modification</a> </li>
114     <li><a href="#p4.9">4.9. Certificate revocation and suspension</a> </li>
115     <li><a href="#p4.10">4.10. Certificate status services</a> </li>
116     <li><a href="#p4.11">4.11. End of subscription</a></li>
117     <li><a href="#p4.12">4.12. Key escrow and recovery</a> </li>
118    </ul>
119   </li>
120   <li><a href="#p5">FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a>
121    <ul>
122     <li><a href="#p5.1">5.1. Physical controls</a> </li>
123     <li><a href="#p5.2">5.2. Procedural controls</a> </li>
124     <li><a href="#p5.3">5.3. Personnel controls</a> </li>
125     <li><a href="#p5.4">5.4. Audit logging procedures</a> </li>
126     <li><a href="#p5.5">5.5. Records archival</a> </li>
127     <li><a href="#p5.6">5.6. Key changeover</a></li>
128     <li><a href="#p5.7">5.7. Compromise and disaster recovery</a> </li>
129     <li><a href="#p5.8">5.8. CA or RA termination</a></li>
130    </ul>
131   </li>
132   <li><a href="#p6">TECHNICAL SECURITY CONTROLS</a>
133    <ul>
134     <li><a href="#p6.1">6.1. Key pair generation and installation</a> </li>
135     <li><a href="#p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a> </li>
136     <li><a href="#p6.3">6.3. Other aspects of key pair management</a> </li>
137     <li><a href="#p6.4">6.4. Activation data</a> </li>
138     <li><a href="#p6.5">6.5. Computer security controls</a> </li>
139     <li><a href="#p6.6">6.6. Life cycle technical controls</a> </li>
140     <li><a href="#p6.7">6.7. Network security controls</a></li>
141     <li><a href="#p6.8">6.8. Time-stamping</a></li>
142    </ul>
143   </li>
144   <li><a href="#p7">CERTIFICATE, CRL, AND OCSP PROFILES</a>
145    <ul>
146     <li><a href="#p7.1">7.1. Certificate profile</a> </li>
147     <li><a href="#p7.2">7.2. CRL profile</a> </li>
148     <li><a href="#p7.3">7.3. OCSP profile</a> </li>
149    </ul>
150   </li>
151   <li><a href="#p8">COMPLIANCE AUDIT AND OTHER ASSESSMENTS</a>
152    <ul>
153     <li><a href="#p8.1">8.1. Frequency or circumstances of assessment</a></li>
154     <li><a href="#p8.2">8.2. Identity/qualifications of assessor</a></li>
155     <li><a href="#p8.3">8.3. Assessor's relationship to assessed entity</a></li>
156     <li><a href="#p8.4">8.4. Topics covered by assessment</a></li>
157     <li><a href="#p8.5">8.5. Actions taken as a result of deficiency</a></li>
158     <li><a href="#p8.6">8.6. Communication of results</a></li>
159    </ul>
160   </li>
161   <li><a href="#p9">OTHER BUSINESS AND LEGAL MATTERS</a>
162    <ul>
163     <li><a href="#p9.1">9.1. Fees</a> </li>
164     <li><a href="#p9.2">9.2. Financial responsibility</a> </li>
165     <li><a href="#p9.3">9.3. Confidentiality of business information</a> </li>
166     <li><a href="#p9.4">9.4. Privacy of personal information</a> </li>
167     <li><a href="#p9.5">9.5. Intellectual property rights</a></li>
168     <li><a href="#p9.6">9.6. Representations and warranties</a> </li>
169     <li><a href="#p9.7">9.7. Disclaimers of warranties</a></li>
170     <li><a href="#p9.8">9.8. Limitations of liability</a></li>
171     <li><a href="#p9.9">9.9. Indemnities</a></li>
172     <li><a href="#p9.10">9.10. Term and termination</a> </li>
173     <li><a href="#p9.11">9.11. Individual notices and communications with participants</a></li>
174     <li><a href="#p9.12">9.12. Amendments</a> </li>
175     <li><a href="#p9.13">9.13. Dispute resolution provisions</a></li>
176     <li><a href="#p9.14">9.14. Governing law</a></li>
177     <li><a href="#p9.15">9.15. Compliance with applicable law</a></li>
178     <li><a href="#p9.16">9.16. Miscellaneous provisions</a> </li>
179    </ul>
180   </li>
181 </ol>
182
183 </font>
184
185
186
187 <!-- *************************************************************** -->
188 <h2><a name="p1" id="p1">1. INTRODUCTION</a></h2>
189
190 <h3><a name="p1.1" id="p1.1">1.1. Overview</a></h3>
191
192 <p>
193 This document is the Certification Practice Statement (CPS) of
194 CAcert, the Community Certification Authority (CA).
195 It describes rules and procedures used by CAcert for
196 operating its CA,
197 and applies to all CAcert PKI Participants,
198 including Assurers, Members, and CAcert itself.
199 </p>
200
201 <p>
202 </p>
203
204 <h3><a name="p1.2" id="p1.2">1.2. Document name and identification</a></h3>
205
206 <p>
207 This document is the Certification Practice Statement (CPS) of CAcert.
208 The CPS also fulfills the role of the Certificate Policy (CP)
209 for each class of certificate.
210 </p>
211
212 <ul>
213   <li>
214     This document is COD6 under CAcert Official Documents numbering scheme.
215   </li>
216   <li>
217     The document is structured according to
218     Chokhani, et al,
219     <a href="http://www.ietf.org/rfc/rfc3647.txt">RFC3647</a>,
220     <a href="http://tools.ietf.org/html/rfc3647#section-4">chapter 4</a>.
221     All headings derive from that Chapter.
222   </li>
223   <li>
224     It has been improved and reviewed (or will be reviewed)
225     to meet or exceed the criteria of the
226     <cite>Certificate Authority Review Checklist</cite>
227     from <i>David E. Ross</i> ("DRC")
228     and Mozilla Foundation's CA policy.
229   </li>
230   <li>
231     OID assigned to this document: 1.3.6.1.4.1.18506.4.4.x (x=approved Version)
232     (<a href="http://www.iana.org/assignments/enterprise-numbers">iana.org</a>)
233     <p class="q"> .x will change to .1 in the first approved instance.</p>
234   </li>
235   <li>
236     &copy; CAcert Inc. 2006-2009.
237     <!-- note that CCS policies must be controlled by CAcert Inc. -->
238   </li>
239   <li>
240     Issued under the CAcert document licence policy,
241     as and when made policy.
242     See <a href="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
243     PolicyDrafts/DocumentLicence</a>.
244      <ul class="q">
245        <li> The cited page discusses 2 options:  CCau Attribute-Share-alike and GNU Free Document License.  Refer to that.  </li>
246        <li> Note that the noun Licence in Australian English has two Cs.  The verb License is spelt the same way as American English. </li>
247      </ul>
248   </li>
249   <li>
250     Earlier notes were written by Christian Barmala
251     in a document placed under GNU Free Document License
252     and under FSF copyright.
253     However this clashed with the control provisions of
254     Configuration-Control Specification
255     (COD2) within Audit criteria.
256   </li>
257   <li>
258     <span class="q">In this document:</span>
259     <ul>
260       <li>
261         <span class="q">green text</span>
262         refers to questions that seek answers,
263       </li><li>
264          <span class="error">red text</span>
265          refers to probably audit fails or serious errors.
266       </li><li>
267          <span class="change">blue text</span>
268          refers to changes written after the document got seriously reviewed.
269     </ul>
270     <span class="q">
271     None is to be considered part of the policy,
272     and they should disappear in the DRAFT
273     and must disappear in the POLICY.
274     </span>
275   </li>
276 <!--
277   <li>
278     Some content is incorporated under
279 <!--     <a href="http://xkcd.com/license.html">Creative Commons license</a> -->
280 <!--     from <a href="http://xkcd.com/">xkcd.com</a>. -->
281     198 177 515
282   </li>
283 -->
284 </ul>
285
286 <p>
287 The CPS is an authoritive document,
288 and rules other documents
289 except where explicitly deferred to.
290 See also <a href="#p1.5.1">1.5.1 Organisation Administering the Document</a>.
291 </p>
292
293 <h3><a name="p1.3" id="p1.3">1.3. PKI participants</a></h3>
294 <p>
295 The CA is legally operated by CAcert Incorporated,
296 an Association registered in 2002 in
297 New South Wales, Australia,
298 on behalf of the wider Community of Members of CAcert.
299 The Association details are at the
300 <a href="http://wiki.cacert.org/wiki/CAcertIncorporated">CAcert wiki</a>.
301 </p>
302
303 <p>
304 CAcert is a Community formed of Members who agree to the
305 <a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">
306 CAcert Community Agreement</a>.
307 The CA is technically operated by the Community,
308 under the direction of the Board of CAcert Incorporated.
309 (The Members of the Community are not to be confused
310 with the <i>Association Members</i>, which latter are
311 not referred to anywhere in this CPS.)
312 </p>
313
314 <h4><a name="p1.3.1" id="p1.3.1">1.3.1. Certification authorities</a></h4>
315 <p>
316 CAcert does not issue certificates to external
317 intermediate CAs under the present CPS.
318 </p>
319
320 <h4><a name="p1.3.2" id="p1.3.2">1.3.2. Registration authorities</a></h4>
321 <p>
322 Registration Authorities (RAs) are controlled under Assurance Policy
323 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
324 </p>
325
326 <h4><a name="p1.3.3" id="p1.3.3">1.3.3. Subscribers</a></h4>
327
328 <p>
329 CAcert issues certificates to Members only.
330 Such Members then become Subscribers.
331 </p>
332
333
334 <h4><a name="p1.3.4" id="p1.3.4">1.3.4. Relying parties</a></h4>
335
336 <p>
337 A relying party is a Member,
338 having agreed to the
339 CAcert Community Agreement
340 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
341 who, in the act of using a CAcert certificate,
342 makes a decision on the basis of that certificate.
343 </p>
344
345 <h4><a name="p1.3.5" id="p1.3.5">1.3.5. Other participants</a></h4>
346
347 <p>
348 <b>Member.</b>
349 Membership of the Community is as defined in the
350 <a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>.
351 Only Members may RELY or may become Subscribers.
352 Membership is free.
353 </p>
354
355 <p>
356 <b>Arbitrator.</b>
357 A senior and experienced Member of the CAcert Community
358 who resolves disputes between Members, including ones
359 of certificate reliance, under
360 Dispute Resolution Policy
361 (<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>).
362 </p>
363
364 <p>
365 <b>Vendor.</b>
366 Software suppliers who integrate the root certificates of CAcert
367 into their software also assume a proxy role of Relying Parties,
368 and are subject to another licence.
369 <span class="q">
370 At the time of writing, the
371 "3rd Party Vendor - Disclaimer and Licence"
372 is being worked upon, but is neither approved nor offered.
373 </span>
374 </p>
375
376 <p>
377 <b>Non-Related Persons</b> (NRPs).
378 These are users of browsers and similar software who are
379 unaware of the CAcert certificates they may use, and
380 are unaware of the ramifications of usage.
381 Their relationship with CAcert
382 is described by the
383 Non-related Persons - Disclaimer and Licence
384 (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
385 No other rights nor relationship is implied or offered.
386 </p>
387
388
389 <h3><a name="p1.4" id="p1.4">1.4. Certificate usage</a></h3>
390
391 <p>CAcert serves as issuer of certificates for
392 individuals, businesses, governments, charities,
393 associations, churches, schools,
394 non-governmental organisations or other groups.
395 CAcert certificates are intended for low-cost
396 community applications especially where volunteers can
397 become Assurers and help CAcert to help the Community.
398 </p>
399
400 <p>
401 Types of certificates and their appropriate and
402 corresponding applications are defined in
403 <a href="#p1.4.1">&sect;1.4.1</a>.
404 Prohibited applications are defined in <a href="#p1.4.2">&sect;1.4.2</a>.
405 Specialist uses may be agreed by contract or within
406 a specific environment, as described in
407 <a href="#p1.4.4">&sect;1.4.4</a>.
408 Note also the
409 unreliable applications in
410 <a href="#p1.4.3">&sect;1.4.3</a>
411 and risks, liabilities and obligations in
412 <a href="#p9">&sect;9</a>.
413 </p>
414
415
416 <center>
417 <table border="1" cellpadding="5">
418  <tr>
419   <td colspan="2"><center><i>Type</center></i></td>
420   <td colspan="2"><center><i>Appropriate Certificate uses</center></i></th>
421  </tr>
422  <tr>
423   <th>General</th>
424   <th>Protocol</th>
425   <th><center>Description</center></th>
426   <th><center>Comments</center></th>
427  </tr>
428  <tr>
429   <td rowspan="2"><center>Server</center></td>
430   <td> TLS </td>
431   <td> web server encryption </td>
432   <td> enables encryption </td>
433  </tr>
434  <tr>
435   <td> embedded </td>
436   <td> embedded server authentication </td>
437   <td> mail servers, IM-servers </td>
438  </tr>
439  <tr>
440   <td rowspan="4"><center>Client</center></td>
441   <td> S/MIME </td>
442   <td> email encryption </td>
443   <td> "digital signatures" employed in S/MIME
444        are not legal / human signatures,
445        but instead enable the encryption mode of S/MIME </td>
446  </tr>
447  <tr>
448   <td> TLS </td>
449   <td> client authentication </td>
450   <td> the nodes must be secure </td>
451  </tr>
452  <tr>
453   <td> TLS </td>
454   <td> web based signature applications </td>
455   <td> the certificate authenticates only.  See <a href="#p1.4.3">&sect;1.4.3</a>. </td>
456  </tr>
457  <tr>
458   <td> &quot;Digital Signing&quot; </td>
459   <td> for human signing over documents </td>
460   <td> Only within a wider application and rules
461        such as by separate policy,
462        as agreed by contract, etc.
463        See <a href="#p1.4.4">&sect;1.4.4</a>. 
464        </td>
465  </tr>
466  <tr>
467   <td><center>Code</center></td>
468   <td> Authenticode, ElfSign, Java </td>
469   <td> Code Signing </td>
470   <td> Signatures on packages are evidence of their Membership and indicative of Identity </td>
471  </tr>
472  <tr>
473   <td><center>PGP</center></td>
474   <td> OpenPGP </td>
475   <td> Key Signing </td>
476   <td> Signatures on Member Keys are evidence of their Membership and indicative of Identity </td>
477  </tr>
478  <tr>
479   <td><center>Special</center></td>
480   <td> X.509 </td>
481   <td> OCSP, Timestamping </td>
482   <td> Only available to CAcert Systems Administrators, as controlled by Security Policy </td>
483  </tr>
484 </table>
485
486 <span class="figure">Table 1.4.  Types of Certificate</span>
487 </center>
488
489 <h4><a name="p1.4.1" id="p1.4.1">1.4.1. Appropriate certificate uses</a></h4>
490
491 <p>
492 General uses.
493 </p>
494
495 <ul><li>
496     CAcert server certificates can be used to enable encryption
497     protection in web servers.
498     Suitable applications include webmail and chat forums.
499   </li><li>
500     CAcert server certificates can be used to enable encryption
501     in SSL/TLS links in embedded protocols such as mail servers
502     and IM-servers.
503   </li><li>
504     CAcert client certificates can be used to enable encryption
505     protection in email clients.
506     (See <a href="#p1.4.3">&sect;1.4.3</a> for caveat on signatures.)
507   </li><li>
508     CAcert client certificates can be used to replace password-based
509     authentication to web servers.
510   </li><li>
511     OpenPGP keys with CAcert signatures can be used
512     to encrypt and sign files and emails,
513     using software compatible with OpenPGP.
514   </li><li>
515     CAcert client certificates can be used in web-based
516     authentication applications.
517   </li><li>
518     CAcert code signing certificates can be used to sign code
519     for distribution to other people.
520   </li><li>
521     Time stamping can be used to attach a time record
522     to a digital document.
523 </li></ul>
524
525
526 <h4><a name="p1.4.2" id="p1.4.2">1.4.2. Prohibited certificate uses</a></h4>
527 <p>
528 CAcert certificates are not designed, intended, or authorised for
529 the following applications:
530 </p>
531 <ul><li>
532     Use or resale as control equipment in hazardous circumstances
533     or for uses requiring fail-safe performance such as the operation
534     of nuclear facilities, aircraft navigation or communication systems,
535     air traffic control systems, or weapons control systems,
536     where failure could lead directly to death, personal injury,
537     or severe environmental damage.
538 </li></ul>
539
540 <h4><a name="p1.4.3" id="p1.4.3">1.4.3. Unreliable Applications</a></h4>
541
542 <p>
543 CAcert certificates are not designed nor intended for use in
544 the following applications, and may not be reliable enough
545 for these applications:
546 </p>
547
548 <ul><li>
549     <b>Signing within Protocols.</b>
550     Digital signatures made by CAcert certificates carry
551     <u>NO default legal or human meaning</u>.
552     See <a href="#p9.15.1">&sect;9.15.1</a>.
553     Especially, protocols such as S/MIME commonly will automatically
554     apply digital signatures as part of their protocol needs.
555     The purpose of the cryptographic signature in S/MIME
556     and similar protocols is limited by default to strictly
557     protocol security purposes: 
558     to provide some confirmation that a familiar certificate
559     is in use, to enable encryption, and to ensure the integrity
560     of the email in transit.
561 </li><li>
562     <b>Non-repudiation applications.</b>
563     Non-repudiation is not to be implied from use of
564     CAcert certificates.  Rather, certificates may
565     provide support or evidence of actions, but that
566     evidence is testable in any dispute.
567 </li><li>
568     <b>Ecommerce applications.</b>
569     Financial transactions or payments or valuable e-commerce.
570 </li><li>
571     Use of anonymous (Class 1 or Member SubRoot) certificates
572     in any application that requires or expects identity.
573 </li></ul>
574
575 <!-- <center><a href="http://xkcd.com/341/"> <img src="http://imgs.xkcd.com/comics/1337_part_1.png"> </a> </center> -->
576
577 <h4><a name="p1.4.4" id="p1.4.4">1.4.4. Limited certificate uses</a></h4>
578
579 <p>
580 By contract or within a specific environment
581 (e.g. internal to a company),
582 CAcert Members are permitted to use Certificates
583 for higher security, customised or experimental applications.
584 Any such usage, however, is limited to such entities
585 and these entities take on the whole responsible for
586 any harm or liability caused by such usage.
587 </p>
588
589 <p>
590     <b>Digital signing applications.</b>
591     CAcert client certificates
592     may be used by Assured Members in
593     applications that provide or support the human signing of documents
594     (known here as "digital signing").
595     This must be part of a wider framework and set of rules.
596     Usage and reliance
597     must be documented either under a separate CAcert digital signing 
598     policy or other external regime agreed by the parties.
599 </p>
600
601 <h4><a name="p1.4.5" id="p1.4.5">1.4.5. Roots and Names</a></h4>
602
603 <p>
604 <b>Named Certificates.</b>
605 Assured Members may be issued certificates
606 with their verified names in the certificate.  In this role, CAcert
607 operates and supports a network of Assurers who verify the
608 identity of the Members.
609 All Names are verified, either by Assurance or another defined
610 method under policy (c.f. Organisations).
611 </p>
612
613 <p>
614 <b>Anonymous Certificates.</b>
615 Members can be issued certificates that are anonymous,
616 which is defined as the certificate with no Name included,
617 or a shared name such as "Community Member".
618 These may be considered to be somewhere between Named certificates
619 and self-signed certificates.  They have serial numbers in them
620 which is ultimately traceable via dispute to a Member, but
621 reliance is undefined.
622 In this role, CAcert provides the
623 infrastructure, saving the Members from managing a difficult
624 and messy process in order to get manufactured certificates.
625 </p>
626
627 <p>
628 <b>Psuedonymous Certificates.</b>
629 Note that CAcert does not currently issue pseudonymous certificates,
630 being those with a name chosen by the Member and not verifiable
631 according to documents.
632 </p>
633
634 <p>
635 <b>Advanced Certificates.</b>
636 Members who are as yet unassured are not permitted to create
637 advanced forms such as wildcard or subjectAltName
638 certificates.
639 </p>
640
641
642 <p>
643 <b> Roots.</b>
644 The <span class="q"> (new) </span> CAcert root layout is as below.
645 These roots are pending Audit,
646 and will be submitted to vendors via the (Top-level) Root.
647 </p>
648 <ul><li>
649     <b>(Top-level) Root.</b>
650     Used to sign on-line CAcert SubRoots only.
651     This Root is kept offline.
652   </li><li>
653     <b>Member SubRoot.</b>
654     For Community Members who are new and unassured (some restrictions exist).
655     Reliance is undefined.
656     (Replacement for the Class 1 root, matches "Domain Validation" type.)
657   </li><li>
658     <b>Assured SubRoot.</b>
659     Only available for Assured individual Members,
660     intended to sign certificates with Names.
661     Suitable for Reliance under this and other policies.
662     Approximates the type known as Individual Validation.
663   </li><li>
664     <b>Organisation SubRoot.</b>
665     Only available for Assured Organisation Members.
666     Suitable for Reliance under this and other policies.
667     Approximates the type known as Organisational Validation.
668
669 </li></ul>
670
671
672
673 <center>
674 <table border="1" cellpadding="5">
675  <tr>
676   <td></td>
677   <td colspan="5"><center><i>Level of Assurance</center></i></td>
678   <th> </th>
679  </tr>
680  <tr>
681   <th></th>
682   <th colspan="2"><center> Members &dagger; </center></th>
683   <th colspan="2"><center> Assured Members</center></th>
684   <th colspan="1"><center> Assurers </center></th>
685   <th colspan="1"><center> </center></th>
686  </tr>
687  <tr>
688   <td><i>Class of Root</i></td>
689   <th>Anon</th>
690   <td>Name</td>
691   <td>Anon</td>
692   <th>Name</th>
693   <td>Name+Anon</td>
694   <td colspan="1"><center><i>Remarks</center></i></td>
695  </tr>
696  <tr>
697   <td><center>Top level<br><big><b>Root</b></big></center></td>
698   <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </th>
699   <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </th>
700   <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
701   <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
702   <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
703   <td> Signs other CAcert SubRoots only. </td>
704  </tr>
705  <tr>
706   <td><center><big><b>Member</b></big><br>SubRoot</center></td>
707   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
708   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
709   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
710   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
711   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
712   <td> &dagger; For Members meeting basic checks in <a href="#p4.2.2">&sect;4.2.2</a><br>(Reliance is undefined.) </td>
713  </tr>
714  <tr>
715   <td><center><big><b>Assured</b></big><br>SubRoot</center></td>
716   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
717   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
718   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
719   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
720   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
721   <td> Assured Members only.<br>Fully intended for reliance. </td>
722  </tr>
723  <tr>
724   <td><center><big><b>Organisation</b></big><br>SubRoot</center></td>
725   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
726   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
727   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
728   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
729   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
730   <td> Assured Organisation Members only.<br>Fully intended for reliance. </td>
731  </tr>
732  <tr>
733   <th>Expiry of Certificates</th>
734   <td colspan="2"><center>6 months</center></th>
735   <td colspan="3"><center>24 months</center></th>
736  </tr>
737  <tr>
738   <th>Types</th>
739   <td colspan="2"><center>client, server</center></th>
740   <td colspan="2"><center>wildcard, subjectAltName</center></th>
741   <td colspan="1"><center>code-signing</center></th>
742   <td> (Inclusive to the left.) </td>
743  </tr>
744 </table>
745
746 <span class="figure">Table 1.4.5.b  Certificate under Audit Roots</span>
747 </center>
748
749
750 <p class="q">
751 Following information on OLD roots here for
752 descriptive and historical purposes only.
753 When CPS goes to DRAFT, this needs to be
754 converted into a short summary of the way
755 OLD roots are used and its relationship to
756 this CPS.  E.g., "OLD roots are used for
757 testing and other purposes outside this CPS."
758 Because ... they still exist, and people will
759 look at the CPS to figure it out.
760 </p>
761
762 <center>
763 <table border="1" cellpadding="5">
764  <tr>
765   <td></td>
766   <td colspan="4"><center><i>Level of Assurance</center></i></td>
767   <th> </th>
768  </tr>
769  <tr>
770   <th></th>
771   <th colspan="2"><center>Members</center></th>
772   <th colspan="2"><center>Assured Members</center></th>
773   <th colspan="1"><center> </center></th>
774  </tr>
775  <tr>
776   <td><i>Class of Root</i></td>
777   <th>Anonymous</th>
778   <td>Named</td>
779   <td>Anonymous</td>
780   <th>Named</th>
781   <td colspan="1"><center><i>Remarks</center></i></td>
782  </tr>
783  <tr>
784   <td><center>Class<br><big><b>1</b></big></center></td>
785   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
786   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
787   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
788   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
789   <td> Available for all Members,<br>reliance is undefined.</td>
790  </tr>
791  <tr>
792   <td><center>Class<br><big><b>3</b></big></center></td>
793   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
794   <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
795   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
796   <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
797   <td> Assured Members only.<br> Intended for Reliance. </center> </td>
798  </tr>
799  <tr>
800   <th>Expiry of Certificates</th>
801   <td colspan="2"><center>6 months</center></th>
802   <td colspan="2"><center>24 months</center></th>
803  </tr>
804  <tr>
805   <th>Types available</th>
806   <td colspan="2"><center>simple only</center></th>
807   <td colspan="2"><center>wildcard, subjectAltName</center></th>
808  </tr>
809 </table>
810
811 <span class="figure">Table 1.4.5.  Certificates under Old Roots - <b>Audit Fail</b>  </span>
812 </center>
813
814 <p>
815 <b> Old Roots.</b>
816 The old CAcert root layout is as below.  These roots are <b>Audit Fail</b>
817 and will only be used where new roots do not serve:
818 </p>
819 <ul><li>
820     (old) <b>Class 1 root.</b>
821     Used primarily for certificates with no names and by
822     unassured Members.
823     For compatibility only,
824     Assured Members may also use this root.
825   </li><li>
826     (old) <b>Class 3 root.</b>
827     Used primarily for certificates including the names
828     of Assured Members.
829     Signed by Class 1 root.
830     Members can decide to rely on these
831     certificates for Assured Members
832     by selecting the Class 3 root for
833     Assured Members as trust anchor.
834 </li></ul>
835
836   <ul class="q">
837     <li> Current Mozilla position has drifted from Class 1,2,3s to DV, IV+OV and EV posture.  Except, the actual posture is either unstated or difficult to fathom.</li>
838     <li> scheme for future roots is at <a href="http://wiki.cacert.org/wiki/Roots/NewRootsTaskForce">NewRootsTaskForce</a>.</li>
839     <li>END OLD ROOTS </li>
840   </ul>
841
842 <h3><a name="p1.5" id="p1.5">1.5. Policy administration</a></h3>
843
844 <p>See <a href="#p1.2">1.2 Document Name and Identification</a>
845   for general scope of this document.</p>
846
847 <h4><a name="p1.5.1" id="p1.5.1">1.5.1. Organization administering the document</a></h4>
848
849 <p>
850 This document is administered by the policy group of
851 the CAcert Community under Policy on Policy (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>).
852 </p>
853
854 <h4><a name="p1.5.2" id="p1.5.2">1.5.2. Contact person</a></h4>
855 <p>
856 For questions including about this document:
857 </p>
858
859 <ul>
860   <li>Join the policy group, by means of the discussion forum at
861   <a href="http://lists.cacert.org/mailman/listinfo">
862   lists.cacert.org</a> . </li>
863   <li>Send email to &lt; support AT cacert DOT org &gt; </li>
864   <li>IRC: irc.cacert.org #CAcert (ssl port 7000, non-ssl port 6667)</li>
865 </ul>
866
867 <h4><a name="p1.5.3" id="p1.5.3">1.5.3. Person determining CPS suitability for the policy</a></h4>
868 <p>
869 This CPS and all other policy documents are managed by
870 the policy group, which is a group of Members of the
871 Community found at policy forum.  See discussion forums above.
872 </p>
873
874 <h4><a name="p1.5.4" id="p1.5.4">1.5.4. CPS approval procedures</a></h4>
875 <p>
876 CPS is controlled and updated according to the
877 Policy on Policy
878 (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>)
879 which is part of
880 Configuration-Control Specification (COD2).
881 </p>
882
883 <p>
884 In brief, the policy forum prepares and discusses.
885 After a last call, the document moves to DRAFT status
886 for a defined period.
887 If no challenges have been received in the defined period,
888 it moves to POLICY status.
889 The process is modelled after some elements of
890 the RFC process by the IETF.
891 </p>
892
893 <h4><a name="p1.5.5" id="p1.5.5">1.5.5 CPS updates</a></h4>
894
895 <p>
896 As per above.
897 </p>
898
899
900 <h3><a name="p1.6" id="p1.6">1.6. Definitions and acronyms</a></h3>
901 <p>
902 <b><a name="d_cert" id="d_cert">Certificate</a></b>.
903   A certificate is a piece of cryptographic data used
904   to validate certain statements, especially those of
905   identity and membership.
906 </p>
907 <p>
908 <b><a name="d_cacert" id="d_cacert">CAcert</a></b>.
909   CAcert is a Community certificate authority as defined under
910   <a href="#p1.2">&sect;1.2 Identification</a>.
911 </p>
912 <p>
913 <b><a name="d_member" id="d_member">Member</a></b>.
914   Everyone who agrees to the
915   CAcert Community Agreement
916   (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
917   This generally implies having an account registered
918   at CAcert and making use of CAcert's data, programs or services.
919   A Member may be an individual ("natural person")
920   or an organisation (sometimes, "legal person").
921 </p>
922 <p>
923 <b><a name="d_community" id="d_community">Community</a></b>.
924   The group of Members who agree to the
925   CAcert Community Agreement
926   (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
927   or equivalent agreements.
928 </p>
929 <p>
930 <b><a name="d_unassured" id="d_unassured">Unassured Member</a></b>.
931   A Member who has not yet been Assured.
932 </p>
933 <p>
934 <b><a name="d_subscriber" id="d_subscriber">Subscriber</a></b>.
935   A Member who requests and receives a certificate.
936 </p>
937 <p>
938 <b><a name="d_assured" id="d_assured">Assured Member</a></b>.
939   A Member whose identity has been sufficiently
940   verified by Assurers or other
941   approved methods under Assurance Policy.</p>
942 </p>
943 <p>
944 <b><a name="d_assurer" id="d_assurer">Assurer</a></b>.
945   An Assured Member who is authorised under Assurance Policy
946   to verify the identity of other Members.
947 </p>
948 <p>
949 <b><a name="d_name" id="d_name">Name</a></b>.
950     As defined in the
951     Assurance Policy
952     (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>),
953     to describe a name of a Member
954     that is verified by the Assurance process.
955 <p>
956 <b><a name="d_oadmin" id="d_oadmin">Organisation Administrator</a></b>.
957   ("O-Admin")
958   An Assurer who is authorised to act for an Organisation.
959   The O-Admin is authorised by an organisation
960   to vouch for the identity of other users of the organisation.
961 </p>
962 <p>
963 <b><a name="d_org_ass" id="d_org_ass">Organisation Assurer</a></b>.
964   An Assurer who is authorised to conduct assurances on
965   organisations.
966 </p>
967 <p>
968 <b><a name="d_user" id="d_user">Non-Related Persons</a></b>.
969   ("NRPs")
970   are general users of browsers and similar software.
971   The NRPs are generally unaware of
972   CAcert or the certificates that they may use, and
973   are unaware of the ramifications of usage.
974   They are not permitted to RELY, but may USE, under the 
975   Non-Related Persons - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
976 </p>
977 <p>
978 <b><a name="rel" id="d_reliance">Reliance</a></b>.
979   An industry term referring to
980   the act of making a decision, including taking a risk,
981   which decision is in part or in whole
982   informed or on the basis of the contents of a certificate.
983 </p>
984 <p>
985 <b><a name="rel" id="rel">Relying Party</a></b>.
986   An industry term refering to someone who relies
987   (that is, makes decisions or takes risks)
988   in part or in whole on a certificate.
989 </p>
990 <p>
991     <b>Subscriber Naming.</b>
992     The term used in this CPS to
993     describe all naming data within a certificate.
994     Approximately similar terms from Industry such as
995     "Subject naming" and "Distinguished Name"
996     are not used here.
997 </p>
998 <p>
999 <b><a name="ver" id="d_verification">Verification</a></b>.
1000   An industry term referring to
1001   the act of checking and controlling
1002   the accuracy and utility of a single claim.
1003 </p>
1004 <p>
1005 <b><a name="ver" id="d_validation">Validation</a></b>.
1006   An industry term referring to the process of
1007   inspecting and verifying the information and
1008   subsidiary claims behind a claim.
1009 </p>
1010 <p>
1011 <b><a name="rel" id="rel">Usage</a></b>.
1012   The event of allowing a certificate to participate in
1013   a protocol, as decided and facilitated by a user's software.
1014   Generally, Usage does not require significant input, if any,
1015   on the part of the user.
1016   This defers all decisions to the user software,
1017   thus elevating the software as user's only and complete
1018   Validation Authority or Agent.
1019 </p>
1020 <p>
1021 <b><a name="drel" id="drel">CAcert Relying Party</a></b>.
1022   CAcert Members who make decisions based in part or in whole
1023   on a certificate issued by CAcert.
1024   Only CAcert Members are permitted to Rely on CAcert certificates,
1025   subject to the CAcert Community Agreement.
1026 </p>
1027 <p>
1028 <b><a name="ddst" id="ddst">Vendors</a></b>.
1029   Non-members who distribute CAcert's root or intermediate certificates
1030   in any way, including but not limited to delivering these
1031   certificates with their products, e.g. browsers, mailers or servers.
1032   Vendors are covered under a separate licence.
1033   <span class="q"> As of the moment, this licence is not written.</span>
1034 </p>
1035 <p>
1036 <b><a name="d_ccs" id="d_ccs">Configuration-Control Specification</a></b> "CCS".
1037   The audit criteria that controls this CPS.
1038   The CCS is documented in COD2, itself a controlled document under CCS.
1039 </p>
1040 <p>
1041 <p>
1042 <b><a name="d_cod" id="d_cod">CAcert Official Document</a></b> (COD).
1043   Controlled Documents that are part of the CCS.
1044 </p>
1045
1046
1047
1048 <!-- *************************************************************** -->
1049 <h2><a name="p2" id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</a></h2>
1050
1051
1052 <h3><a name="p2.1" id="p2.1">2.1. Repositories</a></h3>
1053
1054 <p>
1055 CAcert operates no repositories in the sense
1056 of lookup for non-certificate-related information
1057 for the general public.
1058 </p>
1059
1060 <p>
1061 Under the Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>),
1062 there are means for Members to search, retrieve
1063 and verify certain data about themselves and others.
1064 </p>
1065
1066 <h3><a name="p2.2" id="p2.2">2.2. Publication of certification information</a></h3>
1067
1068 <p>
1069 CAcert publishes:
1070 </p>
1071
1072 <ul>
1073   <li>A repository of CRLs.  An OCSP responder is in operation.</li>
1074   <li>The root certificate and intermediate certificates.</li>
1075 </ul>
1076
1077 <p>
1078 CAcert does not expressly publish information on issued certificates.
1079 However, due to the purpose of certificates, and the essential
1080 public nature of Names and email addresses, all information within
1081 certificates is presumed to be public and published, once
1082 issued and delivered to the Member.
1083 </p>
1084
1085 <h3><a name="p2.3" id="p2.3">2.3. Time or frequency of publication</a></h3>
1086
1087 <p>
1088 Root and Intermediate Certificates and CRLs are
1089 made available on issuance.
1090 </p>
1091
1092 <h3><a name="p2.4" id="p2.4">2.4. Access controls on repositories</a></h3>
1093 <p> No stipulation.  </p>
1094
1095
1096
1097 <!-- *************************************************************** -->
1098 <h2><a name="p3" id="p3">3. IDENTIFICATION AND AUTHENTICATION</a></h2>
1099
1100 <h3><a name="p3.1" id="p3.1">3.1. Naming</a></h3>
1101
1102 <h4><a name="p3.1.1" id="p3.1.1">3.1.1. Types of names</a></h4>
1103
1104 <p>
1105 <b>Client Certificates.</b>
1106 The Subscriber Naming consists of:
1107 </p>
1108 <ul>
1109   <li><tt>subjectAltName=</tt>
1110       One, or more, of the Subscriber's verified email addresses,
1111       in rfc822Name format.
1112
1113   <ul class="q">
1114     <li>SSO in subjectAltName?.</li>
1115   </ul>
1116   <li><tt>EmailAddress=</tt>
1117       One, or more, of the Subscriber's verified email addresses.
1118       This is deprecated under 
1119       RFC5280 <a href="http://tools.ietf.org/html/rfc5280#section-4.2.1.6">4
1120 .1.2.6</a>
1121       and is to be phased out. Also includes a SHA1 hash of a random number if 
1122       the member selects SSO (Single Sign On ID) during submission of CSR.
1123   </li>
1124   <li><tt>CN=</tt> The common name takes its value from one of:
1125     <ul><li>
1126       For all Members,
1127       the string "<tt>CAcert WoT Member</tt>" may be used for
1128       anonymous certificates.
1129     </li><li>
1130       For individual Members,
1131       a Name of the Subscriber,
1132       as Assured under AP.
1133     </li><li>
1134       For Organisation Members,
1135       an organisation-chosen name,
1136       as verified under OAP.
1137     </li></ul>
1138 </ul>
1139
1140   <ul class="q">
1141     <li> <a href="http://bugs.cacert.org/view.php?id=672"> bug 672</a> filed on subjectAltName.</li>
1142     <li> O-Admin must verify as per <a href="http://wiki.cacert.org/wiki/PolicyDecisions">p20081016</a>. </li>
1143     <li> it is a wip for OAP to state how this is done. </li>
1144     <li> curiously, (RFC5280) verification is only mandated for subjectAltName not subject field. </li>
1145     <li> what Directory String is used in above?  UTF8String is specified by RFC52804.1.2.6?  is this important for the CPS to state?</li>
1146   </ul>
1147
1148 <p>
1149 <b>Individual Server Certificates.</b>
1150 The Subscriber Naming consists of:
1151 </p>
1152 <ul>
1153  <li><tt>CN=</tt>
1154     The common name is the host name out of a domain
1155     for which the Member is a domain master.
1156   </li> <li>
1157   <tt>subjectAltName=</tt>
1158     Additional host names for which the Member
1159     is a domain master may be added to permit the
1160     certificate to serve multiple domains on one IP number.
1161   </li> <li>
1162     All other fields are optional and must either match
1163     the CN or they must be empty
1164 </li> </ul>
1165
1166 <p>
1167 <b>Certificates for Organisations.</b>
1168 In addition to the above, the following applies:
1169 </p>
1170
1171 <ul>
1172   <li><tt>OU=</tt>
1173       organizationalUnitName (set by O-Admin, must be verified by O-Admin).</li>
1174   <li><tt>O=</tt>
1175       organizationName is the fixed name of the Organisation.</li>
1176   <li><tt>L=</tt>
1177       localityName</li>
1178   <li><tt>ST=</tt>
1179       stateOrProvinceName</li>
1180   <li><tt>C=</tt>
1181       countryName</li>
1182   <li><tt>contact=</tt>
1183       EMail Address of Contact.
1184       <!--  not included in RFC5280 4.1.2.4 list, but list is not restricted -->
1185   </li>
1186 </ul>
1187
1188 <p>
1189 Except for the OU and CN, fields are taken from the Member's
1190 account and are as verified by the Organisation Assurance process.
1191 Other Subscriber information that is collected and/or retained
1192 does not go into the certificate.
1193 </p>
1194
1195 <h4><a name="p3.1.2" id="p3.1.2">3.1.2. Need for names to be meaningful</a></h4>
1196
1197 <p>
1198 Each Member's Name (<tt>CN=</tt> field)
1199 is assured under the Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
1200 or subsidiary policies (such as Organisation Assurance Policy).
1201 Refer to those documents for meanings and variations.
1202 </p>
1203
1204 <p>
1205 Anonymous certificates have the same <code>subject</code>
1206 field common name.
1207 See <a href="#p1.4.5">&sect;1.4.5.</a>.
1208 </p>
1209
1210 <p>
1211 Email addresses are verified according to
1212 <a href="#p4.2.2">&sect;4.2.2.</a>
1213 </p>
1214
1215 <!-- <center><a href="http://xkcd.com/327/"> <img src="http://imgs.xkcd.com/comics/exploits_of_a_mom.png"> </a> </center> -->
1216
1217 <h4><a name="p3.1.3" id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</a></h4>
1218
1219 <p>
1220 See <a href="#p1.4.5">&sect;1.4.5</a>.
1221 </p>
1222
1223 <h4><a name="p3.1.4" id="p3.1.4">3.1.4. Rules for interpreting various name forms</a></h4>
1224 <p>
1225 Interpretation of Names is controlled by the Assurance Policy,
1226 is administered by means of the Member's account,
1227 and is subject to change by the Arbitrator.
1228 Changes to the interpretation by means of Arbitration
1229 should be expected as fraud (e.g., phishing)
1230 may move too quickly for policies to fully document rules.
1231 </p>
1232
1233 <h4><a name="p3.1.5" id="p3.1.5">3.1.5. Uniqueness of names</a></h4>
1234
1235 <p>
1236 Uniqueness of Names within certificates is not guaranteed.
1237 Each certificate has a unique serial number which maps
1238 to a unique account, and thus maps to a unique Member.
1239 See the Assurance Statement within Assurance Policy
1240 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
1241 </p>
1242
1243 <p>
1244 Domain names and email address
1245 can only be registered to one Member.
1246 </p>
1247
1248 <h4><a name="p3.1.6" id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</a></h4>
1249
1250 <p>
1251 Organisation Assurance Policy
1252 (<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>)
1253 controls issues such as trademarks where applicable.
1254 A trademark can be disputed by filing a dispute.
1255 See
1256 <a href="#adr">&sect;9.13</a>.
1257 </p>
1258
1259 <h4><a name="p3.1.7" id="p3.1.7">3.1.7. International Domain Names</a></h4>
1260
1261 <p>
1262 Certificates containing International Domain Names, being those containing a 
1263 ACE prefix (<a href="http://www.ietf.org/rfc/rfc3490#section-5">RFC3490 
1264 Section 5</a>), will only be issued to domains satisfying one or more 
1265 of the following conditions:
1266 <ul>
1267 <li>The Top Level Domain (TLD) Registrar associated with the domain has a policy
1268 that has taken measures to prevent two homographic domains being registered to 
1269 different entities down to an accepted level.
1270 </li>
1271 <li>Domains contain only code points from a single unicode character script,
1272 excluding the "Common" script, with the additionally allowed numberic
1273 characters [0-9], and an ACSII hyphen '-'.
1274 </li>
1275 </ul>
1276 </p>
1277
1278 <p>Email address containing International Domain Names in the domain portion of
1279 the email address will also be required to satisfy one of the above conditions.
1280 </p>
1281
1282 <p>
1283 The following is a list of accepted TLD Registrars:
1284     <table>
1285
1286       <tr>
1287         <td>.ac</td>
1288         <td><a href="http://www.nic.ac/">Registry</a></td>
1289         <td><a href="http://www.nic.ac/pdf/AC-IDN-Policy.pdf">Policy</a></td>
1290       </tr>
1291       <tr>
1292         <td>.ar</td>
1293
1294         <td><a href="http://www.nic.ar/">Registry</a></td>
1295         <td><a href="http://www.nic.ar/616.html">Policy</a></td>
1296       </tr>
1297       <tr>
1298         <td>.at</td>
1299         <td><a href="http://www.nic.at/">Registry</a></td>
1300         <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>
1301
1302       </tr>
1303       <tr>
1304         <td>.biz</td>
1305         <td><a href="http://www.neustarregistry.biz/">Registry</a></td>
1306         <td><a href="http://www.neustarregistry.biz/products/idns">Policy</a></td>
1307       </tr>
1308       <tr>
1309
1310         <td>.br</td>
1311         <td><a href="http://registro.br/">Registry</a></td>
1312         <td><a href="http://registro.br/faq/faq6.html">Policy</a></td>
1313       </tr>
1314       <tr>
1315         <td>.cat</td>
1316         <td><a href="http://www.domini.cat/">Registry</a></td>
1317
1318         <td><a href="http://www.domini.cat/normativa/en_normativa_registre.html">Policy</a></td>
1319       </tr>
1320       <tr>
1321         <td>.ch</td>
1322         <td><a href="http://www.switch.ch/id/">Registry</a></td>
1323         <td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a></td>
1324       </tr>
1325
1326       <tr>
1327         <td>.cl</td>
1328         <td><a href="http://www.nic.cl/">Registry</a></td>
1329         <td><a href="http://www.nic.cl/CL-IDN-policy.html">Policy</a></td>
1330       </tr>
1331       <tr>
1332         <td>.cn</td>
1333
1334         <td><a href="http://www.cnnic.net.cn/">Registry</a></td>
1335         <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
1336       </tr>
1337       <tr>
1338         <td>.de</td>
1339         <td><a href="http://www.denic.de/">Registry</a></td>
1340
1341         <td><a href="http://www.denic.de/en/richtlinien.html">Policy</a></td>
1342       </tr>
1343       <tr>
1344         <td>.dk</td>
1345         <td><a href="http://www.dk-hostmaster.dk/">Registry</a></td>
1346         <td><a href="http://www.dk-hostmaster.dk/index.php?id=151">Policy</a></td>
1347       </tr>
1348
1349       <tr>
1350         <td>.es</td>
1351         <td><a href="https://www.nic.es/">Registry</a></td>
1352         <td><a href="https://www.nic.es/media/2008-12/1228818323935.pdf">Policy</a></td>
1353       </tr>
1354       <tr>
1355         <td>.fi</td>
1356
1357         <td><a href="http://www.ficora.fi/">Registry</a></td>
1358         <td><a href="http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html">Policy</a></td>
1359       </tr>
1360       <tr>
1361         <td>.gr</td>
1362         <td><a href="https://grweb.ics.forth.gr/english/index.html">Registry</a></td>
1363         <td><a href="https://grweb.ics.forth.gr/english/ENCharacterTable1.jsp">Policy</a></td>
1364
1365       </tr>
1366       <tr>
1367         <td>.hu</td>
1368         <td><a href="http://www.domain.hu/domain/">Registry</a></td>
1369         <td><a href="http://www.domain.hu/domain/English/szabalyzat.html">Policy</a> (section 2.1.2)</td>
1370       </tr>
1371
1372       <tr>
1373         <td>.info</td>
1374         <td><a href="http://www.afilias.info/">Registry</a></td>
1375         <td><a href="http://www.afilias.info/register/idn/">Policy</a></td>
1376       </tr>
1377       <tr>
1378         <td>.io</td>
1379
1380         <td><a href="http://www.nic.io">Registry</a></td>
1381         <td><a href="http://www.nic.io/IO-IDN-Policy.pdf">Policy</a></td>
1382       </tr>
1383       <tr>
1384         <td>.ir</td>
1385         <td><a href="https://www.nic.ir/">Registry</a></td>
1386         <td><a href="https://www.nic.ir/IDN">Policy</a></td>
1387
1388       </tr>
1389       <tr>
1390         <td>.is</td>
1391         <td><a href="http://www.isnic.is/">Registry</a></td>
1392         <td><a href="http://www.isnic.is/english/domain/rules.php">Policy</a></td>
1393       </tr>
1394       <tr>
1395
1396         <td>.jp</td>
1397         <td><a href="http://jprs.co.jp/">Registry</a></td>
1398         <td><a href="http://www.iana.org/assignments/idn/jp-japanese.html">Policy</a></td>
1399       </tr>
1400       <tr>
1401         <td>.kr</td>
1402         <td><a href="http://domain.nic.or.kr/">Registry</a></td>
1403
1404         <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
1405       </tr>
1406       <tr>
1407         <td>.li</td>
1408         <td><a href="http://www.switch.ch/id/">Registry</a></td>
1409         <td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a> (managed by .ch registry)</td>
1410
1411       </tr>
1412       <tr>
1413         <td>.lt</td>
1414         <td><a href="http://www.domreg.lt/public?pg=&sp=&loc=en">Registry</a></td>
1415         <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>
1416
1417       </tr>
1418       <tr>
1419         <td>.museum</td>
1420         <td><a href="http://about.museum/">Registry</a></td>
1421         <td><a href="http://about.museum/idn/idnpolicy.html">Policy</a></td>
1422       </tr>
1423       <tr>
1424
1425         <td>.no</td>
1426         <td><a href="http://www.norid.no/">Registry</a></td>
1427         <td><a href="http://www.norid.no/domeneregistrering/veiviser.en.html">Policy</a> (section 4)</td>
1428       </tr>
1429       <tr>
1430         <td>.org</td>
1431
1432         <td><a href="http://www.pir.org/">Registry</a></td>
1433         <td><a href="http://pir.org/PDFs/ORG-Extended-Characters-22-Jan-07.pdf">Policy</a></td>
1434       </tr>
1435       <tr>
1436         <td>.pl</td>
1437         <td><a href="http://www.nask.pl/">Registry</a></td>
1438         <td><a href="http://www.dns.pl/IDN/idn-registration-policy.txt">Policy</a></td>
1439
1440       </tr>
1441       <tr>
1442         <td>.pr</td>
1443         <td><a href="https://www.nic.pr/">Registry</a></td>
1444         <td><a href="https://www.nic.pr/idn_rules.asp">Policy</a></td>
1445       </tr>
1446       <tr>
1447
1448         <td>.se</td>
1449         <td><a href="http://www.nic-se.se/">Registry</a></td>
1450         <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>
1451       </tr>
1452       <tr>
1453
1454         <td>.sh</td>
1455         <td><a href="http://www.nic.sh">Registry</a></td>
1456         <td><a href="http://www.nic.sh/SH-IDN-Policy.pdf">Policy</a></td>
1457       </tr>
1458       <tr>
1459         <td>.th</td>
1460         <td><a href="http://www.thnic.or.th/">Registry</a></td>
1461
1462         <td><a href="http://www.iana.org/assignments/idn/th-thai.html">Policy</a></td>
1463       </tr>
1464       <tr>
1465         <td>.tm</td>
1466         <td><a href="http://www.nic.tm">Registry</a></td>
1467         <td><a href="http://www.nic.tm/TM-IDN-Policy.pdf">Policy</a></td>
1468       </tr>
1469
1470       <tr>
1471         <td>.tw</td>
1472         <td><a href="http://www.twnic.net.tw/">Registry</a></td>
1473         <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
1474       </tr>
1475       <tr>
1476
1477         <td>.vn</td>
1478         <td><a href="http://www.vnnic.net.vn/">Registry</a></td>
1479         <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>
1480       </tr>
1481   </table>
1482 </p>
1483
1484 <p>
1485 This criteria will apply to the email address and server host name fields for all certificate types.
1486 </p>
1487
1488 <p>
1489 The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list.
1490 </p>
1491
1492 <h3><a name="p3.2" id="p3.2">3.2. Initial Identity Verification</a></h3>
1493
1494 <p>
1495 Identity verification is controlled by the
1496 <a href="http://svn.cacert.org/CAcert/Policies/AssurancePolicy.html">
1497 Assurance Policy</a> (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
1498 The reader is refered to the Assurance Policy,
1499 the following is representative and brief only.
1500 </p>
1501
1502
1503 <h4><a name="p3.2.1" id="p3.2.1">3.2.1. Method to prove possession of private key</a></h4>
1504
1505 <p>
1506 CAcert uses industry-standard techniques to
1507 prove the possession of the private key.
1508 </p>
1509
1510 <p>
1511 For X.509 server certificates,
1512 the stale digital signature of the CSR is verified.
1513 For X.509 client certificates for "Netscape" browsers,
1514 SPKAC uses a challenge-response protocol
1515 to check the private key dynamically.
1516 For X.509 client certificates for "explorer" browsers,
1517 ActiveX uses a challenge-response protocol
1518 to check the private key dynamically.
1519 </p>
1520
1521 <h4><a name="p3.2.2" id="p3.2.2">3.2.2. Authentication of Individual Identity</a></h4>
1522
1523 <p>
1524 <b>Agreement.</b>
1525 An Internet user becomes a Member by agreeing to the
1526 CAcert Community Agreement
1527 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
1528 and registering an account on the online website.
1529 During the registration process Members are asked to
1530 supply information about themselves:
1531 </p>
1532   <ul>
1533     <li>A valid working email.
1534         </li>
1535     <li>Full Name and Date of Birth such as is 
1536         found on Identity documents.
1537         </li>
1538     <li>Personal Questions used only for Password Retrieval.</li>
1539   </ul>
1540
1541 <p>
1542 The online account establishes the method of authentication
1543 for all service requests such as certificates.
1544 </p>
1545
1546 <p>
1547 <b>Assurance.</b>
1548 Each Member is assured according to Assurance Policy
1549 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
1550 </p>
1551
1552 <!-- <center><a href="http://xkcd.com/364/"> <img src="http://imgs.xkcd.com/comics/responsible_behavior.png"> </a> </center> -->
1553
1554
1555
1556 <p>
1557 <b>Certificates.</b>
1558 Based on the total number of Assurance Points
1559 that a Member (Name) has, the Member
1560 can get different levels of certificates.
1561 See <a href="#p1.4.5">&sect;1.4.5</a>.
1562 See Table 3.2.b.
1563 When Members have 50 or more points, they
1564 become <i>Assured Members</i> and may then request
1565 certificates that state their Assured Name(s).
1566 </p>
1567
1568
1569 <br><br>
1570 <center>
1571
1572 <table border="1" cellpadding="5">
1573  <tr>
1574   <th>Assurance Points</th>
1575   <th>Level</th>
1576   <th>Service</th>
1577   <th>Comments</th>
1578  </tr>
1579  <tr>
1580   <td>0</td>
1581   <td>Unassured Member</td>
1582   <td>Anonymous</td>
1583   <td>Certificates with no Name, under Class 1 Root.  Limited to 6 months expiry.</td>
1584  </tr>
1585  <tr>
1586   <td>1-49</td>
1587   <td>Unassured Member</td>
1588   <td>Anonymous</td>
1589   <td>Certificates with no Name under Member SubRoot.  Limited to 6 months expiry.</td>
1590  </tr>
1591  <tr>
1592   <td rowspan="1">50-99</td>
1593   <td>Assured Member</td>
1594   <td>Verified</td>
1595   <td>Certificates with Verified Name for S/MIME, web servers, "digital signing."
1596       Expiry after 24 months is available.</td>
1597  </tr>
1598  <tr>
1599   <td rowspan="2">100++</td>
1600   <td rowspan="2">Assurer</td>
1601   <td>Code-signing</td>
1602   <td>Can create Code-signing certificates </td>
1603  </tr>
1604 </table>
1605
1606 <span class="figure">Table 3.2.b - How Assurance Points are used in Certificates</span>
1607
1608 </center>
1609 <br>
1610
1611
1612
1613 <h4><a name="p3.2.3" id="p3.2.3">3.2.3. Authentication of organization identity</a></h4>
1614
1615
1616 <p>
1617 Verification of organisations is delegated by
1618 the Assurance Policy to the
1619 Organisation Assurance Policy
1620 (<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>).
1621 The reader is refered to the Organisation Assurance Policy,
1622 the following is representative and brief only.
1623 </p>
1624
1625 <p>
1626 Organisations present special challenges.
1627 The Assurance process for Organisations is
1628 intended to permit the organisational Name to
1629 appear in certificates.
1630 The process relies heavily on the Individual
1631 process described above.
1632 </p>
1633
1634 <p>
1635 Organisation Assurance achieves the standard
1636 stated in the OAP, briefly presented here:
1637 </p>
1638
1639 <ol type="a"><li>
1640    the organisation exists,
1641   </li><li>
1642    the organisation name is correct and consistent,
1643   </li><li>
1644    signing rights: requestor can sign on behalf of the organisation, and
1645   </li><li>
1646    the organisation has agreed to the terms of the
1647    CAcert Community Agreement
1648    (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
1649    and is therefore subject to Arbitration. 
1650 </li></ol>
1651
1652   <ul class="error">
1653     <li> As of the current time of writing, OA lacks critical documentation and there are bugs identified with no response.</li>
1654     <li> <a href="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance">documented bugs</a>. </li>
1655     <li> Therefore Organisations will not participate in the current audit cycle of roots. </li>
1656     <li> See <a href="http://wiki.cacert.org/wiki/OrganisationAssurance">wiki</a> for any progress on this. </li>
1657   </ul>
1658
1659
1660 <h4><a name="p3.2.4" id="p3.2.4">3.2.4. Non-verified subscriber information</a></h4>
1661
1662 <p>
1663 All information in the certificate is verified,
1664 see Relying Party Statement, &sect;4.5.2.
1665 </p>
1666
1667
1668 <h4><a name="p3.2.5" id="p3.2.5">3.2.5. Validation of authority</a></h4>
1669
1670 <p>
1671 The authorisation to obtain a certificate is established as follows:
1672 </p>
1673
1674 <p>
1675 <b>Addresses.</b>
1676 The member claims authority over a domain or email address
1677 when adding the address,  <a href="#p4.1.2">&sect;4.1.2</a>.
1678 (Control is tested by means described in <a href="#p4.2.2">&sect;4.2.2</a>.)
1679 </p>
1680
1681 <p>
1682 <b>Individuals.</b>
1683 The authority to participate as a Member is established
1684 by the CAcert Community Agreement
1685 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
1686 Assurances are requested by means of the signed CAP form.
1687 </p>
1688
1689 <p>
1690 <b>Organisations.</b>
1691 The authority for Organisation Assurance is established
1692 in the COAP form, as signed by an authorised representative
1693 of the organisation.
1694 The authority for the
1695 Organisation Administrator
1696 (O-Admin) is also established on the
1697 COAP form.
1698 See Organisation Assurance Policy.
1699 </p>
1700
1701
1702 <h4><a name="p3.2.6" id="p3.2.6">3.2.6. Criteria for interoperation</a></h4>
1703
1704 <p>
1705 CAcert does not currently issue certificates to subordinate CAs
1706 or other PKIs.
1707 Other CAs may become Members, and are then subject to the
1708 same reliance provisions as all Members.
1709 </p>
1710
1711 <h3><a name="p3.3" id="p3.3">3.3. Re-key Requests</a></h3>
1712
1713 <p>
1714 Via the Member's account.
1715 </p>
1716
1717 <h3><a name="p3.4" id="p3.4">3.4. Revocations Requests</a></h3>
1718
1719 <p>
1720 Via the Member's account.
1721 In the event that the Member has lost the password,
1722 or similar, the Member emails the support team who
1723 either work through the lost-password questions
1724 process or file a dispute.
1725 </p>
1726
1727
1728
1729 <!-- *************************************************************** -->
1730 <h2><a name="p4" id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a></h2>
1731
1732 <p>
1733 The general life-cycle for a new certificate for an Individual Member is:
1734
1735 <ol><li>
1736     Member adds claim to an address (domain/email).
1737   </li><li>
1738     System probes address for control.
1739   </li><li>
1740     Member creates key pair.
1741   </li><li>
1742     Member submits CSR with desired options (Anonymous Certificate, SSO, Root Certificate) .
1743   </li><li>
1744     System validates and accepts CSR based on
1745     known information:  claims, assurance, controls, technicalities.
1746   </li><li>
1747     System signs certificate.
1748   </li><li>
1749     System makes signed certificate available to Member.
1750   </li><li>
1751     Member accepts certificate.
1752 </li></ol>
1753     
1754 </p>
1755
1756 <p>
1757 (Some steps are not applicable, such as anonymous certificates.)
1758 </p>
1759
1760
1761 <h3><a name="p4.1" id="p4.1">4.1. Certificate Application</a></h3>
1762
1763 <h4><a name="p4.1.1" id="p4.1.1">4.1.1. Who can submit a certificate application</a></h4>
1764
1765 <p>
1766 Members may submit certificate applications.
1767 On issuance of certificates, Members become Subscribers.
1768 </p>
1769
1770 <h4><a name="p4.1.2" id="p4.1.2">4.1.2. Adding Addresses</a></h4>
1771
1772 <p>
1773 The Member can claim ownership or authorised control of
1774 a domain or email address on the online system.
1775 This is a necessary step towards issuing a certificate.
1776 There are these controls:
1777 <ul><li>
1778     The claim of ownership or control is legally significant
1779     and may be referred to dispute resolution.
1780   </li><li>
1781     Each unique address can be handled by one account only.
1782   </li><li>
1783     When the Member makes the claim,
1784     the certificate application system automatically initiates the
1785     check of control, as below.
1786 </li></ul>
1787 </p>
1788
1789 <h4><a name="p4.1.3" id="p4.1.3">4.1.3. Preparing CSR </a></h4>
1790
1791 <p>
1792 Members generate their own key-pairs.
1793 The CAcert Community Agreement
1794 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
1795 obliges the Member as responsible for security.
1796 See CCA2.5, &sect;9.6.
1797 </p>
1798
1799 <p>
1800 The Certificate Signing Request (CSR) is prepared by the
1801 Member for presentation to the automated system.
1802 </p>
1803
1804 <h3><a name="p4.2" id="p4.2">4.2. Certificate application processing</a></h3>
1805
1806 <!-- states what a CA does on receipt of the request -->
1807
1808 <p>
1809 The CA's certificate application process is completely automated.
1810 Requests, approvals and rejections are handled by the website system.
1811 Each application should be processed in less than a minute.
1812 </p>
1813 <p>
1814 Where certificates are requested for more than one
1815 purpose, the requirements for each purpose must be
1816 fulfilled.
1817 </p>
1818
1819 <!-- all sub headings in 4.2 are local, not from Chokhani. -->
1820
1821 <h4><a name="p4.2.1" id="p4.2.1">4.2.1. Authentication </a></h4>
1822
1823 <p>
1824   The Member logs in to her account on the CAcert website
1825       and thereby authenticates herself with username
1826       and passphrase or with her CAcert client-side digital certificate.
1827 </p>
1828
1829 <h4><a name="p4.2.2" id="p4.2.2">4.2.2. Verifying Control</a></h4>
1830
1831 <p>
1832 In principle, at least two controls are placed on each address.
1833 </p>
1834
1835 <p>
1836 <b><a name="ping">Email-Ping</a>.</b>
1837 Email addresses are verified by means of an
1838 <i><a name="ping">Email-Ping test</a></i>:
1839 </p>
1840
1841 <ul><li>
1842       The system generates a cookie
1843       (a random, hard-to-guess code)
1844       and formats it as a string.
1845   </li><li>
1846       The system sends the cookie
1847       to the Member in an email.
1848   </li><li>
1849       Once the Member receives the email,
1850       she enters the cookie into the website.
1851   </li><li>
1852       The entry of the code verifies
1853       control of that email account.
1854 </li></ul>
1855
1856 <p>
1857 <b><a name="email">Email Control</a>.</b>
1858 Email addresses for client certificates are verified by passing the
1859 following checks:
1860 </p>
1861 <ol>
1862   <li>An Email-ping test
1863       is done on the email address.
1864       </li>
1865   <li>The Member must have signed a CAP form or equivalent,
1866       and been awarded at least one Assurance point.
1867       </li>
1868 </ol>
1869
1870 <p>
1871 <b><a name="domain">Domain Control</a>.</b>
1872 Domains addresses for server certificates are verified by passing two of the
1873 following checks:
1874 </p>
1875 <ol> <li>
1876       An Email-ping test
1877       is done on an email address chosen from <i>whois</i>
1878       or interpolated from the domain name.
1879   </li> <li>
1880       The system generates a cookie
1881       which is then placed in DNS
1882       by the Member.
1883   </li> <li>
1884       The system generates a cookie
1885       which is then placed in HTTP headers or a text file on the website
1886       by the Member.
1887   </li> <li>
1888       Statement by at least 2 Assurers about
1889       ownership/control of the domain name.
1890   </li> <li>
1891       The system generates a cookie
1892       which is then placed in whois registry information
1893       by the Member.
1894 </li> </ol>
1895
1896 <p>
1897 Notes.
1898 <ul><li>
1899     Other methods can be added from time to time by CAcert.
1900   </li><li>
1901     Static cookies should remain for the duration of a certificate
1902     for occasional re-testing.
1903   </li><li>
1904     Dynamic tests can be repeated at a later time of CAcert's choosing.
1905   </li><li>
1906     Domain control checks may be extended to apply to email control
1907     in the future.
1908 </li></ul>
1909 </p>
1910
1911   <ul class="q">
1912     <li> As of the time of writing, only a singular Email-ping is implemented in the technical system. </li>
1913     <li> A further approved check is the 1 pt Assurance. </li>
1914     <li> Practically, this would mean that certificates can only be issued under Audit Roots to Members with 1 point. </li>
1915     <li> Criteria DRC C.7.f, A.2.q, A.2.i indicate registry whois reading. Also A.2.h. </li>
1916     <li> Current view is that this will be resolved in BirdShack. </li>
1917   </ul>
1918
1919 <h4><a name="p4.2.3" id="p4.2.3">4.2.3. Options Available</a></h4>
1920
1921 <p>
1922 The Member has options available:
1923 </p>
1924
1925 <ul>
1926   <li>Each Email address that is verified
1927       is available for Client Certificates.
1928       </li>
1929   <li>Each Domain address that is verified
1930       is available for Server Certificates.
1931       </li>
1932   <li>If the Member is unassured then only the Member SubRoot is available.
1933       </li>
1934   <li>If the Member is Assured then both Assured Member and Member SubRoots
1935       are available.
1936       </li>
1937   <li>If a Name is Assured then it may be
1938       put in a client certificate or an OpenPGP signature.
1939       </li>
1940 </ul>
1941
1942 <h4><a name="p4.2.4" id="p4.2.4">4.2.4. Client Certificate Procedures</a></h4>
1943
1944 <p>
1945 For an individual client certificate, the following is required.
1946 <ul>
1947   <li>The email address is claimed and added. </li>
1948   <li>The email address is ping-tested. </li>
1949   <li>For the Member Subroot, the Member must have
1950       at least one point of Assurance and have signed a CAP form.</li>
1951   <li>For the Assured Subroot, the Member must have
1952       at least fifty points of Assurance. </li>
1953   <li>To include a Name, the Name must be assured to at least fifty points. </li>
1954
1955 </ul>
1956 </p>
1957
1958 <h4><a name="p4.2.5" id="p4.2.5">4.2.5. Server Certificate Procedures</a></h4>
1959
1960 <p>
1961 For a server certificate, the following is required:
1962 <ul>
1963   <li>The domain is claimed and added. </li>
1964   <li>The domain is checked twice as above. </li>
1965   <li>For the Member SubRoot, the Member must have
1966       at least one point of Assurance and have signed a CAP form.</li>
1967   <li>For the Assured SubRoot, the Member must have
1968       at least fifty points of Assurance. </li>
1969 </ul>
1970
1971 </p>
1972
1973 <h4><a name="p4.2.6" id="p4.2.6">4.2.6. Code-signing Certificate Procedures</a></h4>
1974
1975 <p>
1976 Code-signing certificates are made available to Assurers only.
1977 They are processed in a similar manner to client certificates.
1978 </p>
1979
1980 <h4><a name="p4.2.7" id="p4.2.7">4.2.7. Organisation Domain Verification</a></h4>
1981
1982 <p>
1983 Organisation Domains are handled under the Organisation Assurance Policy
1984 and the Organisation Handbook.
1985 </p>
1986
1987   <ul class="q">
1988      <li> 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 ....  </li>
1989      <li> <a href="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance"> Drafts </a> for ongoing story. </li>
1990   </ul>
1991
1992 <h3><a name="p4.3" id="p4.3">4.3. Certificate issuance</a></h3>
1993
1994
1995 <!-- <a href="http://xkcd.com/153/"> <img align="right" src="http://imgs.xkcd.com/comics/cryptography.png"> </a> -->
1996 <h4><a name="p4.3.1" id="p4.3.1">4.3.1. CA actions during certificate issuance</a></h4>
1997
1998 <p>
1999 <b>Key Sizes.</b>
2000 Members may request keys of any size permitted by the key algorithm.
2001 Many older hardware devices require small keys.
2002 </p>
2003
2004 <p>
2005 <b>Algorithms.</b>
2006 CAcert currently only supports the RSA algorithm for X.509 keys.
2007 X.509 signing uses the SHA-1 message digest algorithm.
2008 OpenPGP Signing uses RSA signing over RSA and DSA keys.
2009
2010 </p>
2011
2012 <p>
2013 <b>Process for Certificates:</b>
2014 All details in each certificate are verified
2015 by the website issuance system.
2016 Issuance is based on a 'template' system that selects
2017 profiles for certificate lifetime, size, algorithm.
2018 </p>
2019
2020
2021 <ol><li>
2022    The CSR is verified.
2023   </li><li>
2024    Data is extracted from CSR and verified:
2025     <ul>
2026       <li> Name &sect;3.1, </li>
2027       <li> Email address <a href="#p4.2.2">&sect;4.2.2</a>, </li>
2028       <li> Domain address <a href="#p4.2.2">&sect;4.2.2</a>. </li>
2029     </ul>
2030   </li><li>
2031    Certificate is generated from template.
2032   </li><li>
2033    Data is copied from CSR.
2034   </li><li>
2035    Certificate is signed.
2036   </li><li>
2037    Certificate is stored as well as mailed.
2038 </li></ol>
2039
2040
2041 <p>
2042 <b>Process for OpenPGP key signatures:</b>
2043 All details in each Sub-ID are verified
2044 by the website issuance system.
2045 Issuance is based on the configuration that selects
2046 the profile for signature lifetime, size,
2047 algorithm following the process:
2048 </p>
2049
2050 <ol><li>
2051    The public key is verified.
2052   </li><li>
2053    Data is extracted from the key and verified (Name, Emails).
2054    Only the combinations of data in Table 4.3.1 are permitted.
2055   </li><li>
2056    OpenPGP Key Signature is generated.
2057   </li><li>
2058    Key Signature is applied to the key.
2059   </li><li>
2060    The signed key is stored as well as mailed.
2061 </li></ol>
2062
2063 <center>
2064 <table border="1" align="center" valign="top" cellpadding="5"><tbody>
2065   <tr>
2066     <td><br></td>
2067     <td>Verified Name</td>
2068     <td valign="top">Unverified Name<br></td>
2069     <td>Empty Name<br></td>
2070   </tr>
2071   <tr>
2072     <td>Verified email<br></td>
2073     <td><center> <font title="pass." color="green" size="+3"> &#10004; </font>  </center></td>
2074     <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
2075     <td><center> <font title="pass." color="green" size="+3"> &#10004; </font>  </center></td>
2076   </tr>
2077   <tr>
2078     <td>Unverified email</td>
2079     <td><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
2080     <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
2081     <td><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td></tr><tr><td valign="top">Empty email<br></td>
2082     <td valign="top"><center> <font title="pass." color="green" size="+3"> &#10004; </font>  </center></td>
2083     <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
2084     <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
2085   </tr>
2086 </tbody></table><br>
2087
2088 <span class="figure">Table 4.3.1.  Permitted Data in Signed OpenPgp Keys</span>
2089 </center>
2090
2091 <h4><a name="p4.3.2" id="p4.3.2">4.3.2. Notification to subscriber by the CA of issuance of certificate</a></h4>
2092
2093 <p>
2094 Once signed, the certificate is
2095 made available via the Member's account,
2096 and emailed to the Member.
2097 It is also archived internally.
2098 </p>
2099
2100 <h3><a name="p4.4" id="p4.4">4.4. Certificate acceptance</a></h3>
2101
2102 <h4><a name="p4.4.1" id="p4.4.1">4.4.1. Conduct constituting certificate acceptance</a></h4>
2103
2104 <p>
2105 There is no need for the Member to explicitly accept the certificate.
2106 In case the Member does not accept the certificate,
2107 the certificate has to be revoked and made again.
2108 </p>
2109
2110 <h4><a name="p4.4.2" id="p4.4.2">4.4.2. Publication of the certificate by the CA</a></h4>
2111
2112 <p>
2113 CAcert does not currently publish the issued certificates
2114 in any repository.
2115 In the event that CAcert will run a repository,
2116 the publication of certificates and signatures
2117 there will be at the Member's options.
2118 However note that certificates that are issued
2119 and delivered to the Member are presumed to be
2120 published.  See &sect;2.2.
2121 </p>
2122
2123 <h4><a name="p4.4.3" id="p4.4.3">4.4.3. Notification of certificate issuance by the CA to other entities</a></h4>
2124
2125 <p>
2126 There are no external entities that are notified about issued certificates.
2127 </p>
2128
2129 <h3><a name="p4.5" id="p4.5">4.5. Key pair and certificate usage</a></h3>
2130
2131 <p>
2132 All Members (subscribers and relying parties)
2133 are obliged according to the
2134 CAcert Community Agreement
2135 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
2136 See especially 2.3 through 2.5.
2137 </p>
2138 <h4><a name="p4.5.1" id="p4.5.1">4.5.1. Subscriber Usage and Responsibilities</a></h4>
2139
2140 <p>
2141 Subscribers should use keys only for their proper purpose,
2142 as indicated by the certificate, or by wider agreement with
2143 others.
2144 </p>
2145
2146 <h4><a name="p4.5.2" id="p4.5.2">4.5.2. Relying Party Usage and Responsibilities</a></h4>
2147
2148
2149 <p>
2150 Relying parties (Members) may rely on the following.
2151 </p>
2152
2153 <center>
2154   <table border="1" cellpadding="25"><tr><td>
2155   <p align="center">
2156   <big><b>Relying Party Statement</b></big>
2157   <p>
2158   Certificates are issued to Members only.<br><br>
2159   All information in a certificate is verified.
2160   </p>
2161   </td></tr></table>
2162 </center>
2163
2164
2165 <p>
2166 The following notes are in addition to the Relying Party Statement,
2167 and can be seen as limitations on it.
2168 </p>
2169
2170 <h5>4.5.2.a Methods of Verification </h5>
2171 <p>
2172 The term Verification as used in the Relying Party Statement means one of
2173 </p>
2174 <table border="1" cellpadding="5"><tr>
2175   <th>Type</th><th>How</th><th>Authority</th><th>remarks</th>
2176 </tr><tr>
2177   <th>Assurance</th><td>under CAcert Assurance Programme (CAP)</td>
2178     <td>Assurance Policy</td>
2179     <td>only information assured to 50 points under CAP is placed in the certificate </td>
2180 </tr><tr>
2181   <th>Evaluation</th><td>under automated domain and email checks </td>
2182     <td>this CPS</td>
2183     <td>see &sect;4.2.2</td>
2184 </tr><tr>
2185   <th>Controlled</th><td>programs or "profiles" that check the information within the CSR </td>
2186     <td>this CPS</td>
2187     <td>see &sect;7.1</td>
2188 </tr></table>
2189
2190 <h5>4.5.2.b Who may rely</h5>
2191 <p>
2192 <b>Members may rely.</b>
2193 Relying parties are Members,
2194 and as such are bound by this CPS and the
2195 CAcert Community Agreement
2196 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
2197 The licence and permission to rely is not assignable.
2198 </p>
2199
2200 <p>
2201 <b>Suppliers of Software.</b>
2202 CAcert roots may be distributed in software,
2203 and those providers may
2204 enter into agreement with CAcert by means of the
2205 Third Party Vendor - Disclaimer and Licence
2206 (wip).
2207 This licence brings the supplier in to the Community
2208 to the extent that <span class="q"> ...WIP comment:</span>
2209 they agree to dispute resolution
2210 within CAcert's forum.
2211 </p>
2212
2213   <ul class="q">
2214     <li> Just exactly what the 3PV-DaL says is unclear.</li>
2215     <li> The document itself is more a collection of ideas.</li>
2216   </ul>
2217
2218
2219 <p>
2220 <b>NRPs may not rely.</b>
2221 If not related to CAcert by means of an agreement
2222 that binds the parties to dispute resolution within CAcert's forum,
2223 a person is a Non-Related-Person (NRP).
2224 An NRP is not permitted to rely and is not a Relying Party.
2225 For more details, see the
2226 NRP - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
2227 </p>
2228
2229 <h5>4.5.2.c The Act of Reliance </h5>
2230
2231 <p>
2232 <b>Decision making.</b>
2233 Reliance means taking a decision that is in part or in whole
2234 based on the information in the certificate.
2235
2236 A Relying Party may incorporate
2237 the information in the certificate,
2238 and the implied information such as Membership,
2239 into her decision-making.
2240 In making a decision,
2241 a Relying Party should also:
2242 </p>
2243
2244 <ul><li>
2245     include her own overall risk equation,
2246   </li><li>
2247     include the general limitations of the Assurance process,
2248     certificates, and wider security considerations,
2249   </li><li>
2250     make additional checks to provide more information,
2251   </li><li>
2252     consider any wider agreement with the other Member, and
2253   </li><li>
2254     use an appropriate protocol or custom of reliance (below).
2255 </li></ul>
2256
2257 <p>
2258 <b>Examining the Certificate.</b>
2259 A Relying Party must make her own decision in using
2260 each certificate.  She must examine the certificate,
2261 a process called <i>validation</i>.
2262 Certificate-related information includes,
2263 but is not limited to:
2264 </p> 
2265 <ul><li>
2266     Name,
2267   </li><li>
2268     expiry time of certificate,
2269   </li><li>
2270     current certificate revocation list (CRL),
2271   </li><li>
2272     certificate chain and
2273     the validity check of the certificates in the chain,
2274   </li><li>
2275     issuer of certificate (CAcert),
2276   </li><li>
2277     SubRoot is intended for reliance (Assured, Organisation and Class 3)
2278   </li><li>
2279     purpose of certificate.
2280 </li></ul>
2281
2282 <p>
2283 <b>Keeping Records.</b>
2284 Records should be kept, appropriate to the import of the decision.
2285 The certificate should be preserved.
2286 This should include sufficient
2287 evidence to establish who the parties are
2288 (especially, the certificate relied upon),
2289 to establish the transaction in question,
2290 and to establish the wider agreement that
2291 defines the act.
2292 </p>
2293
2294 <p>
2295 <b>Wider Protocol.</b>
2296 In principle, reliance will be part of a wider protocol
2297 (customary method in reaching and preserving agreement)
2298 that presents and preserves sufficient of the evidence
2299 for dispute resolution under CAcert's forum of Arbitration.
2300 The protocol should be agreed amongst the parties,
2301 and tuned to the needs.
2302 This CPS does not define any such protocol.
2303 In the absence of such a protocol, reliance will be weakened;
2304 a dispute without sufficient evidence may be dismissed by an Arbitrator.
2305 </p>
2306
2307 <p>
2308 <b>As Compared to Usage</b>.
2309 Reliance goes beyond Usage.  The latter is limited to
2310 letting the software act as the total and only Validation
2311 Authority.  When relying, the Member also augments
2312 the algorithmic processing of the software with her own
2313 checks of the business, technical and certificate aspect.
2314 </p>
2315
2316 <h5>4.5.2.d Risks and Limitations of Reliance </h5>
2317 <p>
2318 <b>Roots and Naming.</b>
2319 Where the Class 1 root is used,
2320 this Subscriber may be a new Member
2321 including one with zero points.
2322 Where the Name is not provided,
2323 this indicates it is not available.
2324 In these circumstances,
2325 reliance is not defined,
2326 and Relying parties should take more care.
2327 See Table 4.5.2.
2328 </p>
2329
2330 <center>
2331 <table border="1" cellpadding="5">
2332  <tr>
2333   <td></td>
2334   <td colspan="4"><center><i>Statements of Reliance for Members</center></i></td>
2335  </tr>
2336  <tr>
2337   <td><i>Class of Root</i></td>
2338   <td><center><b>Anonymous</b><br>(all Members)</center></td>
2339   <td><center><b>Named</b><br>(Assured Members only)</center></td>
2340  </tr>
2341  <tr>
2342   <td><center>Class<br><big><b>1</b></big></center></td>
2343   <td rowspan="2" bgcolor="red">
2344        <b>Do not rely.</b><BR>
2345        Relying party must use other methods to check. </td>
2346   <td rowspan="2" bgcolor="orange">
2347        Do not rely.
2348        Although the named Member has been Assured by CAcert,
2349        reliance is not defined with Class 1 root.<BR>
2350        (issued for compatibility only).</td>
2351  </tr>
2352  <tr>
2353   <td><center><big><b>Member</b></big><br>SubRoot</center></td>
2354  </tr>
2355  <tr>
2356   <td><center>Class<br><big><b>3</b></big></center></td>
2357   <td rowspan="2" bgcolor="orange">
2358        Do not rely on the Name (being available).
2359        The Member has been Assured by CAcert,
2360        but reliance is undefined.</td>
2361   <td rowspan="2">
2362        The Member named in the certificate has been Assured by CAcert.</td>
2363  </tr>
2364  <tr>
2365   <td><center><big><b>Assured</b></big><br>SubRoot</center></td>
2366  </tr>
2367 </table>
2368
2369 <span class="figure">Table 4.5.2.  Statements of Reliance</span>
2370 </center>
2371
2372 <p>
2373 <b>Software Agent.</b>
2374 When relying on a certificate, relying parties should
2375 note that your software is responsible for the way it
2376 shows you the information in a certificate.
2377 If your software agent hides parts of the information,
2378 your sole remedy may be to choose another software agent.
2379 </p>
2380
2381 <p>
2382 <b>Malware.</b>
2383 When relying on a certificate, relying parties should
2384 note that platforms that are vulnerable to viruses or
2385 trojans or other weaknesses may not process any certificates
2386 properly and may give deceptive or fraudulent results.
2387 It is your responsibility to ensure you are using a platform
2388 that is secured according to the needs of the application.
2389 </p>
2390
2391 <h5>4.5.2.e When something goes wrong </h5>
2392 <p>
2393 In the event that an issue arises out of the Member's reliance,
2394 her sole avenue is <b>to file dispute under DRP</b>.
2395 See <a href="#p9.13">&sect;9.13</a>.
2396 <!-- DRC_A&sect;A.4.d -->
2397 For this purpose, the certificate (and other evidence) should be preserved.
2398 </p>
2399
2400 <p>
2401 <b>Which person?</b>
2402 Members may install certificates for other individuals or in servers,
2403 but the Member to whom the certificate is issued
2404 remains the responsible person.
2405 E.g., under Organisation Assurance, an organisation is issued
2406 a certificate for the use by individuals
2407 or servers within that organisation,
2408 but the Organisation is the responsible person.
2409 </p>
2410
2411 <!-- <a href="http://xkcd.com/424/"> <img align="right" src="http://imgs.xkcd.com/comics/security_holes.png"> </a>  -->
2412 <p>
2413 <b>Software Agent.</b>
2414 If a Member is relying on a CAcert root embedded in
2415 the software as supplied by a vendor,
2416 the risks, liabilities and obligations of the Member
2417 do not automatically transfer to the vendor.
2418 </p>
2419
2420 <h3><a name="p4.6" id="p4.6">4.6. Certificate renewal</a></h3>
2421
2422 <p>
2423 A certificate can be renewed at any time.
2424 The procedure of certificate renewal is the same
2425 as for the initial certificate issuance.
2426 </p>
2427
2428 <h3><a name="p4.7" id="p4.7">4.7. Certificate re-key</a></h3>
2429
2430 <p>
2431 Certificate "re-keyings" are not offered nor supported.
2432 A new certificate with a new key has to be requested and issued instead,
2433 and the old one revoked.
2434 </p>
2435
2436 <h3><a name="p4.8" id="p4.8">4.8. Certificate modification</a></h3>
2437
2438 <p>
2439 Certificate "modifications" are not offered nor supported.
2440 A new certificate has to be requested and issued instead.
2441 </p>
2442
2443 <h3><a name="p4.9" id="p4.9">4.9. Certificate revocation and suspension</a></h3>
2444
2445 <h4><a name="p4.9.1" id="p4.9.1">4.9.1. Circumstances for revocation</a></h4>
2446 <p>
2447 Certificates may be revoked under the following circumstances:
2448 </p>
2449
2450 <ol><li>
2451     As initiated by the Subscriber through her online account.
2452   </li><li>
2453     As initiated in an emergency action by a
2454     support team member.
2455     Such action will immediately be referred to dispute resolution
2456     for ratification.
2457   </li><li>
2458     Under direction from the Arbitrator in a duly ordered ruling
2459     from a filed dispute.
2460 </li></ol>
2461
2462 <p>
2463 These are the only three circumstances under which a
2464 revocation occurs.
2465 </p>
2466
2467 <h4><a name="p4.9.2" id="p4.9.2">4.9.2. Who can request revocation</a></h4>
2468
2469 <p>
2470 As above.
2471 </p>
2472
2473 <h4><a name="p4.9.3" id="p4.9.3">4.9.3. Procedure for revocation request</a></h4>
2474 <p>
2475 The Subscriber logs in to her online account through
2476 the website at http://www.cacert.org/ .
2477 </p>
2478
2479 <p>
2480 In any other event such as lost passwords or fraud,
2481 a dispute should be filed
2482 by email at
2483     &lt; support AT cacert DOT org &gt;
2484 </p>
2485
2486 <h4><a name="p4.9.4" id="p4.9.4">4.9.4. Revocation request grace period</a></h4>
2487
2488 <p>No stipulation.</p>
2489
2490 <h4><a name="p4.9.5" id="p4.9.5">4.9.5. Time within which CA must process the revocation request</a></h4>
2491
2492 <p>
2493 The revocation automated in the Web Interface for subscribers,
2494 and is handled generally in less than a minute.
2495 </p>
2496
2497 <p>
2498 A filed dispute that requests a revocation should be handled
2499 within a five business days, however the Arbitrator has discretion.
2500 </p>
2501
2502 <h4><a name="p4.9.6" id="p4.9.6">4.9.6. Revocation checking requirement for relying parties</a></h4>
2503
2504 <p>
2505 Each revoked certificate is recorded in the
2506 certificate revocation list (CRL).
2507 Relying Parties must check a certificate against
2508 the most recent CRL issued, in order to validate
2509 the certificate for the intended reliance.
2510 </p>
2511
2512 <h4><a name="p4.9.7" id="p4.9.7">4.9.7. CRL issuance frequency (if applicable)</a></h4>
2513
2514 <p>
2515 A new CRL is issued after every certificate revocation.
2516 </p>
2517
2518 <h4><a name="p4.9.8" id="p4.9.8">4.9.8. Maximum latency for CRLs (if applicable)</a></h4>
2519
2520 <p>
2521 The maximum latency between revocation and issuance of the CRL is 1 hour.
2522 </p>
2523
2524 <h4><a name="p4.9.9" id="p4.9.9">4.9.9. On-line revocation/status checking availability</a></h4>
2525
2526 <p>
2527 OCSP is available at
2528 http://ocsp.cacert.org/ .
2529 </p>
2530
2531 <h4><a name="p4.9.10" id="p4.9.10">4.9.10. On-line revocation checking requirements</a></h4>
2532 <p>
2533 Relying parties must check up-to-date status before relying.
2534 </p>
2535
2536 <h4><a name="p4.9.11" id="p4.9.11">4.9.11. Other forms of revocation advertisements available</a></h4>
2537 <p>
2538 None.
2539 </p>
2540
2541 <h4><a name="p4.9.12" id="p4.9.12">4.9.12. Special requirements re key compromise</a></h4>
2542 <p>
2543 Subscribers are obliged to revoke certificates at the earliest opportunity.
2544 </p>
2545
2546 <h4><a name="p4.9.13" id="p4.9.13">4.9.13. Circumstances for suspension</a></h4>
2547
2548 <p>
2549 Suspension of certificates is not available.
2550 </p>
2551
2552 <h4><a name="p4.9.14" id="p4.9.14">4.9.14. Who can request suspension</a></h4>
2553 <p>
2554 Not applicable.
2555 </p>
2556
2557 <h4><a name="p4.9.15" id="p4.9.15">4.9.15. Procedure for suspension request</a></h4>
2558 <p>
2559 Not applicable.
2560 </p>
2561
2562 <h4><a name="p4.9.16" id="p4.9.16">4.9.16. Limits on suspension period</a></h4>
2563 <p>
2564 Not applicable.
2565 </p>
2566
2567
2568
2569 <h3><a name="p4.10" id="p4.10">4.10. Certificate status services</a></h3>
2570
2571 <h4><a name="p4.10.1" id="p4.10.1">4.10.1. Operational characteristics</a></h4>
2572 <p>
2573 OCSP is available
2574 at http://ocsp.cacert.org/ .
2575 </p>
2576
2577 <h4><a name="p4.10.2" id="p4.10.2">4.10.2. Service availability</a></h4>
2578
2579 <p>
2580 OCSP is made available on an experimental basis.
2581 </p>
2582
2583 <h4><a name="p4.10.3" id="p4.10.3">4.10.3. Optional features</a></h4>
2584
2585 <p>
2586 No stipulation.
2587 </p>
2588
2589 <h3><a name="p4.11" id="p4.11">4.11. End of subscription</a></h3>
2590
2591 <p>
2592 Certificates include expiry dates.
2593 </p>
2594
2595 <h3><a name="p4.12" id="p4.12">4.12. Key escrow and recovery</a></h3>
2596
2597 <h4><a name="p4.12.1" id="p4.12.1">4.12.1. Key escrow and recovery policy and practices</a></h4>
2598
2599 <p>
2600 CAcert does not generate nor escrow subscriber keys.
2601 </p>
2602
2603 <h4><a name="p4.12.2" id="p4.12.2">4.12.2. Session key encapsulation and recovery policy and practices</a></h4>
2604
2605 <p>
2606 No stipulation.
2607 </p>
2608
2609
2610
2611 <!-- *************************************************************** -->
2612 <h2><a name="p5" id="p5">5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a></h2>
2613
2614 <!-- <a href="http://xkcd.com/87/"> <img align="right" src="http://imgs.xkcd.com/comics/velociraptors.jpg"> </a>  -->
2615
2616 <h3><a name="p5.1" id="p5.1">5.1. Physical controls</a></h3>
2617
2618 <p>
2619 Refer to Security Policy (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2620 <ul><li>
2621     Site location and construction - SP2.1
2622   </li><li>
2623     Physical access - SP2.3
2624 </li></ul>
2625 </p>
2626
2627
2628 <h4><a name="p5.1.3" id="p5.1.3">5.1.3. Power and air conditioning</a></h4>
2629 <p>
2630 Refer to Security Policy 2.1.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2631 </p>
2632 <h4><a name="p5.1.4" id="p5.1.4">5.1.4. Water exposures</a></h4>
2633 <p>
2634 Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2635 </p>
2636 <h4><a name="p5.1.5" id="p5.1.5">5.1.5. Fire prevention and protection</a></h4>
2637 <p>
2638 Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2639 </p>
2640 <h4><a name="p5.1.6" id="p5.1.6">5.1.6. Media storage</a></h4>
2641 <p>
2642 Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2643 </p>
2644 <h4><a name="p5.1.7" id="p5.1.7">5.1.7. Waste disposal</a></h4>
2645 <p>
2646 No stipulation.
2647 </p>
2648 <h4><a name="p5.1.8" id="p5.1.8">5.1.8. Off-site backup</a></h4>
2649 <p>
2650 Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2651 </p>
2652
2653 <h3><a name="p5.2" id="p5.2">5.2. Procedural controls</a></h3>
2654
2655 <h4><a name="p5.2.1" id="p5.2.1">5.2.1. Trusted roles</a></h4>
2656
2657 <ul>
2658    <li><b> Technical teams:</b>
2659    <ul>
2660        <li>User support personnel</li>
2661        <li>Systems Administrators -- critical and non-critical</li>
2662        <li>Softare Developers</li>
2663        <li>controllers of keys</li>
2664    </ul>
2665    Refer to Security Policy 9.1 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2666    
2667    </li>
2668
2669    <li><b>Assurance:</b>
2670    <ul>
2671        <li>Assurers</li>
2672        <li> Any others authorised under COD13  </li>
2673    </ul>
2674    Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
2675    </li>
2676
2677    <li><b>Governance:</b>
2678    <ul>
2679        <li>Directors (members of the CAcert Inc. committee, or "Board") </li>
2680        <li>Internal Auditor</li>
2681        <li>Arbitrator</li>
2682    </ul>
2683    </li>
2684 </ul>
2685
2686
2687 <h4><a name="p5.2.2" id="p5.2.2">5.2.2. Number of persons required per task</a></h4>
2688 <p>
2689 CAcert operates to the principles of <i>four eyes</i> and <i>dual control</i>.
2690 All important roles require a minimum of two persons.
2691 The people may be tasked to operate
2692 with an additional person observing (<i>four eyes</i>),
2693 or with two persons controlling (<i>dual control</i>).
2694 </p>
2695
2696 <h4><a name="p5.2.3" id="p5.2.3">5.2.3. Identification and authentication for each role</a></h4>
2697
2698 <p>
2699 All important roles are generally required to be assured
2700 at least to the level of Assurer, as per AP.
2701 Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
2702 </p>
2703
2704 <p>
2705 <b>Technical.</b>
2706 Refer to Security Policy 9.1 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2707 </p>
2708
2709 <h4><a name="p5.2.4" id="p5.2.4">5.2.4. Roles requiring separation of duties</a></h4>
2710
2711 <p>
2712 Roles strive in general for separation of duties, either along the lines of
2713 <i>four eyes principle</i> or <i>dual control</i>.
2714 </p>
2715
2716 <h3><a name="p5.3" id="p5.3">5.3. Personnel controls</a></h3>
2717
2718 <h4><a name="p5.3.1" id="p5.3.1">5.3.1. Qualifications, experience, and clearance requirements</a></h4>
2719
2720 <center>
2721 <table border="1" cellpadding="5">
2722  <tr>
2723   <td><b>Role</b></td> <td><b>Policy</b></td> <td><b>Comments</b></td>
2724  </tr><tr>
2725   <td>Assurer</td>
2726   <td><a href="http://www.cacert.org/policy/AssurancePolicy.php"> COD13</td>
2727   <td>
2728     Passes Challenge, Assured to 100 points.
2729   </td>
2730  </tr><tr>
2731   <td>Organisation Assurer</td>
2732   <td><a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a></td>
2733   <td>
2734     Trained and tested by two supervising OAs.
2735   </td>
2736  </tr><tr>
2737   <td>Technical</td>
2738   <td>SM => COD08</td>
2739   <td>
2740     Teams responsible for testing.
2741   </td>
2742  </tr><tr>
2743   <td>Arbitrator</td>
2744   <td><a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a></td>
2745   <td>
2746     Experienced Assurers.
2747   </td>
2748  </tr>
2749 </table>
2750
2751 <span class="figure">Table 5.3.1.  Controls on Roles</span>
2752 </center>
2753
2754
2755 <h4><a name="p5.3.2" id="p5.3.2">5.3.2. Background check procedures</a></h4>
2756
2757 <p>
2758 Refer to Security Policy 9.1.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2759 </p>
2760 <!-- <a href="http://xkcd.com/538/"> <img align="right" src="http://imgs.xkcd.com/comics/security.png"> </a> -->
2761
2762 <h4><a name="p5.3.3" id="p5.3.3">5.3.3. Training requirements</a></h4>
2763 <p>No stipulation.</p>
2764 <h4><a name="p5.3.4" id="p5.3.4">5.3.4. Retraining frequency and requirements</a></h4>
2765 <p>No stipulation.</p>
2766
2767 <h4><a name="p5.3.5" id="p5.3.5">5.3.5. Job rotation frequency and sequence</a></h4>
2768 <p>No stipulation.</p>
2769
2770 <h4><a name="p5.3.6" id="p5.3.6">5.3.6. Sanctions for unauthorized actions</a></h4>
2771 <p>
2772 Any actions that are questionable
2773 - whether uncertain or grossly negligent -
2774 may be filed as a dispute.
2775 The Arbitrator has wide discretion in
2776 ruling on loss of points, retraining,
2777 or termination of access or status.
2778 Refer to DRP.
2779 </p>
2780
2781 <h4><a name="p5.3.7" id="p5.3.7">5.3.7. Independent contractor requirements</a></h4>
2782 <p>No stipulation.</p>
2783
2784 <h4><a name="p5.3.8" id="p5.3.8">5.3.8. Documentation supplied to personnel</a></h4>
2785 <p>No stipulation.</p>
2786
2787 <h3><a name="p5.4" id="p5.4">5.4. Audit logging procedures</a></h3>
2788
2789 <p>
2790 Refer to Security Policy 4.2, 5 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2791 </p>
2792
2793 <h3><a name="p5.5" id="p5.5">5.5. Records archival</a></h3>
2794 <p>
2795 The standard retention period is 7 years.
2796 Once archived, records can only be obtained and verified
2797 by means of a filed dispute.
2798 Following types of records are archived:
2799 </p>
2800
2801 <center>
2802 <table border="1" cellpadding="5">
2803  <tr>
2804   <td><b>Record</b></td>
2805   <td><b>Nature</b></td>
2806   <td><b>Exceptions</b></td>
2807   <td><b>Documentation</b></td>
2808  </tr>
2809  <tr>
2810   <td>Member</td>
2811   <td>username, primary and added addresses, security questions, Date of Birth</td>
2812   <td>resigned non-subscribers: 0 years.</td>
2813   <td>Security Policy and Privacy Policy</td>
2814  </tr>
2815  <tr>
2816   <td>Assurance</td>
2817   <td>CAP forms</td>
2818   <td>"at least 7 years."<br> as per subsidiary policies</td>
2819   <td>Assurance Policy 4.5</td>
2820  </tr>
2821  <tr>
2822   <td>Organisation Assurance</td>
2823   <td>COAP forms</td>
2824   <td>as per subsidiary policies</td>
2825   <td>Organisation Assurance Policy</td>
2826  </tr>
2827  <tr>
2828   <td>certificates and revocations</td>
2829   <td>  for reliance </td>
2830   <td> 7 years after termination </td>
2831   <td>this CPS</td>
2832  </tr>
2833  <tr>
2834   <td>critical roles</td>
2835   <td>background check worksheets</td>
2836   <td>under direct Arbitrator control</td>
2837   <td>Security Policy 9.1.3</td>
2838  </tr>
2839 </table>
2840
2841 <span class="figure">Table 5.5.  Documents and Retention </span>
2842 </center>
2843
2844
2845 <h3><a name="p5.6" id="p5.6">5.6. Key changeover</a></h3>
2846
2847 <p>
2848 Refer to Security Policy 9.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2849 </p>
2850
2851 <h3><a name="p5.7" id="p5.7">5.7. Compromise and disaster recovery</a></h3>
2852
2853 <p>
2854 Refer to Security Policy 5, 6 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2855 (Refer to <a href="#p1.4">&sect;1.4</a> for limitations to service.)
2856 </p>
2857
2858 </p>
2859
2860 <h3><a name="p5.8" id="p5.8">5.8. CA or RA termination</a></h3>
2861
2862 <h4><a name="p5.8.1" id="p5.8.1">5.8.1 CA termination</a></h4>
2863
2864
2865 <p>
2866 <s>
2867 If CAcert should terminate its operation or be
2868 taken over by another organisation, the actions
2869 will be conducted according to a plan approved
2870 by the CAcert Inc. Board.
2871 </s>
2872 </p>
2873
2874 <p>
2875 In the event of operational termination, the
2876 Roots (including SubRoots)
2877 and all private Member information will be secured.
2878 The Roots will be handed over to a responsible
2879 party for the sole purpose of issuing revocations.
2880 Member information will be securely destroyed.
2881 </p>
2882
2883 <span class="change">
2884 <p>
2885 The CA cannot be transferrred to another organisation.
2886 </p>
2887 </span>
2888
2889 <p>
2890 <s>
2891 In the event of takeover,
2892 the Board will decide if it is in the interest
2893 of the Members to be converted to the
2894 new organisation.
2895 Members will be notified about the conversion
2896 and transfer of the Member information.
2897 Such takeover, conversion or transfer may involve termination
2898 of this CPS and other documents.
2899 See &sect;9.10.2.
2900 Members will have reasonable time in which to file a related
2901 dispute after notification
2902 (at least one month).
2903 See &sect;9.13.
2904 </s>
2905 </p>
2906 <s>
2907   <ul class="error">
2908     <li> The ability to transfer is not given in any of CCA, PP or AP! </li>
2909     <li> The Board does not have the power to terminate a policy, that is the role of policy group! </li>
2910     <li> The right to transfer was against the principles of the CAcert? </li>
2911     <li> Check Association Statutes.... </li>
2912   </ul>
2913 </s>
2914
2915 <span class="change">
2916 <s>
2917 <p>
2918 New root keys and certificates will be made available
2919 by the new organisation as soon as reasonably practical.
2920 </p>
2921 </s>
2922 </span>
2923
2924 <h4><a name="p5.8.2" id="p5.8.2">5.8.2 RA termination</a></h4>
2925
2926 <p>
2927 When an Assurer desires to voluntarily terminates
2928 her responsibilities, she does this by filing a dispute,
2929 and following the instructions of the Arbitrator.
2930 </p>
2931
2932 <p>
2933 In the case of involuntary termination, the process is
2934 the same, save for some other party filing the dispute.
2935 </p>
2936
2937
2938
2939
2940
2941 <!-- *************************************************************** -->
2942 <h2><a name="p6" id="p6">6. TECHNICAL SECURITY CONTROLS</a></h2>
2943
2944
2945 <!-- <a href="http://xkcd.com/221/"> <img align="right" src="http://imgs.xkcd.com/comics/random_number.png"> </a> -->
2946
2947 <h3><a name="p6.1" id="p6.1">6.1. Key Pair Generation and Installation</a></h3>
2948
2949 <h4><a name="p6.1.1" id="p6.1.1">6.1.1. Key Pair Generation</a></h4>
2950
2951 <p>
2952 Subscribers generate their own Key Pairs.
2953 </p>
2954
2955 <h4><a name="p6.1.2" id="p6.1.2">6.1.2. Subscriber Private key security</a></h4>
2956
2957 <p>
2958 There is no technical stipulation on how Subscribers generate
2959 and keep safe their private keys,
2960 however, CCA 2.5 provides for general security obligations.
2961 See <a href="#p9.6">&sect;9.6</a>.
2962 </p>
2963
2964 <h4><a name="p6.1.3" id="p6.1.3">6.1.3. Public Key Delivery to Certificate Issuer</a></h4>
2965
2966 <p>
2967 Members login to their online account.
2968 Public Keys are delivered by cut-and-pasting
2969 them into the appropriate window.
2970 Public Keys are delivered in signed-CSR form
2971 for X.509 and in self-signed form for OpenPGP.
2972 </p>
2973
2974 <h4><a name="p6.1.4" id="p6.1.4">6.1.4. CA Public Key delivery to Relying Parties</a></h4>
2975
2976 <p>
2977 The CA root certificates are distributed by these means:
2978 </p>
2979
2980 <ul><li>
2981     Published on the website of CAcert,
2982     in both HTTP and HTTPS.
2983   </li><li>
2984     Included in Third-Party Software such as
2985     Browsers, Email-Clients.
2986     Such suppliers are subject to the Third Party Vendor Agreement.
2987 </li></ul>
2988
2989 <p class="q"> Third Party Vendor Agreement is early wip, only </p>
2990
2991 <h4><a name="p6.1.5" id="p6.1.5">6.1.5. Key sizes</a></h4>
2992
2993 <p>
2994 No limitation is placed on Subscriber key sizes.
2995 </p>
2996
2997 <p>
2998 CAcert X.509 root and intermediate keys are currently 4096 bits.
2999 X.509 roots use RSA and sign with the SHA-1 message digest algorithm.
3000 See <a href="#p4.3.1">&sect;4.3.1</a>.
3001 </p>
3002
3003 <p>
3004 OpenPGP Signing uses both RSA and DSA (1024 bits).
3005 </p>
3006
3007 <p>
3008 CAcert adds larger keys and hashes
3009 in line with general cryptographic trends,
3010 and as supported by major software suppliers.
3011 </p>
3012
3013   <ul class="q">
3014     <li> old Class 3 SubRoot is signed with MD5 </li>
3015     <li> likely this will clash with future plans of vendors to drop acceptance of MD5</li>
3016     <li> Is this a concern? </li>
3017     <li> to users who have these certs, a lot? </li>
3018     <li> to audit, not much? </li>
3019   </ul>
3020
3021
3022 <h4><a name="p6.1.6" id="p6.1.6">6.1.6. Public key parameters generation and quality checking</a></h4>
3023
3024 <p>
3025 No stipulation.
3026 </p>
3027
3028 <h4><a name="p6.1.7" id="p6.1.7">6.1.7. Key Usage Purposes</a></h4>
3029
3030
3031   <ul class="q">
3032     <li> This section probably needs to detail the key usage bits in the certs. </li>
3033   </ul>
3034
3035
3036 <p>
3037 CAcert roots are general purpose.
3038 Each root key may sign all of the general purposes
3039 - client, server, code.
3040 </p>
3041
3042 <p>
3043 The website controls the usage purposes that may be signed.
3044 This is effected by means of the 'template' system.
3045 </p>
3046
3047
3048
3049 <!-- <a href="http://xkcd.com/257/"> <img align="right" src="http://imgs.xkcd.com/comics/code_talkers.png"> </a> -->
3050
3051 <h3><a name="p6.2" id="p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a></h3>
3052
3053
3054
3055
3056 <h4><a name="p6.2.1" id="p6.2.1">6.2.1. Cryptographic module standards and controls</a></h4>
3057
3058 <p>
3059 SubRoot keys are stored on a single machine which acts
3060 as a Cryptographic Module, or <i>signing server</i>.
3061 It operates a single daemon for signing only.
3062 The signing server has these security features:
3063 </p>
3064
3065 <ul><li>
3066     It is connected only by one
3067     dedicated (serial USB) link
3068     to the online account server.
3069     It is not connected to the network,
3070     nor to any internal LAN (ethernet),
3071     nor to a console switch.
3072   </li><li>
3073     The protocol over the dedicated link is a custom, simple
3074     request protocol that only handles certificate signing requests.
3075   </li><li>
3076     The daemon is designed not to reveal the key.
3077   </li><li>
3078     The daemon incorporates a dead-man switch that monitors
3079     the one webserver machine that requests access.
3080   </li><li>
3081     The daemon shuts down if a bad request is detected.
3082   </li><li>
3083     The daemon resides on an encrypted partition.
3084   </li><li>
3085     The signing server can only be (re)started with direct
3086     systems administration access.
3087   </li><li>
3088     Physical Access to the signing server is under dual control.
3089 </li></ul>
3090
3091 <p>
3092 See &sect;5. and the Security Policy 9.3.1.
3093 </p>
3094
3095 <p>
3096 (Hardware-based, commercial and standards-based cryptographic
3097 modules have been tried and tested, and similar have been tested,
3098 but have been found wanting, e.g., for short key lengths and
3099 power restrictions.)
3100 </p>
3101
3102 <ol class="q"><li>
3103     What document is responsible for architecture?  CPS?  SM?
3104     <a href="http://www.cacert.org/help.php?id=7">website</a>?
3105     SM punts it to CPS, so above stays.
3106   </li><li>
3107     There is no criteria on Architecture.
3108   </li><li>
3109     Old questions moved to SM.
3110   </li><li>
3111     See
3112     <a href="http://www.cacert.org/help.php?id=7">
3113     CAcert Root key protection</a> which should be deprecated by this CPS.
3114 </li></ol>
3115
3116
3117 <h3><a name="p6.3" id="p6.3">6.3. Other aspects of key pair management</a></h3>
3118 <h4><a name="p6.3.1" id="p6.3.1">6.3.1. Public key archival</a></h4>
3119
3120 <p>
3121 Subscriber certificates, including public keys,
3122 are stored in the database backing the online system.
3123 They are not made available in a public- or subscriber-accessible
3124 archive, see &sect;2.
3125 They are backed-up by CAcert's normal backup procedure,
3126 but their availability is a subscriber responsibility.
3127 </p>
3128
3129 <h4><a name="p6.3.2" id="p6.3.2">6.3.2. Certificate operational periods and key pair usage periods</a></h4>
3130
3131 <p>
3132 The operational period of a certificate and its key pair
3133 depends on the Assurance status of the Member,
3134 see <a href="#p1.4.5">&sect;1.4.5</a> and Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
3135 </p>
3136
3137 <p>
3138 The CAcert (top-level) Root certificate
3139 has a 30 year expiry.
3140 SubRoots have 10 years, and are to be rolled over more quickly.
3141 The keysize of the root certificates are chosen
3142 in order to ensure an optimum security to CAcert
3143 Members based on current recommendations from the
3144 <a href="http://www.keylength.com/">cryptographic community</a>
3145 and maximum limits in generally available software.
3146 At time of writing this is 4096 bits.
3147 </p>
3148
3149 <h3><a name="p6.4" id="p6.4">6.4. Activation data</a></h3>
3150 <p> No stipulation.  </p>
3151
3152 <h3><a name="p6.5" id="p6.5">6.5. Computer security controls</a></h3>
3153 <p>
3154 Refer to Security Policy.
3155 </p>
3156
3157 <h3><a name="p6.6" id="p6.6">6.6. Life cycle technical controls</a></h3>
3158 <p>
3159 Refer to SM7 "Software Development".
3160 </p>
3161
3162 <h3><a name="p6.7" id="p6.7">6.7. Network security controls</a></h3>
3163 <p>
3164 Refer to SM3.1 "Logical Security - Network".
3165 </p>
3166
3167 <h3><a name="p6.8" id="p6.8">6.8. Time-stamping</a></h3>
3168 <p>
3169 Each server synchronises with NTP.
3170 No "timestamping" service is currently offered.
3171 </p>
3172
3173   <ul class="q">
3174     <li> How does the signing server syncronise if only connected over serial?</li>
3175     <li>  How is timestamping done on records?</li>
3176   </ul>
3177
3178
3179
3180
3181 <!-- *************************************************************** -->
3182 <h2><a name="p7" id="p7">7. CERTIFICATE, CRL, AND OCSP PROFILES</a></h2>
3183
3184 <p>
3185 CAcert defines all the meanings, semantics and profiles
3186 applicable to issuance of certificates and signatures
3187 in its policies, handbooks and other documents.
3188 Meanings that may be written in external standards or documents
3189 or found in wider conventions are not
3190 incorporated, are not used by CAcert, and must not be implied
3191 by the Member or the Non-related Person.
3192 </p>
3193
3194 <h3><a name="p7.1" id="p7.1">7.1. Certificate profile</a></h3>
3195 <h4><a name="p7.1.1" id="p7.1.1">7.1.1. Version number(s)</a></h4>
3196 <p class="q"> What versions of PGP are signed?  v3?  v4? </p>
3197
3198 <p>
3199 Issued X.509 certificates are of v3 form.
3200 The form of the PGP signatures depends on several factors, therefore no stipulation.
3201 </p>
3202
3203 <h4><a name="p7.1.2" id="p7.1.2">7.1.2. Certificate extensions</a></h4>
3204
3205 <p>
3206   Client certificates include the following extensions:
3207 </p>
3208 <ul>
3209   <li>basicConstraints=CA:FALSE (critical)</li>
3210   <li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
3211   <li>extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC</li>
3212   <li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
3213   <li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced 
3214     with the URI where the certificate revocation list relating to the 
3215     certificate is found</li>
3216   <li>subjectAltName=(as per <a href="#p3.1.1">&sect;3.1.1.</a>).</li>
3217 </ul>
3218   <ul class="q">
3219     <li> what about Client Certificates Adobe Signing extensions ?</li>
3220     <li> SubjectAltName should become critical if DN is removed http://tools.ietf.org/html/rfc5280#section-4.2.1.6</li>
3221   </ul>
3222
3223 <p>
3224   Server certificates include the following extensions:
3225 </p>
3226 <ul>
3227   <li>basicConstraints=CA:FALSE (critical)</li>
3228   <li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
3229   <li>extendedKeyUsage=clientAuth,serverAuth,nsSGC,msSGC</li>
3230   <li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
3231   <li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced 
3232     with the URI where the certificate revocation list relating to the 
3233     certificate is found</li>
3234   <li>subjectAltName=(as per <a href="#p3.1.1">&sect;3.1.1.</a>).</li>
3235 </ul>
3236
3237 <p>
3238   Code-Signing certificates include the following extensions:
3239 </p>
3240 <ul>
3241   <li>basicConstraints=CA:FALSE (critical)</li>
3242   <li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
3243   <li>extendedKeyUsage=emailProtection,clientAuth,codeSigning,msCodeInd,msCodeCom,msEFS,msSGC,nsSGC</li>
3244   <li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
3245   <li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced 
3246     with the URI where the certificate revocation list relating to the 
3247     certificate is found</li>
3248   <li>subjectAltName=(as per <a href="#p3.1.1">&sect;3.1.1.</a>).</li>
3249 </ul>
3250   <ul class="q">
3251     <li> what about subjectAltName for Code-signing</li>
3252   </ul>
3253
3254 <p>
3255 OpenPGP key signatures currently do not include extensions.
3256 In the future, a serial number might be included as an extension.
3257 </p>
3258
3259
3260 <h4><a name="p7.1.3" id="p7.1.3">7.1.3. Algorithm object identifiers</a></h4>
3261 <p>
3262 No stipulation.
3263 </p>
3264
3265 <h4><a name="p7.1.4" id="p7.1.4">7.1.4. Name forms</a></h4>
3266 <p>
3267 Refer to <a href="#p3.1.1">&sect;3.1.1</a>.
3268 </p>
3269
3270 <h4><a name="p7.1.5" id="p7.1.5">7.1.5. Name constraints</a></h4>
3271 <p>
3272 Refer to <a href="#p3.1.1">&sect;3.1.1</a>.
3273 </p>
3274
3275 <h4><a name="p7.1.6" id="p7.1.6">7.1.6. Certificate policy object identifier</a></h4>
3276 <p>
3277 The following OIDs are defined and should be incorporated
3278 into certificates:
3279 </p>
3280
3281 <table border="1" cellpadding="5">
3282  <tr>
3283   <td>
3284     OID
3285   </td>
3286   <td>
3287     Type/Meaning
3288   </td>
3289   <td>
3290     Comment
3291   </td>
3292  </tr>
3293  <tr>
3294   <td>
3295     1.3.6.1.4.1.18506.4.4
3296   </td>
3297   <td>
3298     Certification Practice Statement
3299   </td>
3300   <td>
3301     (this present document)
3302   </td>
3303  </tr>
3304 </table>
3305
3306 <p>
3307 Versions are defined by additional numbers appended such as .1.
3308 </p>
3309
3310 <h4><a name="p7.1.7" id="p7.1.7">7.1.7. Usage of Policy Constraints extension</a></h4>
3311 <p>
3312 No stipulation.
3313 </p>
3314
3315 <h4><a name="p7.1.8" id="p7.1.8">7.1.8. Policy qualifiers syntax and semantics</a></h4>
3316 <p>
3317 No stipulation.
3318 </p>
3319
3320 <h4><a name="p7.1.9" id="p7.1.9">7.1.9. Processing semantics for the critical Certificate Policies extension</a></h4>
3321 <p>
3322 No stipulation.
3323 </p>
3324
3325
3326 <h3><a name="p7.2" id="p7.2">7.2. CRL profile</a></h3>
3327 <h4><a name="p7.2.1" id="p7.2.1">7.2.1. Version number(s)</a></h4>
3328 <p>
3329 CRLs are created in X.509 v2 format.
3330 </p>
3331
3332 <h4><a name="p7.2.2" id="p7.2.2">7.2.2. CRL and CRL entry extensions</a></h4>
3333
3334 <p>
3335 No extensions.
3336 </p>
3337
3338 <h3><a name="p7.3" id="p7.3">7.3. OCSP profile</a></h3>
3339 <h4><a name="p7.3.1" id="p7.3.1">7.3.1. Version number(s)</a></h4>
3340 <p>
3341 The OCSP responder operates in Version 1.
3342 </p>
3343 <h4><a name="p7.3.2" id="p7.3.2">7.3.2. OCSP extensions</a></h4>
3344 <p>
3345 No stipulation.
3346 </p>
3347
3348
3349
3350 <!-- *************************************************************** -->
3351 <h2><a name="p8" id="p8">8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS</a></h2>
3352
3353 <p>
3354 There are two major threads of assessment:
3355 </p>
3356
3357 <ul><li>
3358   <b>Systems Audit</b>.
3359   Analyses the CA for business and operations security.
3360   This is conducted in two phases:  documents for compliance
3361   with criteria, and operations for compliance with documentation.
3362   </li><li>
3363   <b>Code Audit</b>.
3364   Analyses the source code.
3365   This is conducted at two levels:
3366   Security concepts at the web applications level,
3367   and source code security and bugs review.
3368 </li></ul>
3369
3370 <p>
3371 See the Audit page at
3372 <a href="http://wiki.cacert.org/wiki/Audit/">
3373 wiki.cacert.org/wiki/Audit/</a>
3374 for more information.
3375 </p>
3376
3377 <h3><a name="p8.1" id="p8.1">8.1. Frequency or circumstances of assessment</a></h3>
3378 <p>
3379 The first audits started in late 2005,
3380 and since then, assessments have been an
3381 ongoing task.
3382 Even when completed, they are expected to
3383 be permanent features.
3384 </p>
3385
3386 <ul><li>
3387   <b>Systems Audit</b>.
3388   <span class="q">
3389   The first phase of the first audit is nearing completion.
3390   The second phase starts in earnest when documentation is in
3391   effect, at lease as DRAFT under PoP.
3392   As the second phase is dependent on
3393   this CPS and the Security Policy, they will
3394   be in effect as DRAFT at least
3395   before the first audit is completed.
3396   Only prior and completed audits can be reported here.
3397   </span>
3398   </li><li>
3399   <b>Code Audit</b>.
3400   <span class="q">
3401   A complete review of entire source code has not yet been completed.
3402   </span>
3403 </li></ul>
3404
3405 <h3><a name="p8.2" id="p8.2">8.2. Identity/qualifications of assessor</a></h3>
3406
3407 <p>
3408 <b>Systems Auditors.</b>
3409 CAcert uses business systems auditors with broad experience
3410 across the full range of business, information systems
3411 and security fields.
3412 In selecting a business systems auditor, CAcert looks for
3413 experience that includes but is not limited to
3414 cryptography, PKI, governance, auditing,
3415 compliance and regulatory environments,
3416 business strategy, software engineering,
3417 networks, law (including multijurisdictional issues),
3418 identity systems, fraud, IT management.
3419 </p>
3420
3421 <!-- <center><a href="http://xkcd.com/511/"> <img src="http://imgs.xkcd.com/comics/sleet.png"> </a> </center> -->
3422
3423 <p>
3424 <b>Code Auditors.</b>
3425 See Security Policy, sections 7, 9.1.
3426 </p>
3427
3428 <h3><a name="p8.3" id="p8.3">8.3. Assessor's relationship to assessed entity</a></h3>
3429
3430 <p>
3431 Specific internal restrictions on audit personnel:
3432 </p>
3433
3434 <ul><li>
3435     Must be Assured by CAcert Assurers
3436     and must be background checked.
3437   </li><li>
3438     Must not have been active in any (other) role in CAcert.
3439     Specifically, must not be an Assurer, a member of the association,
3440     or in any other defined role or office.
3441   </li><li>
3442     Although the Auditor may be expected to undertake various
3443     of the activities (Assurance, Training)
3444     during the process of the audit, any results are frozen
3445     until resignation as auditor is effected.
3446   </li><li>
3447     The Auditor is required to declare to CAcert all
3448     potential conflicts of interest on an ongoing basis.
3449 </li></ul>
3450
3451 <p>
3452 Specific external restrictions on audit personnel:
3453 </p>
3454
3455 <ul><li>
3456     Should have a verifiable and lengthy history in
3457     user privacy and user security.
3458   </li><li>
3459     Must not have worked for a competitive organisation.
3460   </li><li>
3461     Must not have worked for national security, intelligence,
3462     LEO or similar agencies.
3463 </li></ul>
3464
3465 <p>
3466 An Auditor may convene an audit team.
3467 The same restrictions apply in general
3468 to all members of the team, but may be varied.
3469 Any deviations must be documented and approved
3470 by the CAcert Inc. Board.
3471 </p>
3472
3473 <h3><a name="p8.4" id="p8.4">8.4. Topics covered by assessment</a></h3>
3474
3475 <p>
3476 Systems Audits are generally conducted to criteria.
3477 CAcert requires that the criteria are open:
3478 </p>
3479
3480 <ul><li>
3481     Published.
3482     The criteria must be reviewable by all interested parties.
3483   </li><li>
3484     Understandable.
3485     They should be understandable, in that they provide the 
3486     sufficient information in a readable form for interested
3487     parties to follow the gist and importance.
3488     (Arcane security criteria may stretch this requirement.)
3489   </li><li>
3490     Complete.
3491     There must be sufficent background information that the
3492     whole story is there.  Especially, criteria that refer
3493     to undocumented practices or conventions deliberately
3494     kept secret must be avoided.
3495   </li><li>
3496     Applicable.  The criteria should relate directly
3497     and unambiguously to a need of the identified interested parties
3498     (Members, Relying Parties, Subscribers, Assurers).
3499 </li></ul>
3500
3501 <p>
3502 See
3503 <a href="http://rossde.com/CA_review/">DRC</a>
3504 for the current criteria.
3505 If Auditor determines that a criteria fails to
3506 follow the meet the above requirements, then the criteria
3507 should be reworked to conform, or should be dropped
3508 (both with explanatory notes).
3509 </p>
3510
3511 <h3><a name="p8.5" id="p8.5">8.5. Actions taken as a result of deficiency</a></h3>
3512 <p>
3513 See the current
3514 <a href="http://wiki.cacert.org/wiki/Audit/Done">Audit Done list</a>
3515 for work completed, and
3516 <a href="http://wiki.cacert.org/wiki/AuditToDo">Audit Todo list</a>
3517 for work in progress.
3518 </p>
3519
3520 <p>
3521 Auditor may issue directives instructing changes,
3522 where essential to audit success or other extreme
3523 situations.
3524 Directives should be grounded on criteria,
3525 on established minimum or safe practices,
3526 or clearly described logic.
3527 Adequate discussion with Community
3528 (e.g., CAcert Inc. Board and with Policy Group)
3529 should precede any directive.
3530 They should be presented to the same standard
3531 as the criteria, above.
3532 </p>
3533
3534 <p>
3535 The
3536 <a href="http://wiki.cacert.org/wiki/AuditDirectives">
3537 wiki.cacert.org/wiki/AuditDirectives</a>
3538 documents issued directives and actions.
3539 </p>
3540
3541 <h3><a name="p8.6" id="p8.6">8.6. Communication of results</a></h3>
3542
3543 <p>
3544 Current and past Audit information is available at
3545 <a href="http://wiki.cacert.org/wiki/Audit/">wiki.CAcert.org/wiki/Audit/</a>.
3546 CAcert runs an open disclosure policy and
3547 Audit is no exception.
3548 </p>
3549
3550 <p>
3551 This CPS and other documents are subject to
3552 the process in Policy on Policy (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>).
3553 Audits cover the overall processes more
3554 than any one document, and documents may vary
3555 even as Audit reports are delivered.
3556 </p>
3557
3558
3559
3560
3561 <!-- *************************************************************** -->
3562 <h2><a name="p9" id="p9">9. OTHER BUSINESS AND LEGAL MATTERS</a></h2>
3563 <h3><a name="p9.1" id="p9.1">9.1. Fees</a></h3>
3564
3565
3566 <p>
3567 The current fees structure is posted at
3568 <a href="http://wiki.cacert.org/wiki/Price">wiki.cacert.org/wiki/Price</a>.
3569 Changes to the fees structure will be announced
3570 from time to time on the <a href="http://blog.cacert.org/">blog</a>.
3571 CAcert retains the right to charge fees for services.
3572 All fees are non-refundable.
3573 </p>
3574
3575
3576 <h3><a name="p9.2" id="p9.2">9.2. Financial responsibility</a></h3>
3577
3578 <p>
3579 Financial risks are dealt with primarily by
3580 the Dispute Resolution Policy
3581 (<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>).
3582 </p>
3583
3584 <h4><a name="p9.2.1" id="p9.2.1">9.2.1. Insurance coverage</a></h4>
3585
3586 <p>
3587 No stipulation.
3588 </p>
3589
3590 <h4><a name="p9.2.2" id="p9.2.2">9.2.2. Other assets</a></h4>
3591
3592 <p>
3593 No stipulation.
3594 </p>
3595
3596 <h4><a name="p9.2.3" id="p9.2.3">9.2.3. Insurance or warranty coverage for end-entities</a></h4>
3597
3598 <p>
3599 No stipulation.
3600 </p>
3601
3602 <h3><a name="p9.3" id="p9.3">9.3. Confidentiality of business information</a></h3>
3603
3604 <h4><a name="p9.3.1" id="p9.3.1">9.3.1. Scope of confidential information</a></h4>
3605
3606 <p>
3607 CAcert has a policy of transparency and openness.
3608 The default posture is that information is public
3609 to the extent possible,
3610 unless covered by specific policy provisions
3611 (for example, passwords)
3612 or rulings by Arbitrator.
3613 </p>
3614
3615 <h3><a name="p9.4" id="p9.4">9.4. Privacy of personal information</a></h3>
3616
3617 <!-- <center><a href="http://xkcd.com/46/"> <img src="http://imgs.xkcd.com/comics/secrets.jpg"> </a> </center> -->
3618 <p>
3619 Privacy is covered by the
3620 CCA (COD9)
3621 and the Privacy Policy
3622 (<a href="PrivacyPolicy.html">COD5</a>).
3623 </p>
3624
3625 <h4><a name="p9.4.1" id="p9.4.1">9.4.1. Privacy plan</a></h4>
3626 <p> No stipulation.  </p>
3627 <h4><a name="p9.4.2" id="p9.4.2">9.4.2. Information treated as private</a></h4>
3628 <p>
3629 Member's Date of Birth and "Lost Password" questions are treated as fully private.
3630 </p>
3631 <h4><a name="p9.4.3" id="p9.4.3">9.4.3. Information not deemed private</a></h4>
3632 <p>
3633 To the extent that information is put into an issued certificate,
3634 that information is not deemed private,
3635 as it is expected to be published by the Member as part of routine use of
3636 the certificate.
3637 Such information generally includes
3638 Names, domains, email addresses, and certificate serial numbers.
3639 </p>
3640 <p>
3641 Under Assurance Policy
3642 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
3643 the Member's status (as Assured, Assurer, etc) is available
3644 to other Members.
3645 </p>
3646 <p>
3647 Information placed in forums outside the online system
3648 (wiki, blogs, policies, etc) is not deemed private, and is
3649 generally deemed to be published as contributions by Members.
3650 See
3651 CCA1.3 (COD9).
3652 </p>
3653 <h4><a name="p9.4.4" id="p9.4.4">9.4.4. Responsibility to protect private information</a></h4>
3654 <p>
3655 CAcert is a privacy organisation
3656 and takes privacy more seriously.
3657 Any privacy issue may be referred to dispute resolution.
3658 </p>
3659 <h4><a name="p9.4.5" id="p9.4.5">9.4.5. Notice and consent to use private information</a></h4>
3660 <p>
3661 Members are permitted to rely on certificates of other Members.
3662 As a direct consequence of the general right to rely,
3663 Members may read and store the certificates
3664 and/or the information within them, where duly presented in
3665 a relationship, and to the extent necessary for
3666 the agreed relationship.
3667 </p>
3668 <h4><a name="p9.4.6" id="p9.4.6">9.4.6. Disclosure pursuant to judicial or administrative process</a></h4>
3669 <p>
3670 Any disclosure pursuant to process from foreign courts
3671 (or similar)
3672 is controlled by the Arbitrator.
3673 </p>
3674 <h4><a name="p9.4.7" id="p9.4.7">9.4.7. Other information disclosure circumstances</a></h4>
3675 <p>
3676 None.
3677 </p>
3678
3679 <h3><a name="p9.5" id="p9.5">9.5. Intellectual property rights</a></h3>
3680
3681 <p>
3682 CAcert is committed to the philosophy of
3683 an open and free Internet,
3684 broadly as encapsulated by open and free source.
3685 However, due to the strict control provisions
3686 imposed by the audit criteria (CCS),
3687 and the general environment and role of CAs,
3688 and the commitment to security of Members,
3689 some deviations are necessary.
3690 </p>
3691
3692 <!-- <center><a href="http://xkcd.com/225/"> <img src="http://imgs.xkcd.com/comics/open_source.png"> </a> </center> -->
3693
3694 <h4><a name="p9.5.1" id="p9.5.1">9.5.1. Ownership and Licence</a></h4>
3695
3696 <p>
3697 Assets that fall under the control of CCS
3698 must be transferred to CAcert.
3699 See PoP 6.2
3700 (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>),
3701 CCA 1.3
3702 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
3703 That is, CAcert is free to use, modify,
3704 distribute, and otherwise conduct the business
3705 of the CA as CAcert sees fit with the asset.
3706 </p>
3707
3708 <h4><a name="p9.5.2" id="p9.5.2">9.5.2. Brand</a></h4>
3709 <p>
3710 The brand of CAcert
3711 is made up of its logo, name, trademark, service marks, etc.
3712 Use of the brand is strictly limited by the Board,
3713 and permission is required.
3714 See <a href="http://wiki.cacert.org/wiki/TopMinutes-20070917">
3715 m20070917.5</a>.
3716 </p>
3717
3718 <h4><a name="p9.5.3" id="p9.5.3">9.5.3. Documents</a></h4>
3719
3720 <p>
3721 CAcert owns or requires full control over its documents,
3722 especially those covered by CCS.
3723 See PoP 6.2
3724 (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>).
3725 Contributors transfer the rights,
3726 see CCA 1.3
3727 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
3728 Contributors warrant that they have the right to transfer.
3729 </p>
3730
3731 <p>
3732 Documents are generally licensed under free and open licence.
3733 See
3734 <a href="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
3735 wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence</a>.
3736 Except where explicitly negotiated,
3737 CAcert extends back to contributors a
3738 non-exclusive, unrestricted perpetual
3739 licence, permitting them to to re-use
3740 their original work freely.
3741 See PoP 6.4
3742 (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.4">COD1</a>),
3743 CCA 1.3
3744 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
3745 </p>
3746
3747 <h4><a name="p9.5.4" id="p9.5.4">9.5.4. Code</a></h4>
3748
3749 <p>
3750 CAcert owns its code or requires full control over code in use
3751 by means of a free and open licence.
3752 See CCS.
3753 </p>
3754
3755 <p class="q">
3756 See the (new, wip)
3757 <a href="http://svn.cacert.cl/Documents/SourceCodeManifesto.html">
3758 SourceCodeManifesto</a>.
3759 Maybe this can replace these two paras?
3760 </p>
3761
3762 <p>
3763 CAcert licenses its code under GPL.
3764 CAcert extends back to contributors a
3765 non-exclusive, unrestricted perpetual
3766 licence, permitting them to to re-use
3767 their original work freely.
3768 </p>
3769
3770 <h4><a name="p9.5.5" id="p9.5.5">9.5.5. Certificates and Roots</a></h4>
3771
3772 <p>
3773 CAcert asserts its intellectual property rights over certificates
3774 issued to Members and over roots.
3775 See CCA 4.4
3776 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#4.4">COD9</a>),
3777 CCS.
3778 The certificates may only be used by Members under
3779 <a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#4.4">COD9</a>,
3780 and,
3781 by others under the licences offered,
3782 such as
3783 Non-Related Persons - Disclaimer and Licence
3784 (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
3785 </p>
3786
3787 <h3><a name="p9.6" id="p9.6">9.6. Representations and warranties</a></h3>
3788
3789
3790 <p>
3791 <b>Members.</b>
3792 All Members of the Community agree to the
3793 CAcert Community Agreement
3794 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
3795 which is the primary document for
3796 representations and warranties.
3797 Members include Subscribers, Relying Parties,
3798 Registration Agents and the CA itself.
3799 </p>
3800
3801 <p>
3802 <b>RAs.</b>
3803 Registration Agents are obliged additionally by Assurance Policy,
3804 especially 3.1, 4.1
3805 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
3806 </p>
3807
3808 <p>
3809 <b>CA.</b>
3810 The CA is obliged additionally by the CCS.
3811 </p>
3812
3813 <p>
3814 <b>Third Party Vendors.</b>
3815 Distributors of the roots are offered the
3816 <span class="q">wip</span>
3817 3rd-Party Vendors - Disclaimer and Licence
3818 (3PV-DaL => CODx)
3819 and are offered
3820 <span class="q">wip</span>
3821 the same deal as Members to the extent that they agree
3822 to be Members in the Community.
3823 <span class="q">wip</span>
3824 </p>
3825
3826 <h3><a name="p9.7" id="p9.7">9.7. Disclaimers of Warranties</a></h3>
3827
3828 <p>
3829 Persons who have not accepted the above Agreements are offered the
3830 Non-Related Persons - Disclaimer and Licence
3831 (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
3832 Any representations and
3833 warranties are strictly limited to nominal usage.
3834 In essence, NRPs may USE but must not RELY.
3835 </p>
3836
3837 <p>
3838 In today's aggressive fraud environment,
3839 and within the context of CAcert as a community CA,
3840 all parties should understand that CAcert
3841 and its Subscribers, Assurers and other roles
3842 provide service on a Best Efforts basis.
3843 See <a href="#p1.4">&sect;1.4</a>.
3844 CAcert seeks to provide an adequate minimum
3845 level of quality in operations for its Members
3846 without undue risks to NRPs.
3847 See
3848 <a href="http://svn.cacert.org/CAcert/principles.html">Principles</a>.
3849 </p>
3850
3851 <p>
3852 CAcert on behalf of the Community and itself
3853 makes no Warranty nor Guarantee nor promise
3854 that the service or certificates are adequate
3855 for the needs and circumstances.
3856 </p>
3857
3858 <h3><a name="p9.8" id="p9.8">9.8. Limitations of liability</a></h3>
3859
3860 <h3><a name="p9.8.1" id="p9.8.1">9.8.1 Non-Related Persons </a></h3>
3861
3862 <p>
3863 CAcert on behalf of related parties
3864 (RAs, Subscribers, etc) and itself
3865 disclaims all liability to NRPs
3866 in their usage of CA's certificates.
3867 See <a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>.
3868 </p>
3869
3870 <h3><a name="p9.8.2" id="p9.8.2">9.8.2 Liabilities Between Members</a></h3>
3871
3872 <p>
3873 Liabilities between Members
3874 are dealt with by internal dispute resolution,
3875 which rules on liability and any limits.
3876 See
3877 <a href="#9.13">&sect;9.13</a>.
3878 </p>
3879
3880
3881 <h3><a name="p9.9" id="p9.9">9.9. Indemnities</a></h3>
3882
3883 <p>
3884 No stipulation.
3885 </p>
3886
3887 <h3><a name="p9.10" id="p9.10">9.10. Term and termination</a></h3>
3888 <h4><a name="p9.10.1" id="p9.10.1">9.10.1. Term</a></h4>
3889
3890 <p>
3891 No stipulation.
3892 </p>
3893
3894 <h4><a name="p9.10.2" id="p9.10.2">9.10.2. Termination</a></h4>
3895
3896 <p>
3897 Members file a dispute to terminate their agreement.
3898 See <a href="#p9.13">&sect;9.13</a> and CCA 3.3
3899 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.3">COD9</a>).
3900 </p>
3901
3902 <p>
3903 Documents are varied (including terminated) under <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
3904 </p>
3905
3906 <p>
3907 For termination of the CA, see <a href="#p5.8.1">&sect;5.8.1</a>.
3908 </p>
3909
3910 <h4><a name="p9.10.3" id="p9.10.3">9.10.3. Effect of termination and survival</a></h4>
3911
3912 <p>
3913 No stipulation.
3914 </p>
3915
3916 <h3><a name="p9.11" id="p9.11">9.11. Individual notices and communications with participants</a></h3>
3917
3918 <p>
3919 All participants are obliged to keep their listed
3920 primary email addresses in good working order.
3921 See CCA 3.5
3922 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.5">COD9</a>).
3923 </p>
3924
3925
3926 <h3><a name="p9.12" id="p9.12">9.12. Amendments</a></h3>
3927
3928 <p>
3929 Amendments to the CPS are controlled by <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
3930 Any changes in Member's Agreements are notified under CCA 3.4
3931 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.4">COD9</a>).
3932 </p>
3933
3934 <h3><a name="p9.13" id="p9.13">9.13. Dispute resolution provisions</a></h3>
3935
3936 <p>
3937 CAcert provides a forum and facility for any Member
3938 or other related party to file a dispute.
3939 </p>
3940
3941 <ul><li>
3942     The CAcert
3943     Dispute Resolution Policy
3944     (<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>)
3945     includes rules for dispute resolution.
3946   </li><li>
3947     Filing is done via email to
3948     &lt; support AT cacert DOT org &gt;
3949 </li></ul>
3950
3951 <p>
3952 Members agree to file all disputes through CAcert's
3953 forum for dispute resolution.
3954 The rules include specific provisions to assist
3955 non-Members, etc, to file dispute in this forum.
3956 </p>
3957
3958
3959 <h3><a name="p9.14" id="p9.14">9.14. Governing law</a></h3>
3960
3961 <p>
3962 The governing law is that of New South Wales, Australia.
3963 Disputes are generally heard before the Arbitrator
3964 under this law.
3965 Exceptionally, the Arbitrator may elect to apply the
3966 law of the parties and events, where in common,
3967 but this is unlikely because it may create results
3968 that are at odds with the Community.
3969 </p>
3970
3971 <h3><a name="p9.15" id="p9.15">9.15. Compliance with Applicable Law</a></h3>
3972
3973 <h3><a name="p9.15.1" id="p9.15.1">9.15.1 Digital Signature Law</a></h3>
3974 <p>
3975 The Commonwealth and States of Australia have passed
3976 various Electronic Transactions Acts that speak to
3977 digital signatures.  In summary, these acts follow
3978 the "technology neutral" model and permit but do not
3979 regulate the use of digital signatures.
3980 </p>
3981
3982 <p>
3983 This especially means that the signatures created by
3984 certificates issued by CAcert are not in and of themselves
3985 legally binding human signatures, at least according to
3986 the laws of Australia.
3987 See <a href="#p1.4.3">&sect;1.4.3</a>.
3988 However, certificates may play a part in larger signing
3989 applications.  See <a href="#p1.4.1">&sect;1.4.1</a> for "digital signing" certificates.
3990 These applications may impose significant
3991 obligations, risks and liabilities on the parties.
3992 </p>
3993
3994 <h3><a name="p9.15.2" id="p9.15.2">9.15.2 Privacy Law</a></h3>
3995
3996 <p>
3997 See the Privacy Policy
3998 (<a href="PrivacyPolicy.html">COD5</a>).
3999 </p>
4000
4001 <h3><a name="p9.15.3" id="p9.15.3">9.15.3 Legal Process from External Forums</a></h3>
4002
4003 <p>
4004 CAcert will provide information about
4005 its Members only under legal subpoena or
4006 equivalent process
4007 from a court of competent jurisdiction.
4008 Any requests made by legal subpoena are
4009 treated as under the Dispute Resolution Policy
4010 See
4011 <a href="#p9.13">&sect;9.13</a>
4012 and
4013 <a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>.
4014 That is, all requests are treated as disputes,
4015 as only a duly empanelled Arbitrator has the
4016 authorisation and authority to rule on the
4017 such requests.
4018 <p>
4019
4020 <p>
4021 A subpoena should
4022 include sufficient legal basis to support
4023 an Arbitrator in ruling that information
4024 be released pursuant to the filing,
4025 including the names of claimants in any civil case
4026 and an indication as to whether the claimants are
4027 Members or not
4028 (and are therefore subject to Dispute Resolution Policy).
4029 </p>
4030
4031 <h3><a name="p9.16" id="p9.16">9.16. Miscellaneous provisions</a></h3>
4032 <h4><a name="p9.16.1" id="p9.16.1">9.16.1. Entire agreement</a></h4>
4033
4034 <p>
4035 All Members of the Community agree to the
4036 CAcert Community Agreement
4037 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
4038 This agreement also incorporates other key
4039 documents, being this CPS, DRP and PP.
4040 See CCA 4.2.
4041 </p>
4042
4043 <p>
4044 The Configuration-Control Specification
4045 is the set of policies that rule over the
4046 Community, of which the above documents are part.
4047 See COD2.
4048 Documents that have reached full POLICY status
4049 are located at
4050 <a href="http://www.cacert.org/policy/">
4051 www.cacert.org/policy/</a>.
4052 Although detailed practices may
4053 be found in other places on the website
4054 and on the wiki, the CCS documents that
4055 have reached DRAFT and POLICY status are
4056 the ruling documents.
4057 </p>
4058
4059 <h4><a name="p9.16.2" id="p9.16.2">9.16.2. Assignment</a></h4>
4060
4061 <p>
4062 The rights within CCA may not be ordinarily assigned.
4063 </p>
4064
4065 <h4><a name="p9.16.3" id="p9.16.3">9.16.3. Severability</a></h4>
4066
4067 <p>
4068 No stipulation.
4069 </p>
4070
4071 <h4><a name="p9.16.4" id="p9.16.4">9.16.4. Enforcement (attorneys' fees and waiver of rights)</a></h4>
4072
4073 <p>
4074 The Arbitrator will specify fees and remedies, if any.
4075 </p>
4076
4077 <h4><a name="p9.16.5" id="p9.16.5">9.16.5. Force Majeure</a></h4>
4078
4079 <p>
4080 No stipulation.
4081 </p>
4082
4083 <h2>---This is the end of the Policy---</h2>
4084
4085
4086 </body>
4087 </html>