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