static/policy/CertificationPracticeStatement.html

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