From e2de6e8f7e155d4d202a5ebfc01a7f5fc26dc712 Mon Sep 17 00:00:00 2001
From: Wytze van der Raay <wytze@cacert.org>
Date: Thu, 8 Jan 2015 15:02:47 +0000
Subject: [PATCH] Fix for https://bugs.cacert.org/view.php?id=1131 "Rename
 _all_ Policies from .php to .html and fix all links (was: Rename
 PolicyOnPolicy.php to .html)"

---
 includes/general_stuff.php                    |   12 +-
 pages/index/0.php                             |    4 +-
 pages/index/1.php                             |    2 +-
 pages/index/10.php                            |    2 +-
 pages/index/16.php                            |    2 +-
 pages/index/3.php                             |    2 +-
 pages/wot/6.php                               |    2 +-
 www/.htaccess                                 |    2 +-
 www/cap.html.php                              |    6 +-
 www/cap.php                                   |    6 +-
 www/capnew.php                                |   58 +-
 www/coap.html.php                             |   16 +-
 www/coapnew.php                               |   70 +-
 www/policy/AssurancePolicy.html               |  750 +++
 www/policy/AssurancePolicy.php                |  727 +--
 www/policy/CAcertCommunityAgreement.html      |  531 ++
 www/policy/CAcertCommunityAgreement.php       |  597 +--
 .../CertificationPracticeStatement.html       | 4698 +++++++++++++++++
 www/policy/CertificationPracticeStatement.php | 4091 +-------------
 .../ConfigurationControlSpecification.html    |  277 +
 www/policy/DisputeResolutionPolicy.html       |  780 +++
 www/policy/DisputeResolutionPolicy.php        |  798 +--
 www/policy/NRPDisclaimerAndLicence.php        |   14 -
 www/policy/OrganisationAssurancePolicy.html   |  408 ++
 www/policy/OrganisationAssurancePolicy.php    |  406 +-
 ...OrganisationAssurancePolicy_Australia.html |  309 ++
 .../OrganisationAssurancePolicy_Europe.html   | 1021 ++++
 .../OrganisationAssurancePolicy_Germany.html  |  138 +
 www/policy/PolicyOnJuniorAssurersMembers.html |  202 +
 www/policy/PolicyOnPolicy.html                |  356 ++
 www/policy/PolicyOnPolicy.php                 |  291 +-
 www/policy/PrivacyPolicy.html                 |   82 +-
 www/policy/PrivacyPolicy.php                  |    4 +
 www/policy/RootDistributionLicense.html       |  177 +
 www/policy/RootDistributionLicense.php        |  130 +-
 www/policy/SecurityPolicy.html                | 1308 +++++
 www/policy/TTPAssistedAssurancePolicy.html    |  271 +
 www/policy/cacert-draft.png                   |  Bin 4796 -> 0 bytes
 www/policy/index.php                          |   16 +-
 39 files changed, 11395 insertions(+), 7171 deletions(-)
 create mode 100644 www/policy/AssurancePolicy.html
 create mode 100644 www/policy/CAcertCommunityAgreement.html
 create mode 100644 www/policy/CertificationPracticeStatement.html
 create mode 100644 www/policy/ConfigurationControlSpecification.html
 create mode 100644 www/policy/DisputeResolutionPolicy.html
 delete mode 100644 www/policy/NRPDisclaimerAndLicence.php
 create mode 100644 www/policy/OrganisationAssurancePolicy.html
 create mode 100644 www/policy/OrganisationAssurancePolicy_Australia.html
 create mode 100644 www/policy/OrganisationAssurancePolicy_Europe.html
 create mode 100644 www/policy/OrganisationAssurancePolicy_Germany.html
 create mode 100644 www/policy/PolicyOnJuniorAssurersMembers.html
 create mode 100644 www/policy/PolicyOnPolicy.html
 create mode 100644 www/policy/PrivacyPolicy.php
 create mode 100644 www/policy/RootDistributionLicense.html
 create mode 100644 www/policy/SecurityPolicy.html
 create mode 100644 www/policy/TTPAssistedAssurancePolicy.html
 delete mode 100644 www/policy/cacert-draft.png

diff --git a/includes/general_stuff.php b/includes/general_stuff.php
index 4c1bd30..10c4e0a 100644
--- a/includes/general_stuff.php
+++ b/includes/general_stuff.php
@@ -38,7 +38,7 @@ google_color_text = "000000";
 google_color_border = "FFFFFF";
 //-->
 </script>
-<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script><? } else { 
+<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script><? } else {
 ?><h2><?=_("Free digital certificates!")?></h2><? } ?></div>
   </div>
   <div id="pageNav">
@@ -47,15 +47,15 @@ google_color_border = "FFFFFF";
       <? if(array_key_exists('mconn',$_SESSION) && $_SESSION['mconn']) { ?>
       <a href="https://<?=$_SESSION['_config']['normalhostname']?>/index.php?id=1"><?=_("Join")?></a>
       <? } ?>
-      <a href="/policy/CAcertCommunityAgreement.php"><?=_("Community Agreement")?></a>
+      <a href="/policy/CAcertCommunityAgreement.html"><?=_("Community Agreement")?></a>
       <a href="/index.php?id=3"><?=_("Root Certificate")?></a>
     </div>
     <? if(array_key_exists('mconn',$_SESSION) && $_SESSION['mconn']) { ?>
     <div class="relatedLinks">
       <h3 class="pointer"><?=_("My Account")?></h3>
-      <a href="https://<?=$_SESSION['_config']['normalhostname']?>/index.php?id=4"><?=_("Password Login")?></a> 
+      <a href="https://<?=$_SESSION['_config']['normalhostname']?>/index.php?id=4"><?=_("Password Login")?></a>
       <a href="https://<?=$_SESSION['_config']['normalhostname']?>/index.php?id=5"><?=_("Lost Password")?></a>
-      <a href="https://<?=$_SESSION['_config']['normalhostname']?>/index.php?id=4&amp;noauto=1"><?=_("Net Cafe Login")?></a> 
+      <a href="https://<?=$_SESSION['_config']['normalhostname']?>/index.php?id=4&amp;noauto=1"><?=_("Net Cafe Login")?></a>
       <a href="https://<?=$_SESSION['_config']['securehostname']?>/index.php?id=4"><?=_("Certificate Login")?></a>
     </div>
     <? } ?>
@@ -137,8 +137,8 @@ if(!function_exists("showfooter"))
         <a href="/policy/PrivacyPolicy.html"><?=_("Privacy Policy")?></a> |
         <a href="/index.php?id=51"><?=_("Mission Statement")?></a> | <a href="/index.php?id=11"><?=_("Contact Us")?></a> |
 	&copy;2002-<?=date("Y")?> <?=_("by CAcert")?></div>
-</div>  
-</body>             
+</div>
+</body>
 </html><?
 	}
 }
diff --git a/pages/index/0.php b/pages/index/0.php
index c5301d3..6cca117 100644
--- a/pages/index/0.php
+++ b/pages/index/0.php
@@ -23,7 +23,7 @@
 
 <p><?=sprintf(_("If you want to have free certificates issued to you, %s join the CAcert Community %s."),'<a href="https://www.cacert.org/index.php?id=1">', '</a>')?></p>
 
-<p><?=sprintf(_("If you want to use certificates issued by CAcert, read the CAcert %s Root Distribution License %s."),'<a href="/policy/RootDistributionLicense.php">',"</a>")?>
+<p><?=sprintf(_("If you want to use certificates issued by CAcert, read the CAcert %s Root Distribution License %s."),'<a href="/policy/RootDistributionLicense.html">',"</a>")?>
 <?=sprintf(_("This license applies to using the CAcert %s root keys %s."),'<a href="/index.php?id=3">','</a>')?></p>
 
 
@@ -87,7 +87,7 @@
 
 <p><?=sprintf(_("Have you passed the CAcert %s Assurer Challenge %s yet?"),'<a href="http://wiki.cacert.org/wiki/AssurerChallenge">','</a>')?></p>
 
-<p><?=sprintf(_("Have you read the CAcert %sCommunity Agreement%s yet?"),'<a href="/policy/CAcertCommunityAgreement.php">','</a>')?></p>
+<p><?=sprintf(_("Have you read the CAcert %sCommunity Agreement%s yet?"),'<a href="/policy/CAcertCommunityAgreement.html">','</a>')?></p>
 
 <p><?=sprintf(_("For general documentation and help, please visit the CAcert %sWiki Documentation site %s."),'<a href="http://wiki.CAcert.org">','</a>')?>
 <?=sprintf(_("For specific policies, see the CAcert %sApproved Policies page%s."),'<a href="/policy/">',"</a>")?></p>
diff --git a/pages/index/1.php b/pages/index/1.php
index 3315d69..0f63e7b 100644
--- a/pages/index/1.php
+++ b/pages/index/1.php
@@ -165,7 +165,7 @@
     <td class="DataTD" colspan="3"><?=_("When you click on next, we will send a confirmation email to the email address you have entered above.")?></td>
   </tr>
   <tr>
-    <td class="DataTD" colspan="3"><input type="checkbox" name="cca_agree" value="1" <?=array_key_exists('cca_agree',$_SESSION['signup'])? ($_SESSION['signup']['cca_agree'] == "1" ?"checked=\"checked\"":""):"" ?> ><?=_("I agree to the terms and conditions of the CAcert Community Agreement")?>: <a href="/policy/CAcertCommunityAgreement.php">http://www.cacert.org/policy/CAcertCommunityAgreement.php</a></td>
+    <td class="DataTD" colspan="3"><input type="checkbox" name="cca_agree" value="1" <?=array_key_exists('cca_agree',$_SESSION['signup'])? ($_SESSION['signup']['cca_agree'] == "1" ?"checked=\"checked\"":""):"" ?> ><?=_("I agree to the terms and conditions of the CAcert Community Agreement")?>: <a href="/policy/CAcertCommunityAgreement.html">http://www.cacert.org/policy/CAcertCommunityAgreement.html</a></td>
   </tr>
 
   <tr>
diff --git a/pages/index/10.php b/pages/index/10.php
index 7280e09..7dd8200 100644
--- a/pages/index/10.php
+++ b/pages/index/10.php
@@ -17,5 +17,5 @@
 */
 
     header('HTTP/1.0 301 Moved Permanently');
-    header('Location: http://www.cacert.org/policy/CertificationPracticeStatement.php');
+    header('Location: http://www.cacert.org/policy/CertificationPracticeStatement.html');
     exit();
diff --git a/pages/index/16.php b/pages/index/16.php
index c2cb391..ba3b4ed 100644
--- a/pages/index/16.php
+++ b/pages/index/16.php
@@ -16,7 +16,7 @@
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
 */ ?>
 
-<p><?=sprintf(_("You are bound by the %s Root Distribution Licence %s for any re-distributions of CAcert's roots."),"<a href='/policy/RootDistributionLicense.php'>","</a>")?></p>
+<p><?=sprintf(_("You are bound by the %s Root Distribution Licence %s for any re-distributions of CAcert's roots."),"<a href='/policy/RootDistributionLicense.html'>","</a>")?></p>
 
 <p>
 Class 1 <?=_("PKI Key")?><br>
diff --git a/pages/index/3.php b/pages/index/3.php
index a107c29..f060c8f 100644
--- a/pages/index/3.php
+++ b/pages/index/3.php
@@ -16,7 +16,7 @@
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
 */ ?>
 
-<p><?=sprintf(_("You are bound by the %s Root Distribution Licence %s for any re-distributions of CAcert's roots."),"<a href='/policy/RootDistributionLicense.php'>","</a>")?></p>
+<p><?=sprintf(_("You are bound by the %s Root Distribution Licence %s for any re-distributions of CAcert's roots."),"<a href='/policy/RootDistributionLicense.html'>","</a>")?></p>
 
 <h3><?=_("Windows Installer") ?></h3>
 <ul class="no_indent">
diff --git a/pages/wot/6.php b/pages/wot/6.php
index 4094a18..39605f3 100644
--- a/pages/wot/6.php
+++ b/pages/wot/6.php
@@ -82,7 +82,7 @@
 	AssureTextLine("",_("Only tick the next box if the Assurance was face to face."));
 	AssureBoxLine("assertion",_("I believe that the assertion of identity I am making is correct, complete and verifiable. I have seen original documentation attesting to this identity. I accept that the CAcert Arbitrator may call upon me to provide evidence in any dispute, and I may be held responsible."),array_key_exists('assertion',$_POST) && $_POST['assertion'] == 1);
 	AssureBoxLine("rules",_("I have read and understood the CAcert Community Agreement (CCA), Assurance Policy and the Assurance Handbook. I am making this Assurance subject to and in compliance with the CCA, Assurance policy and handbook."),array_key_exists('rules',$_POST) && $_POST['rules'] == 1);
-	AssureTextLine(_("Policy"),"<a href=\"/policy/CAcertCommunityAgreement.php\" target=\"_blank\">"._("CAcert Community Agreement")."</a> -<a href=\"/policy/AssurancePolicy.php\" target=\"_blank\">"._("Assurance Policy")."</a> - <a href=\"http://wiki.cacert.org/AssuranceHandbook2\" target=\"_blank\">"._("Assurance Handbook")."</a>");
+	AssureTextLine(_("Policy"),"<a href=\"/policy/CAcertCommunityAgreement.html\" target=\"_blank\">"._("CAcert Community Agreement")."</a> - <a href=\"/policy/AssurancePolicy.html\" target=\"_blank\">"._("Assurance Policy")."</a> - <a href=\"http://wiki.cacert.org/AssuranceHandbook2\" target=\"_blank\">"._("Assurance Handbook")."</a>");
 	AssureInboxLine("points",_("Points"),"","<br />(Max. ".maxpoints().")");
 	AssureFoot($id,_("I confirm this Assurance"));
 ?>
diff --git a/www/.htaccess b/www/.htaccess
index bd01047..cc48170 100644
--- a/www/.htaccess
+++ b/www/.htaccess
@@ -4,4 +4,4 @@ errordocument 404 /error404.php
 errordocument 403 /error403.php
 errordocument 401 /error401.php
 
-RedirectPermanent /cps.php http://www.cacert.org/policy/CertificationPracticeStatement.php
+RedirectPermanent /cps.php http://www.cacert.org/policy/CertificationPracticeStatement.html
diff --git a/www/cap.html.php b/www/cap.html.php
index de628b8..3522f1c 100644
--- a/www/cap.html.php
+++ b/www/cap.html.php
@@ -16,7 +16,7 @@
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
         loadem("index");
         showheader(_("Identity Verification Form (CAP) form"));
-	Version: $Id: cap.html.php,v 1.2 2011/06/10 18:30:41 wytze Exp $
+	Version: $Id: cap.html.php,v 1.3 2015/01/08 15:02:40 wytze Exp $
 */
 	echo '<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">', "\n";
 	echo '<html>', "\n";
@@ -146,7 +146,7 @@
 	echo '<tbody>', "\n";
 	echo '<tr>', "\n";
 	echo '    <td colspan="3">'._("Make sure you have read and agreed with the CAcert Community Agreement");
-	echo '(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">CCA</a>)<br>', "\n";
+	echo '(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">CCA</a>)<br>', "\n";
 	echo '</td>', "    \n", '</tr>', "\n";
 /*
 	echo '</tbody>', "\n";
@@ -158,7 +158,7 @@
 	echo '</td>', "\n".'</tr>', "\n";
 	echo '<tr>', "\n". '    <td colspan="3"><input type="checkbox" checked name="checked" value="2"> ';
 	echo _("I agree to the CAcert Community Agreement.").' (';
-	echo '<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">CCA</a>)</dd>', "\n";
+	echo '<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">CCA</a>)</dd>', "\n";
 	echo '</td>', "\n".'</tr>', "\n";
 /*
 	echo '</tbody>', "\n";
diff --git a/www/cap.php b/www/cap.php
index dc283fb..40b269a 100644
--- a/www/cap.php
+++ b/www/cap.php
@@ -146,7 +146,7 @@
 			$this->SetFont("Arial", "", "9");
 			if($_SESSION['_config']['language'] == "ja")
 				$this->SetFont('SJIS','',9);
-			$this->MultiCell($this->w - 29, 3, recode($_SESSION['_config']['recode'], _("I agree to the CAcert Community Agreement.")." ( http://www.cacert.org/policy/CAcertCommunityAgreement.php )"));
+			$this->MultiCell($this->w - 29, 3, recode($_SESSION['_config']['recode'], _("I agree to the CAcert Community Agreement.")." ( http://www.cacert.org/policy/CAcertCommunityAgreement.html )"));
 // new da end
 			$this->SetXY(13, $top + 55); //45->55
 			$this->Write(0, recode($_SESSION['_config']['recode'], _("Applicant's signature")).": __________________________________");
@@ -265,7 +265,7 @@
 				$this->Write(0, str_pad($date, 13, " "));
 			}
 
-		}	
+		}
 	}
 
 	$format = array_key_exists('format',$_REQUEST)?$_REQUEST['format']:"";
@@ -283,7 +283,7 @@
 	$pdf->AddPage();
 	$pdf->Body(array_key_exists('name',$_REQUEST)?$_REQUEST['name']:"", array_key_exists('dob',$_REQUEST)?$_REQUEST['dob']:"", array_key_exists('email',$_REQUEST)?$_REQUEST['email']:"", array_key_exists('assurer',$_REQUEST)?$_REQUEST['assurer']:"", array_key_exists('date',$_REQUEST)?$_REQUEST['date']:"", $maxpoints, array_key_exists('document1',$_REQUEST)?$_REQUEST['document1']:"", array_key_exists('document2',$_REQUEST)?$_REQUEST['document2']:"", array_key_exists('location',$_REQUEST)?$_REQUEST['location']:"");
 	header("Expires: ".gmdate("D, j M Y G:i:s \G\M\T", time()+10800));
-	header("Content-Disposition: attachment; filename=cap.pdf"); 
+	header("Content-Disposition: attachment; filename=cap.pdf");
 	header("Cache-Control: public, max-age=10800");
 	header("Pragma: cache");
 	$pdf->output();
diff --git a/www/capnew.php b/www/capnew.php
index f7531f3..a57bde3 100644
--- a/www/capnew.php
+++ b/www/capnew.php
@@ -17,8 +17,8 @@
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
-//   $Id: capnew.php,v 1.4 2012/01/24 14:26:05 root Exp $
-define('REV', '$Revision: 1.4 $');
+//   $Id: capnew.php,v 1.5 2015/01/08 15:02:40 wytze Exp $
+define('REV', '$Revision: 1.5 $');
 
 /*
 **  Created from old cap.php 2003, which used the now obsoleted ftpdf package
@@ -68,7 +68,7 @@ define('REV', '$Revision: 1.4 $');
 **     On transliteration and abbreviation of a name:
 **        if shoes a std way show accepted conversion as pdf comment
 **     Orientation: on landscape (dflt) print 2-up
-**     PDF URL links are used to web, wiki, and faq for more info search 
+**     PDF URL links are used to web, wiki, and faq for more info search
 **     Only on non-ascii chars in a name the utf8 routines are loaded
 **     PDF reader has wiki info url's and easy email feedback
 **  ENABLED:
@@ -92,7 +92,7 @@ define('REV', '$Revision: 1.4 $');
 **         recode(), recode_string(0 is said to have too many (japanese) defeats
 **         recode_string() is only used on GET[] input (html->utf-8),
 **  UTF-8  use routines from http://www.sourceforge.net/projects/phputf8
-**         which replaces php recode() package. 
+**         which replaces php recode() package.
 **         on many places own utf-8 handling code exists and is loaded (tcpdf problem)
 **  _() translation routine. The returned HTML string is translated to utf-8 string.
 **  the GET() routines expects utf-8 code (see test defs) but might be changed
@@ -196,7 +196,7 @@ define('REV', '$Revision: 1.4 $');
 **     Form Revision string is generated from RCS revision string.
 **     More info on PDF fields:
 **        http://www.adobe.com/devnet/acrobat/pdfs/js_developer_guide.pdf
-**     
+**
 */
 
 // use next define if you test this code
@@ -235,7 +235,7 @@ if( defined( 'TEST' ) ) {
         //$_GET['orientation'] = 'portrait'; // default 2 pages, or portrait
     }
     $_GET['nocca'] = isset($_SERVER['CCA']) ? $_SERVER['CCA'] : '';
-    //$_GET['policy1'] = 'policy/PolicyOnPolicy.php';
+    //$_GET['policy1'] = 'policy/PolicyOnPolicy.html';
     if( isset($_SERVER['FORM']) AND $_SERVER['FORM'] == 'noform' )
         $_GET['noform'] = 'true';
 
@@ -310,7 +310,7 @@ define('ARBIT', WIKI.'/ArbitrationForum');
 // CAcert Community Agreement
 define('CCA', 'CAcertCommunityAgreement'); // default policy to print
 define('POLICY','policy/'); // default polciy doc directory
-define('EXT','.php'); // default polciy doc extention, should be html
+define('EXT','.html'); // default polciy doc extention, should be html
 /* finger print CAcert Root Key */ // should obtain this automatically
 define('CLASS1_SHA1','135C EC36 F49C B8E9 3B1A B270 CD80 8846 76CE 8F33');
 define('CLASS3_SHA1','AD7C 3F64 FC44 39FE F4E9 0BE8 F47C 6CFA 8AAD FDCE');
@@ -387,7 +387,7 @@ function utf8_is_ascii_ctrl($str) {
 // extend TCPF with custom functions
 class CAPPDF extends TCPDF {
 
-    // do cap form version numbering automatically '$Revision: 1.4 $'
+    // do cap form version numbering automatically '$Revision: 1.5 $'
     /*public*/ function Version() {
 	strtok(REV, ' ');
         return(strtok(' '));
@@ -484,16 +484,16 @@ class CAPPDF extends TCPDF {
 
     //number of colums
     /*protected*/ var $ncols=1;
-    
+
     // columns width
     /*protected*/ var $colwidth=0;
 
     // space between columns
     /*protected*/ var $column_space = 0;
-    
+
     //Current column
     /*protected*/ var $col=0;
-    
+
     //Ordinate of column start
     /*protected*/ var $y0;
 
@@ -535,7 +535,7 @@ class CAPPDF extends TCPDF {
         $this->SetDisplayMode(intval($this->scale), 'SinglePage', 'UseOC');
         return( $format );
     }
-        
+
     //Set position at a given column
     /*private*/ function SetCol($col = -1) {
         static $pagecolwidth = 1.0;
@@ -576,7 +576,7 @@ class CAPPDF extends TCPDF {
 	    $this->myFooter(); // print footer msg if defined
         }
         if( $col >= $this->ncols ) {
-                $this->addPage(); $col = 0; 
+                $this->addPage(); $col = 0;
                 $this->ScaleXY($this->scale,0,0);
                 $this->y0 = 0;  //no header/footer done...
         } elseif ( $col > 0  AND $col < $this->ncols) {
@@ -599,7 +599,7 @@ class CAPPDF extends TCPDF {
         $this->PrintTable('', 0); // if in table reprint title table
         $this->InFooter = false;
     }
-    
+
     //Method accepting or not automatic page break
     /*public*/ function AcceptPageBreak() {
        $this->SetCol();
@@ -688,7 +688,7 @@ class CAPPDF extends TCPDF {
             elseif( preg_match('/\./', $nm ) ) {
                 if( $first_name < 0 ) $first_name = $j;
                 if( $first_name >= 0 ) $success = TRUE; // was abbreviated
-                continue; // title 
+                continue; // title
             }
             if( $first_name < 0 ) $first_name = $j;
             if( $married == 0 ) $fam = $j;
@@ -710,7 +710,7 @@ class CAPPDF extends TCPDF {
             elseif( preg_match('/\./', $nm ) ) $name .= $nm;
             elseif( $j < $fam ) { // need to abbreviate
                  // not utf8
-                 // and abbreviate 
+                 // and abbreviate
                 if( $j == $first_name )
                     $abr = '('. $substr( $nm, 1 ) . ')';
                 else $abr = '.';
@@ -724,7 +724,7 @@ class CAPPDF extends TCPDF {
             $nm = $tk[0];
             if( $ext < 0 AND preg_match('/(^[^A-Z]|\.)/', $nm ) ) continue;
             if( $ext < 0 ) $ext = $j+1;
-            if( preg_match('/\./', $nm ) ) {  $success = TRUE; break; } 
+            if( preg_match('/\./', $nm ) ) {  $success = TRUE; break; }
         }
         return( $success? $name : '' ); // and return abbriviated name
     }
@@ -841,7 +841,7 @@ class CAPPDF extends TCPDF {
         $this->StatementAssuree( $assuree['date']);
         $this->StatementAssurer( $assurer, $assurance );
     }
-    
+
     //Add form and/or CCA (on duplex only when more as one page is printed)
     /*public*/ function PrintForm( $assuree = NULL, $assurer = NULL, $assurance = NULL, $page = NULL ) {
 
@@ -1033,7 +1033,7 @@ class CAPPDF extends TCPDF {
         $this->Line($this->lMargin,$tSide+$height,$this->lMargin+$this->colwidth,$tSide+$height);
         $this->Line($this->lMargin+$this->colwidth,$tSide-1, $this->lMargin+$this->colwidth, $tSide+$height);
         $this->SetDrawColor(0);
-	$this->SetY($tSide + $height + 1); // set Y ordinate to plus 7 
+	$this->SetY($tSide + $height + 1); // set Y ordinate to plus 7
         $tSide = -1; $title = '';
 	return($this->GetY());
     }
@@ -1045,7 +1045,7 @@ class CAPPDF extends TCPDF {
         $id_type = $names == NULL ? '' : $names['idtype'];
         // store current margin values
 	static $nr = 0;
-        static $idtypes = NULL; 
+        static $idtypes = NULL;
         static $listpoints = NULL;
         static $ComboProps = array( 'fillColor'=> LBLUE, 'strokeColor'=> LLBLUE, 'editable'=> 'true', 'textSize' => 9, 'rotate'=> '0');
         static $TextProps = array('strokeColor'=> LLBLUE, 'value' => ' ', 'fillColor'=> LBLUE, 'doNotScrole'=> 'false', 'textSize' => 12, 'rotate'=> '0');
@@ -1146,7 +1146,7 @@ class CAPPDF extends TCPDF {
             $this->SetFont(FONT, 'B', (F_SIZE+1)/6*H);
             $this->Cell($this->colwidth-37, 2, '('.$id_type .')', 0, 0, 'R');
             // hide id type print on screen with the formfields, just nicety
-            // one could extend the name field, but this has more drawbacks 
+            // one could extend the name field, but this has more drawbacks
             $this->TextField(sprintf('AssureeNames_%d_None',$nr), $this->SetFieldXY($this->lMargin+$this->colwidth-38,$savey+0.5,20), 7/6*H, $TextBlankProps);
             $this->SetFieldXY();
         }
@@ -1200,7 +1200,7 @@ class CAPPDF extends TCPDF {
         // all (max) three names with ID type right aligned.
         $cnt = $assuree['namecnt'];
         $space = $this->getPageHeight()/$this->scale*100.0 -MINH ; // margin
-        for( $i = 0; $i < $cnt; $i++ )  { // names to be printed 
+        for( $i = 0; $i < $cnt; $i++ )  { // names to be printed
             $this->PrintName( $assuree['names'][$i], $assurer['maxpoints'] < 0? 35: $assurer['maxpoints'] );
             if( $space < $this->getY() ) break;
         }
@@ -1390,7 +1390,7 @@ class CAPPDF extends TCPDF {
         $this->SetFieldXY();
         $TextProps['value'] = $assurer['email'] ? $assurer['email'] : $this->unhtmlentities( _('email') ) . '?';
         $TextProps['userName'] = $this->unhtmlentities( _('On mutual assurance provide email address of Assurer.') );
-        $this->TextField('AssurerEmail', $this->SetFieldXY($this->lMargin+68.5, $savey+1, 35), 5, $TextProps ); 
+        $this->TextField('AssurerEmail', $this->SetFieldXY($this->lMargin+68.5, $savey+1, 35), 5, $TextProps );
         $this->SetFieldXY();
         $this->SetXY($this->lMargin+2, $savey+5);
 
@@ -1457,7 +1457,7 @@ class CAPPDF extends TCPDF {
 // get $form, $orientation, $assuree, $assurer, $assurance info
 // FONT and BW are set already
 
-// import info 
+// import info
 function GET( $key = '' ) {
     return ( array_key_exists( $key, $_GET) ? $_GET[$key] : '');
 }
@@ -1532,7 +1532,7 @@ for( $i = 1; $i <= 9 AND $j < 2; $i++) { // max 9 names we only print 4 max...
         $assuree[ 'namecnt' ]++;
         $assuree[ 'names' ] [] = array (
             'name' => $name ? $name : '',
-            'idtype' => my_recode(GET(Dstr('ID',$i)))? my_recode(GET(Dstr('ID',$i))) : '', 
+            'idtype' => my_recode(GET(Dstr('ID',$i)))? my_recode(GET(Dstr('ID',$i))) : '',
             'points' => my_recode(GET(Dstr('Pnts',$i))) != '' ? intval(my_recode(GET(Dstr('Pnts',$i)))) : -1
         );
         if( $name  != '' AND
@@ -1565,7 +1565,7 @@ unset( $document ); unset( $i ); unset( $j); // unset($_GET);
        PDF_UNIT /* mm */,
        /* PDF_PAGE_FORMAT */ $page['format'],
        true
-       ); 
+       );
     $pdf->SetFormat( $page['format']  ); // set paper size scaling
 
 // protection is encryption and this will cause 3.5 times performance loss
@@ -1588,10 +1588,10 @@ unset( $document ); unset( $i ); unset( $j); // unset($_GET);
     $pdf->SetAutoPageBreak(TRUE, MARGIN*0.707);
 
 //set image scale factor
-    $pdf->setImageScale(PDF_IMAGE_SCALE_RATIO); 
+    $pdf->setImageScale(PDF_IMAGE_SCALE_RATIO);
 
 //set some language-dependent strings
-    $pdf->setLanguageArray($l); 
+    $pdf->setLanguageArray($l);
 
 //initialize document
     $pdf->AliasNbPages();
@@ -1608,6 +1608,6 @@ unset( $document ); unset( $i ); unset( $j); // unset($_GET);
     $pdf->Output('CAcert CAP.pdf', 'I');
 
 //============================================================+
-// END OF FILE                                                 
+// END OF FILE
 //============================================================+
 ?>
diff --git a/www/coap.html.php b/www/coap.html.php
index a5dd5ac..fdc186e 100644
--- a/www/coap.html.php
+++ b/www/coap.html.php
@@ -14,7 +14,7 @@
     You should have received a copy of the GNU General Public License
     along with this program; if not, write to the Free Software
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
-        Version: $Id: coap.html.php,v 1.2 2011/06/10 18:30:41 wytze Exp $
+        Version: $Id: coap.html.php,v 1.3 2015/01/08 15:02:41 wytze Exp $
 */
 ?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
@@ -29,7 +29,7 @@
 
 <body>
 
-<style type="text/css"> 
+<style type="text/css">
 table#TAB1 {border-color: rgb(173,197,215); border-top: solid 5px rgb(173,197,215); border-left: solid 5px rgb(173,197,215);}
 table#TAB1 td { border: 0 }
 </style>
@@ -121,7 +121,7 @@ table#TAB1 td { border: 0 }
 <?php
 	for ( $i = 0; $i < 2; $i++ ) {
 	    echo '<tr>', "\n", '    <td>';
-	    if ( $i < 1 ) { echo _("Registered Trade Names");} 
+	    if ( $i < 1 ) { echo _("Registered Trade Names");}
 	    echo '</td>', "\n";
 	    for ( $j = 1; $j <= 3; $j++ ) {
 		printf("    <td align=\"%s\"><input size=\"25\" maxlength=\"80\" name=\"dba%d\"></td>\n", $j > 2 ? "right" : ($j > 2 ? "center" : "left") , $i * 3 + $j);
@@ -189,7 +189,7 @@ table#TAB1 td { border: 0 }
 <?php
 	echo _("Make sure you have read and agreed with the CAcert Community Agreement");
 ?>
- (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">CCA</a>)</i><br></td>
+ (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">CCA</a>)</i><br></td>
 </tr>
 <tr><td colspan=2><p></td></tr>
 <tr>
@@ -210,7 +210,7 @@ table#TAB1 td { border: 0 }
 <?php
 	echo ' '. _("I agree to the CAcert Community Agreement.").' (';
 ?>
-<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">CCA</a>)</dd></td>
+<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.html">CCA</a>)</dd></td>
 </tr>
 <tr>
     <td colspan="2"><input type="checkbox" checked name="checked" value="2">
@@ -281,7 +281,7 @@ table#TAB1 td { border: 0 }
 <tr><td colspan="2"></td><tr>
 </tbody>
 </table>
-<div style="text-align: right;"><small><small><span>&copy; 
+<div style="text-align: right;"><small><small><span>&copy;
 <?php
 	echo date('Y').' CAcert Inc., V2, '.date('Y-n-j');
 ?>
@@ -327,7 +327,7 @@ table#TAB1 td { border: 0 }
 	        'http://svn.cacert.org/CAcert/Policies/OrganisationAssurancePolicy/OrganisationAssuranceSubPolicyEurope.html',
 	    'Organisation Assurance Subpolicy for the United States' =>
 	        'http://svn.cacert.org/CAcert/Policies/OrganisationAssurancePolicy/OrganizationAssuranceSubPolicyUnitedStates.html',
-	); 
+	);
 	$cnt = 0;
 	while( list($key, $ref) = each($policies) ) {
 	    $cnt++;
@@ -338,7 +338,7 @@ table#TAB1 td { border: 0 }
         }
 	if( $cnt > 0 ) {
 	    echo "</dd>\n";
-	} 
+	}
 	echo "</dl>\n";
 	echo _("Submit the form").': <button type="submit" style="background-color: rgb(112, 154, 186); color: white;"> '._("generate PDF file");
 	echo "</button>\n";
diff --git a/www/coapnew.php b/www/coapnew.php
index 73392d9..832e397 100644
--- a/www/coapnew.php
+++ b/www/coapnew.php
@@ -17,8 +17,8 @@
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
-//   $Id: coapnew.php,v 1.4 2012/01/24 14:26:05 root Exp $
-define('REV', '$Revision: 1.4 $');
+//   $Id: coapnew.php,v 1.5 2015/01/08 15:02:41 wytze Exp $
+define('REV', '$Revision: 1.5 $');
 
 /*
 **  Created from old cap.php 2003, which used the now obsoleted ftpdf package
@@ -70,7 +70,7 @@ define('REV', '$Revision: 1.4 $');
 **     On transliteration and abbreviation of a name:
 **        if shoes a std way show accepted conversion as pdf comment
 **     Orientation: on landscape (dflt) print 2-up
-**     PDF URL links are used to web, wiki, and faq for more info search 
+**     PDF URL links are used to web, wiki, and faq for more info search
 **     Only on non-ascii chars in a name the utf8 routines are loaded
 **     PDF reader has wiki info url's and easy email feedback
 **  ENABLED:
@@ -94,7 +94,7 @@ define('REV', '$Revision: 1.4 $');
 **         recode(), recode_string(0 is said to have too many (japanese) defeats
 **         recode_string() is only used on GET[] input (html->utf-8),
 **  UTF-8  use routines from http://www.sourceforge.net/projects/phputf8
-**         which replaces php recode() package. 
+**         which replaces php recode() package.
 **         on many places own utf-8 handling code exists and is loaded (tcpdf problem)
 **  _() translation routine. The returned HTML string is translated to utf-8 string.
 **  the GET() routines expects utf-8 code (see test defs) but might be changed
@@ -221,7 +221,7 @@ define('REV', '$Revision: 1.4 $');
 **     Form Revision string is generated from RCS revision string.
 **     More info on PDF fields:
 **        http://www.adobe.com/devnet/acrobat/pdfs/js_developer_guide.pdf
-**     
+**
 */
 
 // use next define if you test this code
@@ -281,7 +281,7 @@ if( defined( 'TEST' ) ) {
         // trade office information
         $_GET['identifier'] = "NL-238603-AA02";
         $_GET['tor'] = "Kamer van Koophandel";
-        $_GET['torregion'] = "Amsterdam"; 
+        $_GET['torregion'] = "Amsterdam";
         //$_GET['tordate'] = "2008-04-03";
         // contact name(s)
         $_GET['domain1'] = "oophaga.org, oophaga.nl";
@@ -345,7 +345,7 @@ define('ARBIT', WIKI."/ArbitrationForum");
 // CAcert Community Agreement
 define('CCA', "CAcertCommunityAgreement"); // default policy to print
 define('POLICY','policy/'); // default polciy doc directory
-define('EXT','.php'); // default polciy doc extention, should be html
+define('EXT','.html'); // default polciy doc extention, should be html
 /* finger print CAcert Root Key */ // should obtain this automatically
 define('CLASS1_SHA1','135C EC36 F49C B8E9 3B1A B270 CD80 8846 76CE 8F33');
 define('CLASS3_SHA1','AD7C 3F64 FC44 39FE F4E9 0BE8 F47C 6CFA 8AAD FDCE');
@@ -422,12 +422,12 @@ function utf8_is_ascii_ctrl($str) {
 // extend TCPF with custom functions
 class COAPPDF extends TCPDF {
 
-    // do cap form version numbering automatically "$Revision: 1.4 $"
+    // do cap form version numbering automatically "$Revision: 1.5 $"
     /*public*/ function Version() {
 	strtok(REV, " ");
         return(strtok(" "));
     }
-    
+
     /*public*/ function myHeader( $msg = NULL, $url = NULL )
     {
        static $my_url = NULL;
@@ -450,7 +450,7 @@ class COAPPDF extends TCPDF {
        $this->setXY($this->lMargin, MARGIN+3);
        $this->y0 = $this->getY();
      }
- 
+
      // undefine default header and footer handling
      // default routines do not handle columns
      function Footer() { }
@@ -458,7 +458,7 @@ class COAPPDF extends TCPDF {
      function Mark( $string = "" ) {
          return array( $string, 1+substr_count($string,'.') );
      }
- 
+
      /*public*/ function myFooter( $msg = NULL, $url = NULL )
      {
        static $my_url = NULL;
@@ -501,7 +501,7 @@ class COAPPDF extends TCPDF {
            $this->StopTransform();
            $this->SetXY($savex,$savey);
         }
- 
+
         if( !empty($font_fam ) )
             $this->SetFont($font_fam,$font_style,$font_size);
         $this->InFooter = false;
@@ -519,16 +519,16 @@ class COAPPDF extends TCPDF {
 
     //number of colums
     /*protected*/ var $ncols=1;
-    
+
     // columns width
     /*protected*/ var $colwidth=0;
 
     // space between columns
     /*protected*/ var $column_space = 0;
-    
+
     //Current column
     /*protected*/ var $col=0;
-    
+
     //Ordinate of column start
     /*protected*/ var $y0;
 
@@ -570,7 +570,7 @@ class COAPPDF extends TCPDF {
         $this->SetDisplayMode(intval($this->scale), 'SinglePage', 'UseOC');
         return( $format );
     }
-        
+
     //Set position at a given column
     /*private*/ function SetCol($col = -1) {
         static $pagecolwidth = 1.0;
@@ -610,7 +610,7 @@ class COAPPDF extends TCPDF {
 	    $this->myFooter(); // print footer msg if defined
         }
         if( $col >= $this->ncols ) {
-                $this->addPage(); $col = 0; 
+                $this->addPage(); $col = 0;
                 $this->ScaleXY($this->scale,0,0);
                 $this->y0 = 0;  //no header/footer done...
         } elseif ( $col > 0  AND $col < $this->ncols) {
@@ -710,7 +710,7 @@ class COAPPDF extends TCPDF {
             elseif( preg_match('/\./', $nm ) ) {
                 if( $first_name < 0 ) $first_name = $j;
                 if( $first_name >= 0 ) $success = TRUE; // was abbreviated
-                continue; // title 
+                continue; // title
             }
             if( $first_name < 0 ) $first_name = $j;
             if( $married == 0 ) $fam = $j;
@@ -732,7 +732,7 @@ class COAPPDF extends TCPDF {
             elseif( preg_match('/\./', $nm ) ) $name .= $nm;
             elseif( $j < $fam ) { // need to abbreviate
                  // not utf8
-                 // and abbreviate 
+                 // and abbreviate
                 if( $j == $first_name )
                     $abr = "(". $substr( $nm, 1 ) . ")";
                 else $abr = ".";
@@ -746,7 +746,7 @@ class COAPPDF extends TCPDF {
             $nm = $tk[0];
             if( $ext < 0 AND preg_match('/(^[^A-Z]|\.)/', $nm ) ) continue;
             if( $ext < 0 ) $ext = $j+1;
-            if( preg_match('/\./', $nm ) ) {  $success = TRUE; break; } 
+            if( preg_match('/\./', $nm ) ) {  $success = TRUE; break; }
         }
         return( $success? $name : "" ); // and return abbriviated name
     }
@@ -859,7 +859,7 @@ class COAPPDF extends TCPDF {
             $this->StatementOrganisation($organisation);
             $this->StatementAssurer( $assurer, $assurance );
     }
-    
+
     //Add form and/or CCA (on duplex only when more as one page is printed)
     /*public*/ function PrintForm( $organisation = NULL, $registry = NULL, $assurer = NULL, $page = NULL ) {
 
@@ -1045,7 +1045,7 @@ class COAPPDF extends TCPDF {
         $this->Line($this->lMargin,$tSide+$height,$this->lMargin+$this->colwidth,$tSide+$height);
         $this->Line($this->lMargin+$this->colwidth,$tSide-1, $this->lMargin+$this->colwidth, $tSide+$height);
         $this->SetDrawColor(0);
-	$this->SetY($tSide + $height + 1); // set Y ordinate to plus 7 
+	$this->SetY($tSide + $height + 1); // set Y ordinate to plus 7
         $tSide = -1; $title = "";
 	return($this->GetY());
     }
@@ -1078,7 +1078,7 @@ class COAPPDF extends TCPDF {
             if ( BW ) {
                 $this->SetFillColor(241);
             } else {
-                //$this->SetFillColor(173,197,215); 
+                //$this->SetFillColor(173,197,215);
                 $this->SetFillColor(234, 241, 246);
             }
             $this->Rect($this->lMargin+37.5,$this->GetY()+0.1,
@@ -1141,7 +1141,7 @@ class COAPPDF extends TCPDF {
         if( $phone ) {
             $TextProps['value'] = $phone ? $phone : $this->unhtmlentities( _('phone nr') ) . "?";
             $TextProps['userName'] = $this->unhtmlentities( _('For organisation administrators and assurer: provide email address and optionally your phone number.') );
-            $this->TextField($field.'Phone', $this->SetFieldXY($this->lMargin+$this->colwidth-25, $savey, 24), 4.5, $TextProps ); 
+            $this->TextField($field.'Phone', $this->SetFieldXY($this->lMargin+$this->colwidth-25, $savey, 24), 4.5, $TextProps );
             $this->SetFieldXY();
         }
         $savey += 3;
@@ -1156,7 +1156,7 @@ class COAPPDF extends TCPDF {
         if( $email ) {
             $TextProps['value'] = $email ? $email : $this->unhtmlentities( _('email') ) . "?";
             $TextProps['userName'] = $this->unhtmlentities( _('For organisation administrators and assurer: provide email address and optionally your phone number.') );
-            $this->TextField($field.'Email', $this->SetFieldXY($this->lMargin+2+$l, $savey, $this->colwidth-$l-28), 4.5, $TextProps); 
+            $this->TextField($field.'Email', $this->SetFieldXY($this->lMargin+2+$l, $savey, $this->colwidth-$l-28), 4.5, $TextProps);
             $this->SetFieldXY(); $savey += 3;
         }
 // phone number
@@ -1166,7 +1166,7 @@ class COAPPDF extends TCPDF {
     }
 
 // All information of Applicant goes in one table
-/*public*/ function InfoOrganisation( $organisation = NULL, $registry = NULL ){ 
+/*public*/ function InfoOrganisation( $organisation = NULL, $registry = NULL ){
         // Applicant Identity information part
         $tSide = $this->PrintTable($this->unhtmlentities( _('Organisation Identity Information') ))+1;
 
@@ -1220,7 +1220,7 @@ class COAPPDF extends TCPDF {
                          $strg,
                          NULL, NULL, true);
         $this->Ln(0.4);
-        $strg = ""; foreach( $organisation['domains'] as $i ) 
+        $strg = ""; foreach( $organisation['domains'] as $i )
             $strg .= ($strg != "" ? ", " : "") . $i;
         $this->PrintName(
                          $this->unhtmlentities( _('The internet domain name(s) the organisation controls and owns. The names will be checked with WHOIS with e.g. the DNS official top domain registrar e.g. the country ccTLD .<country code> registrar.') ),
@@ -1233,7 +1233,7 @@ class COAPPDF extends TCPDF {
 	// contact info o-admin address assuree
         $cnt = $organisation['admincnt'];
         $space = $this->getPageHeight()/$this->scale*100.0 -MINH ; // margin
-        for( $i = 0; $i < $cnt; $i++ )  { // names to be printed 
+        for( $i = 0; $i < $cnt; $i++ )  { // names to be printed
             $this->PrintName(
                     $this->unhtmlentities( _('The organisation administrator (CAcert Assurer) contact information. The administrator is appointed by the organisation director to administer the organisation domain certificates, secure the certificates and maintain them.') ),
                     $this->unhtmlentities( _('Organisation Administrator') ),
@@ -1400,7 +1400,7 @@ class COAPPDF extends TCPDF {
 // get $form, $orientation, $assuree, $assurer, $assurance info
 // FONT and BW are set already
 
-// import info 
+// import info
 $utf8 = false;
 function GET( $key = "" ) {
     global $utf8;
@@ -1457,7 +1457,7 @@ $registry = array (
 $organisation = array (
                    'names'      => array( ), // [0] full name, [>0] DBA's
                    'namecnt'    => 0,
-                   'date'       => my_recode(GET('date')) == "now" ? date("Y-m-d") : 
+                   'date'       => my_recode(GET('date')) == "now" ? date("Y-m-d") :
                                    my_recode(GET('date')),
                    'address'    => my_recode(GET('address')),
                    'state'	=> my_recode(GET('state')),
@@ -1507,7 +1507,7 @@ for( $i = 0; $i <= 25 AND $j < 2; $i++ ) {
         if( $domains != "" ) $domains .= ",";
         $domains .= strtolower($name);
     } else $j ++;
-} 
+}
 $i = 0;
 if( $domains ) { // csv list to array and trim white spaces
     $domains = strtok($domains,',');
@@ -1547,7 +1547,7 @@ unset( $i ); unset( $j); unset( $utf8 ); // unset($_GET);
        PDF_UNIT /* mm */,
        /* PDF_PAGE_FORMAT */ $page['format'],
        true
-       ); 
+       );
     $pdf->SetFormat( $page['format']  ); // set paper size scaling
 
 // protection is encryption and this will cause 3.5 times performance loss
@@ -1570,10 +1570,10 @@ unset( $i ); unset( $j); unset( $utf8 ); // unset($_GET);
     $pdf->SetAutoPageBreak(TRUE, MARGIN*0.707);
 
 //set image scale factor
-    $pdf->setImageScale(PDF_IMAGE_SCALE_RATIO); 
+    $pdf->setImageScale(PDF_IMAGE_SCALE_RATIO);
 
 //set some language-dependent strings
-    $pdf->setLanguageArray($l); 
+    $pdf->setLanguageArray($l);
 
 //initialize document
     $pdf->AliasNbPages();
@@ -1589,6 +1589,6 @@ unset( $i ); unset( $j); unset( $utf8 ); // unset($_GET);
     $pdf->Output("CAcert COAP.pdf", "I");
 
 //============================================================+
-// END OF FILE                                                 
+// END OF FILE
 //============================================================+
 ?>
diff --git a/www/policy/AssurancePolicy.html b/www/policy/AssurancePolicy.html
new file mode 100644
index 0000000..cfa8400
--- /dev/null
+++ b/www/policy/AssurancePolicy.html
@@ -0,0 +1,750 @@
+<!DOCTYPE html>
+<html><head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+<title>Assurance Policy</title>
+
+<!--meta name="CREATED" content="20080530;0" -->
+<!--meta name="CHANGEDBY" content="Teus Hagen" -->
+<!--meta name="CHANGED" content="20080709;12381800" -->
+<!--meta name="CREATEDBY" content="Ian Grigg" -->
+<!--meta name="CHANGEDBY" content="Teus Hagen" -->
+<!--meta name="CHANGEDBY" content="Robert Cruikshank" -->
+<!--meta name="CHANGEDBY" content="Teus Hagen" -->
+<style type="text/css">
+
+P { color: #000000 }
+TD P { color: #000000 }
+H1 { color: #000000 }
+H2 { color: #000000 }
+DT { color: #000000; font-style: italic; }
+DD { color: #000000 }
+H3 { color: #000000 }
+TH P { color: #000000 }
+.r{ text-align: right; }
+.l{ text-align: left; }
+.c{ text-align : center; }
+.vTop{ vertical-align: top; }
+.size075{font-size: .75em;}
+.size1{font-size: 1.1em;}
+.size2{font-size: 1.5em;}
+.size3{font-size: 2em;}
+.parentC {margin-left:auto; margin-right:auto;}
+.padding5 td{padding: 5px;}
+.padding2 td{padding: 2px;}
+.margin0 {margin: 0px;}
+
+</style></head>
+<body style="direction: ltr; color: rgb(0, 0, 0);" lang="en-GB">
+
+<div class="comment">
+<table style="width: 100%;">
+
+<tr>
+<td>
+  Name: AP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD13</a><br>
+  Status: POLICY <a style="color: steelblue" href="https://wiki.cacert.org/PolicyDecisions#p20090105.2">p20090105.2</a><br>
+Editor: <a style="color: steelblue" href="https://wiki.cacert.org/TeusHagen">Teus Hagen</a><br>
+Creation date: 2008-05-30<br>
+Last change by: Iang<br>
+Last change date: 2009-01-08<br>
+  Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br>
+
+</td>
+<td class="r vTop">
+  <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-policy.png" alt="AP Status - POLICY" height="31" width="88" style="border-style: none;"></a>
+
+</td>
+</tr>
+</table>
+</div>
+
+
+<h1>Assurance Policy for CAcert Community Members</h1>
+
+<h2 id="s0">0. Preamble</h2>
+<h3 id="s0.1">0.1. Definition of Terms</h3>
+<dl>
+<dt>Member</dt>
+<dd> A Member is an individual who has agreed to the CAcert
+Community Agreement
+(<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html" target="_blank">CCA</a>)
+and has created successfully
+a CAcert login account on the CAcert web site. </dd>
+<dt>Assurance</dt>
+<dd> Assurance is the process by which a Member of CAcert
+Community (Assurer) identifies an individual (<span lang="en-US">Assuree</span>).
+</dd>
+<dt>Prospective Member</dt>
+<dd> An individual who participates in the process of Assurance,
+but has not yet created a CAcert login account. </dd>
+<dt>Name</dt>
+<dd> A Name is the full name of an individual.
+</dd>
+<dt>Secondary Distinguishing Feature</dt>
+<dd> An additional personal data item of the Member
+that assists discrimination from Members with similar full names.
+(Currently this is the Date of Birth (DoB).)
+</dd>
+</dl>
+
+<h3 id="s0.2">0.2. The CAcert Web of Trust</h3>
+<p>
+In face-to-face meetings,
+an Assurer allocates a number of Assurance Points
+to the Member being Assured.
+CAcert combines the Assurance Points
+into a global <i>Web-of-Trust</i> (or "WoT").
+</p>
+<p>
+CAcert explicitly chooses to meet its various goals by
+construction of a Web-of-Trust of all Members.
+</p>
+
+<h3 id="s0.3">0.3. Related Documentation</h3>
+<p>
+Documentation on Assurance is split between this
+Assurance Policy (AP) and the
+<a href="https://wiki.cacert.org/AssuranceHandbook2" target="_blank">Assurance
+Handbook</a>. The policy is controlled by Configuration Control
+Specification
+(<a href="https://svn.cacert.org/CAcert/Policies/ConfigurationControlSpecification.html" target="_blank">CCS</a>)
+under Policy on Policy
+(<a href="https://www.cacert.org/policy/PolicyOnPolicy.html" target="_blank">PoP</a>)
+policy document regime.  Because Assurance is an active area, much
+of the practice is handed over to the Assurance Handbook, which is
+not a controlled policy document, and can more easily respond to
+experience and circumstances. It is also more readable.
+</p>
+<p>
+See also Organisation Assurance Policy (<a href="https://www.cacert.org/policy/OrganisationAssurancePolicy.html" target="_blank">OAP</a>)
+and CAcert Policy Statement (<a href="https://www.cacert.org/policy/CertificationPracticeStatement.html" target="_blank">CPS</a>).
+</p>
+
+<h2 id="s1">1. Assurance Purpose</h2>
+<p>The purpose of Assurance is to add confidence
+in the Assurance Statement made by the CAcert Community of a Member. </p>
+<p>With sufficient assurances, a Member may: (a) issue certificates
+with their assured Name included, (b) participate in assuring others,
+and (c) other related activities. The strength of these activities is
+based on the strength of the assurance. </p>
+
+<h3 id="s1.1">1.1. The Assurance Statement</h3>
+<p>
+The Assurance Statement makes the following claims
+about a person:
+</p>
+<ol>
+<li>
+<p>The person is a bona fide Member. In other words, the
+person is a member of the CAcert Community as defined by the CAcert
+Community Agreement (<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html" target="_blank">CCA</a>); </p>
+</li>
+<li>
+<p>The Member has a (login) account with CAcert's on-line
+registration and service system; </p>
+</li>
+<li>
+<p>The Member can be determined from any CAcert certificate
+issued by the Account; </p>
+</li>
+<li>
+<p>The Member is bound into CAcert's Arbitration as defined
+by the CAcert Community Agreement; </p>
+</li>
+<li>
+<p>Some personal details of the Member are known to CAcert:
+the individual Name(s), primary and other listed individual email
+address(es), secondary distinguishing feature (e.g. DoB). </p>
+</li>
+</ol>
+<p>The confidence level of the Assurance Statement is expressed by
+the Assurance Points. </p>
+<h3 id="s1.2">1.2. Relying Party Statement</h3>
+<p>The primary goal of the Assurance Statement is for the express
+purpose of certificates to meet the needs of the <em>Relying Party
+Statement</em>, which latter is found in the Certification Practice
+Statement (<a href="https://www.cacert.org/policy/CertificationPracticeStatement.html" target="_blank">CPS</a>).
+</p>
+<p>When a certificate is issued, some of the Assurance Statement may
+be incorporated, e.g. Name. Other parts may be implied, e.g.
+Membership, exact account and status. They all are part of the
+<em>Relying Party Statement</em>. In short, this means that other
+Members of the Community may rely on the information verified by
+Assurance and found in the certificate.</p>
+<p>In particular, certificates are sometimes considered to provide
+reliable indications of e.g. the Member's Name and email address. The
+nature of Assurance, the number of Assurance Points, and other
+policies and processes should be understood as limitations on any
+reliance. </p>
+<h2 id="s2">2. The Member</h2>
+<h3 id="s2.1">2.1. The Member's Name </h3>
+<p>
+At least one individual Name is recorded in the Member's
+CAcert login account.  The general standard of a Name is:
+</p>
+<ul>
+<li>
+<p>
+The Name should be recorded as written in a
+government-issued photo identity document (ID).
+</p>
+</li>
+<li>
+<p>
+The Name should be recorded as completely as possible.
+That is, including all middle names, any titles and extensions,
+without abbreviations, and without transliteration of characters.
+</p>
+</li>
+<li>
+<p>The Name is recorded as a string of characters,
+encoded in unicode
+transformation format.</p>
+</li>
+</ul>
+<h3 id="s2.2">2.2. Multiple Names and variations</h3>
+<p>
+In order to handle the contradictions in the above general standard,
+a Member may record multiple Names or multiple variations of a Name
+in her CAcert online Account.
+Examples of variations include married names,
+variations of initials of first or middle names,
+abbreviations of a first name,
+different language or country variations,
+and transliterations of characters in a name.
+</p>
+
+<h3 id="s2.3">2.3. Status and Capabilities</h3>
+<p>
+A Name which has reached
+the level of 50 Assurance Points is defined as an Assured
+Name. An Assured Name can be used in a certificate issued by CAcert.
+A Member with at least one Assured Name has reached the Assured
+Member status.
+Additional capabilities are described in Table 1.
+</p>
+
+<blockquote>
+<p class="l size075"><em>Table 1:
+Assurance Capability</em></p>
+<table class="padding5 margin0" border="1">
+<tbody>
+<tr>
+<td style="width: 10%;">
+<p class="l"><em>Minimum Assurance Points</em></p>
+</td>
+<td style="width: 15%;">
+<p class="l"><em>Capability</em></p>
+</td>
+<td style="width: 15%;">
+<p class="l"><em>Status</em></p>
+</td>
+<td style="width: 60%;">
+<p class="l"><em>Comment</em></p>
+</td>
+</tr>
+<tr class="vTop">
+<td>
+<p class="c">0</p>
+</td>
+<td>
+<p class="l">Request Assurance</p>
+</td>
+<td>
+<p class="l">Prospective Member</p>
+</td>
+<td>
+<p class="l">Individual taking part of an
+Assurance, who does not have created a CAcert login account (yet). The
+allocation of Assurance Points is awaiting login account creation.</p>
+</td>
+</tr>
+<tr class="vTop">
+<td>
+<p class="c">0</p>
+</td>
+<td>
+<p class="l">Request unnamed certificates</p>
+</td>
+<td>
+<p class="l">Member</p>
+</td>
+<td>
+<p class="l">Although the Member's details are
+recorded in the account, they are not highly assured.</p>
+</td>
+</tr>
+<tr class="vTop">
+<td>
+<p class="c">50</p>
+</td>
+<td>
+<p class="l">Request named certificates</p>
+</td>
+<td>
+<p class="l">Assured Member</p>
+</td>
+<td>
+<p class="l">Statements of Assurance: the Name is
+assured to 50 Assurance Points or more</p>
+</td>
+</tr>
+<tr class="vTop">
+<td>
+<p class="c">100</p>
+</td>
+<td>
+<p class="l">Become an Assurer</p>
+</td>
+<td>
+<p class="l">Prospective Assurer</p>
+</td>
+<td>
+<p class="l">Assured to 100 Assurance Points (or
+more) on at least one Name, and passing the Assurer Challenge.</p>
+</td>
+</tr>
+</tbody>
+</table>
+</blockquote>
+
+
+<p>
+A Member may check the status of another Member, especially
+for an assurance process.
+Status may be implied from information in a certificate.
+The number of Assurance Points for each Member is not published.
+</p>
+
+<p>
+The CAcert Policy Statement
+(<a href="https://www.cacert.org/policy/CertificationPracticeStatement.html" target="_blank">CPS</a>)
+and other policies may list other capabilities that rely on Assurance
+Points.
+</p>
+
+<h2 id="s3">3. The Assurer</h2>
+<p>An Assurer is a Member with the following: </p>
+<ul>
+<li>
+<p>Is assured to a minimum of 100 Assurance Points; </p>
+</li>
+<li>
+<p>Has passed the CAcert Assurer Challenge. </p>
+</li>
+</ul>
+<p>The Assurer Challenge is administered by the Education Team on
+behalf of the Assurance Officer. </p>
+<h3 id="s3.1">3.1. The Obligations of the Assurer</h3>
+<p>The Assurer is obliged to: </p>
+<ul>
+<li>
+<p>Follow this Assurance Policy; </p>
+</li>
+<li>
+<p>Follow any additional rules of detail laid out by the
+CAcert Assurance Officer; </p>
+</li>
+<li>
+<p>Be guided by the CAcert <a href="https://wiki.cacert.org/AssuranceHandbook2" target="_blank">Assurance Handbook</a> in their
+judgement; </p>
+</li>
+<li>
+<p>Make a good faith effort at identifying and verifying
+Members; </p>
+</li>
+<li>
+<p>Maintain the documentation on each Assurance; </p>
+</li>
+<li>
+<p>Deliver documentation to Arbitration, or as otherwise
+directed by the Arbitrator; </p>
+</li>
+<li>
+<p>Keep up-to-date with developments within the CAcert
+Community. </p>
+</li>
+</ul>
+<h2 id="s4">4. The Assurance</h2>
+<h3 id="s4.1">4.1. The Assurance Process</h3>
+<p>The Assurer conducts the process of Assurance with each
+Member. </p>
+<p>The process consists of: </p>
+<ol>
+<li>
+<p>Voluntary agreement by both Assurer and Member or
+Prospective Member to conduct the Assurance; </p>
+</li>
+<li>
+<p>Personal meeting of Assurer and Member or Prospective
+Member; </p>
+</li>
+<li>
+<p>Recording of essential details on CAcert Assurance
+Programme form; </p>
+</li>
+<li>
+<p>Examination of Identity documents by Assurer and
+verification of recorded details (the Name(s) and Secondary
+Distinguishing Feature, e.g., DoB); </p>
+</li>
+<li>
+<p>Allocation of Assurance Points by Assurer; </p>
+</li>
+<li>
+<p>Optional: supervision of reciprocal Assurance made by
+Assuree (Mutual Assurance); </p>
+</li>
+<li>
+<p>Safekeeping of the CAcert Assurance Programme (<a href="https://www.cacert.org/cap.php" target="_blank">CAP</a>)
+forms by Assurer. </p>
+</li>
+</ol>
+<h3 id="s4.2">4.2. Mutual Assurance</h3>
+<p>Mutual Assurance follows the principle of reciprocity. This
+means
+that the Assurance may be two-way, and that each member participating
+in the Assurance procedure should be able to show evidence of their
+identity to the other. </p>
+<p>In the event that an Assurer is assured by a Member who is not
+certified as an Assurer, the Assurer supervises the Assurance
+procedure and process, and is responsible for the results. </p>
+<p>Reciprocity maintains a balance between the (new) member and
+the
+Assurer, and reduces any sense of power. It is also an important aid
+to the assurance training for future Assurers. </p>
+
+<h3 id="s4.3">4.3. Assurance Points</h3>
+<p>The Assurance applies Assurance Points to each Member which
+measure the increase of confidence in the Statement (above).
+Assurance Points should not be interpreted for any other purpose.
+Note that, even though they are sometimes referred to as <em>Web-of-Trust</em>
+(Assurance) Points, or <em>Trust</em> Points, the meaning
+of the word
+'Trust' is not well defined. </p>
+<p><em>Assurance Points Allocation</em><br>
+An Assurer can allocate a
+number of Assurance Points to the Member according to the Assurer's
+experience (Experience Point system, see below). The allocation of
+the maximum means that the Assurer is 100% confident in the
+information presented: </p>
+<ul>
+<li>
+<p>Detail on form, system, documents, person in accordance; </p>
+</li>
+<li>
+<p>Sufficient quality identity documents have been checked; </p>
+</li>
+<li>
+<p>Assurer's familiarity with identity documents; </p>
+</li>
+<li>
+<p>The Assurance Statement is confirmed. </p>
+</li>
+</ul>
+<p>
+Any lesser confidence should result in less Assurance Points for a
+Name. If the Assurer has no confidence in the information presented,
+then <em>zero</em> Assurance Points may be allocated by the Assurer.
+For example, this may happen if the identity documents are totally
+unfamiliar to the Assurer. The number of Assurance Points from <em>zero</em>
+to <em>maximum</em> is guided by the Assurance Handbook
+and the judgement of the Assurer.
+If there is negative confidence the Assurer should consider
+filing a dispute.
+</p>
+<p>Multiple Names should be allocated Assurance Points
+independently within a single Assurance. </p>
+<p>
+A Member who is not an Assurer may award an Assurer in a
+reciprocal process a maximum of 2 Assurance Points, according to
+her judgement. The Assurer should strive to have the Member allocate
+according to the Member's judgement, and stay on the cautious side;
+the Member new to the assurance process
+should allocate <em>zero</em> Assurance Points
+until she gains some confidence in what is happening.
+</p>
+<p>
+In general, for a Member to reach 50 Assurance Points, the Member must
+have participated in at least two assurances, and
+at least one Name will have been assured to that level.
+</p>
+<p>
+To reach 100 Assurance
+Points, at least one Name of the Assured Member must have been
+assured at least three times.
+</p>
+<p>
+The maximum number of Assurance
+Points which can be allocated for an Assurance under this policy
+and under any act under any
+Subsidiary Policy (below) is 50 Assurance Points.
+</p>
+
+<h3 id="s4.4">4.4. Experience Points</h3>
+<p>The maximum number of Assurance Points that may be awarded by
+an
+Assurer is determined by the Experience Points of the Assurer. </p>
+<blockquote>
+<p class="l size075" ><em>Table 2:
+Maximum of Assurance Points </em>
+</p>
+<table class="padding margin0" border="1" style="width: 15%;">
+<tbody>
+<tr>
+<td>
+<p><em>Assurer's Experience Points</em></p>
+</td>
+<td>
+<p><em>Allocatable Assurance Points</em></p>
+</td>
+</tr>
+<tr>
+<td>
+<p class="c">0</p>
+</td>
+<td>
+<p class="c">10</p>
+</td>
+</tr>
+<tr>
+<td>
+<p class="c">10</p>
+</td>
+<td>
+<p class="c">15</p>
+</td>
+</tr>
+<tr>
+<td>
+<p class="c">20</p>
+</td>
+<td>
+<p class="c">20</p>
+</td>
+</tr>
+<tr>
+<td>
+<p class="c">30</p>
+</td>
+<td>
+<p class="c">25</p>
+</td>
+</tr>
+<tr>
+<td>
+<p class="c">40</p>
+</td>
+<td>
+<p class="c">30</p>
+</td>
+</tr>
+<tr>
+<td>
+<p class="c">&gt;=50</p>
+</td>
+<td>
+<p class="c">35</p>
+</td>
+</tr>
+</tbody>
+</table>
+</blockquote>
+<p>An Assurer is given a maximum of 2 Experience Points for every
+completed Assurance. On reaching Assurer status, the Experience
+Points start at 0 (zero). </p>
+<p>Less Experience Points (1) may be given for mass Assurance
+events,
+where each Assurance is quicker. </p>
+<p>Additional Experience Points may be granted temporarily or
+permanently to an Assurer by CAcert Inc.'s Committee (board), on
+recommendation from the Assurance Officer. </p>
+<p>Experience Points are not to be confused with Assurance
+Points. </p>
+<h3 id="s4.5">4.5. CAcert Assurance Programme (CAP) form</h3>
+<p>The CAcert Assurance Programme (<a href="https://www.cacert.org/cap.php" target="_blank">CAP</a>)
+form requests the following details of each Member or Prospective
+Member: </p>
+<ul>
+<li>
+<p>Name(s), as recorded in the on-line account; </p>
+</li>
+<li>
+<p>Primary email address, as recorded in the on-line account;
+</p>
+</li>
+<li>
+<p>Secondary Distinguishing Feature, as recorded in the
+on-line account (normally, date of birth); </p>
+</li>
+<li>
+<p>Statement of agreement with the CAcert Community
+Agreement; </p>
+</li>
+<li>
+<p>Permission to the Assurer to conduct the Assurance
+(required for privacy reasons); </p>
+</li>
+<li>
+<p>Date and signature of the Assuree. </p>
+</li>
+</ul>
+<p>The CAP form requests the following details of the Assurer: </p>
+<ul>
+<li>
+<p>At least one Name as recorded in the on-line account of
+the Assurer; </p>
+</li>
+<li>
+<p>Assurance Points for each Name in the identity
+document(s); </p>
+</li>
+<li>
+<p>Statement of Assurance; </p>
+</li>
+<li>
+<p>Optional: If the Assurance is reciprocal, then the
+Assurer's email address and Secondary Distinguishing Feature are
+required as well; </p>
+</li>
+<li>
+<p>Date, location of Assurance and signature of Assurer. </p>
+</li>
+</ul>
+<p>The CAP forms are to be kept at least for 7 years by the
+Assurer. </p>
+<h2 id="s5">5. The Assurance Officer</h2>
+<p>The Committee (board) of CAcert Inc. appoints an Assurance
+Officer
+with the following responsibilities: </p>
+<ul>
+<li>
+<p>Reporting to the Committee and advising on all matters to
+do with Assurance; </p>
+</li>
+<li>
+<p>Training and testing of Assurers, in association with the
+Education Team; </p>
+</li>
+<li>
+<p>Updating this Assurance Policy, under the process
+established by Policy on Policy (<a href="https://www.cacert.org/policy/PolicyOnPolicy.html" target="_blank">PoP</a>); </p>
+</li>
+<li>
+<p>Management of all Subsidiary Policies (see below) for
+Assurances, under Policy on Policy; </p>
+</li>
+<li>
+<p>Managing and creating rules of detail or procedure where
+inappropriate for policies; </p>
+</li>
+<li>
+<p>Incorporating rulings from Arbitration into policies,
+procedures or guidelines; </p>
+</li>
+<li>
+<p>Assisting the Arbitrator in any requests; </p>
+</li>
+<li>
+<p>Managing the Assurer Handbook; </p>
+</li>
+<li>
+<p>Maintaining a sufficient strength in the Assurance process
+(web-of-trust) to meet the agreed needs of the Community. </p>
+</li>
+</ul>
+<h2 id="s6">6. Subsidiary Policies</h2>
+<p>The Assurance Officer manages various exceptions and additional
+processes. Each must be covered by an approved Subsidiary Policy
+(refer to <a href="https://www.cacert.org/policy/PolicyOnPolicy.html" target="_blank">Policy on Policy</a> =&gt; CAcert Official Document COD1).
+Subsidiary Policies specify any additional tests of knowledge
+required and variations to process and documentation, within the
+general standard stated here. </p>
+<h3 id="s6.1">6.1. Standard</h3>
+<p>Each Subsidiary Policy must augment and improve the general
+standards in this Assurance Policy. It is the responsibility of each
+Subsidiary Policy to describe how it maintains and improves the
+specific and overall goals. It must describe exceptions and potential
+areas of risk. </p>
+
+<h3 id="s6.2">6.2. High Risk Applications</h3>
+<p>In addition to the Assurance or Experience Points ratings set
+here and in other subsidiary policies, the Assurance Officer or policies can
+designate certain applications as high risk. If so, additional
+measures may be added to the Assurance process that specifically
+address the risks.</p>
+<p>Additional measures may include:
+</p>
+<ul>
+<li>
+<p>Additional information can be required in process of assurance: </p>
+<ul>
+<li>unique numbers of identity documents,</li>
+<li>photocopy of identity documents,</li>
+<li>photo of User,</li>
+<li>address of User.</li>
+</ul>
+<p>Additional Information is to be kept by Assurer, attached to
+CAcert Assurance Programme (<a href="https://www.cacert.org/cap.php" target="_blank">CAP</a>)
+form. Assurance Points allocation by this assurance is unchanged.
+User's CAcert login account should be annotated to record type of
+additional information;</p>
+</li>
+<li>
+<p>Arbitration: </p>
+<ul>
+<li> Member to participate in Arbitration. This confirms
+their acceptance of the forum as well as trains in the process and
+import,
+</li>
+<li> Member to file Arbitration to present case. This
+allows Arbitrator as final authority;
+</li>
+</ul>
+</li>
+<li>
+<p>Additional training; </p>
+</li>
+<li>
+<p>Member to be Assurer (at least 100 Assurance Points and
+passed Assurer Challenge); </p>
+</li>
+<li>
+<p>Member agrees to additional specific agreement(s); </p>
+</li>
+<li>
+<p>Additional checking/auditing of systems data by CAcert
+support administrators. </p>
+</li>
+</ul>
+<p>Applications that might attract additional measures include
+code-signing certificates and administration roles. </p>
+<h2 id="s7">7. Privacy</h2>
+<p>CAcert is a "privacy" organisation, and takes the
+privacy of its Members seriously. The process maintains the security
+and privacy of both parties. </p>
+<p>Information is collected primarily to make claims within the
+certificates requested by users and to contact the Members. It is
+used secondarily for training, testing, administration and other
+internal purposes. </p>
+<p>The Member's information can be accessed under these
+circumstances: </p>
+<ul>
+<li>
+<p>Under Arbitrator ruling, in a duly filed dispute (<a href="https://www.cacert.org/policy/DisputeResolutionPolicy.html" target="_blank">Dispute Resolution Policy</a>
+=&gt; COD7); </p>
+</li>
+<li>
+<p>An Assurer in the process of an Assurance, as permitted on
+the CAcert Assurance Programme (<a href="https://www.cacert.org/cap.php" target="_blank">CAP</a>)
+form; </p>
+</li>
+<li>
+<p>CAcert support administration and CAcert systems
+administration when operating under the authority of Arbitrator or
+under CAcert policy. </p>
+</li>
+</ul>
+<p><a href="http://validator.w3.org/check?uri=referer"><img src="images/valid-html50-blue.png" alt="Valid HTML 5" height="31" width="88"></a></p>
+</body></html>
+
diff --git a/www/policy/AssurancePolicy.php b/www/policy/AssurancePolicy.php
index 4998de5..025d37b 100644
--- a/www/policy/AssurancePolicy.php
+++ b/www/policy/AssurancePolicy.php
@@ -1,723 +1,4 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html><head>
-<title>Assurance Policy</title>
-
-<meta name="CREATED" content="20080530;0">
-<meta name="CHANGEDBY" content="Teus Hagen">
-<meta name="CHANGED" content="20080709;12381800">
-<meta name="CREATEDBY" content="Ian Grigg">
-<meta name="CHANGEDBY" content="Teus Hagen">
-<meta name="CHANGEDBY" content="Robert Cruikshank">
-<meta name="CHANGEDBY" content="Teus Hagen">
-<style type="text/css">
-<!--
-P { color: #000000 }
-TD P { color: #000000 }
-H1 { color: #000000 }
-H2 { color: #000000 }
-DT { color: #000000 }
-DD { color: #000000 }
-H3 { color: #000000 }
-TH P { color: #000000 }
--->
-</style></head>
-<body style="direction: ltr; color: rgb(0, 0, 0);" lang="en-GB">
-<h1>Assurance Policy for CAcert Community Members</h1>
-<p><a href="PolicyOnPolicy.php"><img src="/images/cacert-policy.png" id="graphics1" alt="CAcert Policy Status == POLICY" align="bottom" border="0" height="33" width="90"></a>
-<br>
-Editor: Teus Hagen<br>
-Creation date: 2008-05-30<br>
-Last change by: Iang<br>
-Last change date: 2009-01-08<br>
-Status: POLICY p20090105.2
-</p>
-
-<h2><a name="0">0.</a> Preamble</h2>
-<h3><a name="0.1">0.1.</a> Definition of Terms</h3>
-<dl>
-<dt><i>Member</i> </dt>
-<dd> A Member is an individual who has agreed to the CAcert
-Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php" target="_blank">CCA</a>)
-and has created successfully
-a CAcert login account on the CAcert web site. </dd>
-<dt> <i>Assurance</i> </dt>
-<dd> Assurance is the process by which a Member of CAcert
-Community (Assurer) identifies an individual (<span lang="en-US">Assuree</span>).
-</dd>
-<dt> <i>Prospective Member</i> </dt>
-<dd> An individual who participates in the process of Assurance,
-but has not yet created a CAcert login account. </dd>
-<dt> <i>Name</i> </dt>
-<dd> A Name is the full name of an individual.
-</dd>
-<dt> <i>Secondary Distinguishing Feature</i>
-</dt>
-<dd> An additional personal data item of the Member
-that assists discrimination from Members with similar full names.
-(Currently this is the Date of Birth (DoB).)
-</dd>
-</dl>
-
-<h3><a name="0.2">0.2.</a> The CAcert Web of Trust</h3>
-<p>
-In face-to-face meetings,
-an Assurer allocates a number of Assurance Points
-to the Member being Assured.
-CAcert combines the Assurance Points
-into a global <i>Web-of-Trust</i> (or "WoT").
-</p>
-<p>
-CAcert explicitly chooses to meet its various goals by
-construction of a Web-of-Trust of all Members.
-</p>
-
-<h3><a name="0.3">0.3.</a> Related Documentation</h3>
-<p>
-Documentation on Assurance is split between this
-Assurance Policy (AP) and the
-<a href="http://wiki.cacert.org/wiki/AssuranceHandbook2" target="_blank">Assurance
-Handbook</a>. The policy is controlled by Configuration Control
-Specification
-(<a href="http://wiki.cacert.org/wiki/PolicyDrafts/ConfigurationControlSpecification" target="_blank">CCS</a>)
-under Policy on Policy
-(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php" target="_blank">PoP</a>)
-policy document regime.  Because Assurance is an active area, much
-of the practice is handed over to the Assurance Handbook, which is
-not a controlled policy document, and can more easily respond to
-experience and circumstances. It is also more readable.
-</p>
-<p>
-See also Organisation Assurance Policy (<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php" target="_blank">OAP</a>)
-and CAcert Policy Statement (<a href="http://www.cacert.org/policy/CertificationPracticeStatement.php" target="_blank">CPS</a>).
-</p>
-
-<h2><a name="1">1.</a> Assurance Purpose</h2>
-<p>The purpose of Assurance is to add confidence
-in the Assurance Statement made by the CAcert Community of a Member. </p>
-<p>With sufficient assurances, a Member may: (a) issue certificates
-with their assured Name included, (b) participate in assuring others,
-and (c) other related activities. The strength of these activities is
-based on the strength of the assurance. </p>
-
-<h3><a name="1.1">1.1.</a>The Assurance Statement</h3>
-<p>
-The Assurance Statement makes the following claims
-about a person:
-</p>
-<ol>
-<li>
-<p>The person is a bona fide Member. In other words, the
-person is a member of the CAcert Community as defined by the CAcert
-Community Agreement (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php" target="_blank">CCA</a>); </p>
-</li>
-<li>
-<p>The Member has a (login) account with CAcert's on-line
-registration and service system; </p>
-</li>
-<li>
-<p>The Member can be determined from any CAcert certificate
-issued by the Account; </p>
-</li>
-<li>
-<p>The Member is bound into CAcert's Arbitration as defined
-by the CAcert Community Agreement; </p>
-</li>
-<li>
-<p>Some personal details of the Member are known to CAcert:
-the individual Name(s), primary and other listed individual email
-address(es), secondary distinguishing feature (e.g. DoB). </p>
-</li>
-</ol>
-<p>The confidence level of the Assurance Statement is expressed by
-the Assurance Points. </p>
-<h3><a name="1.2">1.2.</a>Relying Party Statement</h3>
-<p>The primary goal of the Assurance Statement is for the express
-purpose of certificates to meet the needs of the <i>Relying Party
-Statement</i>, which latter is found in the Certification Practice
-Statement (<a href="http://www.cacert.org/policy/CertificationPracticeStatement.php" target="_blank">CPS</a>).
-</p>
-<p>When a certificate is issued, some of the Assurance Statement may
-be incorporated, e.g. Name. Other parts may be implied, e.g.
-Membership, exact account and status. They all are part of the
-<i>Relying Party Statement</i>. In short, this means that other
-Members of the Community may rely on the information verified by
-Assurance and found in the certificate.</p>
-<p>In particular, certificates are sometimes considered to provide
-reliable indications of e.g. the Member's Name and email address. The
-nature of Assurance, the number of Assurance Points, and other
-policies and processes should be understood as limitations on any
-reliance. </p>
-<h2><a name="2">2.</a> The Member</h2>
-<h3><a name="2.1">2.1.</a> The Member's Name </h3>
-<p>
-At least one individual Name is recorded in the Member's
-CAcert login account.  The general standard of a Name is:
-</p>
-<ul>
-<li>
-<p>
-The Name should be recorded as written in a
-government-issued photo identity document (ID).
-</p>
-</li>
-<li>
-<p>
-The Name should be recorded as completely as possible.
-That is, including all middle names, any titles and extensions,
-without abbreviations, and without transliteration of characters.
-</p>
-</li>
-<li>
-<p>The Name is recorded as a string of characters,
-encoded in <span lang="en-US">unicode</span>
-transformation format.</p>
-</li>
-</ul>
-<h3><a name="2.2">2.2.</a> Multiple Names and variations</h3>
-<p>
-In order to handle the contradictions in the above general standard,
-a Member may record multiple Names or multiple variations of a Name
-in her CAcert online Account.
-Examples of variations include married names,
-variations of initials of first or middle names,
-abbreviations of a first name,
-different language or country variations,
-and transliterations of characters in a name.
-</p>
-
-<h3><a name="2.3">2.3.</a> Status and Capabilities</h3>
-<p>
-A Name which has reached
-the level of 50 Assurance Points is defined as an Assured
-Name. An Assured Name can be used in a certificate issued by CAcert.
-A Member with at least one Assured Name has reached the Assured
-Member status.
-Additional capabilities are described in Table 1.
-</p>
-
-<blockquote>
-<p align="left"><font size="2"><i>Table 1:
-Assurance Capability</i></font></p>
-<table border="1" cellpadding="5" cellspacing="0">
-<tbody>
-<tr>
-<td width="10%">
-<p align="left"><i>Minimum Assurance Points</i></p>
-</td>
-<td width="15%">
-<p align="left"><i>Capability</i></p>
-</td>
-<td width="15%">
-<p align="left"><i>Status</i></p>
-</td>
-<td width="60%">
-<p align="left"><i>Comment</i></p>
-</td>
-</tr>
-<tr valign="top">
-<td>
-<p align="center">0</p>
-</td>
-<td>
-<p align="left">Request Assurance</p>
-</td>
-<td>
-<p align="left">Prospective Member</p>
-</td>
-<td>
-<p align="left">Individual taking part of an
-Assurance, who does not have created a CAcert login account (yet). The
-allocation of Assurance Points is awaiting login account creation.</p>
-</td>
-</tr>
-<tr valign="top">
-<td>
-<p align="center">0</p>
-</td>
-<td>
-<p align="left">Request unnamed certificates</p>
-</td>
-<td>
-<p align="left">Member</p>
-</td>
-<td>
-<p align="left">Although the Member's details are
-recorded in the account, they are not highly assured.</p>
-</td>
-</tr>
-<tr valign="top">
-<td>
-<p align="center">50</p>
-</td>
-<td>
-<p align="left">Request named certificates</p>
-</td>
-<td>
-<p align="left">Assured Member</p>
-</td>
-<td>
-<p align="left">Statements of Assurance: the Name is
-assured to 50 Assurance Points or more</p>
-</td>
-</tr>
-<tr valign="top">
-<td>
-<p align="center">100</p>
-</td>
-<td>
-<p align="left">Become an Assurer</p>
-</td>
-<td>
-<p align="left">Prospective Assurer</p>
-</td>
-<td>
-<p align="left">Assured to 100 Assurance Points (or
-more) on at least one Name, and passing the Assurer Challenge.</p>
-</td>
-</tr>
-</tbody>
-</table>
-</blockquote>
-
-
-<p>
-A Member may check the status of another Member, especially
-for an assurance process.
-Status may be implied from information in a certificate.
-The number of Assurance Points for each Member is not published.
-</p>
-
-<p>
-The CAcert Policy Statement
-(<a href="http://www.cacert.org/policy/CertificationPracticeStatement.php" target="_blank">CPS</a>)
-and other policies may list other capabilities that rely on Assurance
-Points.
-</p>
-
-<h2><a name="3">3.</a> The Assurer</h2>
-<p>An Assurer is a Member with the following: </p>
-<ul>
-<li>
-<p>Is assured to a minimum of 100 Assurance Points; </p>
-</li>
-<li>
-<p>Has passed the CAcert Assurer Challenge. </p>
-</li>
-</ul>
-<p>The Assurer Challenge is administered by the Education Team on
-behalf of the Assurance Officer. </p>
-<h3><a name="3.1">3.1.</a> The Obligations of the Assurer</h3>
-<p>The Assurer is obliged to: </p>
-<ul>
-<li>
-<p>Follow this Assurance Policy; </p>
-</li>
-<li>
-<p>Follow any additional rules of detail laid out by the
-CAcert Assurance Officer; </p>
-</li>
-<li>
-<p>Be guided by the CAcert <a href="http://wiki.cacert.org/wiki/AssuranceHandbook2" target="_blank">Assurance Handbook</a> in their
-judgement; </p>
-</li>
-<li>
-<p>Make a good faith effort at identifying and verifying
-Members; </p>
-</li>
-<li>
-<p>Maintain the documentation on each Assurance; </p>
-</li>
-<li>
-<p>Deliver documentation to Arbitration, or as otherwise
-directed by the Arbitrator; </p>
-</li>
-<li>
-<p>Keep up-to-date with developments within the CAcert
-Community. </p>
-</li>
-</ul>
-<h2><a name="4">4.</a> The Assurance</h2>
-<h3><a name="4.1">4.1.</a> The Assurance Process</h3>
-<p>The Assurer conducts the process of Assurance with each
-Member. </p>
-<p>The process consists of: </p>
-<ol>
-<li>
-<p>Voluntary agreement by both Assurer and Member or
-Prospective Member to conduct the Assurance; </p>
-</li>
-<li>
-<p>Personal meeting of Assurer and Member or Prospective
-Member; </p>
-</li>
-<li>
-<p>Recording of essential details on CAcert Assurance
-Programme form; </p>
-</li>
-<li>
-<p>Examination of Identity documents by Assurer and
-verification of recorded details (the Name(s) and Secondary
-Distinguishing Feature, e.g., DoB); </p>
-</li>
-<li>
-<p>Allocation of Assurance Points by Assurer; </p>
-</li>
-<li>
-<p>Optional: supervision of reciprocal Assurance made by
-Assuree (Mutual Assurance); </p>
-</li>
-<li>
-<p>Safekeeping of the CAcert Assurance Programme (<a href="http://www.cacert.org/cap.php" target="_blank">CAP</a>)
-forms by Assurer. </p>
-</li>
-</ol>
-<h3><a name="4.2">4.2.</a> Mutual Assurance</h3>
-<p>Mutual Assurance follows the principle of reciprocity. This
-means
-that the Assurance may be two-way, and that each member participating
-in the Assurance procedure should be able to show evidence of their
-identity to the other. </p>
-<p>In the event that an Assurer is assured by a Member who is not
-certified as an Assurer, the Assurer supervises the Assurance
-procedure and process, and is responsible for the results. </p>
-<p>Reciprocity maintains a balance between the (new) member and
-the
-Assurer, and reduces any sense of power. It is also an important aid
-to the assurance training for future Assurers. </p>
-
-<h3><a name="4.3">4.3.</a> Assurance Points</h3>
-<p>The Assurance applies Assurance Points to each Member which
-measure the increase of confidence in the Statement (above).
-Assurance Points should not be interpreted for any other purpose.
-Note that, even though they are sometimes referred to as <i>Web-of-Trust</i>
-(Assurance) Points, or <i>Trust</i> Points, the meaning
-of the word
-'Trust' is not well defined. </p>
-<p><i>Assurance Points Allocation</i><br>
-An Assurer can allocate a
-number of Assurance Points to the Member according to the Assurer's
-experience (Experience Point system, see below). The allocation of
-the maximum means that the Assurer is 100% confident in the
-information presented: </p>
-<ul>
-<li>
-<p>Detail on form, system, documents, person in accordance; </p>
-</li>
-<li>
-<p>Sufficient quality identity documents have been checked; </p>
-</li>
-<li>
-<p>Assurer's familiarity with identity documents; </p>
-</li>
-<li>
-<p>The Assurance Statement is confirmed. </p>
-</li>
-</ul>
-<p>
-Any lesser confidence should result in less Assurance Points for a
-Name. If the Assurer has no confidence in the information presented,
-then <i>zero</i> Assurance Points may be allocated by the Assurer.
-For example, this may happen if the identity documents are totally
-unfamiliar to the Assurer. The number of Assurance Points from <i>zero</i>
-to <i>maximum</i> is guided by the Assurance Handbook
-and the judgement of the Assurer.
-If there is negative confidence the Assurer should consider
-filing a dispute.
-</p>
-<p>Multiple Names should be allocated Assurance Points
-independently within a single Assurance. </p>
-<p>
-A Member who is not an Assurer may award an Assurer in a
-reciprocal process a maximum of 2 Assurance Points, according to
-her judgement. The Assurer should strive to have the Member allocate
-according to the Member's judgement, and stay on the cautious side;
-the Member new to the assurance process
-should allocate <i>zero</i> Assurance Points
-until she gains some confidence in what is happening.
-</p>
-<p>
-In general, for a Member to reach 50 Assurance Points, the Member must
-have participated in at least two assurances, and
-at least one Name will have been assured to that level.
-</p>
-<p>
-To reach 100 Assurance
-Points, at least one Name of the Assured Member must have been
-assured at least three times.
-</p>
-<p>
-The maximum number of Assurance
-Points which can be allocated for an Assurance under this policy
-and under any act under any
-Subsidiary Policy (below) is 50 Assurance Points.
-</p>
-
-<h3><a name="4.4">4.4.</a> Experience Points</h3>
-<p>The maximum number of Assurance Points that may be awarded by
-an
-Assurer is determined by the Experience Points of the Assurer. </p>
-<blockquote>
-<p align="left"><font size="2"><i>Table 2:
-Maximum of Assurance Points </i></font>
-</p>
-<table border="1" cellpadding="2" cellspacing="0" width="15%">
-<tbody>
-<tr>
-<td>
-<p><i>Assurer's Experience Points</i></p>
-</td>
-<td>
-<p><i>Allocatable Assurance Points</i></p>
-</td>
-</tr>
-<tr>
-<td>
-<p align="center">0</p>
-</td>
-<td>
-<p align="center">10</p>
-</td>
-</tr>
-<tr>
-<td>
-<p align="center">10</p>
-</td>
-<td>
-<p align="center">15</p>
-</td>
-</tr>
-<tr>
-<td>
-<p align="center">20</p>
-</td>
-<td>
-<p align="center">20</p>
-</td>
-</tr>
-<tr>
-<td>
-<p align="center">30</p>
-</td>
-<td>
-<p align="center">25</p>
-</td>
-</tr>
-<tr>
-<td>
-<p align="center">40</p>
-</td>
-<td>
-<p align="center">30</p>
-</td>
-</tr>
-<tr>
-<td>
-<p align="center">&gt;=50</p>
-</td>
-<td>
-<p align="center">35</p>
-</td>
-</tr>
-</tbody>
-</table>
-</blockquote>
-<p>An Assurer is given a maximum of 2 Experience Points for every
-completed Assurance. On reaching Assurer status, the Experience
-Points start at 0 (zero). </p>
-<p>Less Experience Points (1) may be given for mass Assurance
-events,
-where each Assurance is quicker. </p>
-<p>Additional Experience Points may be granted temporarily or
-permanently to an Assurer by CAcert Inc.'s Committee (board), on
-recommendation from the Assurance Officer. </p>
-<p>Experience Points are not to be confused with Assurance
-Points. </p>
-<h3><a name="4.5">4.5.</a> CAcert Assurance Programme (CAP) form</h3>
-<p>The CAcert Assurance Programme (<a href="http://www.cacert.org/cap.php" target="_blank">CAP</a>)
-form requests the following details of each Member or Prospective
-Member: </p>
-<ul>
-<li>
-<p>Name(s), as recorded in the on-line account; </p>
-</li>
-<li>
-<p>Primary email address, as recorded in the on-line account;
-</p>
-</li>
-<li>
-<p>Secondary Distinguishing Feature, as recorded in the
-on-line account (normally, date of birth); </p>
-</li>
-<li>
-<p>Statement of agreement with the CAcert Community
-Agreement; </p>
-</li>
-<li>
-<p>Permission to the Assurer to conduct the Assurance
-(required for privacy reasons); </p>
-</li>
-<li>
-<p>Date and signature of the Assuree. </p>
-</li>
-</ul>
-<p>The CAP form requests the following details of the Assurer: </p>
-<ul>
-<li>
-<p>At least one Name as recorded in the on-line account of
-the Assurer; </p>
-</li>
-<li>
-<p>Assurance Points for each Name in the identity
-document(s); </p>
-</li>
-<li>
-<p>Statement of Assurance; </p>
-</li>
-<li>
-<p>Optional: If the Assurance is reciprocal, then the
-Assurer's email address and Secondary Distinguishing Feature are
-required as well; </p>
-</li>
-<li>
-<p>Date, location of Assurance and signature of Assurer. </p>
-</li>
-</ul>
-<p>The CAP forms are to be kept at least for 7 years by the
-Assurer. </p>
-<h2><a name="5">5.</a> The Assurance Officer</h2>
-<p>The Committee (board) of CAcert Inc. appoints an Assurance
-Officer
-with the following responsibilities: </p>
-<ul>
-<li>
-<p>Reporting to the Committee and advising on all matters to
-do with Assurance; </p>
-</li>
-<li>
-<p>Training and testing of Assurers, in association with the
-Education Team; </p>
-</li>
-<li>
-<p>Updating this Assurance Policy, under the process
-established by Policy on Policy (<a href="https://www.cacert.org/policy/PolicyOnPolicy.php" target="_blank">PoP</a>); </p>
-</li>
-<li>
-<p>Management of all Subsidiary Policies (see below) for
-Assurances, under Policy on Policy; </p>
-</li>
-<li>
-<p>Managing and creating rules of detail or procedure where
-inappropriate for policies; </p>
-</li>
-<li>
-<p>Incorporating rulings from Arbitration into policies,
-procedures or guidelines; </p>
-</li>
-<li>
-<p>Assisting the Arbitrator in any requests; </p>
-</li>
-<li>
-<p>Managing the Assurer Handbook; </p>
-</li>
-<li>
-<p>Maintaining a sufficient strength in the Assurance process
-(web-of-trust) to meet the agreed needs of the Community. </p>
-</li>
-</ul>
-<h2><a name="6">6.</a> Subsidiary Policies</h2>
-<p>The Assurance Officer manages various exceptions and additional
-processes. Each must be covered by an approved Subsidiary Policy
-(refer to Policy on Policy =&gt; CAcert Official Document COD1).
-Subsidiary Policies specify any additional tests of knowledge
-required and variations to process and documentation, within the
-general standard stated here. </p>
-<h3><a name="6.1">6.1.</a> Standard</h3>
-<p>Each Subsidiary Policy must augment and improve the general
-standards in this Assurance Policy. It is the responsibility of each
-Subsidiary Policy to describe how it maintains and improves the
-specific and overall goals. It must describe exceptions and potential
-areas of risk. </p>
-
-<h3><a name="6.2">6.2.</a> High Risk Applications</h3>
-<p>In addition to the Assurance or Experience Points ratings set
-here and in other subsidiary policies, the Assurance Officer or policies can
-designate certain applications as high risk. If so, additional
-measures may be added to the Assurance process that specifically
-address the risks.</p>
-<p>Additional measures may include:
-</p>
-<ul>
-<li>
-<p>Additional information can be required in process of assurance: </p>
-<ul>
-<li>unique numbers of identity documents,</li>
-<li>photocopy of identity documents,</li>
-<li>photo of User,</li>
-<li>address of User.</li>
-</ul>
-<p>Additional Information is to be kept by Assurer, attached to
-CAcert Assurance Programme (<a href="http://www.cacert.org/cap.php" target="_blank">CAP</a>)
-form. Assurance Points allocation by this assurance is unchanged.
-User's CAcert login account should be annotated to record type of
-additional information;</p>
-</li>
-<li>
-<p>Arbitration: </p>
-<ul>
-<li> Member to participate in Arbitration. This confirms
-their acceptance of the forum as well as trains in the process and
-import,
-</li>
-<li> Member to file Arbitration to present case. This
-allows Arbitrator as final authority;
-</li>
-</ul>
-</li>
-<li>
-<p>Additional training; </p>
-</li>
-<li>
-<p>Member to be Assurer (at least 100 Assurance Points and
-passed Assurer Challenge); </p>
-</li>
-<li>
-<p>Member agrees to additional specific agreement(s); </p>
-</li>
-<li>
-<p>Additional checking/auditing of systems data by CAcert
-support administrators. </p>
-</li>
-</ul>
-<p>Applications that might attract additional measures include
-code-signing certificates and administration roles. </p>
-<h2><a name="7">7.</a> Privacy</h2>
-<p>CAcert is a "privacy" organisation, and takes the
-privacy of its Members seriously. The process maintains the security
-and privacy of both parties. </p>
-<p>Information is collected primarily to make claims within the
-certificates requested by users and to contact the Members. It is
-used secondarily for training, testing, administration and other
-internal purposes. </p>
-<p>The Member's information can be accessed under these
-circumstances: </p>
-<ul>
-<li>
-<p>Under Arbitrator ruling, in a duly filed dispute (<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php" target="_blank">Dispute Resolution Policy</a>
-=&gt; COD7); </p>
-</li>
-<li>
-<p>An Assurer in the process of an Assurance, as permitted on
-the CAcert Assurance Programme (<a href="http://www.cacert.org/cap.php" target="_blank">CAP</a>)
-form; </p>
-</li>
-<li>
-<p>CAcert support administration and CAcert systems
-administration when operating under the authority of Arbitrator or
-under CAcert policy. </p>
-</li>
-</ul>
-<p><a href="http://validator.w3.org/check?uri=referer"><img src="/images/valid-xhtml11-blue" id="graphics2" alt="Valid XHTML 1.1" align="bottom" border="0" height="33" width="90"></a>
-</p>
-</body></html>
-
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: AssurancePolicy.html');
+exit();
\ No newline at end of file
diff --git a/www/policy/CAcertCommunityAgreement.html b/www/policy/CAcertCommunityAgreement.html
new file mode 100644
index 0000000..810c043
--- /dev/null
+++ b/www/policy/CAcertCommunityAgreement.html
@@ -0,0 +1,531 @@
+<!DOCTYPE html>
+<html>
+<head>
+    <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" lang="en">
+    <title>CAcert Community Agreement</title>
+    <style>
+    .r{
+        text-align: right;
+    }
+    .vTop{
+        vertical-align: top;
+    }
+    dt{
+        font-style: italic;
+    }
+    </style>
+
+</head>
+<body>
+
+<div class="comment">
+<table style="width: 100%;">
+
+<tr>
+<td>
+  Name: CCA <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD9</a><br />
+  Status: POLICY <a style="color: steelblue" href="https://wiki.cacert.org/PolicyDecisions#p20080109">p20080109</a><br />
+Editor: <a style="color: steelblue" href="https://wiki.cacert.org/Iang">Iang</a><br />
+  Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br />
+
+</td>
+<td class="vTop r">
+  <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-policy.png" alt="CCA Status - POLICY" height="31" width="88" style="border-style: none;" /></a>
+
+</td>
+</tr>
+</table>
+</div>
+
+<h2> CAcert Community Agreement </h2>
+
+
+
+<h3 id="s0"> 0.   Introduction </h3>
+
+<p>
+This agreement is between
+you, being a registered member ("Member")
+within CAcert's community at large ("Community")
+and CAcert Incorporated ("CAcert"),
+being an operator of services to the Community.
+</p>
+
+<h4 id="s0.1"> 0.1   Terms </h4>
+<dl>
+  <dt>"CAcert"</dt><dd>
+    means CAcert Inc.,
+    a non-profit Association of Members incorporated in
+    New South Wales, Australia.
+    Note that Association Members are distinct from
+    the Members defined here.</dd>
+  <dt>"Member"</dt><dd>
+    means you, a registered participant within CAcert's Community,
+    with an account on the website and the
+    facility to request certificates.
+    Members may be individuals ("natural persons")
+    or organisations ("legal persons").</dd>
+  <dt>"Organisation"</dt><dd>
+    is defined under the Organisation Assurance programme,
+    and generally includes corporations and other entities
+    that become Members and become Assured.</dd>
+  <dt>"Community"</dt><dd>
+    means all of the Members
+    that are registered by this agreement
+    and other parties by other agreements,
+    all being under CAcert's Arbitration.</dd>
+  <dt>"Non-Related Person" ("NRP")</dt><dd>
+    being someone who is not a
+    Member, is not part of the Community,
+    and has not registered their agreement.
+    Such people are offered the NRP-DaL
+    another agreement allowing the USE of certificates.</dd>
+  <dt>"Non-Related Persons - Disclaimer and Licence" ("NRP-DaL")</dt><dd>
+    another agreement that is offered to persons outside the
+    Community.</dd>
+  <dt>"Arbitration"</dt><dd>
+    is the Community's forum for
+    resolving disputes, or jurisdiction.</dd>
+  <dt>"Dispute Resolution Policy" ("DRP" =&gt; COD7)</dt><dd>
+    is the policy and
+    rules for resolving disputes.</dd>
+  <dt>"USE"</dt><dd>
+    means the act by your software
+    to conduct its tasks, incorporating
+    the certificates according to software procedures.</dd>
+  <dt>"RELY"</dt><dd>
+    means your human act in taking on a
+    risk and liability on the basis of the claim(s)
+    bound within a certificate.</dd>
+  <dt>"OFFER"</dt><dd>
+    means the your act
+    of making available your certificate to another person.
+    Generally, you install and configure your software
+    to act as your agent and facilite this and other tasks.
+    OFFER does not imply suggestion of reliance.</dd>
+  <dt>"Issue"</dt><dd>
+    means creation of a certificate by CAcert.
+    To create a certificate,
+    CAcert affixes a digital signature from the root
+    onto a public key and other information.
+    This act would generally bind a statement or claim,
+    such as your name, to your key.</dd>
+  <dt>"Root"</dt><dd>
+    means CAcert's top level key,
+    used for signing certificates for Members.
+    In this document, the term includes any subroots.</dd>
+  <dt>"CAcert Official Document" ("COD" =&gt; COD3)</dt><dd>
+    in a standard format for describing the details of
+    operation and governance essential to a certificate authority.
+    Changes are managed and controlled.
+    CODs define more technical terms.
+    See 4.2 for listing of relevant CODs.</dd>
+  <dt>"Certification Practice Statement" ("CPS" =&gt; COD6)</dt><dd>
+    is the document that controls details
+    about operational matters within CAcert.</dd>
+</dl>
+
+
+<h3 id="s1"> 1.   Agreement and Licence </h3>
+
+<h4 id="s1.1"> 1.1   Agreement </h4>
+
+<p>
+You and CAcert both agree to the terms and conditions
+in this agreement.
+Your agreement is given by any of
+</p>
+
+<ul><li>
+    your signature on a form to request assurance of identity
+    ("CAP" form),
+  </li><li>
+    your request on the website
+    to join the Community and create an account,
+  </li><li>
+    your request for Organisation Assurance,
+  </li><li>
+    your request for issuing of certificates, or
+  </li><li>
+    if you USE, RELY, or OFFER
+    any certificate issued to you.
+</li></ul>
+
+<p>
+Your agreement
+is effective from the date of the first event above
+that makes this agreement known to you.
+This Agreement
+replaces and supercedes prior agreements,
+including the NRP-DaL.
+</p>
+
+
+<h4 id="s1.2"> 1.2   Licence </h4>
+
+<p>
+As part of the Community, CAcert offers you these rights:
+</p>
+
+<ol><li>
+    You may USE any certificates issued by CAcert.
+  </li><li>
+    You may RELY on any certificate issued by CAcert,
+    as explained and limited by CPS (COD6).
+  </li><li>
+    You may OFFER certificates issued to you by CAcert
+    to Members for their RELIANCE.
+  </li><li>
+    You may OFFER certificates issued to you by CAcert
+    to NRPs for their USE, within the general principles
+    of the Community.
+  </li><li>
+    This Licence is free of cost,
+    non-exclusive, and non-transferrable.
+</li></ol>
+
+<h4 id="s1.3"> 1.3   Your Contributions </h4>
+
+
+<p>
+You agree to a non-exclusive non-restrictive non-revokable
+transfer of Licence to CAcert for your contributions.
+That is, if you post an idea or comment on a CAcert forum,
+or email it to other Members,
+your work can be used freely by the Community for
+CAcert purposes, including placing under CAcert's licences
+for wider publication.
+</p>
+
+<p>
+You retain authorship rights, and the rights to also transfer
+non-exclusive rights to other parties.
+That is, you can still use your
+ideas and contributions outside the Community.
+</p>
+
+<p>
+Note that the following exceptions override this clause:
+</p>
+
+<ol><li>
+    Contributions to controlled documents are subject to
+    Policy on Policy ("PoP" =&gt; COD1)
+  </li><li>
+    Source code is subject to an open source licence regime.
+</li></ol>
+
+<h4 id="s1.4"> 1.4   Privacy </h4>
+
+
+<p>
+You give rights to CAcert to store, verify and process
+and publish your data in accordance with policies in force.
+These rights include shipping the data to foreign countries
+for system administration, support and processing purposes.
+Such shipping will only be done among
+CAcert Community administrators and Assurers.
+</p>
+
+<p>
+Privacy is further covered in the Privacy Policy ("PP" =&gt; COD5).
+</p>
+
+<h3 id="s2"> 2.   Your Risks, Liabilities and Obligations </h3>
+
+<p>
+As a Member, you have risks, liabilities
+and obligations within this agreement.
+</p>
+
+<h4 id="s2.1"> 2.1   Risks </h4>
+
+<ol><li>
+    A certificate may prove unreliable.
+  </li><li>
+    Your account, keys or other security tools may be
+    lost or otherwise compromised.
+  </li><li>
+    You may find yourself subject to Arbitration
+    (DRP =&gt; COD7).
+</li></ol>
+
+<h4 id="s2.2"> 2.2   Liabilities </h4>
+
+<ol><li>
+    You are liable for any penalties
+    as awarded against you by the Arbitrator.
+  </li><li>
+    Remedies are as defined in the DRP (COD7).
+    An Arbitrator's ruling may
+    include monetary amounts, awarded against you.
+  </li><li>
+    Your liability is limited to
+    a total maximum of
+    <b>1000 Euros</b>.
+  </li><li>
+    "Foreign Courts" may assert jurisdiction.
+    These include your local courts, and are outside our Arbitration.
+    Foreign Courts will generally refer to the Arbitration
+    Act of their country, which will generally refer
+    civil cases to Arbitration.
+    The Arbitration Act will not apply to criminal cases.
+</li></ol>
+
+<h4 id="s2.3"> 2.3   Obligations </h4>
+
+<p>
+    You are obliged
+</p>
+
+<ol><li>
+    to provide accurate information
+    as part of Assurance.
+    You give permission for verification of the information
+    using CAcert-approved methods.
+  </li><li>
+    to make no false representations.
+  </li><li>
+    to submit all your disputes to Arbitration
+    (DRP =&gt; COD7).
+</li></ol>
+
+<h4 id="s2.4"> 2.4   Principles </h4>
+
+<p>
+As a Member of CAcert, you are a member of
+the Community.
+    You are further obliged to
+    work within the spirit of the Principles
+    of the Community.
+    These are described in
+    <a href="https://svn.cacert.org/CAcert/principles.html">Principles of the Community</a>.
+</p>
+
+<h4 id="s2.5"> 2.5   Security </h4>
+<p>
+CAcert exists to help you to secure yourself.
+You are primarily responsible for your own security.
+Your security obligations include
+</p>
+
+<ol><li>
+    to secure yourself and your computing platform (e.g., PC),
+  </li><li>
+    to keep your email account in good working order,
+  </li><li>
+    to secure your CAcert account
+    (e.g., credentials such as username, password),
+  </li><li>
+    to secure your private keys,
+  </li><li>
+    to review certificates for accuracy,
+    and
+  </li><li>
+    when in doubt, notify CAcert,
+  </li><li>
+    when in doubt, take other reasonable actions, such as
+    revoking certificates,
+    changing account credentials,
+    and/or generating new keys.
+</li></ol>
+
+<p>
+Where, above, 'secure' means to protect to a reasonable
+degree, in proportion with your risks and the risks of
+others.
+</p>
+
+<h3 id="s3"> 3.   Law and Jurisdiction </h3>
+
+<h4 id="s3.1"> 3.1   Governing Law </h4>
+
+<p>
+This agreement is governed under the law of
+New South Wales, Australia,
+being the home of the CAcert Inc. Association.
+</p>
+
+<h4 id="s3.2"> 3.2   Arbitration as Forum of Dispute Resolution </h4>
+
+<p>
+You agree, with CAcert and all of the Community,
+that all disputes arising out
+of or in connection to our use of CAcert services
+shall be referred to and finally resolved
+by Arbitration under the rules within the
+Dispute Resolution Policy of CAcert
+(DRP =&gt; COD7).
+The rules select a single Arbitrator chosen by CAcert
+from among senior Members in the Community.
+The ruling of the Arbitrator is binding and
+final on Members and CAcert alike.
+</p>
+
+<p>
+In general, the jurisdiction for resolution of disputes
+is within CAcert's own forum of Arbitration,
+as defined and controlled by its own rules (DRP =&gt; COD7).
+</p>
+
+<p>
+We use Arbitration for many purposes beyond the strict
+nature of disputes, such as governance and oversight.
+A systems administrator may
+need authorisation to conduct a non-routine action,
+and Arbitration may provide that authorisation.
+Thus, you may find yourself party to Arbitration
+that is simply support actions, and you may file disputes in
+order to initiate support actions.
+</p>
+
+<h4 id="s3.3"> 3.3   Termination </h4>
+<p>
+You may terminate this agreement by resigning
+from CAcert.  You may do this at any time by
+writing to CAcert's online support forum and
+filing dispute to resign.
+All services will be terminated, and your
+certificates will be revoked.
+However, some information will continue to
+be held for certificate processing purposes.
+</p>
+
+<p>
+The provisions on Arbitration survive any termination
+by you by leaving CAcert.
+That is, even if you resign from CAcert,
+you are still bound by the DRP (COD7),
+and the Arbitrator may reinstate any provision of this
+agreement or bind you to a ruling.
+</p>
+
+<p>
+Only the Arbitrator may terminate this agreement with you.
+</p>
+
+<h4 id="s3.4"> 3.4   Changes of Agreement </h4>
+
+<p>
+CAcert may from time to time vary the terms of this Agreement.
+Changes will be done according to the documented CAcert policy
+for changing policies, and is subject to scrutiny and feedback
+by the Community.
+Changes will be notified to you by email to your primary address.
+</p>
+
+<p>
+If you do not agree to the changes, you may terminate as above.
+Continued use of the service shall be deemed to be agreement
+by you.
+</p>
+
+<h4 id="s3.5"> 3.5   Communication </h4>
+
+<p>
+Notifications to CAcert are to be sent by
+email to the address
+<b>support</b> <i>at</i> CAcert.org.
+You should attach a digital signature,
+but need not do so in the event of security
+or similar urgency.
+</p>
+
+<p>
+Notifications to you are sent
+by CAcert to the primary email address
+registered with your account.
+You are responsible for keeping your email
+account in good working order and able
+to receive emails from CAcert.
+</p>
+
+<p>
+Arbitration is generally conducted by email.
+</p>
+
+<h3 id="s4"> 4.  Miscellaneous </h3>
+
+<h4 id="s4.1"> 4.1   Other Parties Within the Community </h4>
+
+<p>
+As well as you and other Members in the Community,
+CAcert forms agreements with third party
+vendors and others.
+Thus, such parties will also be in the Community.
+Such agreements are also controlled by the same
+policy process as this agreement, and they should
+mirror and reinforce these terms.
+</p>
+
+
+<h4 id="s4.2"> 4.2   References and Other Binding Documents </h4>
+
+<p>
+This agreement is CAcert Official Document 9 (COD9)
+and is a controlled document.
+</p>
+
+<p>
+You are also bound by
+</p>
+
+<ol><li>
+    <a href="https://www.cacert.org/policy/CertificationPracticeStatement.html">
+    Certification Practice Statement</a> (CPS =&gt; COD6).
+  </li><li>
+    <a href="https://www.cacert.org/policy/DisputeResolutionPolicy.html">
+    Dispute Resolution Policy</a> (DRP =&gt; COD7).
+  </li><li>
+    <a href="https://www.cacert.org/policy/PrivacyPolicy.html">
+    Privacy Policy</a> (PP =&gt; COD5).
+  </li><li>
+    <a href="https://svn.cacert.org/CAcert/principles.html">
+    Principles of the Community</a>.
+</li></ol>
+
+<p>
+Where documents are referred to as <i>=&gt; COD x</i>,
+they are controlled documents
+under the control of Policy on Policies (COD1).
+</p>
+
+<p>
+This agreement and controlled documents above are primary,
+and may not be replaced or waived except
+by formal policy channels and by Arbitration.
+</p>
+
+<h4 id="s4.3"> 4.3   Informative References </h4>
+
+<p>
+The governing documents are in English.
+Documents may be translated for convenience.
+Because we cannot control the legal effect of translations,
+the English documents are the ruling ones.
+</p>
+
+<p>
+You are encouraged to be familiar with the
+Assurer Handbook,
+which provides a more readable introduction for much of
+the information needed.
+The Handbook is not however an agreement, and is overruled
+by this agreement and others listed above.
+</p>
+
+<h4 id="s4.4"> 4.4   Not Covered in this Agreement </h4>
+
+<p>
+<b>Intellectual Property.</b>
+This Licence does not transfer any intellectual
+property rights ("IPR") to you.  CAcert asserts and
+maintains its IPR over its roots, issued certificates,
+brands, logos and other assets.
+Note that the certificates issued to you
+are CAcert's intellectual property
+and you do not have rights other than those stated.
+</p>
+<p><a href="http://validator.w3.org/check?uri=referer"><img src="images/valid-html50-blue.png" alt="Valid HTML 5" height="31" width="88"></a></p>
+</body>
+</html>
diff --git a/www/policy/CAcertCommunityAgreement.php b/www/policy/CAcertCommunityAgreement.php
index 17065f1..e730593 100644
--- a/www/policy/CAcertCommunityAgreement.php
+++ b/www/policy/CAcertCommunityAgreement.php
@@ -1,593 +1,4 @@
-<?='<?xml version="1.0" encoding="utf-8"?>'?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
-        "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
- <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" />
- <title> CAcert Community Agreement </title>
-<style type="text/css">
-<!--
-.comment {
-        color : steelblue;
-}
-.first-does-not-work {
-        color : red;
-}
-.q {
-        color : green;
-        font-weight: bold;
-        text-align: center;
-        font-style:italic;
-}
-.change {
-        color : blue;
-        font-weight: bold;
-}
-.change2 {
-        color : blue;
-		font-weight: bold;
-}
-.change3 {
-        color : blue;
-		font-weight: bold;
-}
-.change4 {
-        color : blue;
-	font-weight: bold;
-}
-.change5 {
-        color : blue;
-	font-weight: bold;
-}
-.change6 {
-        color : blue;
-	font-weight: bold;
-}
-.change7 {
-        color : blue ;
-	font-weight: bold;
-}
-.change8 {
-        color : blue;
-	font-weight: bold;
-}
-.change9 {
-        color : blue;
-	font-weight: bold;
-}
-.change10 {
-        color : blue;
-	font-weight: bold;
-}
-.change11 {
-        color : blue;
-	font-weight: bold;
-}
-.change12 {
-        color : blue;
-	font-weight: bold;
-}
-.change13 {
-        color : blue;
-	font-weight: bold;
-}
-.strike {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike2 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike4 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike5 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike6 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike7 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike8 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike9 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike10 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike11 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike12 {
-        color : blue;
-        text-decoration:line-through;
-}
-.strike13 {
-        color : blue;
-        text-decoration:line-through;
-}
--->
-</style>
-
-</head>
-<body>
-
-	<div class="comment">
-	<table width="100%">
-	
-	<tr>
-	<td rowspan="2">
-	  Name: CCA <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD9</a><br />
-	  Status: POLICY <a style="color: steelblue" href="https://wiki.cacert.org/PolicyDecisions#p20080109.1_CCA_to_POLICY_status">p20080109.1</a><br />
-	  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="draftadd">DRAFT  <a style="color: steelblue" href="https://wiki.cacert.org/PolicyDecisions#p20140709_CCA_update_to_DRAFT">p20140709</a></span> <br />
-	  Editor: <a style="color: steelblue" href="https://wiki.cacert.org/Community/HomePagesMembers/BenediktHeintel">Benedikt</a><br />
-	  Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a><br />
-	
-	</td>
-	<td valign="top" align="right">
-	  <a href="https://www.cacert.org/policy/PolicyOnPolicy.php"><img src="images/cacert-policy.png" alt="CCA Status - POLICY" height="31" width="88" style="border-style: none;" /></a>
-	
-	<!-- XXXXXXXXXXXXXX delete this going to POLICY -->
-	<br />
-	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php"><img src="images/cacert-draft.png" alt="CCA Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
-	
-	</td>
-	</tr>
-	</table>
-	</div>
-
-  <h2>CAcert Community Agreement</h2>
-
-  <h3><a name="0">0.</a> Introduction</h3>
-
-  <p>This agreement is between you, being a registered member ("Member") within
-  CAcert's community at large ("Community") and CAcert Incorporated ("CAcert"),
-  being an operator of services to the Community.</p>
-
-  <h4><a name="0.1">0.1</a> Terms</h4>
-
-  <ol>
-    <li>"CAcert" means CAcert Inc., a non-profit Association of Members
-    incorporated in New South Wales, Australia. Note that Association Members
-    are distinct from the Members defined here.</li>
-
-    <li>"Member" means you, a registered participant within CAcert's Community,
-    with an account on the website and the facility to request certificates.
-    Members may be individuals ("natural persons") or organisations ("legal
-    persons").</li>
-
-    <li>"Organisation" is defined under the Organisation Assurance programme,
-    and generally includes corporations and other entities that become Members
-    and become Assured.</li>
-
-    <li>"Community" means all of the Members that are registered by this
-    agreement and other parties by other agreements, all being under CAcert's
-    Arbitration.</li>
-
-    <li>"Non-Related Person" ("NRP"), being someone who is not a Member, is not
-    part of the Community, and has not registered their agreement. <span class=
-    "strike7">Such people are offered the NRP-DaL another agreement allowing
-    the USE of certificates.</span></li>
-
-    <li><span class="strike7">"Non-Related Persons - Disclaimer and Licence"
-    ("NRP-DaL"), another agreement that is offered to persons outside the
-    Community.</span><span class="change7">(withdrawn)</span></li>
-
-    <li>"Arbitration" is the Community's forum for resolving disputes, or
-    jurisdiction.</li>
-
-    <li>"Dispute Resolution Policy" ("DRP" =&gt; COD7) is the policy and rules
-    for resolving disputes.</li>
-
-    <li>"USE" means the act by your software to conduct its tasks,
-    incorporating the certificates according to software procedures.</li>
-
-    <li>"RELY" means your human act in taking on a risk and liability on the
-    basis of the claim(s) bound within a certificate.</li>
-
-    <li>"OFFER" means the your act of making available your certificate to
-    another person. Generally, you install and configure your software to act
-    as your agent and facilite this and other tasks. OFFER does not imply
-    suggestion of reliance.</li>
-
-    <li>"Issue" means creation of a certificate by CAcert. To create a
-    certificate, CAcert affixes a digital signature from the root onto a public
-    key and other information. This act would generally bind a statement or
-    claim, such as your name, to your key.</li>
-
-    <li>"Root" means CAcert's top level key, used for signing certificates for
-    Members. In this document, the term includes any subroots.</li>
-
-    <li>"CAcert Official Document" ("COD" <span class="strike4">=&gt;
-    COD3</span>) <span class="strike4">in a standard format for describing the
-    details of operation and governance essential to a certificate authority.
-    Changes are managed and controlled. CODs define more technical terms. See
-    4.2 for listing of relevant CODs.</span> <span class="change4">is an
-    official managed and controlled document (e. g. a Policy) of
-    CAcert.</span></li>
-
-    <li>"Certification Practice Statement" ("CPS" =&gt; COD6) is the document
-    that controls details about operational matters within CAcert.</li>
-  </ol>
-
-  <h3><a name="1">1.</a> Agreement and Licence</h3>
-
-  <h4><a name="1.1">1.1</a> Agreement</h4>
-
-  <p>You <span class="strike">and CAcert both</span> agree to the terms and
-  conditions in this agreement. Your agreement is given by <span class=
-  "change2">but not limited to</span> <span class="strike2">any of</span></p>
-
-  <ul>
-    <li>your signature on a form to request assurance of identity ("CAP"
-    form),</li>
-
-    <li>your request on the website to join the Community and create an
-    account,</li>
-
-    <li>your request for Organisation Assurance,</li>
-
-    <li>your request for issuing of certificates, or</li>
-
-    <li>if you USE, RELY, or OFFER any certificate issued to you.</li>
-  </ul>
-
-  <p>Your agreement is effective from the date of the first event above that
-  makes this agreement known to you. This Agreement replaces and <span class=
-  "strike2">supercedes prior agreements, including the NRP-DaL.</span>
-  <span class="change2">supersedes any prior agreements.</span></p>
-
-  <h4><a name="1.2">1.2</a> Licence</h4>
-
-  <p>As part of the Community, CAcert offers you these rights:</p>
-
-  <ol>
-    <li>You may USE any certificates issued by CAcert.</li>
-
-    <li>You may RELY on any certificate issued by CAcert, as explained and
-    limited by CPS (COD6).</li>
-
-    <li>You may OFFER certificates issued to you by CAcert to Members for their
-    RELIANCE.</li>
-
-    <li>You may OFFER certificates issued to you by CAcert to NRPs for their
-    USE, within the general principles of the Community.</li>
-
-    <li>This Licence is free of cost, non-exclusive, and
-    non-transferrable.</li>
-  </ol>
-
-  <h4><a name="1.3">1.3</a> Your Contributions</h4>
-
-  <p>You agree to a non-exclusive non-restrictive non-revokable transfer of
-  Licence to CAcert for your contributions. That is, if you post an idea or
-  comment on a CAcert forum, or email it to other Members, your work can be
-  used freely by the Community for CAcert purposes, including placing under
-  CAcert's licences for wider publication.</p>
-
-  <p>You retain authorship rights, and the rights to also transfer
-  non-exclusive rights to other parties. That is, you can still use your ideas
-  and contributions outside the Community.</p>
-
-  <p>Note that the following exceptions override this clause:</p>
-
-  <ol>
-    <li>Contributions to controlled documents are subject to Policy on Policy
-    ("PoP" =&gt; COD1)</li>
-
-    <li>Source code is subject to an open source licence regime.</li>
-
-    <li><span class="change">Personal data</span></li>
-
-    <li><span class="change">Postings under competing licenses if clearly
-    stated when posted</span></li>
-  </ol>
-
-  <h4><a name="1.4">1.4</a> Privacy</h4>
-
-  <p>You give rights to CAcert to store, verify and
-  process and publish your data in accordance with policies in force. These
-  rights include shipping the data to foreign countries for system
-  administration, support and processing purposes. Such shipping will only be
-  done among CAcert Community administrators and Assurers.</p>
-
-  <p>Privacy is further covered in the Privacy Policy ("PP" =&gt; COD5).</p>
-
-  <h3><a name="2">2.</a> Your Risks, Liabilities and Obligations</h3>
-
-  <p>As a Member, you have risks, liabilities and obligations within this agreement.</p>
-
-  <h4><a name="2.1">2.1</a> Risks</h4>
-
-  <ol>
-    <li>A certificate may prove unreliable.</li>
-
-    <li>Your account, keys or other security tools may be
-    lost or otherwise compromised.</li>
-
-    <li>You may find yourself subject to Arbitration (DRP
-    =&gt; COD7).</li>
-  </ol>
-
-  <h4><a name="2.2">2.2</a> Liabilities</h4>
-
-  <ol>
-    <li>You are liable for any penalties as awarded
-    against you by the Arbitrator.</li>
-
-    <li>Remedies are as defined in the DRP (COD7). An
-    Arbitrator's ruling may include monetary amounts, awarded against
-    you.</li>
-
-    <li>Your liability is limited to a total maximum of
-    <b>1000 Euros</b>.</li>
-
-    <li>"Foreign Courts" may assert jurisdiction. These
-    include your local courts, and are outside our Arbitration. Foreign Courts
-    will generally refer to the Arbitration Act of their country, which will
-    generally refer civil cases to Arbitration. The Arbitration Act will not
-    apply to criminal cases.</li>
-  </ol>
-
-  <h4><a name="2.3">2.3</a> Obligations</h4>
-
-  <p>You are obliged</p>
-
-  <ol>
-    <li>to provide accurate information as part of
-    Assurance. You give permission for verification of the information using
-    CAcert-approved methods.</li>
-
-    <li>to make no false representations.</li>
-
-    <li>to submit all your disputes to Arbitration (DRP
-    =&gt; COD7).</li>
-
-    <li><span class="change">to assist the Arbitrator by truthfully providing
-    information, or with any other reasonable request.</span></li>
-
-    <li><span class="change7">to not share your CAcert account.</span></li>
-  </ol>
-
-  <h4><a name="2.4">2.4</a> Principles</h4>
-
-  <p>As a Member of CAcert, you are a member of the Community. You are further
-  obliged to work within the spirit of the Principles of the Community. These
-  are described in <a href=
-  "http://svn.cacert.org/CAcert/principles.html">Principles of the
-  Community</a>.</p>
-
-  <h4><a name="2.5">2.5</a> Security</h4>
-
-  <p>CAcert exists to help you to secure yourself. You are primarily
-  responsible for your own security. Your security obligations include</p>
-
-  <ol>
-    <li>to secure yourself and your computing platform (e. g. PC),</li>
-
-    <li>to keep your email account in good working order,</li>
-
-    <li>to secure your CAcert account (e. g., credentials such as username,
-    password),</li>
-
-    <li>to secure your private keys, <span class="change8">ensuring that they
-    are only used as indicated by the certificate, or by wider agreement with
-    others,</span></li>
-
-    <li>to review certificates for accuracy, and</li>
-
-    <li>when in doubt, notify CAcert,</li>
-
-    <li>when in doubt, take other reasonable actions, such as revoking
-    certificates, changing account credentials, and/or generating new
-    keys.</li>
-  </ol>
-
-  <p>Where, above, 'secure' means to protect to a reasonable degree, in
-  proportion with your risks and the risks of others.</p>
-
-  <h3><a name="3">3.</a> Law and Jurisdiction</h3>
-
-  <h4><a name="3.1">3.1</a> Governing Law</h4>
-
-  <p>This agreement is governed under the law of New South Wales, Australia,
-  being the home of the CAcert Inc. Association.</p>
-
-  <h4><a name="3.2">3.2</a> Arbitration as Forum of Dispute Resolution</h4>
-
-  <p>You agree, with CAcert and all of the Community, that all disputes arising
-  out of or in connection to our use of CAcert services shall be referred to
-  and finally resolved by Arbitration under the rules within the Dispute
-  Resolution Policy of CAcert (DRP =&gt; COD7). The rules select a single
-  Arbitrator chosen by CAcert from among senior Members in the Community. The
-  ruling of the Arbitrator is binding and final on Members and CAcert
-  alike.</p>
-
-  <p>In general, the jurisdiction for resolution of disputes is within CAcert's
-  own forum of Arbitration, as defined and controlled by its own rules (DRP
-  =&gt; COD7).</p>
-
-  <p>We use Arbitration for many purposes beyond the strict nature of disputes,
-  such as governance and oversight. A systems administrator may need
-  authorisation to conduct a non-routine action, and Arbitration may provide
-  that authorisation. Thus, you may find yourself party to Arbitration that is
-  simply support actions, and you may file disputes in order to initiate
-  support actions.</p>
-
-  <h4><a name="3.3">3.3</a> Termination</h4>
-
-  <p><span class="strike12">You may terminate this agreement by resigning from
-  CAcert. You may do this at any time by writing to CAcert's online support
-  forum and filing dispute to resign. All services will be terminated, and your
-  certificates will be revoked. However, some information will continue to be
-  held for certificate processing purposes.</span></p>
-
-  <p><span class="strike12">The provisions on Arbitration survive any
-  termination by you by leaving CAcert. That is, even if you resign from
-  CAcert, you are still bound by the DRP (COD7), and the Arbitrator may
-  reinstate any provision of this agreement or bind you to a ruling.</span></p>
-
-  <p><span class="strike12">Only the Arbitrator may terminate this agreement
-  with you.</span></p>
-
-  <p><span class="change12">The CAcert Community Agreement is
-  terminated</span></p>
-
-  <ol>
-    <li><span class="change12">based on a Policy Group decision following (PoP
-    =&gt; COD1). This terminates the Agreement with every member.</span></li>
-
-    <li><span class="change12">with a ruling of the Arbitrator or the
-    completion of a termination process defined by an Arbitrator ruling (DRP
-    =&gt; COD7).</span></li>
-
-    <li><span class="change12">by the end of existence of a member (i.e. death
-    in the case of individuals).</span></li>
-  </ol>
-
-  <p><span class="change12">A member may declare the wish to resign from CAcert
-  at any time by writing to <em>support AT cacert.org</em>. This triggers a
-  process for termination of this agreement with the member.</span></p>
-
-  <h4><span class="change12"><a name="3.3">3.3a</a> Consequences of
-  Termination</span></h4>
-
-  <p><span class="change12">The termination discontinues the right to USE,
-  OFFER and CREATE personal certificates in any account of the former member.
-  Those certificates will be revoked and all services to the former member will
-  be terminated as soon as possible. However, some information will continue to
-  be held for certificate processing purposes.</span></p>
-
-  <p><span class="change12">The provisions on Arbitration for the time of
-  membership survive any termination. Former members are still bound by the DRP
-  (COD7), and the Arbitrator may reinstate any provision of this agreement or
-  bind them to a ruling.</span></p>
-
-  <p><span class="change12">As far as Organisations are concerned details are
-  also defined in the Organisation Assurance Policy (OAP =&gt;
-  COD11).</span></p>
-
-  <p><span class="change12">Every member learning about the death of a member
-  or termination of existence of a member should notify <em>support AT
-  cacert.org</em>.</span></p>
-
-  <h4><a name="3.4">3.4</a> Changes of Agreement</h4>
-
-  <p>CAcert may from time to time vary the terms of this Agreement. Changes
-  will be done according to the documented CAcert policy for changing policies,
-  and is subject to scrutiny and feedback by the Community. Changes will be
-  notified to you by email to your primary address.</p>
-
-  <p>If you do not agree to the changes, you may terminate as above. Continued
-  use of the service shall be deemed to be agreement by you.</p>
-
-  <h4><a name="3.5">3.5</a> Communication</h4>
-
-  <p><span class="change6">You are responsible for keeping your primary email
-  account in good working order and able to receive emails from
-  CAcert.</span></p>
-
-  <p>Notifications to CAcert are to be sent by email to the address <em>support
-  AT cacert.org</em>. You should attach a digital signature<span class=
-  "strike6">, but need not do so in the event of security or similar
-  urgency</span>.</p>
-
-  <p><span class="strike6">Notifications to you are sent by CAcert to the
-  primary email address registered with your account. You are responsible for
-  keeping your email account in good working order and able to receive emails
-  from CAcert.</span></p>
-
-  <p><span class="strike6">Arbitration is generally conducted by
-  email.</span></p>
-
-  <h3><a name="4">4.</a> Miscellaneous</h3>
-
-  <h4><a name="4.1">4.1</a> <span class="strike10">Other Parties Within the
-  Community</span> <span class="change10">(withdrawn)</span></h4>
-
-  <p class="strike10">As well as you and other Members in the Community, CAcert
-  forms agreements with third party vendors and others. Thus, such parties will
-  also be in the Community. Such agreements are also controlled by the same
-  policy process as this agreement, and they should mirror and reinforce these
-  terms.</p>
-
-  <h4><a name="4.2">4.2</a> References and Other Binding Documents</h4>
-
-  <p class="strike11">This agreement is CAcert Official Document 9 (COD9) and
-  is a controlled document.</p>
-
-  <p>You are also bound by <span class="change11">the Policies of the Community
-  under the control of Policy on Policy ("PoP" =&gt; COD1) and listed in
-  <a href=
-  "https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">Controlled
-  Document List</a>.</span></p>
-
-  <ol>
-    <li><span class="strike11"><a href=
-    "http://www.cacert.org/policy/CertificationPracticeStatement.php">Certification
-    Practice Statement</a> (CPS =&gt; COD6).</span></li>
-
-    <li><span class="strike11"><a href=
-    "http://www.cacert.org/policy/DisputeResolutionPolicy.php">Dispute
-    Resolution Policy</a> (DRP =&gt; COD7).</span></li>
-
-    <li><span class="strike11"><a href="PrivacyPolicy.html">Privacy Policy</a>
-    (PP =&gt; COD5).</span></li>
-
-    <li><span class="strike11"><a href=
-    "http://svn.cacert.org/CAcert/principles.html">Principles of the
-    Community</a>.</span></li>
-  </ol>
-
-  <p class="strike11">Where documents are referred to as <i>=&gt; COD x</i>,
-  they are controlled documents under the control of Policy on Policies
-  (COD1).</p>
-
-  <p class="strike11">This agreement and controlled documents above are
-  primary, and may not be replaced or waived except by formal policy channels
-  and by Arbitration.</p>
-
-  <p class="change11">Controlled documents are primary, and may not be replaced
-  or waived except by formal policy channels and Arbitration.</p>
-
-  <p class="change11">This agreement is controlled document COD9.</p>
-
-  <h4><a name="4.3">4.3</a> Informative References</h4>
-
-  <p>The governing documents are in English. Documents may be translated for
-  convenience. Because we cannot control the legal effect of translations, the
-  English documents are the ruling ones.</p>
-
-  <p class="strike9">You are encouraged to be familiar with the Assurer
-  Handbook, which provides a more readable introduction for much of the
-  information needed. The Handbook is not however an agreement, and is
-  overruled by this agreement and others listed above.</p>
-
-  <p class="change9">Beside this Agreement and the Policies, there are other
-  documents, i. e. Policy Guides, Manuals and Handbooks, supporting and
-  explaining this Agreement and the Policies. These documents are not binding
-  and in doubt this Agreement and the Policies are valid.</p>
-
-  <h4><a name="4.4">4.4</a> <span class="strike9">Not Covered in this
-  Agreement</span> <span class="change9">(withdrawn)</span></h4>
-
-  <p class="strike9"><b>Intellectual Property.</b> This Licence does not
-  transfer any intellectual property rights ("IPR") to you. CAcert asserts and
-  maintains its IPR over its roots, issued certificates, brands, logos and
-  other assets. Note that the certificates issued to you are CAcert's
-  intellectual property and you do not have rights other than those stated.</p>
-</body>
-</html>
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: CAcertCommunityAgreement.html');
+exit();
diff --git a/www/policy/CertificationPracticeStatement.html b/www/policy/CertificationPracticeStatement.html
new file mode 100644
index 0000000..334a63e
--- /dev/null
+++ b/www/policy/CertificationPracticeStatement.html
@@ -0,0 +1,4698 @@
+<!DOCTYPE html>
+<html>
+<head>
+    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+    <title>Certification Practice Statement (CPS)</title>
+    <style type="text/css">
+    <!--
+    body {
+        font-family : verdana, helvetica, arial, sans-serif;
+    }
+    .comment {
+        color : steelblue;
+    }
+    .figure {
+        text-align : center;
+        color : gray;
+        margin-top : 0.5em;
+    }
+
+    a:hover {
+        color : gray;
+    }
+    -->
+    </style>
+</head>
+<body>
+
+<h1>CAcert CPS and CP</h1>
+<div class="comment">
+<table width="100%">
+<tbody>
+<tr>
+<td rowspan="2">
+   Name: CPS <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD6</a>
+<br>
+   Creation Date : 20060726, drafted at 20091108
+<br>
+   Editor: NN
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+<img src="images/cacert-policy.png" alt="CPS Status - POLICY" style="border-style: none;" height="31" width="88">
+</a>
+    </td>
+ </tr>
+</tbody>
+</table>
+</div>
+
+
+<font size="-1">
+
+<ol>
+
+<li> <a href="#p1">INTRODUCTION</a>
+
+<ul>
+
+<li><a href="#p1.1">1.1. Overview</a></li>
+
+<li><a href="#p1.2">1.2. Document name and identification</a></li>
+
+<li><a href="#p1.3">1.3. PKI participants</a> </li>
+
+<li><a href="#p1.4">1.4. Certificate usage</a> </li>
+
+<li><a href="#p1.5">1.5. Policy administration</a> </li>
+
+<li><a href="#p1.6">1.6. Definitions and acronyms</a></li>
+   </ul>
+  </li>
+
+<li> <a href="#p2">PUBLICATION AND REPOSITORY RESPONSIBILITIES</a>
+
+<ul>
+
+<li><a href="#p2.1">2.1. Repositories</a></li>
+
+<li><a href="#p2.2">2.2. Publication of certification information</a></li>
+
+<li><a href="#p2.3">2.3. Time or frequency of publication</a></li>
+
+<li><a href="#p2.4">2.4. Access controls on repositories</a></li>
+   </ul>
+  </li>
+
+<li> <a href="#p3">IDENTIFICATION AND AUTHENTICATION (I&amp;A)</a>
+
+<ul>
+
+<li><a href="#p3.1">3.1. Naming</a> </li>
+
+<li><a href="#p3.2">3.2. Initial Identity Verification</a> </li>
+
+<li><a href="#p3.3">3.3. I&amp;A for Re-key Requests</a> </li>
+
+<li><a href="#p3.4">3.4. I&amp;A for Revocation Request</a></li>
+   </ul>
+  </li>
+
+<li><a href="#p4">CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a>
+
+<ul>
+
+<li><a href="#p4.1">4.1. Certificate Application</a> </li>
+
+<li><a href="#p4.2">4.2. Certificate application processing</a> </li>
+
+<li><a href="#p4.3">4.3. Certificate issuance</a> </li>
+
+<li><a href="#p4.4">4.4. Certificate acceptance</a> </li>
+
+<li><a href="#p4.5">4.5. Key pair and certificate usage</a> </li>
+
+<li><a href="#p4.6">4.6. Certificate renewal</a> </li>
+
+<li><a href="#p4.7">4.7. Certificate re-key</a> </li>
+
+<li><a href="#p4.8">4.8. Certificate modification</a> </li>
+
+<li><a href="#p4.9">4.9. Certificate revocation and suspension</a> </li>
+
+<li><a href="#p4.10">4.10. Certificate status services</a> </li>
+
+<li><a href="#p4.11">4.11. End of subscription</a></li>
+
+<li><a href="#p4.12">4.12. Key escrow and recovery</a> </li>
+   </ul>
+  </li>
+
+<li><a href="#p5">FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a>
+
+<ul>
+
+<li><a href="#p5.1">5.1. Physical controls</a> </li>
+
+<li><a href="#p5.2">5.2. Procedural controls</a> </li>
+
+<li><a href="#p5.3">5.3. Personnel controls</a> </li>
+
+<li><a href="#p5.4">5.4. Audit logging procedures</a> </li>
+
+<li><a href="#p5.5">5.5. Records archival</a> </li>
+
+<li><a href="#p5.6">5.6. Key changeover</a></li>
+
+<li><a href="#p5.7">5.7. Compromise and disaster recovery</a> </li>
+
+<li><a href="#p5.8">5.8. CA or RA termination</a></li>
+   </ul>
+  </li>
+
+<li><a href="#p6">TECHNICAL SECURITY CONTROLS</a>
+
+<ul>
+
+<li><a href="#p6.1">6.1. Key pair generation and installation</a> </li>
+
+<li><a href="#p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a> </li>
+
+<li><a href="#p6.3">6.3. Other aspects of key pair management</a> </li>
+
+<li><a href="#p6.4">6.4. Activation data</a> </li>
+
+<li><a href="#p6.5">6.5. Computer security controls</a> </li>
+
+<li><a href="#p6.6">6.6. Life cycle technical controls</a> </li>
+
+<li><a href="#p6.7">6.7. Network security controls</a></li>
+
+<li><a href="#p6.8">6.8. Time-stamping</a></li>
+   </ul>
+  </li>
+
+<li><a href="#p7">CERTIFICATE, CRL, AND OCSP PROFILES</a>
+
+<ul>
+
+<li><a href="#p7.1">7.1. Certificate profile</a> </li>
+
+<li><a href="#p7.2">7.2. CRL profile</a> </li>
+
+<li><a href="#p7.3">7.3. OCSP profile</a> </li>
+   </ul>
+  </li>
+
+<li><a href="#p8">COMPLIANCE AUDIT AND OTHER ASSESSMENTS</a>
+
+<ul>
+
+<li><a href="#p8.1">8.1. Frequency or circumstances of assessment</a></li>
+
+<li><a href="#p8.2">8.2. Identity/qualifications of assessor</a></li>
+
+<li><a href="#p8.3">8.3. Assessor's relationship to assessed entity</a></li>
+
+<li><a href="#p8.4">8.4. Topics covered by assessment</a></li>
+
+<li><a href="#p8.5">8.5. Actions taken as a result of deficiency</a></li>
+
+<li><a href="#p8.6">8.6. Communication of results</a></li>
+   </ul>
+  </li>
+
+<li><a href="#p9">OTHER BUSINESS AND LEGAL MATTERS</a>
+
+<ul>
+
+<li><a href="#p9.1">9.1. Fees</a> </li>
+
+<li><a href="#p9.2">9.2. Financial responsibility</a> </li>
+
+<li><a href="#p9.3">9.3. Confidentiality of business information</a> </li>
+
+<li><a href="#p9.4">9.4. Privacy of personal information</a> </li>
+
+<li><a href="#p9.5">9.5. Intellectual property rights</a></li>
+
+<li><a href="#p9.6">9.6. Representations and warranties</a> </li>
+
+<li><a href="#p9.7">9.7. Disclaimers of warranties</a></li>
+
+<li><a href="#p9.8">9.8. Limitations of liability</a></li>
+
+<li><a href="#p9.9">9.9. Indemnities</a></li>
+
+<li><a href="#p9.10">9.10. Term and termination</a> </li>
+
+<li><a href="#p9.11">9.11. Individual notices and communications with participants</a></li>
+
+<li><a href="#p9.12">9.12. Amendments</a> </li>
+
+<li><a href="#p9.13">9.13. Dispute resolution provisions</a></li>
+
+<li><a href="#p9.14">9.14. Governing law</a></li>
+
+<li><a href="#p9.15">9.15. Compliance with applicable law</a></li>
+
+<li><a href="#p9.16">9.16. Miscellaneous provisions</a> </li>
+   </ul>
+  </li>
+</ol>
+
+</font>
+
+
+
+<!-- *************************************************************** -->
+<h2 id="p1">1. INTRODUCTION</h2>
+
+<h3 id="p1.1">1.1. Overview</h3>
+
+<p>
+This document is the Certification Practice Statement (CPS) of
+CAcert, the Community Certification Authority (CA).
+It describes rules and procedures used by CAcert for
+operating its CA,
+and applies to all CAcert PKI Participants,
+including Assurers, Members, and CAcert itself.
+</p>
+
+<p>
+</p>
+
+<h3 id="p1.2">1.2. Document name and identification</h3>
+
+<p>
+This document is the Certification Practice Statement (CPS) of CAcert.
+The CPS also fulfills the role of the Certificate Policy (CP)
+for each class of certificate.
+</p>
+
+<ul>
+
+<li>
+    This document is COD6 under CAcert Official Documents numbering scheme.
+  </li>
+
+<li>
+    The document is structured according to
+    Chokhani, et al,
+    <a href="http://www.ietf.org/rfc/rfc3647.txt">RFC3647</a>,
+    <a href="http://tools.ietf.org/html/rfc3647#section-4">chapter 4</a>.
+    All headings derive from that Chapter.
+  </li>
+
+<li>
+    It has been improved and reviewed (or will be reviewed)
+    to meet or exceed the criteria of the
+    <cite>Certificate Authority Review Checklist</cite>
+    from <i>David E. Ross</i> ("DRC")
+    and Mozilla Foundation's CA policy.
+  </li>
+
+<li>
+    OID assigned to this document: 1.3.6.1.4.1.18506.4.4.x (x=approved Version)
+    (<a href="http://www.iana.org/assignments/enterprise-numbers">iana.org</a>)
+
+  </li>
+
+<li>
+    © CAcert Inc. 2006-2009.
+    <!-- note that CCS policies must be controlled by CAcert Inc. -->
+  </li>
+
+
+<li>
+    Earlier notes were written by Christian Barmala
+    in a document placed under GNU Free Document License
+    and under FSF copyright.
+    However this clashed with the control provisions of
+    Configuration-Control Specification
+    (COD2) within Audit criteria.
+  </li>
+</ul>
+
+<p>
+The CPS is an authoritive document,
+and rules other documents
+except where explicitly deferred to.
+See also <a href="#p1.5.1">1.5.1 Organisation Administering the Document</a>.
+</p>
+
+<h3 id="p1.3">1.3. PKI participants</h3>
+<p>
+The CA is legally operated by CAcert Incorporated,
+an Association registered in 2002 in
+New South Wales, Australia,
+on behalf of the wider Community of Members of CAcert.
+The Association details are at the
+<a href="http://wiki.cacert.org/wiki/CAcertIncorporated">CAcert wiki</a>.
+</p>
+
+<p>
+CAcert is a Community formed of Members who agree to the
+<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">
+CAcert Community Agreement</a>.
+The CA is technically operated by the Community,
+under the direction of the Board of CAcert Incorporated.
+(The Members of the Community are not to be confused
+with the <i>Association Members</i>, which latter are
+not referred to anywhere in this CPS.)
+</p>
+
+<h4 id="p1.3.1">1.3.1. Certification authorities</h4>
+<p>
+CAcert does not issue certificates to external
+intermediate CAs under the present CPS.
+</p>
+
+<h4 id="p1.3.2">1.3.2. Registration authorities</h4>
+<p>
+Registration Authorities (RAs) are controlled under Assurance Policy
+(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
+</p>
+
+<h4 id="p1.3.3">1.3.3. Subscribers</h4>
+
+<p>
+CAcert issues certificates to Members only.
+Such Members then become Subscribers.
+</p>
+
+
+<h4 id="p1.3.4">1.3.4. Relying parties</h4>
+
+<p>
+A relying party is a Member,
+having agreed to the
+CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
+who, in the act of using a CAcert certificate,
+makes a decision on the basis of that certificate.
+</p>
+
+<h4 id="p1.3.5">1.3.5. Other participants</h4>
+
+<p>
+<b>Member.</b>
+Membership of the Community is as defined in the
+<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>.
+Only Members may RELY or may become Subscribers.
+Membership is free.
+</p>
+
+<p>
+<b>Arbitrator.</b>
+A senior and experienced Member of the CAcert Community
+who resolves disputes between Members, including ones
+of certificate reliance, under
+Dispute Resolution Policy
+(<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>).
+</p>
+
+<p>
+<b>Vendor.</b>
+Software suppliers who integrate the root certificates of CAcert
+into their software also assume a proxy role of Relying Parties,
+and are subject to another licence.
+</p>
+
+<p>
+<b>Non-Related Persons</b> (NRPs).
+These are users of browsers and similar software who are
+unaware of the CAcert certificates they may use, and
+are unaware of the ramifications of usage.
+Their relationship with CAcert
+is described by the
+Non-related Persons - Disclaimer and Licence
+(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
+No other rights nor relationship is implied or offered.
+</p>
+
+
+<h3 id="p1.4">1.4. Certificate usage</h3>
+
+<p>CAcert serves as issuer of certificates for
+individuals, businesses, governments, charities,
+associations, churches, schools,
+non-governmental organisations or other groups.
+CAcert certificates are intended for low-cost
+community applications especially where volunteers can
+become Assurers and help CAcert to help the Community.
+</p>
+
+<p>
+Types of certificates and their appropriate and
+corresponding applications are defined in
+<a href="#p1.4.1">§1.4.1</a>.
+Prohibited applications are defined in <a href="#p1.4.2">§1.4.2</a>.
+Specialist uses may be agreed by contract or within
+a specific environment, as described in
+<a href="#p1.4.4">§1.4.4</a>.
+Note also the
+unreliable applications in
+<a href="#p1.4.3">§1.4.3</a>
+and risks, liabilities and obligations in
+<a href="#p9">§9</a>.
+</p>
+
+
+<center>
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<td colspan="2">
+<center><i>Type</i></center>
+</td>
+
+<td colspan="2">
+<center><i>Appropriate Certificate uses</i></center>
+ </td>
+</tr>
+<tr>
+
+<th>General</th>
+
+<th>Protocol</th>
+
+<th>
+<center>Description</center>
+</th>
+
+<th>
+<center>Comments</center>
+</th>
+ </tr>
+<tr>
+
+<td rowspan="2">
+<center>Server</center>
+</td>
+
+<td> TLS </td>
+
+<td> web server encryption </td>
+
+<td> enables encryption </td>
+ </tr>
+<tr>
+
+<td> embedded </td>
+
+<td> embedded server authentication </td>
+
+<td> mail servers, IM-servers </td>
+ </tr>
+<tr>
+
+<td rowspan="4">
+<center>Client</center>
+</td>
+
+<td> S/MIME </td>
+
+<td> email encryption </td>
+
+<td> "digital signatures" employed in S/MIME
+       are not legal / human signatures,
+       but instead enable the encryption mode of S/MIME </td>
+ </tr>
+<tr>
+
+<td> TLS </td>
+
+<td> client authentication </td>
+
+<td> the nodes must be secure </td>
+ </tr>
+<tr>
+
+<td> TLS </td>
+
+<td> web based signature applications </td>
+
+<td> the certificate authenticates only.  See <a href="#p1.4.3">§1.4.3</a>. </td>
+ </tr>
+<tr>
+
+<td> "Digital Signing" </td>
+
+<td> for human signing over documents </td>
+
+<td> Only within a wider application and rules
+       such as by separate policy,
+       as agreed by contract, etc.
+       See <a href="#p1.4.4">§1.4.4</a>.
+       </td>
+ </tr>
+<tr>
+
+<td>
+<center>Code</center>
+</td>
+
+<td> Authenticode, ElfSign, Java </td>
+
+<td> Code Signing </td>
+
+<td> Signatures on packages are evidence of their Membership and indicative of Identity </td>
+ </tr>
+<tr>
+
+<td>
+<center>PGP</center>
+</td>
+
+<td> OpenPGP </td>
+
+<td> Key Signing </td>
+
+<td> Signatures on Member Keys are evidence of their Membership and indicative of Identity </td>
+ </tr>
+<tr>
+
+<td>
+<center>Special</center>
+</td>
+
+<td> X.509 </td>
+
+<td> OCSP, Timestamping </td>
+
+<td> Only available to CAcert Systems Administrators, as controlled by Security Policy </td>
+ </tr>
+</tbody>
+</table>
+
+<span class="figure">Table 1.4.  Types of Certificate</span>
+</center>
+
+<h4 id="p1.4.1">1.4.1. Appropriate certificate uses</h4>
+
+<p>
+General uses.
+</p>
+
+<ul>
+<li>
+    CAcert server certificates can be used to enable encryption
+    protection in web servers.
+    Suitable applications include webmail and chat forums.
+  </li>
+<li>
+    CAcert server certificates can be used to enable encryption
+    in SSL/TLS links in embedded protocols such as mail servers
+    and IM-servers.
+  </li>
+<li>
+    CAcert client certificates can be used to enable encryption
+    protection in email clients.
+    (See <a href="#p1.4.3">§1.4.3</a> for caveat on signatures.)
+  </li>
+<li>
+    CAcert client certificates can be used to replace password-based
+    authentication to web servers.
+  </li>
+<li>
+    OpenPGP keys with CAcert signatures can be used
+    to encrypt and sign files and emails,
+    using software compatible with OpenPGP.
+  </li>
+<li>
+    CAcert client certificates can be used in web-based
+    authentication applications.
+  </li>
+<li>
+    CAcert code signing certificates can be used to sign code
+    for distribution to other people.
+  </li>
+<li>
+    Time stamping can be used to attach a time record
+    to a digital document.
+</li>
+</ul>
+
+
+<h4 id="p1.4.2">1.4.2. Prohibited certificate uses</h4>
+<p>
+CAcert certificates are not designed, intended, or authorised for
+the following applications:
+</p>
+<ul>
+<li>
+    Use or resale as control equipment in hazardous circumstances
+    or for uses requiring fail-safe performance such as the operation
+    of nuclear facilities, aircraft navigation or communication systems,
+    air traffic control systems, or weapons control systems,
+    where failure could lead directly to death, personal injury,
+    or severe environmental damage.
+</li>
+</ul>
+
+<h4 id="p1.4.3">1.4.3. Unreliable Applications</h4>
+
+<p>
+CAcert certificates are not designed nor intended for use in
+the following applications, and may not be reliable enough
+for these applications:
+</p>
+
+<ul>
+<li>
+    <b>Signing within Protocols.</b>
+    Digital signatures made by CAcert certificates carry
+    <u>NO default legal or human meaning</u>.
+    See <a href="#p9.15.1">§9.15.1</a>.
+    Especially, protocols such as S/MIME commonly will automatically
+    apply digital signatures as part of their protocol needs.
+    The purpose of the cryptographic signature in S/MIME
+    and similar protocols is limited by default to strictly
+    protocol security purposes:
+    to provide some confirmation that a familiar certificate
+    is in use, to enable encryption, and to ensure the integrity
+    of the email in transit.
+</li>
+<li>
+    <b>Non-repudiation applications.</b>
+    Non-repudiation is not to be implied from use of
+    CAcert certificates.  Rather, certificates may
+    provide support or evidence of actions, but that
+    evidence is testable in any dispute.
+</li>
+<li>
+    <b>Ecommerce applications.</b>
+    Financial transactions or payments or valuable e-commerce.
+</li>
+<li>
+    Use of anonymous (Class 1 or Member SubRoot) certificates
+    in any application that requires or expects identity.
+</li>
+</ul>
+
+
+<h4 id="p1.4.4">1.4.4. Limited certificate uses</h4>
+
+<p>
+By contract or within a specific environment
+(e.g. internal to a company),
+CAcert Members are permitted to use Certificates
+for higher security, customised or experimental applications.
+Any such usage, however, is limited to such entities
+and these entities take on the whole responsible for
+any harm or liability caused by such usage.
+</p>
+
+<p>
+    <b>Digital signing applications.</b>
+    CAcert client certificates
+    may be used by Assured Members in
+    applications that provide or support the human signing of documents
+    (known here as "digital signing").
+    This must be part of a wider framework and set of rules.
+    Usage and reliance
+    must be documented either under a separate CAcert digital signing
+    policy or other external regime agreed by the parties.
+</p>
+
+<h4 id="p1.4.5">1.4.5. Roots and Names</h4>
+
+<p>
+<b>Named Certificates.</b>
+Assured Members may be issued certificates
+with their verified names in the certificate.  In this role, CAcert
+operates and supports a network of Assurers who verify the
+identity of the Members.
+All Names are verified, either by Assurance or another defined
+method under policy (c.f. Organisations).
+</p>
+
+<p>
+<b>Anonymous Certificates.</b>
+Members can be issued certificates that are anonymous,
+which is defined as the certificate with no Name included,
+or a shared name such as "Community Member".
+These may be considered to be somewhere between Named certificates
+and self-signed certificates.  They have serial numbers in them
+which is ultimately traceable via dispute to a Member, but
+reliance is undefined.
+In this role, CAcert provides the
+infrastructure, saving the Members from managing a difficult
+and messy process in order to get manufactured certificates.
+</p>
+
+<p>
+<b>Psuedonymous Certificates.</b>
+Note that CAcert does not currently issue pseudonymous certificates,
+being those with a name chosen by the Member and not verifiable
+according to documents.
+</p>
+
+<p>
+<b>Advanced Certificates.</b>
+Members who are as yet unassured are not permitted to create
+advanced forms such as wildcard or subjectAltName
+certificates.
+</p>
+
+
+<p>
+<b> Roots.</b>
+The CAcert root layout is as below.
+These roots are pending Audit,
+and will be submitted to vendors via the (Top-level) Root.
+</p>
+<ul>
+<li>
+    <b>(Top-level) Root.</b>
+    Used to sign on-line CAcert SubRoots only.
+    This Root is kept offline.
+  </li>
+<li>
+    <b>Member SubRoot.</b>
+    For Community Members who are new and unassured (some restrictions exist).
+    Reliance is undefined.
+    (Replacement for the Class 1 root, matches "Domain Validation" type.)
+  </li>
+<li>
+    <b>Assured SubRoot.</b>
+    Only available for Assured individual Members,
+    intended to sign certificates with Names.
+    Suitable for Reliance under this and other policies.
+    Approximates the type known as Individual Validation.
+  </li>
+<li>
+    <b>Organisation SubRoot.</b>
+    Only available for Assured Organisation Members.
+    Suitable for Reliance under this and other policies.
+    Approximates the type known as Organisational Validation.
+
+</li>
+</ul>
+
+
+
+<center>
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<td></td>
+
+<td colspan="5">
+<center><i>Level of Assurance</i></center>
+</td>
+
+<th> </th>
+ </tr>
+<tr>
+
+<th></th>
+
+<th colspan="2">
+<center> Members † </center>
+</th>
+
+<th colspan="2">
+<center> Assured Members</center>
+</th>
+
+<th colspan="1">
+<center> Assurers </center>
+</th>
+
+<th colspan="1">
+<center> </center>
+</th>
+ </tr>
+<tr>
+
+<td><i>Class of Root</i></td>
+
+<th>Anon</th>
+
+<td>Name</td>
+
+<td>Anon</td>
+
+<th>Name</th>
+
+<td>Name+Anon</td>
+
+<td colspan="1">
+<center><i>Remarks</i></center>
+</td>
+ </tr>
+<tr>
+
+<td>
+<center>Top level
+<br>
+<big><b>Root</b></big></center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> • </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="green" size="+3"> • </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="green" size="+3"> • </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> • </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> • </font> </center>
+</td>
+
+<td> Signs other CAcert SubRoots only. </td>
+ </tr>
+<tr>
+
+<td>
+<center><big><b>Member</b></big>
+<br>
+SubRoot</center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td> † For Members meeting basic checks in <a href="#p4.2.2">§4.2.2</a>
+<br>
+(Reliance is undefined.) </td>
+ </tr>
+<tr>
+
+<td>
+<center><big><b>Assured</b></big>
+<br>
+SubRoot</center>
+</td>
+
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td> Assured Members only.
+<br>
+Fully intended for reliance. </td>
+ </tr>
+<tr>
+
+<td>
+<center><big><b>Organisation</b></big>
+<br>
+SubRoot</center>
+</td>
+
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td> Assured Organisation Members only.
+<br>
+Fully intended for reliance. </td>
+ </tr>
+<tr>
+
+<th>Expiry of Certificates</th>
+
+<td colspan="2">
+<center>6 months</center>
+  </td>
+<td colspan="3">
+<center>24 months</center>
+ </td>
+</tr>
+<tr>
+
+<th>Types</th>
+
+<td colspan="2">
+<center>client, server</center>
+  </td>
+<td colspan="2">
+<center>wildcard, subjectAltName</center>
+  </td>
+<td colspan="1">
+<center>code-signing</center>
+  </td>
+<td> (Inclusive to the left.) </td>
+ </tr>
+</tbody>
+</table>
+
+<span class="figure">Table 1.4.5.b  Certificate under Audit Roots</span>
+</center>
+
+<center>
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<td></td>
+
+<td colspan="4">
+<center><i>Level of Assurance</i></center>
+</td>
+
+<th> </th>
+ </tr>
+<tr>
+
+<th></th>
+
+<th colspan="2">
+<center>Members</center>
+</th>
+
+<th colspan="2">
+<center>Assured Members</center>
+</th>
+
+<th colspan="1">
+<center> </center>
+</th>
+ </tr>
+<tr>
+
+<td><i>Class of Root</i></td>
+
+<th>Anonymous</th>
+
+<td>Named</td>
+
+<td>Anonymous</td>
+
+<th>Named</th>
+
+<td colspan="1">
+<center><i>Remarks</i></center>
+</td>
+ </tr>
+<tr>
+
+<td>
+<center>Class
+<br>
+<big><b>1</b></big></center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td> Available for all Members,
+<br>
+reliance is undefined.</td>
+ </tr>
+<tr>
+
+<td>
+<center>Class
+<br>
+<big><b>3</b></big></center>
+</td>
+
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+  </td>
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font> </center>
+</td>
+
+<td> Assured Members only.
+<br>
+ Intended for Reliance.  </td>
+ </tr>
+<tr>
+
+<th>Expiry of Certificates</th>
+
+<td colspan="2">
+<center>6 months</center>
+  </td>
+<td colspan="2">
+<center>24 months</center>
+ </td>
+</tr>
+<tr>
+
+<th>Types available</th>
+
+<td colspan="2">
+<center>simple only</center>
+  </td>
+<td colspan="2">
+<center>wildcard, subjectAltName</center>
+ </td>
+</tr>
+</tbody>
+</table>
+
+<span class="figure">Table 1.4.5.  Certificates under Old Roots - <b>Audit Fail</b>  </span>
+</center>
+
+<p>
+<b> Old Roots.</b>
+The old CAcert root layout is as below.  These roots are <b>Audit Fail</b>
+and will only be used where new roots do not serve:
+</p>
+<ul>
+<li>
+    (old) <b>Class 1 root.</b>
+    Used primarily for certificates with no names and by
+    unassured Members.
+    For compatibility only,
+    Assured Members may also use this root.
+  </li>
+<li>
+    (old) <b>Class 3 root.</b>
+    Used primarily for certificates including the names
+    of Assured Members.
+    Signed by Class 1 root.
+    Members can decide to rely on these
+    certificates for Assured Members
+    by selecting the Class 3 root for
+    Assured Members as trust anchor.
+</li>
+</ul>
+
+<h3 id="p1.5">1.5. Policy administration</h3>
+
+<p>See <a href="#p1.2">1.2 Document Name and Identification</a>
+  for general scope of this document.</p>
+
+<h4 id="p1.5.1">1.5.1. Organization administering the document</h4>
+
+<p>
+This document is administered by the policy group of
+the CAcert Community under Policy on Policy (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>).
+</p>
+
+<h4 id="p1.5.2">1.5.2. Contact person</h4>
+<p>
+For questions including about this document:
+</p>
+
+<ul>
+
+<li>Join the policy group, by means of the discussion forum at
+  <a href="http://lists.cacert.org/mailman/listinfo">
+  lists.cacert.org</a> . </li>
+
+<li>Send email to &lt; support AT cacert DOT org &gt; </li>
+
+<li>IRC: irc.cacert.org #CAcert (ssl port 7000, non-ssl port 6667)</li>
+</ul>
+
+<h4 id="p1.5.3">1.5.3. Person determining CPS suitability for the policy</h4>
+<p>
+This CPS and all other policy documents are managed by
+the policy group, which is a group of Members of the
+Community found at policy forum.  See discussion forums above.
+</p>
+
+<h4 id="p1.5.4">1.5.4. CPS approval procedures</h4>
+<p>
+CPS is controlled and updated according to the
+Policy on Policy
+(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>)
+which is part of
+Configuration-Control Specification (COD2).
+</p>
+
+<p>
+In brief, the policy forum prepares and discusses.
+After a last call, the document moves to DRAFT status
+for a defined period.
+If no challenges have been received in the defined period,
+it moves to POLICY status.
+The process is modelled after some elements of
+the RFC process by the IETF.
+</p>
+
+<h4 id="p1.5.5">1.5.5. CPS updates</h4>
+
+<p>
+As per above.
+</p>
+
+
+<h3 id="p1.6">1.6. Definitions and acronyms</h3>
+<p>
+<b><a name="d_cert" id="d_cert">Certificate</a></b>.
+  A certificate is a piece of cryptographic data used
+  to validate certain statements, especially those of
+  identity and membership.
+</p>
+<p>
+<b><a name="d_cacert" id="d_cacert">CAcert</a></b>.
+  CAcert is a Community certificate authority as defined under
+  <a href="#p1.2">§1.2 Identification</a>.
+</p>
+<p>
+<b><a name="d_member" id="d_member">Member</a></b>.
+  Everyone who agrees to the
+  CAcert Community Agreement
+  (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
+  This generally implies having an account registered
+  at CAcert and making use of CAcert's data, programs or services.
+  A Member may be an individual ("natural person")
+  or an organisation (sometimes, "legal person").
+</p>
+<p>
+<b><a name="d_community" id="d_community">Community</a></b>.
+  The group of Members who agree to the
+  CAcert Community Agreement
+  (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
+  or equivalent agreements.
+</p>
+<p>
+<b><a name="d_unassured" id="d_unassured">Unassured Member</a></b>.
+  A Member who has not yet been Assured.
+</p>
+<p>
+<b><a name="d_subscriber" id="d_subscriber">Subscriber</a></b>.
+  A Member who requests and receives a certificate.
+</p>
+<p>
+<b><a name="d_assured" id="d_assured">Assured Member</a></b>.
+  A Member whose identity has been sufficiently
+  verified by Assurers or other
+  approved methods under Assurance Policy.</p>
+<p></p>
+<p>
+<b><a name="d_assurer" id="d_assurer">Assurer</a></b>.
+  An Assured Member who is authorised under Assurance Policy
+  to verify the identity of other Members.
+</p>
+<p>
+<b><a name="d_name" id="d_name">Name</a></b>.
+    As defined in the
+    Assurance Policy
+    (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>),
+    to describe a name of a Member
+    that is verified by the Assurance process.
+</p>
+<p>
+<b><a name="d_oadmin" id="d_oadmin">Organisation Administrator</a></b>.
+  ("O-Admin")
+  An Assurer who is authorised to act for an Organisation.
+  The O-Admin is authorised by an organisation
+  to vouch for the identity of other users of the organisation.
+</p>
+<p>
+<b><a name="d_org_ass" id="d_org_ass">Organisation Assurer</a></b>.
+  An Assurer who is authorised to conduct assurances on
+  organisations.
+</p>
+<p>
+<b><a name="d_user" id="d_user">Non-Related Persons</a></b>.
+  ("NRPs")
+  are general users of browsers and similar software.
+  The NRPs are generally unaware of
+  CAcert or the certificates that they may use, and
+  are unaware of the ramifications of usage.
+  They are not permitted to RELY, but may USE, under the
+  Non-Related Persons - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
+</p>
+<p>
+<b><a name="rel" id="d_reliance">Reliance</a></b>.
+  An industry term referring to
+  the act of making a decision, including taking a risk,
+  which decision is in part or in whole
+  informed or on the basis of the contents of a certificate.
+</p>
+<p>
+<b><a name="rel" id="rel">Relying Party</a></b>.
+  An industry term refering to someone who relies
+  (that is, makes decisions or takes risks)
+  in part or in whole on a certificate.
+</p>
+<p>
+    <b>Subscriber Naming.</b>
+    The term used in this CPS to
+    describe all naming data within a certificate.
+    Approximately similar terms from Industry such as
+    "Subject naming" and "Distinguished Name"
+    are not used here.
+</p>
+<p>
+<b><a name="ver" id="d_verification">Verification</a></b>.
+  An industry term referring to
+  the act of checking and controlling
+  the accuracy and utility of a single claim.
+</p>
+<p>
+<b><a name="ver" id="d_validation">Validation</a></b>.
+  An industry term referring to the process of
+  inspecting and verifying the information and
+  subsidiary claims behind a claim.
+</p>
+<p>
+<b><a name="rel" id="rel">Usage</a></b>.
+  The event of allowing a certificate to participate in
+  a protocol, as decided and facilitated by a user's software.
+  Generally, Usage does not require significant input, if any,
+  on the part of the user.
+  This defers all decisions to the user software,
+  thus elevating the software as user's only and complete
+  Validation Authority or Agent.
+</p>
+<p>
+<b><a name="drel" id="drel">CAcert Relying Party</a></b>.
+  CAcert Members who make decisions based in part or in whole
+  on a certificate issued by CAcert.
+  Only CAcert Members are permitted to Rely on CAcert certificates,
+  subject to the CAcert Community Agreement.
+</p>
+<p>
+<b><a name="ddst" id="ddst">Vendors</a></b>.
+  Non-members who distribute CAcert's root or intermediate certificates
+  in any way, including but not limited to delivering these
+  certificates with their products, e.g. browsers, mailers or servers.
+  Vendors are covered under a separate licence.
+</p>
+<p>
+<b><a name="d_ccs" id="d_ccs">Configuration-Control Specification</a></b> "CCS".
+  The audit criteria that controls this CPS.
+  The CCS is documented in COD2, itself a controlled document under CCS.
+</p>
+<p>
+</p>
+<p>
+<b><a name="d_cod" id="d_cod">CAcert Official Document</a></b> (COD).
+  Controlled Documents that are part of the CCS.
+</p>
+
+
+
+<!-- *************************************************************** -->
+<h2 id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</h2>
+
+
+<h3 id="p2.1">2.1. Repositories</h3>
+
+<p>
+CAcert operates no repositories in the sense
+of lookup for non-certificate-related information
+for the general public.
+</p>
+
+<p>
+Under the Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>),
+there are means for Members to search, retrieve
+and verify certain data about themselves and others.
+</p>
+
+<h3 id="p2.2">2.2. Publication of certification information</h3>
+
+<p>
+CAcert publishes:
+</p>
+
+<ul>
+
+<li>A repository of CRLs.  An OCSP responder is in operation.</li>
+
+<li>The root certificate and intermediate certificates.</li>
+</ul>
+
+<p>
+CAcert does not expressly publish information on issued certificates.
+However, due to the purpose of certificates, and the essential
+public nature of Names and email addresses, all information within
+certificates is presumed to be public and published, once
+issued and delivered to the Member.
+</p>
+
+<h3 id="p2.3">2.3. Time or frequency of publication</h3>
+
+<p>
+Root and Intermediate Certificates and CRLs are
+made available on issuance.
+</p>
+
+<h3 id="p2.4">2.4. Access controls on repositories</h3>
+<p> No stipulation.  </p>
+
+
+
+<!-- *************************************************************** -->
+<h2 id="p3">3. IDENTIFICATION AND AUTHENTICATION</h2>
+
+<h3 id="p3.1">3.1. Naming</h3>
+
+<h4 id="p3.1.1">3.1.1. Types of names</h4>
+
+<p>
+<b>Client Certificates.</b>
+The Subscriber Naming consists of:
+</p>
+<ul>
+
+<li><tt>subjectAltName=</tt>
+      One, or more, of the Subscriber's verified email addresses,
+      in rfc822Name format.
+
+  </li>
+<li><tt>EmailAddress=</tt>
+      One, or more, of the Subscriber's verified email addresses.
+      This is deprecated under
+      RFC5280 <a href="http://tools.ietf.org/html/rfc5280#section-4.2.1.6">4
+.2.1.6</a>
+      and is to be phased out. Also includes a SHA1 hash of a random number if
+      the member selects SSO (Single Sign On ID) during submission of CSR.
+  </li>
+
+<li><tt>CN=</tt> The common name takes its value from one of:
+
+<ul>
+<li>
+      For all Members,
+      the string "<tt>CAcert WoT Member</tt>" may be used for
+      anonymous certificates.
+    </li>
+<li>
+      For individual Members,
+      a Name of the Subscriber,
+      as Assured under AP.
+    </li>
+<li>
+      For Organisation Members,
+      an organisation-chosen name,
+      as verified under OAP.
+    </li>
+</ul>
+</li>
+</ul>
+
+<p>
+<b>Individual Server Certificates.</b>
+The Subscriber Naming consists of:
+</p>
+<ul>
+<li><tt>CN=</tt>
+    The common name is the host name out of a domain
+    for which the Member is a domain master.
+  </li>
+<li>
+  <tt>subjectAltName=</tt>
+    Additional host names for which the Member
+    is a domain master may be added to permit the
+    certificate to serve multiple domains on one IP number.
+  </li>
+<li>
+    All other fields are optional and must either match
+    the CN or they must be empty
+</li>
+</ul>
+
+<p>
+<b>Certificates for Organisations.</b>
+In addition to the above, the following applies:
+</p>
+
+<ul>
+
+<li><tt>OU=</tt>
+      organizationalUnitName (set by O-Admin, must be verified by O-Admin).</li>
+
+<li><tt>O=</tt>
+      organizationName is the fixed name of the Organisation.</li>
+
+<li><tt>L=</tt>
+      localityName</li>
+
+<li><tt>ST=</tt>
+      stateOrProvinceName</li>
+
+<li><tt>C=</tt>
+      countryName</li>
+
+<li><tt>contact=</tt>
+      EMail Address of Contact.
+  </li>
+</ul>
+
+<p>
+Except for the OU and CN, fields are taken from the Member's
+account and are as verified by the Organisation Assurance process.
+Other Subscriber information that is collected and/or retained
+does not go into the certificate.
+</p>
+
+<h4 id="p3.1.2">3.1.2. Need for names to be meaningful</h4>
+
+<p>
+Each Member's Name (<tt>CN=</tt> field)
+is assured under the Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
+or subsidiary policies (such as Organisation Assurance Policy).
+Refer to those documents for meanings and variations.
+</p>
+
+<p>
+Anonymous certificates have the same <code>subject</code>
+field common name.
+See <a href="#p1.4.5">§1.4.5.</a>.
+</p>
+
+<p>
+Email addresses are verified according to
+<a href="#p4.2.2">§4.2.2.</a>
+</p>
+
+<h4 id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</h4>
+
+<p>
+See <a href="#p1.4.5">§1.4.5</a>.
+</p>
+
+<h4 id="p3.1.4">3.1.4. Rules for interpreting various name forms</h4>
+<p>
+Interpretation of Names is controlled by the Assurance Policy,
+is administered by means of the Member's account,
+and is subject to change by the Arbitrator.
+Changes to the interpretation by means of Arbitration
+should be expected as fraud (e.g., phishing)
+may move too quickly for policies to fully document rules.
+</p>
+
+<h4 id="p3.1.5">3.1.5. Uniqueness of names</h4>
+
+<p>
+Uniqueness of Names within certificates is not guaranteed.
+Each certificate has a unique serial number which maps
+to a unique account, and thus maps to a unique Member.
+See the Assurance Statement within Assurance Policy
+(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
+</p>
+
+<p>
+Domain names and email address
+can only be registered to one Member.
+</p>
+
+<h4 id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</h4>
+
+<p>
+Organisation Assurance Policy
+(<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>)
+controls issues such as trademarks where applicable.
+A trademark can be disputed by filing a dispute.
+See
+<a href="#adr">§9.13</a>.
+</p>
+
+<h4 id="p3.1.7">3.1.7. International Domain Names</h4>
+
+<p>
+Certificates containing International Domain Names, being those containing a
+ACE prefix (<a href="http://www.ietf.org/rfc/rfc3490#section-5">RFC3490
+Section 5</a>), will only be issued to domains satisfying one or more
+of the following conditions:
+</p>
+<ul>
+<li>The Top Level Domain (TLD) Registrar associated with the domain has a policy
+that has taken measures to prevent two homographic domains being registered to
+different entities down to an accepted level.
+</li>
+<li>Domains contain only code points from a single unicode character script,
+excluding the "Common" script, with the additionally allowed numberic
+characters [0-9], and an ACSII hyphen '-'.
+</li>
+</ul>
+<p></p>
+
+<p>Email address containing International Domain Names in the domain portion of
+the email address will also be required to satisfy one of the above conditions.
+</p>
+
+<p>
+The following is a list of accepted TLD Registrars:
+
+</p>
+
+<table>
+  <tbody>
+
+<tr>
+<td>.ac</td>
+
+<td><a href="http://www.nic.ac/">Registry</a></td>
+
+<td><a href="http://www.nic.ac/pdf/AC-IDN-Policy.pdf">Policy</a></td>
+</tr>
+
+<tr>
+<td>.ar</td>
+
+<td><a href="http://www.nic.ar/">Registry</a></td>
+
+<td><a href="http://www.nic.ar/616.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.at</td>
+
+<td><a href="http://www.nic.at/">Registry</a></td>
+
+<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>
+</tr>
+
+<tr>
+<td>.biz</td>
+
+<td><a href="http://www.neustarregistry.biz/">Registry</a></td>
+
+<td><a href="http://www.neustarregistry.biz/products/idns">Policy</a></td>
+</tr>
+
+<tr>
+<td>.br</td>
+
+<td><a href="http://registro.br/">Registry</a></td>
+
+<td><a href="http://registro.br/faq/faq6.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.cat</td>
+
+<td><a href="http://www.domini.cat/">Registry</a></td>
+
+<td><a href="http://www.domini.cat/normativa/en_normativa_registre.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.ch</td>
+
+<td><a href="http://www.switch.ch/id/">Registry</a></td>
+
+<td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a></td>
+</tr>
+
+<tr>
+<td>.cl</td>
+
+<td><a href="http://www.nic.cl/">Registry</a></td>
+
+<td><a href="http://www.nic.cl/CL-IDN-policy.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.cn</td>
+
+<td><a href="http://www.cnnic.net.cn/">Registry</a></td>
+
+<td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
+</tr>
+
+<tr>
+<td>.de</td>
+
+<td><a href="http://www.denic.de/">Registry</a></td>
+
+<td><a href="http://www.denic.de/en/richtlinien.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.dk</td>
+
+<td><a href="http://www.dk-hostmaster.dk/">Registry</a></td>
+
+<td><a href="http://www.dk-hostmaster.dk/index.php?id=151">Policy</a></td>
+</tr>
+
+<tr>
+<td>.es</td>
+
+<td><a href="https://www.nic.es/">Registry</a></td>
+
+<td><a href="https://www.nic.es/media/2008-12/1228818323935.pdf">Policy</a></td>
+</tr>
+
+<tr>
+<td>.fi</td>
+
+<td><a href="http://www.ficora.fi/">Registry</a></td>
+
+<td><a href="http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.gr</td>
+
+<td><a href="https://grweb.ics.forth.gr/english/index.html">Registry</a></td>
+
+<td><a href="https://grweb.ics.forth.gr/english/ENCharacterTable1.jsp">Policy</a></td>
+</tr>
+
+<tr>
+<td>.hu</td>
+
+<td><a href="http://www.domain.hu/domain/">Registry</a></td>
+
+<td><a href="http://www.domain.hu/domain/English/szabalyzat.html">Policy</a> (section 2.1.2)</td>
+</tr>
+
+<tr>
+<td>.info</td>
+
+<td><a href="http://www.afilias.info/">Registry</a></td>
+
+<td><a href="http://www.afilias.info/register/idn/">Policy</a></td>
+</tr>
+
+<tr>
+<td>.io</td>
+
+<td><a href="http://www.nic.io/">Registry</a></td>
+
+<td><a href="http://www.nic.io/IO-IDN-Policy.pdf">Policy</a></td>
+</tr>
+
+<tr>
+<td>.ir</td>
+
+<td><a href="https://www.nic.ir/">Registry</a></td>
+
+<td><a href="https://www.nic.ir/IDN">Policy</a></td>
+</tr>
+
+<tr>
+<td>.is</td>
+
+<td><a href="http://www.isnic.is/">Registry</a></td>
+
+<td><a href="http://www.isnic.is/english/domain/rules.php">Policy</a></td>
+</tr>
+
+<tr>
+<td>.jp</td>
+
+<td><a href="http://jprs.co.jp/">Registry</a></td>
+
+<td><a href="http://www.iana.org/assignments/idn/jp-japanese.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.kr</td>
+
+<td><a href="http://domain.nic.or.kr/">Registry</a></td>
+
+<td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
+</tr>
+
+<tr>
+<td>.li</td>
+
+<td><a href="http://www.switch.ch/id/">Registry</a></td>
+
+<td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a> (managed by .ch registry)</td>
+</tr>
+
+<tr>
+<td>.lt</td>
+
+<td><a href="http://www.domreg.lt/public?pg=&amp;sp=&amp;loc=en">Registry</a></td>
+
+<td><a href="http://www.domreg.lt/public?pg=8A7FB6&amp;sp=idn&amp;loc=en">Policy</a> (<a href="http://www.domreg.lt/static/doc/public/idn_symbols-en.pdf">character list</a>)</td>
+</tr>
+
+<tr>
+<td>.museum</td>
+
+<td><a href="http://about.museum/">Registry</a></td>
+
+<td><a href="http://about.museum/idn/idnpolicy.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.no</td>
+
+<td><a href="http://www.norid.no/">Registry</a></td>
+
+<td><a href="http://www.norid.no/domeneregistrering/veiviser.en.html">Policy</a> (section 4)</td>
+</tr>
+
+<tr>
+<td>.org</td>
+
+<td><a href="http://www.pir.org/">Registry</a></td>
+
+<td><a href="http://pir.org/PDFs/ORG-Extended-Characters-22-Jan-07.pdf">Policy</a></td>
+</tr>
+
+<tr>
+<td>.pl</td>
+
+<td><a href="http://www.nask.pl/">Registry</a></td>
+
+<td><a href="http://www.dns.pl/IDN/idn-registration-policy.txt">Policy</a></td>
+</tr>
+
+<tr>
+<td>.pr</td>
+
+<td><a href="https://www.nic.pr/">Registry</a></td>
+
+<td><a href="https://www.nic.pr/idn_rules.asp">Policy</a></td>
+</tr>
+
+<tr>
+<td>.se</td>
+
+<td><a href="http://www.nic-se.se/">Registry</a></td>
+
+<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>
+</tr>
+
+<tr>
+<td>.sh</td>
+
+<td><a href="http://www.nic.sh/">Registry</a></td>
+
+<td><a href="http://www.nic.sh/SH-IDN-Policy.pdf">Policy</a></td>
+</tr>
+
+<tr>
+<td>.th</td>
+
+<td><a href="http://www.thnic.or.th/">Registry</a></td>
+
+<td><a href="http://www.iana.org/assignments/idn/th-thai.html">Policy</a></td>
+</tr>
+
+<tr>
+<td>.tm</td>
+
+<td><a href="http://www.nic.tm/">Registry</a></td>
+
+<td><a href="http://www.nic.tm/TM-IDN-Policy.pdf">Policy</a></td>
+</tr>
+
+<tr>
+<td>.tw</td>
+
+<td><a href="http://www.twnic.net.tw/">Registry</a></td>
+
+<td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
+</tr>
+
+<tr>
+<td>.vn</td>
+
+<td><a href="http://www.vnnic.net.vn/">Registry</a></td>
+
+<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>
+</tr>
+
+  </tbody>
+</table>
+<p></p>
+
+<p>
+This criteria will apply to the email address and server host name fields for all certificate types.
+</p>
+
+<p>
+The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list.
+</p>
+
+<h3 id="p3.2">3.2. Initial Identity Verification</h3>
+
+<p>
+Identity verification is controlled by the
+<a href="https://www.cacert.org/policy/AssurancePolicy.html">
+Assurance Policy</a> (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
+The reader is refered to the Assurance Policy,
+the following is representative and brief only.
+</p>
+
+
+<h4 id="p3.2.1">3.2.1. Method to prove possession of private key</h4>
+
+<p>
+CAcert uses industry-standard techniques to
+prove the possession of the private key.
+</p>
+
+<p>
+For X.509 server certificates,
+the stale digital signature of the CSR is verified.
+For X.509 client certificates for "Netscape" browsers,
+SPKAC uses a challenge-response protocol
+to check the private key dynamically.
+For X.509 client certificates for "explorer" browsers,
+ActiveX uses a challenge-response protocol
+to check the private key dynamically.
+</p>
+
+<h4 id="p3.2.2">3.2.2. Authentication of Individual Identity</h4>
+
+<p>
+<b>Agreement.</b>
+An Internet user becomes a Member by agreeing to the
+CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
+and registering an account on the online website.
+During the registration process Members are asked to
+supply information about themselves:
+</p>
+
+<ul>
+
+<li>A valid working email.
+        </li>
+
+<li>Full Name and Date of Birth such as is
+        found on Identity documents.
+        </li>
+
+<li>Personal Questions used only for Password Retrieval.</li>
+  </ul>
+
+<p>
+The online account establishes the method of authentication
+for all service requests such as certificates.
+</p>
+
+<p>
+<b>Assurance.</b>
+Each Member is assured according to Assurance Policy
+(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
+</p>
+
+<p>
+<b>Certificates.</b>
+Based on the total number of Assurance Points
+that a Member (Name) has, the Member
+can get different levels of certificates.
+See <a href="#p1.4.5">§1.4.5</a>.
+See Table 3.2.b.
+When Members have 50 or more points, they
+become <i>Assured Members</i> and may then request
+certificates that state their Assured Name(s).
+</p>
+
+
+<br>
+
+<br>
+<center>
+
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<th>Assurance Points</th>
+
+<th>Level</th>
+
+<th>Service</th>
+
+<th>Comments</th>
+ </tr>
+<tr>
+
+<td>0</td>
+
+<td>Unassured Member</td>
+
+<td>Anonymous</td>
+
+<td>Certificates with no Name, under Class 1 Root.  Limited to 6 months expiry.</td>
+ </tr>
+<tr>
+
+<td>1-49</td>
+
+<td>Unassured Member</td>
+
+<td>Anonymous</td>
+
+<td>Certificates with no Name under Member SubRoot.  Limited to 6 months expiry.</td>
+ </tr>
+<tr>
+
+<td rowspan="1">50-99</td>
+
+<td>Assured Member</td>
+
+<td>Verified</td>
+
+<td>Certificates with Verified Name for S/MIME, web servers, "digital signing."
+      Expiry after 24 months is available.</td>
+ </tr>
+<tr>
+
+<td rowspan="2">100++</td>
+
+<td rowspan="2">Assurer</td>
+
+<td>Code-signing</td>
+
+<td>Can create Code-signing certificates </td>
+ </tr>
+</tbody>
+</table>
+
+<span class="figure">Table 3.2.b - How Assurance Points are used in Certificates</span>
+
+</center>
+<br>
+
+
+
+<h4 id="p3.2.3">3.2.3. Authentication of organization identity</h4>
+
+
+<p>
+Verification of organisations is delegated by
+the Assurance Policy to the
+Organisation Assurance Policy
+(<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>).
+The reader is refered to the Organisation Assurance Policy,
+the following is representative and brief only.
+</p>
+
+<p>
+Organisations present special challenges.
+The Assurance process for Organisations is
+intended to permit the organisational Name to
+appear in certificates.
+The process relies heavily on the Individual
+process described above.
+</p>
+
+<p>
+Organisation Assurance achieves the standard
+stated in the OAP, briefly presented here:
+</p>
+
+<ol type="a">
+<li>
+   the organisation exists,
+  </li>
+<li>
+   the organisation name is correct and consistent,
+  </li>
+<li>
+   signing rights: requestor can sign on behalf of the organisation, and
+  </li>
+<li>
+   the organisation has agreed to the terms of the
+   CAcert Community Agreement
+   (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
+   and is therefore subject to Arbitration.
+</li>
+</ol>
+
+<h4 id="p3.2.4">3.2.4. Non-verified subscriber information</h4>
+
+<p>
+All information in the certificate is verified,
+see Relying Party Statement, §4.5.2.
+</p>
+
+
+<h4 id="p3.2.5">3.2.5. Validation of authority</h4>
+
+<p>
+The authorisation to obtain a certificate is established as follows:
+</p>
+
+<p>
+<b>Addresses.</b>
+The member claims authority over a domain or email address
+when adding the address,  <a href="#p4.1.2">§4.1.2</a>.
+(Control is tested by means described in <a href="#p4.2.2">§4.2.2</a>.)
+</p>
+
+<p>
+<b>Individuals.</b>
+The authority to participate as a Member is established
+by the CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
+Assurances are requested by means of the signed CAP form.
+</p>
+
+<p>
+<b>Organisations.</b>
+The authority for Organisation Assurance is established
+in the COAP form, as signed by an authorised representative
+of the organisation.
+The authority for the
+Organisation Administrator
+(O-Admin) is also established on the
+COAP form.
+See Organisation Assurance Policy.
+</p>
+
+
+<h4 id="p3.2.6">3.2.6. Criteria for interoperation</h4>
+
+<p>
+CAcert does not currently issue certificates to subordinate CAs
+or other PKIs.
+Other CAs may become Members, and are then subject to the
+same reliance provisions as all Members.
+</p>
+
+<h3 id="p3.3">3.3. Re-key Requests</h3>
+
+<p>
+Via the Member's account.
+</p>
+
+<h3 id="p3.4">3.4. Revocations Requests</h3>
+
+<p>
+Via the Member's account.
+In the event that the Member has lost the password,
+or similar, the Member emails the support team who
+either work through the lost-password questions
+process or file a dispute.
+</p>
+
+
+
+<!-- *************************************************************** -->
+<h2 id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</h2>
+
+<p>
+The general life-cycle for a new certificate for an Individual Member is:
+
+</p>
+<ol>
+<li>
+    Member adds claim to an address (domain/email).
+  </li>
+<li>
+    System probes address for control.
+  </li>
+<li>
+    Member creates key pair.
+  </li>
+<li>
+    Member submits CSR with desired options (Anonymous Certificate, SSO, Root Certificate) .
+  </li>
+<li>
+    System validates and accepts CSR based on
+    known information:  claims, assurance, controls, technicalities.
+  </li>
+<li>
+    System signs certificate.
+  </li>
+<li>
+    System makes signed certificate available to Member.
+  </li>
+<li>
+    Member accepts certificate.
+</li>
+</ol>
+ 
+<p></p>
+
+<p>
+(Some steps are not applicable, such as anonymous certificates.)
+</p>
+
+
+<h3 id="p4.1">4.1. Certificate Application</h3>
+
+<h4 id="p4.1.1">4.1.1. Who can submit a certificate application</h4>
+
+<p>
+Members may submit certificate applications.
+On issuance of certificates, Members become Subscribers.
+</p>
+
+<h4 id="p4.1.2">4.1.2. Adding Addresses</h4>
+
+<p>
+The Member can claim ownership or authorised control of
+a domain or email address on the online system.
+This is a necessary step towards issuing a certificate.
+There are these controls:
+</p>
+<ul>
+<li>
+    The claim of ownership or control is legally significant
+    and may be referred to dispute resolution.
+  </li>
+<li>
+    Each unique address can be handled by one account only.
+  </li>
+<li>
+    When the Member makes the claim,
+    the certificate application system automatically initiates the
+    check of control, as below.
+</li>
+</ul>
+<p></p>
+
+<h4 id="p4.1.3">4.1.3. Preparing CSR </h4>
+
+<p>
+Members generate their own key-pairs.
+The CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
+obliges the Member as responsible for security.
+See CCA2.5, §9.6.
+</p>
+
+<p>
+The Certificate Signing Request (CSR) is prepared by the
+Member for presentation to the automated system.
+</p>
+
+<h3 id="p4.2">4.2. Certificate application processing</h3>
+
+<!-- states what a CA does on receipt of the request -->
+
+<p>
+The CA's certificate application process is completely automated.
+Requests, approvals and rejections are handled by the website system.
+Each application should be processed in less than a minute.
+</p>
+<p>
+Where certificates are requested for more than one
+purpose, the requirements for each purpose must be
+fulfilled.
+</p>
+
+<!-- all sub headings in 4.2 are local, not from Chokhani. -->
+
+<h4 id="p4.2.1">4.2.1. Authentication </h4>
+
+<p>
+  The Member logs in to her account on the CAcert website
+      and thereby authenticates herself with username
+      and passphrase or with her CAcert client-side digital certificate.
+</p>
+
+<h4 id="p4.2.2">4.2.2. Verifying Control</h4>
+
+<p>
+In principle, at least two controls are placed on each address.
+</p>
+
+<p>
+<b><a name="ping">Email-Ping</a>.</b>
+Email addresses are verified by means of an
+<i><a name="ping">Email-Ping test</a></i>:
+</p>
+
+<ul>
+<li>
+      The system generates a cookie
+      (a random, hard-to-guess code)
+      and formats it as a string.
+  </li>
+<li>
+      The system sends the cookie
+      to the Member in an email.
+  </li>
+<li>
+      Once the Member receives the email,
+      she enters the cookie into the website.
+  </li>
+<li>
+      The entry of the code verifies
+      control of that email account.
+</li>
+</ul>
+
+<p>
+<b><a name="email">Email Control</a>.</b>
+Email addresses for client certificates are verified by passing the
+following checks:
+</p>
+<ol>
+
+<li>An Email-ping test
+      is done on the email address.
+      </li>
+
+<li>The Member must have signed a CAP form or equivalent,
+      and been awarded at least one Assurance point.
+      </li>
+</ol>
+
+<p>
+<b><a name="domain">Domain Control</a>.</b>
+Domains addresses for server certificates are verified by passing two of the
+following checks:
+</p>
+<ol>
+<li>
+      An Email-ping test
+      is done on an email address chosen from <i>whois</i>
+      or interpolated from the domain name.
+  </li>
+<li>
+      The system generates a cookie
+      which is then placed in DNS
+      by the Member.
+  </li>
+<li>
+      The system generates a cookie
+      which is then placed in HTTP headers or a text file on the website
+      by the Member.
+  </li>
+<li>
+      Statement by at least 2 Assurers about
+      ownership/control of the domain name.
+  </li>
+<li>
+      The system generates a cookie
+      which is then placed in whois registry information
+      by the Member.
+</li>
+</ol>
+
+<p>
+Notes.
+</p>
+<ul>
+<li>
+    Other methods can be added from time to time by CAcert.
+  </li>
+<li>
+    Static cookies should remain for the duration of a certificate
+    for occasional re-testing.
+  </li>
+<li>
+    Dynamic tests can be repeated at a later time of CAcert's choosing.
+  </li>
+<li>
+    Domain control checks may be extended to apply to email control
+    in the future.
+</li>
+</ul>
+<p></p>
+
+
+
+<h4 id="p4.2.3">4.2.3. Options Available</h4>
+
+<p>
+The Member has options available:
+</p>
+
+<ul>
+
+<li>Each Email address that is verified
+      is available for Client Certificates.
+      </li>
+
+<li>Each Domain address that is verified
+      is available for Server Certificates.
+      </li>
+
+<li>If the Member is unassured then only the Member SubRoot is available.
+      </li>
+
+<li>If the Member is Assured then both Assured Member and Member SubRoots
+      are available.
+      </li>
+
+<li>If a Name is Assured then it may be
+      put in a client certificate or an OpenPGP signature.
+      </li>
+</ul>
+
+<h4 id="p4.2.4">4.2.4. Client Certificate Procedures</h4>
+
+<p>
+For an individual client certificate, the following is required.
+</p>
+<ul>
+
+<li>The email address is claimed and added. </li>
+
+<li>The email address is ping-tested. </li>
+
+<li>For the Member Subroot, the Member must have
+      at least one point of Assurance and have signed a CAP form.</li>
+
+<li>For the Assured Subroot, the Member must have
+      at least fifty points of Assurance. </li>
+
+<li>To include a Name, the Name must be assured to at least fifty points. </li>
+
+</ul>
+<p></p>
+
+<h4 id="p4.2.5">4.2.5. Server Certificate Procedures</h4>
+
+<p>
+For a server certificate, the following is required:
+</p>
+<ul>
+
+<li>The domain is claimed and added. </li>
+
+<li>The domain is checked twice as above. </li>
+
+<li>For the Member SubRoot, the Member must have
+      at least one point of Assurance and have signed a CAP form.</li>
+
+<li>For the Assured SubRoot, the Member must have
+      at least fifty points of Assurance. </li>
+</ul>
+
+<p></p>
+
+<h4 id="p4.2.6">4.2.6. Code-signing Certificate Procedures</h4>
+
+<p>
+Code-signing certificates are made available to Assurers only.
+They are processed in a similar manner to client certificates.
+</p>
+
+<h4 id="p4.2.7">4.2.7. Organisation Domain Verification</h4>
+
+<p>
+Organisation Domains are handled under the Organisation Assurance Policy
+and the Organisation Handbook.
+</p>
+
+<h3 id="p4.3">4.3. Certificate issuance</h3>
+
+
+<h4 id="p4.3.1">4.3.1. CA actions during certificate issuance</h4>
+
+<p>
+<b>Key Sizes.</b>
+Members may request keys of any size permitted by the key algorithm.
+Many older hardware devices require small keys.
+</p>
+
+<p>
+<b>Algorithms.</b>
+CAcert currently only supports the RSA algorithm for X.509 keys.
+X.509 signing uses the SHA-1 message digest algorithm.
+OpenPGP Signing uses RSA signing over RSA and DSA keys.
+
+</p>
+
+<p>
+<b>Process for Certificates:</b>
+All details in each certificate are verified
+by the website issuance system.
+Issuance is based on a 'template' system that selects
+profiles for certificate lifetime, size, algorithm.
+</p>
+
+
+<ol>
+<li>
+   The CSR is verified.
+  </li>
+<li>
+   Data is extracted from CSR and verified:
+
+<ul>
+  
+<li> Name §3.1, </li>
+  
+<li> Email address <a href="#p4.2.2">§4.2.2</a>, </li>
+  
+<li> Domain address <a href="#p4.2.2">§4.2.2</a>. </li>
+    </ul>
+  </li>
+<li>
+   Certificate is generated from template.
+  </li>
+<li>
+   Data is copied from CSR.
+  </li>
+<li>
+   Certificate is signed.
+  </li>
+<li>
+   Certificate is stored as well as mailed.
+</li>
+</ol>
+
+
+<p>
+<b>Process for OpenPGP key signatures:</b>
+All details in each Sub-ID are verified
+by the website issuance system.
+Issuance is based on the configuration that selects
+the profile for signature lifetime, size,
+algorithm following the process:
+</p>
+
+<ol>
+<li>
+   The public key is verified.
+  </li>
+<li>
+   Data is extracted from the key and verified (Name, Emails).
+   Only the combinations of data in Table 4.3.1 are permitted.
+  </li>
+<li>
+   OpenPGP Key Signature is generated.
+  </li>
+<li>
+   Key Signature is applied to the key.
+  </li>
+<li>
+   The signed key is stored as well as mailed.
+</li>
+</ol>
+
+<center>
+<table valign="top" align="center" border="1" cellpadding="5">
+<tbody>
+
+<tr>
+
+<td>
+<br>
+</td>
+
+<td>Verified Name</td>
+
+<td valign="top">Unverified Name
+<br>
+</td>
+
+<td>Empty Name
+<br>
+</td>
+  </tr>
+
+<tr>
+
+<td>Verified email
+<br>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font>  </center>
+</td>
+
+<td valign="top">
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="green" size="+3"> ✔ </font>  </center>
+</td>
+  </tr>
+
+<tr>
+
+<td>Unverified email</td>
+
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+</td>
+
+<td valign="top">
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+</td>
+
+<td>
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+</td>
+</tr>
+<tr>
+<td valign="top">Empty email
+<br>
+</td>
+
+<td valign="top">
+<center> <font title="pass." color="green" size="+3"> ✔ </font>  </center>
+</td>
+
+<td valign="top">
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+</td>
+
+<td valign="top">
+<center> <font title="pass." color="red" size="+3"> ✘ </font> </center>
+</td>
+  </tr>
+</tbody>
+</table>
+<br>
+
+<span class="figure">Table 4.3.1.  Permitted Data in Signed OpenPgp Keys</span>
+</center>
+
+<h4 id="p4.3.2">4.3.2. Notification to subscriber by the CA of issuance of certificate</h4>
+
+<p>
+Once signed, the certificate is
+made available via the Member's account,
+and emailed to the Member.
+It is also archived internally.
+</p>
+
+<h3 id="p4.4">4.4. Certificate acceptance</h3>
+
+<h4 id="p4.4.1">4.4.1. Conduct constituting certificate acceptance</h4>
+
+<p>
+There is no need for the Member to explicitly accept the certificate.
+In case the Member does not accept the certificate,
+the certificate has to be revoked and made again.
+</p>
+
+<h4 id="p4.4.2">4.4.2. Publication of the certificate by the CA</h4>
+
+<p>
+CAcert does not currently publish the issued certificates
+in any repository.
+In the event that CAcert will run a repository,
+the publication of certificates and signatures
+there will be at the Member's options.
+However note that certificates that are issued
+and delivered to the Member are presumed to be
+published.  See §2.2.
+</p>
+
+<h4 id="p4.4.3">4.4.3. Notification of certificate issuance by the CA to other entities</h4>
+
+<p>
+There are no external entities that are notified about issued certificates.
+</p>
+
+<h3 id="p4.5">4.5. Key pair and certificate usage</h3>
+
+<p>
+All Members (subscribers and relying parties)
+are obliged according to the
+CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
+See especially 2.3 through 2.5.
+</p>
+<h4 id="p4.5.1">4.5.1. Subscriber Usage and Responsibilities</h4>
+
+<p>
+Subscribers should use keys only for their proper purpose,
+as indicated by the certificate, or by wider agreement with
+others.
+</p>
+
+<h4 id="p4.5.2">4.5.2. Relying Party Usage and Responsibilities</h4>
+
+
+<p>
+Relying parties (Members) may rely on the following.
+</p>
+
+<center>
+
+<table border="1" cellpadding="25">
+<tbody>
+<tr>
+<td>
+
+<p align="center">
+  <big><b>Relying Party Statement</b></big>
+  </p>
+<p>
+  Certificates are issued to Members only.
+<br>
+
+<br>
+  All information in a certificate is verified.
+  </p>
+  </td>
+</tr>
+</tbody>
+</table>
+</center>
+
+
+<p>
+The following notes are in addition to the Relying Party Statement,
+and can be seen as limitations on it.
+</p>
+
+<h5 id="p4.5.2.1">4.5.2.a Methods of Verification </h5>
+<p>
+The term Verification as used in the Relying Party Statement means one of
+</p>
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<th>Type</th>
+<th>How</th>
+<th>Authority</th>
+<th>remarks</th>
+</tr>
+<tr>
+
+<th>Assurance</th>
+<td>under CAcert Assurance Programme (CAP)</td>
+
+<td>Assurance Policy</td>
+
+<td>only information assured to 50 points under CAP is placed in the certificate </td>
+</tr>
+<tr>
+
+<th>Evaluation</th>
+<td>under automated domain and email checks </td>
+
+<td>this CPS</td>
+
+<td>see §4.2.2</td>
+</tr>
+<tr>
+
+<th>Controlled</th>
+<td>programs or "profiles" that check the information within the CSR </td>
+
+<td>this CPS</td>
+
+<td>see §7.1</td>
+</tr>
+</tbody>
+</table>
+
+<h5 id="p4.5.2.2">4.5.2.b Who may rely</h5>
+<p>
+<b>Members may rely.</b>
+Relying parties are Members,
+and as such are bound by this CPS and the
+CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
+The licence and permission to rely is not assignable.
+</p>
+
+<p>
+<b>Suppliers of Software.</b>
+CAcert roots may be distributed in software,
+and those providers may
+enter into agreement with CAcert by means of the
+Third Party Vendor - Disclaimer and Licence
+(wip).
+This licence brings the supplier in to the Community
+to the extent that
+they agree to dispute resolution
+within CAcert's forum.
+</p>
+
+<p>
+<b>NRPs may not rely.</b>
+If not related to CAcert by means of an agreement
+that binds the parties to dispute resolution within CAcert's forum,
+a person is a Non-Related-Person (NRP).
+An NRP is not permitted to rely and is not a Relying Party.
+For more details, see the
+NRP - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
+</p>
+
+<h5 id="p4.5.2.3">4.5.2.c The Act of Reliance </h5>
+
+<p>
+<b>Decision making.</b>
+Reliance means taking a decision that is in part or in whole
+based on the information in the certificate.
+
+A Relying Party may incorporate
+the information in the certificate,
+and the implied information such as Membership,
+into her decision-making.
+In making a decision,
+a Relying Party should also:
+</p>
+
+<ul>
+<li>
+    include her own overall risk equation,
+  </li>
+<li>
+    include the general limitations of the Assurance process,
+    certificates, and wider security considerations,
+  </li>
+<li>
+    make additional checks to provide more information,
+  </li>
+<li>
+    consider any wider agreement with the other Member, and
+  </li>
+<li>
+    use an appropriate protocol or custom of reliance (below).
+</li>
+</ul>
+
+<p>
+<b>Examining the Certificate.</b>
+A Relying Party must make her own decision in using
+each certificate.  She must examine the certificate,
+a process called <i>validation</i>.
+Certificate-related information includes,
+but is not limited to:
+</p>
+<ul>
+<li>
+    Name,
+  </li>
+<li>
+    expiry time of certificate,
+  </li>
+<li>
+    current certificate revocation list (CRL),
+  </li>
+<li>
+    certificate chain and
+    the validity check of the certificates in the chain,
+  </li>
+<li>
+    issuer of certificate (CAcert),
+  </li>
+<li>
+    SubRoot is intended for reliance (Assured, Organisation and Class 3)
+  </li>
+<li>
+    purpose of certificate.
+</li>
+</ul>
+
+<p>
+<b>Keeping Records.</b>
+Records should be kept, appropriate to the import of the decision.
+The certificate should be preserved.
+This should include sufficient
+evidence to establish who the parties are
+(especially, the certificate relied upon),
+to establish the transaction in question,
+and to establish the wider agreement that
+defines the act.
+</p>
+
+<p>
+<b>Wider Protocol.</b>
+In principle, reliance will be part of a wider protocol
+(customary method in reaching and preserving agreement)
+that presents and preserves sufficient of the evidence
+for dispute resolution under CAcert's forum of Arbitration.
+The protocol should be agreed amongst the parties,
+and tuned to the needs.
+This CPS does not define any such protocol.
+In the absence of such a protocol, reliance will be weakened;
+a dispute without sufficient evidence may be dismissed by an Arbitrator.
+</p>
+
+<p>
+<b>As Compared to Usage</b>.
+Reliance goes beyond Usage.  The latter is limited to
+letting the software act as the total and only Validation
+Authority.  When relying, the Member also augments
+the algorithmic processing of the software with her own
+checks of the business, technical and certificate aspect.
+</p>
+
+<h5 id="p4.5.2.4">4.5.2.d Risks and Limitations of Reliance </h5>
+<p>
+<b>Roots and Naming.</b>
+Where the Class 1 root is used,
+this Subscriber may be a new Member
+including one with zero points.
+Where the Name is not provided,
+this indicates it is not available.
+In these circumstances,
+reliance is not defined,
+and Relying parties should take more care.
+See Table 4.5.2.
+</p>
+
+<center>
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<td></td>
+
+<td colspan="4">
+<center><i>Statements of Reliance for Members</i></center>
+</td>
+ </tr>
+<tr>
+
+<td><i>Class of Root</i></td>
+
+<td>
+<center><b>Anonymous</b>
+<br>
+(all Members)</center>
+</td>
+
+<td>
+<center><b>Named</b>
+<br>
+(Assured Members only)</center>
+</td>
+ </tr>
+<tr>
+
+<td>
+<center>Class
+<br>
+<big><b>1</b></big></center>
+</td>
+
+<td rowspan="2" bgcolor="red">
+       <b>Do not rely.</b>
+<br>
+       Relying party must use other methods to check. </td>
+
+<td rowspan="2" bgcolor="orange">
+       Do not rely.
+       Although the named Member has been Assured by CAcert,
+       reliance is not defined with Class 1 root.
+<br>
+       (issued for compatibility only).</td>
+ </tr>
+<tr>
+
+<td>
+<center><big><b>Member</b></big>
+<br>
+SubRoot</center>
+</td>
+ </tr>
+<tr>
+
+<td>
+<center>Class
+<br>
+<big><b>3</b></big></center>
+</td>
+
+<td rowspan="2" bgcolor="orange">
+       Do not rely on the Name (being available).
+       The Member has been Assured by CAcert,
+       but reliance is undefined.</td>
+
+<td rowspan="2">
+       The Member named in the certificate has been Assured by CAcert.</td>
+ </tr>
+<tr>
+
+<td>
+<center><big><b>Assured</b></big>
+<br>
+SubRoot</center>
+</td>
+ </tr>
+</tbody>
+</table>
+
+<span class="figure">Table 4.5.2.  Statements of Reliance</span>
+</center>
+
+<p>
+<b>Software Agent.</b>
+When relying on a certificate, relying parties should
+note that your software is responsible for the way it
+shows you the information in a certificate.
+If your software agent hides parts of the information,
+your sole remedy may be to choose another software agent.
+</p>
+
+<p>
+<b>Malware.</b>
+When relying on a certificate, relying parties should
+note that platforms that are vulnerable to viruses or
+trojans or other weaknesses may not process any certificates
+properly and may give deceptive or fraudulent results.
+It is your responsibility to ensure you are using a platform
+that is secured according to the needs of the application.
+</p>
+
+<h5 id="p4.5.2.5">4.5.2.e When something goes wrong </h5>
+<p>
+In the event that an issue arises out of the Member's reliance,
+her sole avenue is <b>to file dispute under DRP</b>.
+See <a href="#p9.13">§9.13</a>.
+
+For this purpose, the certificate (and other evidence) should be preserved.
+</p>
+
+<p>
+<b>Which person?</b>
+Members may install certificates for other individuals or in servers,
+but the Member to whom the certificate is issued
+remains the responsible person.
+E.g., under Organisation Assurance, an organisation is issued
+a certificate for the use by individuals
+or servers within that organisation,
+but the Organisation is the responsible person.
+</p>
+
+<p>
+<b>Software Agent.</b>
+If a Member is relying on a CAcert root embedded in
+the software as supplied by a vendor,
+the risks, liabilities and obligations of the Member
+do not automatically transfer to the vendor.
+</p>
+
+<h3 id="p4.6">4.6. Certificate renewal</h3>
+
+<p>
+A certificate can be renewed at any time.
+The procedure of certificate renewal is the same
+as for the initial certificate issuance.
+</p>
+
+<h3 id="p4.7">4.7. Certificate re-key</h3>
+
+<p>
+Certificate "re-keyings" are not offered nor supported.
+A new certificate with a new key has to be requested and issued instead,
+and the old one revoked.
+</p>
+
+<h3 id="p4.8">4.8. Certificate modification</h3>
+
+<p>
+Certificate "modifications" are not offered nor supported.
+A new certificate has to be requested and issued instead.
+</p>
+
+<h3 id="p4.9">4.9. Certificate revocation and suspension</h3>
+
+<h4 id="p4.9.1">4.9.1. Circumstances for revocation</h4>
+<p>
+Certificates may be revoked under the following circumstances:
+</p>
+
+<ol>
+<li>
+    As initiated by the Subscriber through her online account.
+  </li>
+<li>
+    As initiated in an emergency action by a
+    support team member.
+    Such action will immediately be referred to dispute resolution
+    for ratification.
+  </li>
+<li>
+    Under direction from the Arbitrator in a duly ordered ruling
+    from a filed dispute.
+</li>
+</ol>
+
+<p>
+These are the only three circumstances under which a
+revocation occurs.
+</p>
+
+<h4 id="p4.9.2">4.9.2. Who can request revocation</h4>
+
+<p>
+As above.
+</p>
+
+<h4 id="p4.9.3">4.9.3. Procedure for revocation request</h4>
+<p>
+The Subscriber logs in to her online account through
+the website at http://www.cacert.org/ .
+</p>
+
+<p>
+In any other event such as lost passwords or fraud,
+a dispute should be filed
+by email at
+    &lt; support AT cacert DOT org &gt;
+</p>
+
+<h4 id="p4.9.4">4.9.4. Revocation request grace period</h4>
+
+<p>No stipulation.</p>
+
+<h4 id="p4.9.5">4.9.5. Time within which CA must process the revocation request</h4>
+
+<p>
+The revocation automated in the Web Interface for subscribers,
+and is handled generally in less than a minute.
+</p>
+
+<p>
+A filed dispute that requests a revocation should be handled
+within a five business days, however the Arbitrator has discretion.
+</p>
+
+<h4 id="p4.9.6">4.9.6. Revocation checking requirement for relying parties</h4>
+
+<p>
+Each revoked certificate is recorded in the
+certificate revocation list (CRL).
+Relying Parties must check a certificate against
+the most recent CRL issued, in order to validate
+the certificate for the intended reliance.
+</p>
+
+<h4 id="p4.9.7">4.9.7. CRL issuance frequency (if applicable)</h4>
+
+<p>
+A new CRL is issued after every certificate revocation.
+</p>
+
+<h4 id="p4.9.8">4.9.8. Maximum latency for CRLs (if applicable)</h4>
+
+<p>
+The maximum latency between revocation and issuance of the CRL is 1 hour.
+</p>
+
+<h4 id="p4.9.9">4.9.9. On-line revocation/status checking availability</h4>
+
+<p>
+OCSP is available at
+http://ocsp.cacert.org/ .
+</p>
+
+<h4 id="p4.9.10">4.9.10. On-line revocation checking requirements</h4>
+<p>
+Relying parties must check up-to-date status before relying.
+</p>
+
+<h4 id="p4.9.11">4.9.11. Other forms of revocation advertisements available</h4>
+<p>
+None.
+</p>
+
+<h4 id="p4.9.12">4.9.12. Special requirements re key compromise</h4>
+<p>
+Subscribers are obliged to revoke certificates at the earliest opportunity.
+</p>
+
+<h4 id="p4.9.13">4.9.13. Circumstances for suspension</h4>
+
+<p>
+Suspension of certificates is not available.
+</p>
+
+<h4 id="p4.9.14">4.9.14. Who can request suspension</h4>
+<p>
+Not applicable.
+</p>
+
+<h4 id="p4.9.15">4.9.15. Procedure for suspension request</h4>
+<p>
+Not applicable.
+</p>
+
+<h4 id="p4.9.16">4.9.16. Limits on suspension period</h4>
+<p>
+Not applicable.
+</p>
+
+
+
+<h3 id="p4.10">4.10. Certificate status services</h3>
+
+<h4 id="p4.10.1">4.10.1. Operational characteristics</h4>
+<p>
+OCSP is available
+at http://ocsp.cacert.org/ .
+</p>
+
+<h4 id="p4.10.2">4.10.2. Service availability</h4>
+
+<p>
+OCSP is made available on an experimental basis.
+</p>
+
+<h4 id="p4.10.3">4.10.3. Optional features</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h3 id="p4.11">4.11. End of subscription</h3>
+
+<p>
+Certificates include expiry dates.
+</p>
+
+<h3 id="p4.12">4.12. Key escrow and recovery</h3>
+
+<h4 id="p4.12.1">4.12.1. Key escrow and recovery policy and practices</h4>
+
+<p>
+CAcert does not generate nor escrow subscriber keys.
+</p>
+
+<h4 id="p4.12.2">4.12.2. Session key encapsulation and recovery policy and practices</h4>
+
+<p>
+No stipulation.
+</p>
+
+
+
+<!-- *************************************************************** -->
+<h2 id="p5">5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</h2>
+
+<!-- <a href="http://xkcd.com/87/">
+<img align="right" src="http://imgs.xkcd.com/comics/velociraptors.jpg">
+ </a>  -->
+
+<h3 id="p5.1">5.1. Physical controls</h3>
+
+<p>
+Refer to Security Policy (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
+</p>
+<ul>
+<li>
+    Site location and construction - SP2.1
+  </li>
+<li>
+    Physical access - SP2.3
+</li>
+</ul>
+<p></p>
+
+
+<h4 id="p5.1.1">5.1.1. Power and air conditioning</h4>
+<p>
+Refer to Security Policy 2.1.2 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
+</p>
+<h4 id="p5.1.2">5.1.2. Water exposures</h4>
+<p>
+Refer to Security Policy 2.1.4 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
+</p>
+<h4 id="p5.1.3">5.1.3. Fire prevention and protection</h4>
+<p>
+Refer to Security Policy 2.1.4 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
+</p>
+<h4 id="p5.1.4">5.1.4. Media storage</h4>
+<p>
+Refer to Security Policy 4.3 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
+</p>
+<h4 id="p5.1.5">5.1.5. Waste disposal</h4>
+<p>
+No stipulation.
+</p>
+<h4 id="p5.1.6">5.1.6. Off-site backup</h4>
+<p>
+Refer to Security Policy 4.3 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
+</p>
+
+<h3 id="p5.2">5.2. Procedural controls</h3>
+
+<h4 id="p5.2.1">5.2.1. Trusted roles</h4>
+
+<ul>
+
+<li><b> Technical teams:</b>
+
+<ul>
+   
+<li>User support personnel</li>
+   
+<li>Systems Administrators -- critical and non-critical</li>
+   
+<li>Softare Developers</li>
+   
+<li>controllers of keys</li>
+   </ul>
+   Refer to Security Policy 9.1 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>)
+
+   </li>
+
+
+<li><b>Assurance:</b>
+
+<ul>
+   
+<li>Assurers</li>
+   
+<li> Any others authorised under COD13  </li>
+   </ul>
+   Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
+   </li>
+
+
+<li><b>Governance:</b>
+
+<ul>
+   
+<li>Directors (members of the CAcert Inc. committee, or "Board") </li>
+   
+<li>Internal Auditor</li>
+   
+<li>Arbitrator</li>
+   </ul>
+   </li>
+</ul>
+
+
+<h4 id="p5.2.2">5.2.2. Number of persons required per task</h4>
+<p>
+CAcert operates to the principles of <i>four eyes</i> and <i>dual control</i>.
+All important roles require a minimum of two persons.
+The people may be tasked to operate
+with an additional person observing (<i>four eyes</i>),
+or with two persons controlling (<i>dual control</i>).
+</p>
+
+<h4 id="p5.2.3">5.2.3. Identification and authentication for each role</h4>
+
+<p>
+All important roles are generally required to be assured
+at least to the level of Assurer, as per AP.
+Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
+</p>
+
+<p>
+<b>Technical.</b>
+Refer to Security Policy 9.1 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
+</p>
+
+<h4 id="p5.2.4">5.2.4. Roles requiring separation of duties</h4>
+
+<p>
+Roles strive in general for separation of duties, either along the lines of
+<i>four eyes principle</i> or <i>dual control</i>.
+</p>
+
+<h3 id="p5.3">5.3. Personnel controls</h3>
+
+<h4 id="p5.3.1">5.3.1. Qualifications, experience, and clearance requirements</h4>
+
+<center>
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<td><b>Role</b></td>
+<td><b>Policy</b></td>
+<td><b>Comments</b></td>
+ </tr>
+<tr>
+
+<td>Assurer</td>
+
+<td><a href="http://www.cacert.org/policy/AssurancePolicy.php"> COD13</a></td>
+
+<td>
+    Passes Challenge, Assured to 100 points.
+  </td>
+ </tr>
+<tr>
+
+<td>Organisation Assurer</td>
+
+<td><a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a></td>
+
+<td>
+    Trained and tested by two supervising OAs.
+  </td>
+ </tr>
+<tr>
+
+<td>Technical</td>
+
+<td>SM =&gt; COD08</td>
+
+<td>
+    Teams responsible for testing.
+  </td>
+ </tr>
+<tr>
+
+<td>Arbitrator</td>
+
+<td><a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a></td>
+
+<td>
+    Experienced Assurers.
+  </td>
+ </tr>
+</tbody>
+</table>
+
+<span class="figure">Table 5.3.1.  Controls on Roles</span>
+</center>
+
+
+<h4 id="p5.3.2">5.3.2. Background check procedures</h4>
+
+<p>
+Refer to Security Policy 9.1.3 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
+</p>
+
+<h4 id="p5.3.3">5.3.3. Training requirements</h4>
+<p>No stipulation.</p>
+<h4 id="p5.3.4">5.3.4. Retraining frequency and requirements</h4>
+<p>No stipulation.</p>
+
+<h4 id="p5.3.5">5.3.5. Job rotation frequency and sequence</h4>
+<p>No stipulation.</p>
+
+<h4 id="p5.3.6">5.3.6. Sanctions for unauthorized actions</h4>
+<p>
+Any actions that are questionable
+- whether uncertain or grossly negligent -
+may be filed as a dispute.
+The Arbitrator has wide discretion in
+ruling on loss of points, retraining,
+or termination of access or status.
+Refer to DRP.
+</p>
+
+<h4 id="p5.3.7">5.3.7. Independent contractor requirements</h4>
+<p>No stipulation.</p>
+
+<h4 id="p5.3.8">5.3.8. Documentation supplied to personnel</h4>
+<p>No stipulation.</p>
+
+<h3 id="p5.4">5.4. Audit logging procedures</h3>
+
+<p>
+Refer to Security Policy 4.2, 5 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
+</p>
+
+<h3 id="p5.5">5.5. Records archival</h3>
+<p>
+The standard retention period is 7 years.
+Once archived, records can only be obtained and verified
+by means of a filed dispute.
+Following types of records are archived:
+</p>
+
+<center>
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<td><b>Record</b></td>
+
+<td><b>Nature</b></td>
+
+<td><b>Exceptions</b></td>
+
+<td><b>Documentation</b></td>
+ </tr>
+<tr>
+
+<td>Member</td>
+
+<td>username, primary and added addresses, security questions, Date of Birth</td>
+
+<td>resigned non-subscribers: 0 years.</td>
+
+<td>Security Policy and Privacy Policy</td>
+ </tr>
+<tr>
+
+<td>Assurance</td>
+
+<td>CAP forms</td>
+
+<td>"at least 7 years."
+<br>
+ as per subsidiary policies</td>
+
+<td>Assurance Policy 4.5</td>
+ </tr>
+<tr>
+
+<td>Organisation Assurance</td>
+
+<td>COAP forms</td>
+
+<td>as per subsidiary policies</td>
+
+<td>Organisation Assurance Policy</td>
+ </tr>
+<tr>
+
+<td>certificates and revocations</td>
+
+<td>  for reliance </td>
+
+<td> 7 years after termination </td>
+
+<td>this CPS</td>
+ </tr>
+<tr>
+
+<td>critical roles</td>
+
+<td>background check worksheets</td>
+
+<td>under direct Arbitrator control</td>
+
+<td>Security Policy 9.1.3</td>
+ </tr>
+</tbody>
+</table>
+
+<span class="figure">Table 5.5.  Documents and Retention </span>
+</center>
+
+
+<h3 id="p5.6">5.6. Key changeover</h3>
+
+<p>
+Refer to Security Policy 9.2 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
+</p>
+
+<h3 id="p5.7">5.7. Compromise and disaster recovery</h3>
+
+<p>
+Refer to Security Policy 5, 6 (<a href="http://www.cacert.org/policy/SecurityPolicy.html">COD8</a>).
+(Refer to <a href="#p1.4">§1.4</a> for limitations to service.)
+</p>
+
+<p></p>
+
+<h3 id="p5.8">5.8. CA or RA termination</h3>
+
+<h4 id="p5.8.1">5.8.1. CA termination</h4>
+
+<p>
+In the event of operational termination, the
+Roots (including SubRoots)
+and all private Member information will be secured.
+The Roots will be handed over to a responsible
+party for the sole purpose of issuing revocations.
+Member information will be securely destroyed.
+</p>
+
+
+<h4 id="p5.8.2">5.8.2. RA termination</h4>
+
+<p>
+When an Assurer desires to voluntarily terminates
+her responsibilities, she does this by filing a dispute,
+and following the instructions of the Arbitrator.
+</p>
+
+<p>
+In the case of involuntary termination, the process is
+the same, save for some other party filing the dispute.
+</p>
+
+
+<!-- *************************************************************** -->
+<h2 id="p6">6. TECHNICAL SECURITY CONTROLS</h2>
+
+<h3 id="p6.1">6.1. Key Pair Generation and Installation</h3>
+
+<h4 id="p6.1.1">6.1.1. Key Pair Generation</h4>
+
+<p>
+Subscribers generate their own Key Pairs.
+</p>
+
+<h4 id="p6.1.2">6.1.2. Subscriber Private key security</h4>
+
+<p>
+There is no technical stipulation on how Subscribers generate
+and keep safe their private keys,
+however, CCA 2.5 provides for general security obligations.
+See <a href="#p9.6">§9.6</a>.
+</p>
+
+<h4 id="p6.1.3">6.1.3. Public Key Delivery to Certificate Issuer</h4>
+
+<p>
+Members login to their online account.
+Public Keys are delivered by cut-and-pasting
+them into the appropriate window.
+Public Keys are delivered in signed-CSR form
+for X.509 and in self-signed form for OpenPGP.
+</p>
+
+<h4 id="p6.1.4">6.1.4. CA Public Key delivery to Relying Parties</h4>
+
+<p>
+The CA root certificates are distributed by these means:
+</p>
+
+<ul>
+<li>
+    Published on the website of CAcert,
+    in both HTTP and HTTPS.
+  </li>
+<li>
+    Included in Third-Party Software such as
+    Browsers, Email-Clients.
+    Such suppliers are subject to the Third Party Vendor Agreement.
+</li>
+</ul>
+
+<h4 id="p6.1.5">6.1.5. Key sizes</h4>
+
+<p>
+No limitation is placed on Subscriber key sizes.
+</p>
+
+<p>
+CAcert X.509 root and intermediate keys are currently 4096 bits.
+X.509 roots use RSA and sign with the SHA-1 message digest algorithm.
+See <a href="#p4.3.1">§4.3.1</a>.
+</p>
+
+<p>
+OpenPGP Signing uses both RSA and DSA (1024 bits).
+</p>
+
+<p>
+CAcert adds larger keys and hashes
+in line with general cryptographic trends,
+and as supported by major software suppliers.
+</p>
+
+
+<h4 id="p6.1.6">6.1.6. Public key parameters generation and quality checking</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h4 id="p6.1.7">6.1.7. Key Usage Purposes</h4>
+
+
+<p>
+CAcert roots are general purpose.
+Each root key may sign all of the general purposes
+- client, server, code.
+</p>
+
+<p>
+The website controls the usage purposes that may be signed.
+This is effected by means of the 'template' system.
+</p>
+
+
+<h3 id="p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</h3>
+
+
+
+
+<h4 id="p6.2.1">6.2.1. Cryptographic module standards and controls</h4>
+
+<p>
+SubRoot keys are stored on a single machine which acts
+as a Cryptographic Module, or <i>signing server</i>.
+It operates a single daemon for signing only.
+The signing server has these security features:
+</p>
+
+<ul>
+<li>
+    It is connected only by one
+    dedicated (serial USB) link
+    to the online account server.
+    It is not connected to the network,
+    nor to any internal LAN (ethernet),
+    nor to a console switch.
+  </li>
+<li>
+    The protocol over the dedicated link is a custom, simple
+    request protocol that only handles certificate signing requests.
+  </li>
+<li>
+    The daemon is designed not to reveal the key.
+  </li>
+<li>
+    The daemon incorporates a dead-man switch that monitors
+    the one webserver machine that requests access.
+  </li>
+<li>
+    The daemon shuts down if a bad request is detected.
+  </li>
+<li>
+    The daemon resides on an encrypted partition.
+  </li>
+<li>
+    The signing server can only be (re)started with direct
+    systems administration access.
+  </li>
+<li>
+    Physical Access to the signing server is under dual control.
+</li>
+</ul>
+
+<p>
+See §5. and the Security Policy 9.3.1.
+</p>
+
+<p>
+(Hardware-based, commercial and standards-based cryptographic
+modules have been tried and tested, and similar have been tested,
+but have been found wanting, e.g., for short key lengths and
+power restrictions.)
+</p>
+
+
+<h3 id="p6.3">6.3. Other aspects of key pair management</h3>
+<h4 id="p6.3.1">6.3.1. Public key archival</h4>
+
+<p>
+Subscriber certificates, including public keys,
+are stored in the database backing the online system.
+They are not made available in a public- or subscriber-accessible
+archive, see §2.
+They are backed-up by CAcert's normal backup procedure,
+but their availability is a subscriber responsibility.
+</p>
+
+<h4 id="p6.3.2">6.3.2. Certificate operational periods and key pair usage periods</h4>
+
+<p>
+The operational period of a certificate and its key pair
+depends on the Assurance status of the Member,
+see <a href="#p1.4.5">§1.4.5</a> and Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
+</p>
+
+<p>
+The CAcert (top-level) Root certificate
+has a 30 year expiry.
+SubRoots have 10 years, and are to be rolled over more quickly.
+The keysize of the root certificates are chosen
+in order to ensure an optimum security to CAcert
+Members based on current recommendations from the
+<a href="http://www.keylength.com/">cryptographic community</a>
+and maximum limits in generally available software.
+At time of writing this is 4096 bits.
+</p>
+
+<h3 id="p6.4">6.4. Activation data</h3>
+<p> No stipulation.  </p>
+
+<h3 id="p6.5">6.5. Computer security controls</h3>
+<p>
+Refer to Security Policy.
+</p>
+
+<h3 id="p6.6">6.6. Life cycle technical controls</h3>
+<p>
+Refer to SM7 "Software Development".
+</p>
+
+<h3 id="p6.7">6.7. Network security controls</h3>
+<p>
+Refer to SM3.1 "Logical Security - Network".
+</p>
+
+<h3 id="p6.8">6.8. Time-stamping</h3>
+<p>
+Each server synchronises with NTP.
+No "timestamping" service is currently offered.
+</p>
+
+<!-- *************************************************************** -->
+<h2 id="p7">CERTIFICATE, CRL, AND OCSP PROFILES</h2>
+
+<p>
+CAcert defines all the meanings, semantics and profiles
+applicable to issuance of certificates and signatures
+in its policies, handbooks and other documents.
+Meanings that may be written in external standards or documents
+or found in wider conventions are not
+incorporated, are not used by CAcert, and must not be implied
+by the Member or the Non-related Person.
+</p>
+
+<h3 id="p7.1">7.1. Certificate profile</h3>
+<h4 id="p7.1.1">7.1.1. Version number(s)</h4>
+
+<p>
+Issued X.509 certificates are of v3 form.
+The form of the PGP signatures depends on several factors, therefore no stipulation.
+</p>
+
+<h4 id="p7.1.2">7.1.2. Certificate extensions</h4>
+
+<p>
+  Client certificates include the following extensions:
+</p>
+<ul>
+
+<li>basicConstraints=CA:FALSE (critical)</li>
+
+<li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
+
+<li>extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC</li>
+
+<li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
+
+<li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced
+    with the URI where the certificate revocation list relating to the
+    certificate is found</li>
+
+<li>subjectAltName=(as per <a href="#p3.1.1">§3.1.1.</a>).</li>
+</ul>
+
+
+<p>
+  Server certificates include the following extensions:
+</p>
+<ul>
+
+<li>basicConstraints=CA:FALSE (critical)</li>
+
+<li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
+
+<li>extendedKeyUsage=clientAuth,serverAuth,nsSGC,msSGC</li>
+
+<li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
+
+<li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced
+    with the URI where the certificate revocation list relating to the
+    certificate is found</li>
+
+<li>subjectAltName=(as per <a href="#p3.1.1">§3.1.1.</a>).</li>
+</ul>
+
+<p>
+  Code-Signing certificates include the following extensions:
+</p>
+<ul>
+
+<li>basicConstraints=CA:FALSE (critical)</li>
+
+<li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
+
+<li>extendedKeyUsage=emailProtection,clientAuth,codeSigning,msCodeInd,msCodeCom,msEFS,msSGC,nsSGC</li>
+
+<li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
+
+<li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced
+    with the URI where the certificate revocation list relating to the
+    certificate is found</li>
+
+<li>subjectAltName=(as per <a href="#p3.1.1">§3.1.1.</a>).</li>
+</ul>
+
+<p>
+OpenPGP key signatures currently do not include extensions.
+In the future, a serial number might be included as an extension.
+</p>
+
+
+<h4 id="p7.1.3">7.1.3. Algorithm object identifiers</h4>
+<p>
+No stipulation.
+</p>
+
+<h4 id="p7.1.4">7.1.4. Name forms</h4>
+<p>
+Refer to <a href="#p3.1.1">§3.1.1</a>.
+</p>
+
+<h4 id="p7.1.5">7.1.5. Name constraints</h4>
+<p>
+Refer to <a href="#p3.1.1">§3.1.1</a>.
+</p>
+
+<h4 id="p7.1.6">7.1.6. Certificate policy object identifier</h4>
+<p>
+The following OIDs are defined and should be incorporated
+into certificates:
+</p>
+
+<table border="1" cellpadding="5">
+<tbody>
+<tr>
+
+<td>
+    OID
+  </td>
+
+<td>
+    Type/Meaning
+  </td>
+
+<td>
+    Comment
+  </td>
+ </tr>
+<tr>
+
+<td>
+    1.3.6.1.4.1.18506.4.4
+  </td>
+
+<td>
+    Certification Practice Statement
+  </td>
+
+<td>
+    (this present document)
+  </td>
+ </tr>
+</tbody>
+</table>
+
+<p>
+Versions are defined by additional numbers appended such as .1.
+</p>
+
+<h4 id="p7.1.7">7.1.7. Usage of Policy Constraints extension</h4>
+<p>
+No stipulation.
+</p>
+
+<h4 id="p7.1.8">7.1.8. Policy qualifiers syntax and semantics</h4>
+<p>
+No stipulation.
+</p>
+
+<h4 id="p7.1.9">7.1.9. Processing semantics for the critical Certificate Policies extension</h4>
+<p>
+No stipulation.
+</p>
+
+
+<h3 id="p7.2">7.2. CRL profile</h3>
+<h4 id="p7.2.1">7.2.1. Version number(s)</h4>
+<p>
+CRLs are created in X.509 v2 format.
+</p>
+
+<h4 id="p7.2.2">7.2.2. CRL and CRL entry extensions</h4>
+
+<p>
+No extensions.
+</p>
+
+<h3 id="p7.3">7.3. OCSP profile</h3>
+<h4 id="p7.3.1">7.3.1. Version number(s)</h4>
+<p>
+The OCSP responder operates in Version 1.
+</p>
+<h4 id="p7.3.2">7.3.2. OCSP extensions</h4>
+<p>
+No stipulation.
+</p>
+
+
+
+<!-- *************************************************************** -->
+<h2 id="p8">8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS</h2>
+
+<p>
+There are two major threads of assessment:
+</p>
+
+<ul>
+<li>
+  <b>Systems Audit</b>.
+  Analyses the CA for business and operations security.
+  This is conducted in two phases:  documents for compliance
+  with criteria, and operations for compliance with documentation.
+  </li>
+<li>
+  <b>Code Audit</b>.
+  Analyses the source code.
+  This is conducted at two levels:
+  Security concepts at the web applications level,
+  and source code security and bugs review.
+</li>
+</ul>
+
+<p>
+See the Audit page at
+<a href="http://wiki.cacert.org/wiki/Audit/">
+wiki.cacert.org/wiki/Audit/</a>
+for more information.
+</p>
+
+<h3 id="p8.1">8.1. Frequency or circumstances of assessment</h3>
+<p>
+The first audits started in late 2005,
+and since then, assessments have been an
+ongoing task.
+Even when completed, they are expected to
+be permanent features.
+</p>
+
+<ul>
+<li>
+  <b>Systems Audit</b>.
+  </li>
+<li>
+  <b>Code Audit</b>.
+</li>
+</ul>
+
+<h3 id="p8.2">8.2. Identity/qualifications of assessor</h3>
+
+<p>
+<b>Systems Auditors.</b>
+CAcert uses business systems auditors with broad experience
+across the full range of business, information systems
+and security fields.
+In selecting a business systems auditor, CAcert looks for
+experience that includes but is not limited to
+cryptography, PKI, governance, auditing,
+compliance and regulatory environments,
+business strategy, software engineering,
+networks, law (including multijurisdictional issues),
+identity systems, fraud, IT management.
+</p>
+
+
+<p>
+<b>Code Auditors.</b>
+See Security Policy, sections 7, 9.1.
+</p>
+
+<h3 id="p8.3">8.3. Assessor's relationship to assessed entity</h3>
+
+<p>
+Specific internal restrictions on audit personnel:
+</p>
+
+<ul>
+<li>
+    Must be Assured by CAcert Assurers
+    and must be background checked.
+  </li>
+<li>
+    Must not have been active in any (other) role in CAcert.
+    Specifically, must not be an Assurer, a member of the association,
+    or in any other defined role or office.
+  </li>
+<li>
+    Although the Auditor may be expected to undertake various
+    of the activities (Assurance, Training)
+    during the process of the audit, any results are frozen
+    until resignation as auditor is effected.
+  </li>
+<li>
+    The Auditor is required to declare to CAcert all
+    potential conflicts of interest on an ongoing basis.
+</li>
+</ul>
+
+<p>
+Specific external restrictions on audit personnel:
+</p>
+
+<ul>
+<li>
+    Should have a verifiable and lengthy history in
+    user privacy and user security.
+  </li>
+<li>
+    Must not have worked for a competitive organisation.
+  </li>
+<li>
+    Must not have worked for national security, intelligence,
+    LEO or similar agencies.
+</li>
+</ul>
+
+<p>
+An Auditor may convene an audit team.
+The same restrictions apply in general
+to all members of the team, but may be varied.
+Any deviations must be documented and approved
+by the CAcert Inc. Board.
+</p>
+
+<h3 id="p8.4">8.4. Topics covered by assessment</h3>
+
+<p>
+Systems Audits are generally conducted to criteria.
+CAcert requires that the criteria are open:
+</p>
+
+<ul>
+<li>
+    Published.
+    The criteria must be reviewable by all interested parties.
+  </li>
+<li>
+    Understandable.
+    They should be understandable, in that they provide the
+    sufficient information in a readable form for interested
+    parties to follow the gist and importance.
+    (Arcane security criteria may stretch this requirement.)
+  </li>
+<li>
+    Complete.
+    There must be sufficent background information that the
+    whole story is there.  Especially, criteria that refer
+    to undocumented practices or conventions deliberately
+    kept secret must be avoided.
+  </li>
+<li>
+    Applicable.  The criteria should relate directly
+    and unambiguously to a need of the identified interested parties
+    (Members, Relying Parties, Subscribers, Assurers).
+</li>
+</ul>
+
+<p>
+See
+<a href="http://rossde.com/CA_review/">DRC</a>
+for the current criteria.
+If Auditor determines that a criteria fails to
+follow the meet the above requirements, then the criteria
+should be reworked to conform, or should be dropped
+(both with explanatory notes).
+</p>
+
+<h3 id="p8.5">8.5. Actions taken as a result of deficiency</h3>
+<p>
+See the current
+<a href="http://wiki.cacert.org/wiki/Audit/Done">Audit Done list</a>
+for work completed, and
+<a href="http://wiki.cacert.org/wiki/AuditToDo">Audit Todo list</a>
+for work in progress.
+</p>
+
+<p>
+Auditor may issue directives instructing changes,
+where essential to audit success or other extreme
+situations.
+Directives should be grounded on criteria,
+on established minimum or safe practices,
+or clearly described logic.
+Adequate discussion with Community
+(e.g., CAcert Inc. Board and with Policy Group)
+should precede any directive.
+They should be presented to the same standard
+as the criteria, above.
+</p>
+
+<p>
+The
+<a href="http://wiki.cacert.org/wiki/AuditDirectives">
+wiki.cacert.org/wiki/AuditDirectives</a>
+documents issued directives and actions.
+</p>
+
+<h3 id="p8.6">8.6. Communication of results</h3>
+
+<p>
+Current and past Audit information is available at
+<a href="http://wiki.cacert.org/wiki/Audit/">wiki.CAcert.org/wiki/Audit/</a>.
+CAcert runs an open disclosure policy and
+Audit is no exception.
+</p>
+
+<p>
+This CPS and other documents are subject to
+the process in Policy on Policy (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>).
+Audits cover the overall processes more
+than any one document, and documents may vary
+even as Audit reports are delivered.
+</p>
+
+
+
+
+<!-- *************************************************************** -->
+<h2 id="p9">9. OTHER BUSINESS AND LEGAL MATTERS</h2>
+<h3 id="p9.1">9.1. Fees</h3>
+
+
+<p>
+The current fees structure is posted at
+<a href="http://wiki.cacert.org/wiki/Price">wiki.cacert.org/wiki/Price</a>.
+Changes to the fees structure will be announced
+from time to time on the <a href="http://blog.cacert.org/">blog</a>.
+CAcert retains the right to charge fees for services.
+All fees are non-refundable.
+</p>
+
+
+<h3 id="p9.2">9.2. Financial responsibility</h3>
+
+<p>
+Financial risks are dealt with primarily by
+the Dispute Resolution Policy
+(<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>).
+</p>
+
+<h4 id="p9.2.1">9.2.1. Insurance coverage</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h4 id="p9.2.2">9.2.2. Other assets</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h4 id="p9.2.3">9.2.3. Insurance or warranty coverage for end-entities</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h3 id="p9.3">9.3. Confidentiality of business information</h3>
+
+<h4 id="p9.3.1">9.3.1. Scope of confidential information</h4>
+
+<p>
+CAcert has a policy of transparency and openness.
+The default posture is that information is public
+to the extent possible,
+unless covered by specific policy provisions
+(for example, passwords)
+or rulings by Arbitrator.
+</p>
+
+<h3 id="p9.4">9.4. Privacy of personal information</h3>
+
+<p>
+Privacy is covered by the
+CCA (COD9)
+and the Privacy Policy
+(<a href="https://www.cacert.org/policy/PrivacyPolicy.html">COD5</a>).
+</p>
+
+<h4 id="p9.4.1">9.4.1. Privacy plan</h4>
+<p> No stipulation.  </p>
+<h4 id="p9.4.2">9.4.2. Information treated as private</h4>
+<p>
+Member's Date of Birth and "Lost Password" questions are treated as fully private.
+</p>
+<h4 id="p9.4.3">9.4.3. Information not deemed private</h4>
+<p>
+To the extent that information is put into an issued certificate,
+that information is not deemed private,
+as it is expected to be published by the Member as part of routine use of
+the certificate.
+Such information generally includes
+Names, domains, email addresses, and certificate serial numbers.
+</p>
+<p>
+Under Assurance Policy
+(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
+the Member's status (as Assured, Assurer, etc) is available
+to other Members.
+</p>
+<p>
+Information placed in forums outside the online system
+(wiki, blogs, policies, etc) is not deemed private, and is
+generally deemed to be published as contributions by Members.
+See
+CCA1.3 (COD9).
+</p>
+<h4 id="p9.4.4">9.4.4. Responsibility to protect private information</h4>
+<p>
+CAcert is a privacy organisation
+and takes privacy more seriously.
+Any privacy issue may be referred to dispute resolution.
+</p>
+<h4 id="p9.4.5">9.4.5. Notice and consent to use private information</h4>
+<p>
+Members are permitted to rely on certificates of other Members.
+As a direct consequence of the general right to rely,
+Members may read and store the certificates
+and/or the information within them, where duly presented in
+a relationship, and to the extent necessary for
+the agreed relationship.
+</p>
+<h4 id="p9.4.6">9.4.6. Disclosure pursuant to judicial or administrative process</h4>
+<p>
+Any disclosure pursuant to process from foreign courts
+(or similar)
+is controlled by the Arbitrator.
+</p>
+<h4 id="p9.4.7">9.4.7. Other information disclosure circumstances</h4>
+<p>
+None.
+</p>
+
+<h3 id="p9.5">9.5. Intellectual property rights</h3>
+
+<p>
+CAcert is committed to the philosophy of
+an open and free Internet,
+broadly as encapsulated by open and free source.
+However, due to the strict control provisions
+imposed by the audit criteria (CCS),
+and the general environment and role of CAs,
+and the commitment to security of Members,
+some deviations are necessary.
+</p>
+
+
+<h4 id="p9.5.1">9.5.1. Ownership and Licence</h4>
+
+<p>
+Assets that fall under the control of CCS
+must be transferred to CAcert.
+See PoP 6.2
+(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>),
+CCA 1.3
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
+That is, CAcert is free to use, modify,
+distribute, and otherwise conduct the business
+of the CA as CAcert sees fit with the asset.
+</p>
+
+<h4 id="p9.5.2">9.5.2. Brand</h4>
+<p>
+The brand of CAcert
+is made up of its logo, name, trademark, service marks, etc.
+Use of the brand is strictly limited by the Board,
+and permission is required.
+See <a href="http://wiki.cacert.org/wiki/TopMinutes-20070917">
+m20070917.5</a>.
+</p>
+
+<h4 id="p9.5.3">9.5.3. Documents</h4>
+
+<p>
+CAcert owns or requires full control over its documents,
+especially those covered by CCS.
+See PoP 6.2
+(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>).
+Contributors transfer the rights,
+see CCA 1.3
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
+Contributors warrant that they have the right to transfer.
+</p>
+
+<p>
+Documents are generally licensed under free and open licence.
+See
+<a href="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
+wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence</a>.
+Except where explicitly negotiated,
+CAcert extends back to contributors a
+non-exclusive, unrestricted perpetual
+licence, permitting them to to re-use
+their original work freely.
+See PoP 6.4
+(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.4">COD1</a>),
+CCA 1.3
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
+</p>
+
+<h4 id="p9.5.4">9.5.4. Code</h4>
+
+<p>
+CAcert owns its code or requires full control over code in use
+by means of a free and open licence.
+See CCS.
+</p>
+
+
+<p>
+CAcert licenses its code under GPL.
+CAcert extends back to contributors a
+non-exclusive, unrestricted perpetual
+licence, permitting them to to re-use
+their original work freely.
+</p>
+
+<h4 id="p9.5.5">9.5.5. Certificates and Roots</h4>
+
+<p>
+CAcert asserts its intellectual property rights over certificates
+issued to Members and over roots.
+See CCA 4.4
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#4.4">COD9</a>),
+CCS.
+The certificates may only be used by Members under
+<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#4.4">COD9</a>,
+and,
+by others under the licences offered,
+such as
+Non-Related Persons - Disclaimer and Licence
+(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
+</p>
+
+<h3 id="p9.6">9.6. Representations and warranties</h3>
+
+
+<p>
+<b>Members.</b>
+All Members of the Community agree to the
+CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
+which is the primary document for
+representations and warranties.
+Members include Subscribers, Relying Parties,
+Registration Agents and the CA itself.
+</p>
+
+<p>
+<b>RAs.</b>
+Registration Agents are obliged additionally by Assurance Policy,
+especially 3.1, 4.1
+(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
+</p>
+
+<p>
+<b>CA.</b>
+The CA is obliged additionally by the CCS.
+</p>
+
+<p>
+<b>Third Party Vendors.</b>
+Distributors of the roots are offered the
+
+3rd-Party Vendors - Disclaimer and Licence
+(3PV-DaL =&gt; CODx)
+and are offered
+
+the same deal as Members to the extent that they agree
+to be Members in the Community.
+
+</p>
+
+<h3 id="p9.7">9.7. Disclaimers of Warranties</h3>
+
+<p>
+Persons who have not accepted the above Agreements are offered the
+Non-Related Persons - Disclaimer and Licence
+(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
+Any representations and
+warranties are strictly limited to nominal usage.
+In essence, NRPs may USE but must not RELY.
+</p>
+
+<p>
+In today's aggressive fraud environment,
+and within the context of CAcert as a community CA,
+all parties should understand that CAcert
+and its Subscribers, Assurers and other roles
+provide service on a Best Efforts basis.
+See <a href="#p1.4">§1.4</a>.
+CAcert seeks to provide an adequate minimum
+level of quality in operations for its Members
+without undue risks to NRPs.
+See
+<a href="http://svn.cacert.org/CAcert/principles.html">Principles</a>.
+</p>
+
+<p>
+CAcert on behalf of the Community and itself
+makes no Warranty nor Guarantee nor promise
+that the service or certificates are adequate
+for the needs and circumstances.
+</p>
+
+<h3 id="p9.8">9.8. Limitations of liability</h3>
+
+<h3 id="p9.9">9.9. Non-Related Persons </h3>
+
+<p>
+CAcert on behalf of related parties
+(RAs, Subscribers, etc) and itself
+disclaims all liability to NRPs
+in their usage of CA's certificates.
+See <a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>.
+</p>
+
+<h3 id="p9.10">9.10. Liabilities Between Members</h3>
+
+<p>
+Liabilities between Members
+are dealt with by internal dispute resolution,
+which rules on liability and any limits.
+See
+<a href="#9.13">§9.13</a>.
+</p>
+
+
+<h3 id="p9.11">9.11. Indemnities</h3>
+
+<p>
+No stipulation.
+</p>
+
+<h3 id="p9.12">9.12. Term and termination</h3>
+<h4 id="p9.12.1">9.12.1. Term</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h4 id="p9.12.2">9.12.2. Termination</h4>
+
+<p>
+Members file a dispute to terminate their agreement.
+See <a href="#p9.13">§9.13</a> and CCA 3.3
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.3">COD9</a>).
+</p>
+
+<p>
+Documents are varied (including terminated) under <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
+</p>
+
+<p>
+For termination of the CA, see <a href="#p5.8.1">§5.8.1</a>.
+</p>
+
+<h4 id="p9.12.3">9.12.3. Effect of termination and survival</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h3 id="p9.13">9.13. Individual notices and communications with participants</h3>
+
+<p>
+All participants are obliged to keep their listed
+primary email addresses in good working order.
+See CCA 3.5
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.5">COD9</a>).
+</p>
+
+
+<h3 id="p9.14">9.14. Amendments</h3>
+
+<p>
+Amendments to the CPS are controlled by <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
+Any changes in Member's Agreements are notified under CCA 3.4
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.4">COD9</a>).
+</p>
+
+<h3 id="p9.15">9.15. Dispute resolution provisions</h3>
+
+<p>
+CAcert provides a forum and facility for any Member
+or other related party to file a dispute.
+</p>
+
+<ul>
+<li>
+    The CAcert
+    Dispute Resolution Policy
+    (<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>)
+    includes rules for dispute resolution.
+  </li>
+<li>
+    Filing is done via email to
+    &lt; support AT cacert DOT org &gt;
+</li>
+</ul>
+
+<p>
+Members agree to file all disputes through CAcert's
+forum for dispute resolution.
+The rules include specific provisions to assist
+non-Members, etc, to file dispute in this forum.
+</p>
+
+
+<h3 id="p9.16">9.16. Governing law</h3>
+
+<p>
+The governing law is that of New South Wales, Australia.
+Disputes are generally heard before the Arbitrator
+under this law.
+Exceptionally, the Arbitrator may elect to apply the
+law of the parties and events, where in common,
+but this is unlikely because it may create results
+that are at odds with the Community.
+</p>
+
+<h3 id="p9.17">9.17. Compliance with Applicable Law</h3>
+
+<h3 id="p9.18">9.18. Digital Signature Law</h3>
+<p>
+The Commonwealth and States of Australia have passed
+various Electronic Transactions Acts that speak to
+digital signatures.  In summary, these acts follow
+the "technology neutral" model and permit but do not
+regulate the use of digital signatures.
+</p>
+
+<p>
+This especially means that the signatures created by
+certificates issued by CAcert are not in and of themselves
+legally binding human signatures, at least according to
+the laws of Australia.
+See <a href="#p1.4.3">§1.4.3</a>.
+However, certificates may play a part in larger signing
+applications.  See <a href="#p1.4.1">§1.4.1</a> for "digital signing" certificates.
+These applications may impose significant
+obligations, risks and liabilities on the parties.
+</p>
+
+<h3 id="p9.19">9.19. Privacy Law</h3>
+
+<p>
+See the Privacy Policy
+(<a href="https://www.cacert.org/policy/PrivacyPolicy.html">COD5</a>).
+</p>
+
+<h3 id="p9.20">9.20. Legal Process from External Forums</h3>
+
+<p>
+CAcert will provide information about
+its Members only under legal subpoena or
+equivalent process
+from a court of competent jurisdiction.
+Any requests made by legal subpoena are
+treated as under the Dispute Resolution Policy
+See
+<a href="#p9.13">§9.13</a>
+and
+<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>.
+That is, all requests are treated as disputes,
+as only a duly empanelled Arbitrator has the
+authorisation and authority to rule on the
+such requests.
+</p>
+<p>
+
+</p>
+<p>
+A subpoena should
+include sufficient legal basis to support
+an Arbitrator in ruling that information
+be released pursuant to the filing,
+including the names of claimants in any civil case
+and an indication as to whether the claimants are
+Members or not
+(and are therefore subject to Dispute Resolution Policy).
+</p>
+
+<h3 id="p9.21">9.21. Miscellaneous provisions</h3>
+<h4 id="p9.21.1">9.21.1. Entire agreement</h4>
+
+<p>
+All Members of the Community agree to the
+CAcert Community Agreement
+(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
+This agreement also incorporates other key
+documents, being this CPS, DRP and PP.
+See CCA 4.2.
+</p>
+
+<p>
+The Configuration-Control Specification
+is the set of policies that rule over the
+Community, of which the above documents are part.
+See COD2.
+Documents that have reached full POLICY status
+are located at
+<a href="http://www.cacert.org/policy/">
+www.cacert.org/policy/</a>.
+Although detailed practices may
+be found in other places on the website
+and on the wiki, the CCS documents that
+have reached DRAFT and POLICY status are
+the ruling documents.
+</p>
+
+<h4 id="p9.21.2">9.21.2. Assignment</h4>
+
+<p>
+The rights within CCA may not be ordinarily assigned.
+</p>
+
+<h4 id="p9.21.3">9.21.3. Severability</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h4 id="p9.21.4">9.21.4. Enforcement (attorneys' fees and waiver of rights)</h4>
+
+<p>
+The Arbitrator will specify fees and remedies, if any.
+</p>
+
+<h4 id="p9.21.5">9.21.5. Force Majeure</h4>
+
+<p>
+No stipulation.
+</p>
+
+<h2 id="p10">---This is the end of the Policy---</h2>
+
+
+</body>
+</html>
diff --git a/www/policy/CertificationPracticeStatement.php b/www/policy/CertificationPracticeStatement.php
index 415bbe2..adffa0e 100644
--- a/www/policy/CertificationPracticeStatement.php
+++ b/www/policy/CertificationPracticeStatement.php
@@ -1,4087 +1,4 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-    <meta name="copyright" content="CAcert Inc http://www.cacert.org/">
-    <title>Certification Practice Statement (CPS)</title>
-
-<style type="text/css">
-<!--
-body {
-	font-family : verdana, helvetica, arial, sans-serif;
-}
-
-pre, code, kbd, tt, samp {
-	font-family : courier, monospace;
-}
-
-th {
-	text-align : left;
-}
-
-.blockpar {
-	text-indent : 2em;
-	margin-top : 0em;
-	margin-bottom : 0.5em;
-	text-align : justify;
-}
-
-.figure {
-	text-align : center;
-	color : gray;
-	margin-top : 0.5em;
-}
-
-.center {
-	text-align : center;
-}
-
-.q {
-	color : green;
-	font-weight: bold;
-	text-align: center;
-	font-style:italic;
-}
-
-.error {
-	color : red;
-	font-weight: bold;
-	text-align: center;
-	font-style:italic;
-}
-
-.change {
-	color : blue;
-	font-weight: bold;
-}
-
-a:hover {
-	color : gray;
-}
--->
-</style>
-
-
-</head>
-<body>
-
-<h1>CAcert CPS and CP</h1>
-
-<a href="PolicyOnPolicy.html"><img src="cacert-draft.png" alt="CAcert Policy Status" height="31" width="88" style="border-style: none;" /></a><br />
-Creation date: 20060726<br />
-Status: DRAFT p20091108<br />
-<!-- $Id: CertificationPracticeStatement.php,v 1.3 2012/07/27 16:00:29 wytze Exp $ -->
-
-
-<font size="-1">
-
-<ol>
-  <li> <a href="#p1">INTRODUCTION</a>
-   <ul>
-    <li><a href="#p1.1">1.1. Overview</a></li>
-    <li><a href="#p1.2">1.2. Document name and identification</a></li>
-    <li><a href="#p1.3">1.3. PKI participants</a> </li>
-    <li><a href="#p1.4">1.4. Certificate usage</a> </li>
-    <li><a href="#p1.5">1.5. Policy administration</a> </li>
-    <li><a href="#p1.6">1.6. Definitions and acronyms</a></li>
-   </ul>
-  </li>
-  <li> <a href="#p2">PUBLICATION AND REPOSITORY RESPONSIBILITIES</a>
-   <ul>
-    <li><a href="#p2.1">2.1. Repositories</a></li>
-    <li><a href="#p2.2">2.2. Publication of certification information</a></li>
-    <li><a href="#p2.3">2.3. Time or frequency of publication</a></li>
-    <li><a href="#p2.4">2.4. Access controls on repositories</a></li>
-   </ul>
-  </li>
-  <li> <a href="#p3">IDENTIFICATION AND AUTHENTICATION (I&amp;A)</a>
-   <ul>
-    <li><a href="#p3.1">3.1. Naming</a> </li>
-    <li><a href="#p3.2">3.2. Initial Identity Verification</a> </li>
-    <li><a href="#p3.3">3.3. I&amp;A for Re-key Requests</a> </li>
-    <li><a href="#p3.4">3.4. I&amp;A for Revocation Request</a></li>
-   </ul>
-  </li>
-  <li><a href="#p4">CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a>
-   <ul>
-    <li><a href="#p4.1">4.1. Certificate Application</a> </li>
-    <li><a href="#p4.2">4.2. Certificate application processing</a> </li>
-    <li><a href="#p4.3">4.3. Certificate issuance</a> </li>
-    <li><a href="#p4.4">4.4. Certificate acceptance</a> </li>
-    <li><a href="#p4.5">4.5. Key pair and certificate usage</a> </li>
-    <li><a href="#p4.6">4.6. Certificate renewal</a> </li>
-    <li><a href="#p4.7">4.7. Certificate re-key</a> </li>
-    <li><a href="#p4.8">4.8. Certificate modification</a> </li>
-    <li><a href="#p4.9">4.9. Certificate revocation and suspension</a> </li>
-    <li><a href="#p4.10">4.10. Certificate status services</a> </li>
-    <li><a href="#p4.11">4.11. End of subscription</a></li>
-    <li><a href="#p4.12">4.12. Key escrow and recovery</a> </li>
-   </ul>
-  </li>
-  <li><a href="#p5">FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a>
-   <ul>
-    <li><a href="#p5.1">5.1. Physical controls</a> </li>
-    <li><a href="#p5.2">5.2. Procedural controls</a> </li>
-    <li><a href="#p5.3">5.3. Personnel controls</a> </li>
-    <li><a href="#p5.4">5.4. Audit logging procedures</a> </li>
-    <li><a href="#p5.5">5.5. Records archival</a> </li>
-    <li><a href="#p5.6">5.6. Key changeover</a></li>
-    <li><a href="#p5.7">5.7. Compromise and disaster recovery</a> </li>
-    <li><a href="#p5.8">5.8. CA or RA termination</a></li>
-   </ul>
-  </li>
-  <li><a href="#p6">TECHNICAL SECURITY CONTROLS</a>
-   <ul>
-    <li><a href="#p6.1">6.1. Key pair generation and installation</a> </li>
-    <li><a href="#p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a> </li>
-    <li><a href="#p6.3">6.3. Other aspects of key pair management</a> </li>
-    <li><a href="#p6.4">6.4. Activation data</a> </li>
-    <li><a href="#p6.5">6.5. Computer security controls</a> </li>
-    <li><a href="#p6.6">6.6. Life cycle technical controls</a> </li>
-    <li><a href="#p6.7">6.7. Network security controls</a></li>
-    <li><a href="#p6.8">6.8. Time-stamping</a></li>
-   </ul>
-  </li>
-  <li><a href="#p7">CERTIFICATE, CRL, AND OCSP PROFILES</a>
-   <ul>
-    <li><a href="#p7.1">7.1. Certificate profile</a> </li>
-    <li><a href="#p7.2">7.2. CRL profile</a> </li>
-    <li><a href="#p7.3">7.3. OCSP profile</a> </li>
-   </ul>
-  </li>
-  <li><a href="#p8">COMPLIANCE AUDIT AND OTHER ASSESSMENTS</a>
-   <ul>
-    <li><a href="#p8.1">8.1. Frequency or circumstances of assessment</a></li>
-    <li><a href="#p8.2">8.2. Identity/qualifications of assessor</a></li>
-    <li><a href="#p8.3">8.3. Assessor's relationship to assessed entity</a></li>
-    <li><a href="#p8.4">8.4. Topics covered by assessment</a></li>
-    <li><a href="#p8.5">8.5. Actions taken as a result of deficiency</a></li>
-    <li><a href="#p8.6">8.6. Communication of results</a></li>
-   </ul>
-  </li>
-  <li><a href="#p9">OTHER BUSINESS AND LEGAL MATTERS</a>
-   <ul>
-    <li><a href="#p9.1">9.1. Fees</a> </li>
-    <li><a href="#p9.2">9.2. Financial responsibility</a> </li>
-    <li><a href="#p9.3">9.3. Confidentiality of business information</a> </li>
-    <li><a href="#p9.4">9.4. Privacy of personal information</a> </li>
-    <li><a href="#p9.5">9.5. Intellectual property rights</a></li>
-    <li><a href="#p9.6">9.6. Representations and warranties</a> </li>
-    <li><a href="#p9.7">9.7. Disclaimers of warranties</a></li>
-    <li><a href="#p9.8">9.8. Limitations of liability</a></li>
-    <li><a href="#p9.9">9.9. Indemnities</a></li>
-    <li><a href="#p9.10">9.10. Term and termination</a> </li>
-    <li><a href="#p9.11">9.11. Individual notices and communications with participants</a></li>
-    <li><a href="#p9.12">9.12. Amendments</a> </li>
-    <li><a href="#p9.13">9.13. Dispute resolution provisions</a></li>
-    <li><a href="#p9.14">9.14. Governing law</a></li>
-    <li><a href="#p9.15">9.15. Compliance with applicable law</a></li>
-    <li><a href="#p9.16">9.16. Miscellaneous provisions</a> </li>
-   </ul>
-  </li>
-</ol>
-
-</font>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p1" id="p1">1. INTRODUCTION</a></h2>
-
-<h3><a name="p1.1" id="p1.1">1.1. Overview</a></h3>
-
-<p>
-This document is the Certification Practice Statement (CPS) of
-CAcert, the Community Certification Authority (CA).
-It describes rules and procedures used by CAcert for
-operating its CA,
-and applies to all CAcert PKI Participants,
-including Assurers, Members, and CAcert itself.
-</p>
-
-<p>
-</p>
-
-<h3><a name="p1.2" id="p1.2">1.2. Document name and identification</a></h3>
-
-<p>
-This document is the Certification Practice Statement (CPS) of CAcert.
-The CPS also fulfills the role of the Certificate Policy (CP)
-for each class of certificate.
-</p>
-
-<ul>
-  <li>
-    This document is COD6 under CAcert Official Documents numbering scheme.
-  </li>
-  <li>
-    The document is structured according to
-    Chokhani, et al,
-    <a href="http://www.ietf.org/rfc/rfc3647.txt">RFC3647</a>,
-    <a href="http://tools.ietf.org/html/rfc3647#section-4">chapter 4</a>.
-    All headings derive from that Chapter.
-  </li>
-  <li>
-    It has been improved and reviewed (or will be reviewed)
-    to meet or exceed the criteria of the
-    <cite>Certificate Authority Review Checklist</cite>
-    from <i>David E. Ross</i> ("DRC")
-    and Mozilla Foundation's CA policy.
-  </li>
-  <li>
-    OID assigned to this document: 1.3.6.1.4.1.18506.4.4.x (x=approved Version)
-    (<a href="http://www.iana.org/assignments/enterprise-numbers">iana.org</a>)
-    <p class="q"> .x will change to .1 in the first approved instance.</p>
-  </li>
-  <li>
-    &copy; CAcert Inc. 2006-2009.
-    <!-- note that CCS policies must be controlled by CAcert Inc. -->
-  </li>
-  <li>
-    Issued under the CAcert document licence policy,
-    as and when made policy.
-    See <a href="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
-    PolicyDrafts/DocumentLicence</a>.
-     <ul class="q">
-       <li> The cited page discusses 2 options:  CCau Attribute-Share-alike and GNU Free Document License.  Refer to that.  </li>
-       <li> Note that the noun Licence in Australian English has two Cs.  The verb License is spelt the same way as American English. </li>
-     </ul>
-  </li>
-  <li>
-    Earlier notes were written by Christian Barmala
-    in a document placed under GNU Free Document License
-    and under FSF copyright.
-    However this clashed with the control provisions of
-    Configuration-Control Specification
-    (COD2) within Audit criteria.
-  </li>
-  <li>
-    <span class="q">In this document:</span>
-    <ul>
-      <li>
-        <span class="q">green text</span>
-        refers to questions that seek answers,
-      </li><li>
-         <span class="error">red text</span>
-         refers to probably audit fails or serious errors.
-      </li><li>
-         <span class="change">blue text</span>
-         refers to changes written after the document got seriously reviewed.
-    </ul>
-    <span class="q">
-    None is to be considered part of the policy,
-    and they should disappear in the DRAFT
-    and must disappear in the POLICY.
-    </span>
-  </li>
-<!--
-  <li>
-    Some content is incorporated under
-<!--     <a href="http://xkcd.com/license.html">Creative Commons license</a> -->
-<!--     from <a href="http://xkcd.com/">xkcd.com</a>. -->
-    198 177 515
-  </li>
--->
-</ul>
-
-<p>
-The CPS is an authoritive document,
-and rules other documents
-except where explicitly deferred to.
-See also <a href="#p1.5.1">1.5.1 Organisation Administering the Document</a>.
-</p>
-
-<h3><a name="p1.3" id="p1.3">1.3. PKI participants</a></h3>
-<p>
-The CA is legally operated by CAcert Incorporated,
-an Association registered in 2002 in
-New South Wales, Australia,
-on behalf of the wider Community of Members of CAcert.
-The Association details are at the
-<a href="http://wiki.cacert.org/wiki/CAcertIncorporated">CAcert wiki</a>.
-</p>
-
-<p>
-CAcert is a Community formed of Members who agree to the
-<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">
-CAcert Community Agreement</a>.
-The CA is technically operated by the Community,
-under the direction of the Board of CAcert Incorporated.
-(The Members of the Community are not to be confused
-with the <i>Association Members</i>, which latter are
-not referred to anywhere in this CPS.)
-</p>
-
-<h4><a name="p1.3.1" id="p1.3.1">1.3.1. Certification authorities</a></h4>
-<p>
-CAcert does not issue certificates to external
-intermediate CAs under the present CPS.
-</p>
-
-<h4><a name="p1.3.2" id="p1.3.2">1.3.2. Registration authorities</a></h4>
-<p>
-Registration Authorities (RAs) are controlled under Assurance Policy
-(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
-</p>
-
-<h4><a name="p1.3.3" id="p1.3.3">1.3.3. Subscribers</a></h4>
-
-<p>
-CAcert issues certificates to Members only.
-Such Members then become Subscribers.
-</p>
-
-
-<h4><a name="p1.3.4" id="p1.3.4">1.3.4. Relying parties</a></h4>
-
-<p>
-A relying party is a Member,
-having agreed to the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
-who, in the act of using a CAcert certificate,
-makes a decision on the basis of that certificate.
-</p>
-
-<h4><a name="p1.3.5" id="p1.3.5">1.3.5. Other participants</a></h4>
-
-<p>
-<b>Member.</b>
-Membership of the Community is as defined in the
-<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>.
-Only Members may RELY or may become Subscribers.
-Membership is free.
-</p>
-
-<p>
-<b>Arbitrator.</b>
-A senior and experienced Member of the CAcert Community
-who resolves disputes between Members, including ones
-of certificate reliance, under
-Dispute Resolution Policy
-(<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>).
-</p>
-
-<p>
-<b>Vendor.</b>
-Software suppliers who integrate the root certificates of CAcert
-into their software also assume a proxy role of Relying Parties,
-and are subject to another licence.
-<span class="q">
-At the time of writing, the
-"3rd Party Vendor - Disclaimer and Licence"
-is being worked upon, but is neither approved nor offered.
-</span>
-</p>
-
-<p>
-<b>Non-Related Persons</b> (NRPs).
-These are users of browsers and similar software who are
-unaware of the CAcert certificates they may use, and
-are unaware of the ramifications of usage.
-Their relationship with CAcert
-is described by the
-Non-related Persons - Disclaimer and Licence
-(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
-No other rights nor relationship is implied or offered.
-</p>
-
-
-<h3><a name="p1.4" id="p1.4">1.4. Certificate usage</a></h3>
-
-<p>CAcert serves as issuer of certificates for
-individuals, businesses, governments, charities,
-associations, churches, schools,
-non-governmental organisations or other groups.
-CAcert certificates are intended for low-cost
-community applications especially where volunteers can
-become Assurers and help CAcert to help the Community.
-</p>
-
-<p>
-Types of certificates and their appropriate and
-corresponding applications are defined in
-<a href="#p1.4.1">&sect;1.4.1</a>.
-Prohibited applications are defined in <a href="#p1.4.2">&sect;1.4.2</a>.
-Specialist uses may be agreed by contract or within
-a specific environment, as described in
-<a href="#p1.4.4">&sect;1.4.4</a>.
-Note also the
-unreliable applications in
-<a href="#p1.4.3">&sect;1.4.3</a>
-and risks, liabilities and obligations in
-<a href="#p9">&sect;9</a>.
-</p>
-
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
-  <td colspan="2"><center><i>Type</center></i></td>
-  <td colspan="2"><center><i>Appropriate Certificate uses</center></i></th>
- </tr>
- <tr>
-  <th>General</th>
-  <th>Protocol</th>
-  <th><center>Description</center></th>
-  <th><center>Comments</center></th>
- </tr>
- <tr>
-  <td rowspan="2"><center>Server</center></td>
-  <td> TLS </td>
-  <td> web server encryption </td>
-  <td> enables encryption </td>
- </tr>
- <tr>
-  <td> embedded </td>
-  <td> embedded server authentication </td>
-  <td> mail servers, IM-servers </td>
- </tr>
- <tr>
-  <td rowspan="4"><center>Client</center></td>
-  <td> S/MIME </td>
-  <td> email encryption </td>
-  <td> "digital signatures" employed in S/MIME
-       are not legal / human signatures,
-       but instead enable the encryption mode of S/MIME </td>
- </tr>
- <tr>
-  <td> TLS </td>
-  <td> client authentication </td>
-  <td> the nodes must be secure </td>
- </tr>
- <tr>
-  <td> TLS </td>
-  <td> web based signature applications </td>
-  <td> the certificate authenticates only.  See <a href="#p1.4.3">&sect;1.4.3</a>. </td>
- </tr>
- <tr>
-  <td> &quot;Digital Signing&quot; </td>
-  <td> for human signing over documents </td>
-  <td> Only within a wider application and rules
-       such as by separate policy,
-       as agreed by contract, etc.
-       See <a href="#p1.4.4">&sect;1.4.4</a>. 
-       </td>
- </tr>
- <tr>
-  <td><center>Code</center></td>
-  <td> Authenticode, ElfSign, Java </td>
-  <td> Code Signing </td>
-  <td> Signatures on packages are evidence of their Membership and indicative of Identity </td>
- </tr>
- <tr>
-  <td><center>PGP</center></td>
-  <td> OpenPGP </td>
-  <td> Key Signing </td>
-  <td> Signatures on Member Keys are evidence of their Membership and indicative of Identity </td>
- </tr>
- <tr>
-  <td><center>Special</center></td>
-  <td> X.509 </td>
-  <td> OCSP, Timestamping </td>
-  <td> Only available to CAcert Systems Administrators, as controlled by Security Policy </td>
- </tr>
-</table>
-
-<span class="figure">Table 1.4.  Types of Certificate</span>
-</center>
-
-<h4><a name="p1.4.1" id="p1.4.1">1.4.1. Appropriate certificate uses</a></h4>
-
-<p>
-General uses.
-</p>
-
-<ul><li>
-    CAcert server certificates can be used to enable encryption
-    protection in web servers.
-    Suitable applications include webmail and chat forums.
-  </li><li>
-    CAcert server certificates can be used to enable encryption
-    in SSL/TLS links in embedded protocols such as mail servers
-    and IM-servers.
-  </li><li>
-    CAcert client certificates can be used to enable encryption
-    protection in email clients.
-    (See <a href="#p1.4.3">&sect;1.4.3</a> for caveat on signatures.)
-  </li><li>
-    CAcert client certificates can be used to replace password-based
-    authentication to web servers.
-  </li><li>
-    OpenPGP keys with CAcert signatures can be used
-    to encrypt and sign files and emails,
-    using software compatible with OpenPGP.
-  </li><li>
-    CAcert client certificates can be used in web-based
-    authentication applications.
-  </li><li>
-    CAcert code signing certificates can be used to sign code
-    for distribution to other people.
-  </li><li>
-    Time stamping can be used to attach a time record
-    to a digital document.
-</li></ul>
-
-
-<h4><a name="p1.4.2" id="p1.4.2">1.4.2. Prohibited certificate uses</a></h4>
-<p>
-CAcert certificates are not designed, intended, or authorised for
-the following applications:
-</p>
-<ul><li>
-    Use or resale as control equipment in hazardous circumstances
-    or for uses requiring fail-safe performance such as the operation
-    of nuclear facilities, aircraft navigation or communication systems,
-    air traffic control systems, or weapons control systems,
-    where failure could lead directly to death, personal injury,
-    or severe environmental damage.
-</li></ul>
-
-<h4><a name="p1.4.3" id="p1.4.3">1.4.3. Unreliable Applications</a></h4>
-
-<p>
-CAcert certificates are not designed nor intended for use in
-the following applications, and may not be reliable enough
-for these applications:
-</p>
-
-<ul><li>
-    <b>Signing within Protocols.</b>
-    Digital signatures made by CAcert certificates carry
-    <u>NO default legal or human meaning</u>.
-    See <a href="#p9.15.1">&sect;9.15.1</a>.
-    Especially, protocols such as S/MIME commonly will automatically
-    apply digital signatures as part of their protocol needs.
-    The purpose of the cryptographic signature in S/MIME
-    and similar protocols is limited by default to strictly
-    protocol security purposes: 
-    to provide some confirmation that a familiar certificate
-    is in use, to enable encryption, and to ensure the integrity
-    of the email in transit.
-</li><li>
-    <b>Non-repudiation applications.</b>
-    Non-repudiation is not to be implied from use of
-    CAcert certificates.  Rather, certificates may
-    provide support or evidence of actions, but that
-    evidence is testable in any dispute.
-</li><li>
-    <b>Ecommerce applications.</b>
-    Financial transactions or payments or valuable e-commerce.
-</li><li>
-    Use of anonymous (Class 1 or Member SubRoot) certificates
-    in any application that requires or expects identity.
-</li></ul>
-
-<!-- <center><a href="http://xkcd.com/341/"> <img src="http://imgs.xkcd.com/comics/1337_part_1.png"> </a> </center> -->
-
-<h4><a name="p1.4.4" id="p1.4.4">1.4.4. Limited certificate uses</a></h4>
-
-<p>
-By contract or within a specific environment
-(e.g. internal to a company),
-CAcert Members are permitted to use Certificates
-for higher security, customised or experimental applications.
-Any such usage, however, is limited to such entities
-and these entities take on the whole responsible for
-any harm or liability caused by such usage.
-</p>
-
-<p>
-    <b>Digital signing applications.</b>
-    CAcert client certificates
-    may be used by Assured Members in
-    applications that provide or support the human signing of documents
-    (known here as "digital signing").
-    This must be part of a wider framework and set of rules.
-    Usage and reliance
-    must be documented either under a separate CAcert digital signing 
-    policy or other external regime agreed by the parties.
-</p>
-
-<h4><a name="p1.4.5" id="p1.4.5">1.4.5. Roots and Names</a></h4>
-
-<p>
-<b>Named Certificates.</b>
-Assured Members may be issued certificates
-with their verified names in the certificate.  In this role, CAcert
-operates and supports a network of Assurers who verify the
-identity of the Members.
-All Names are verified, either by Assurance or another defined
-method under policy (c.f. Organisations).
-</p>
-
-<p>
-<b>Anonymous Certificates.</b>
-Members can be issued certificates that are anonymous,
-which is defined as the certificate with no Name included,
-or a shared name such as "Community Member".
-These may be considered to be somewhere between Named certificates
-and self-signed certificates.  They have serial numbers in them
-which is ultimately traceable via dispute to a Member, but
-reliance is undefined.
-In this role, CAcert provides the
-infrastructure, saving the Members from managing a difficult
-and messy process in order to get manufactured certificates.
-</p>
-
-<p>
-<b>Psuedonymous Certificates.</b>
-Note that CAcert does not currently issue pseudonymous certificates,
-being those with a name chosen by the Member and not verifiable
-according to documents.
-</p>
-
-<p>
-<b>Advanced Certificates.</b>
-Members who are as yet unassured are not permitted to create
-advanced forms such as wildcard or subjectAltName
-certificates.
-</p>
-
-
-<p>
-<b> Roots.</b>
-The <span class="q"> (new) </span> CAcert root layout is as below.
-These roots are pending Audit,
-and will be submitted to vendors via the (Top-level) Root.
-</p>
-<ul><li>
-    <b>(Top-level) Root.</b>
-    Used to sign on-line CAcert SubRoots only.
-    This Root is kept offline.
-  </li><li>
-    <b>Member SubRoot.</b>
-    For Community Members who are new and unassured (some restrictions exist).
-    Reliance is undefined.
-    (Replacement for the Class 1 root, matches "Domain Validation" type.)
-  </li><li>
-    <b>Assured SubRoot.</b>
-    Only available for Assured individual Members,
-    intended to sign certificates with Names.
-    Suitable for Reliance under this and other policies.
-    Approximates the type known as Individual Validation.
-  </li><li>
-    <b>Organisation SubRoot.</b>
-    Only available for Assured Organisation Members.
-    Suitable for Reliance under this and other policies.
-    Approximates the type known as Organisational Validation.
-
-</li></ul>
-
-
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
-  <td></td>
-  <td colspan="5"><center><i>Level of Assurance</center></i></td>
-  <th> </th>
- </tr>
- <tr>
-  <th></th>
-  <th colspan="2"><center> Members &dagger; </center></th>
-  <th colspan="2"><center> Assured Members</center></th>
-  <th colspan="1"><center> Assurers </center></th>
-  <th colspan="1"><center> </center></th>
- </tr>
- <tr>
-  <td><i>Class of Root</i></td>
-  <th>Anon</th>
-  <td>Name</td>
-  <td>Anon</td>
-  <th>Name</th>
-  <td>Name+Anon</td>
-  <td colspan="1"><center><i>Remarks</center></i></td>
- </tr>
- <tr>
-  <td><center>Top level<br><big><b>Root</b></big></center></td>
-  <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </th>
-  <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </th>
-  <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &bull; </font> </center> </td>
-  <td> Signs other CAcert SubRoots only. </td>
- </tr>
- <tr>
-  <td><center><big><b>Member</b></big><br>SubRoot</center></td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> &dagger; For Members meeting basic checks in <a href="#p4.2.2">&sect;4.2.2</a><br>(Reliance is undefined.) </td>
- </tr>
- <tr>
-  <td><center><big><b>Assured</b></big><br>SubRoot</center></td>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> Assured Members only.<br>Fully intended for reliance. </td>
- </tr>
- <tr>
-  <td><center><big><b>Organisation</b></big><br>SubRoot</center></td>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> Assured Organisation Members only.<br>Fully intended for reliance. </td>
- </tr>
- <tr>
-  <th>Expiry of Certificates</th>
-  <td colspan="2"><center>6 months</center></th>
-  <td colspan="3"><center>24 months</center></th>
- </tr>
- <tr>
-  <th>Types</th>
-  <td colspan="2"><center>client, server</center></th>
-  <td colspan="2"><center>wildcard, subjectAltName</center></th>
-  <td colspan="1"><center>code-signing</center></th>
-  <td> (Inclusive to the left.) </td>
- </tr>
-</table>
-
-<span class="figure">Table 1.4.5.b  Certificate under Audit Roots</span>
-</center>
-
-
-<p class="q">
-Following information on OLD roots here for
-descriptive and historical purposes only.
-When CPS goes to DRAFT, this needs to be
-converted into a short summary of the way
-OLD roots are used and its relationship to
-this CPS.  E.g., "OLD roots are used for
-testing and other purposes outside this CPS."
-Because ... they still exist, and people will
-look at the CPS to figure it out.
-</p>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
-  <td></td>
-  <td colspan="4"><center><i>Level of Assurance</center></i></td>
-  <th> </th>
- </tr>
- <tr>
-  <th></th>
-  <th colspan="2"><center>Members</center></th>
-  <th colspan="2"><center>Assured Members</center></th>
-  <th colspan="1"><center> </center></th>
- </tr>
- <tr>
-  <td><i>Class of Root</i></td>
-  <th>Anonymous</th>
-  <td>Named</td>
-  <td>Anonymous</td>
-  <th>Named</th>
-  <td colspan="1"><center><i>Remarks</center></i></td>
- </tr>
- <tr>
-  <td><center>Class<br><big><b>1</b></big></center></td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> Available for all Members,<br>reliance is undefined.</td>
- </tr>
- <tr>
-  <td><center>Class<br><big><b>3</b></big></center></td>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
-  <td> <center> <font title="pass." color="red" size="+3"> &#10008; </font> </center> </th>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> <center> <font title="pass." color="green" size="+3"> &#10004; </font> </center> </td>
-  <td> Assured Members only.<br> Intended for Reliance. </center> </td>
- </tr>
- <tr>
-  <th>Expiry of Certificates</th>
-  <td colspan="2"><center>6 months</center></th>
-  <td colspan="2"><center>24 months</center></th>
- </tr>
- <tr>
-  <th>Types available</th>
-  <td colspan="2"><center>simple only</center></th>
-  <td colspan="2"><center>wildcard, subjectAltName</center></th>
- </tr>
-</table>
-
-<span class="figure">Table 1.4.5.  Certificates under Old Roots - <b>Audit Fail</b>  </span>
-</center>
-
-<p>
-<b> Old Roots.</b>
-The old CAcert root layout is as below.  These roots are <b>Audit Fail</b>
-and will only be used where new roots do not serve:
-</p>
-<ul><li>
-    (old) <b>Class 1 root.</b>
-    Used primarily for certificates with no names and by
-    unassured Members.
-    For compatibility only,
-    Assured Members may also use this root.
-  </li><li>
-    (old) <b>Class 3 root.</b>
-    Used primarily for certificates including the names
-    of Assured Members.
-    Signed by Class 1 root.
-    Members can decide to rely on these
-    certificates for Assured Members
-    by selecting the Class 3 root for
-    Assured Members as trust anchor.
-</li></ul>
-
-  <ul class="q">
-    <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>
-    <li> scheme for future roots is at <a href="http://wiki.cacert.org/wiki/Roots/NewRootsTaskForce">NewRootsTaskForce</a>.</li>
-    <li>END OLD ROOTS </li>
-  </ul>
-
-<h3><a name="p1.5" id="p1.5">1.5. Policy administration</a></h3>
-
-<p>See <a href="#p1.2">1.2 Document Name and Identification</a>
-  for general scope of this document.</p>
-
-<h4><a name="p1.5.1" id="p1.5.1">1.5.1. Organization administering the document</a></h4>
-
-<p>
-This document is administered by the policy group of
-the CAcert Community under Policy on Policy (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>).
-</p>
-
-<h4><a name="p1.5.2" id="p1.5.2">1.5.2. Contact person</a></h4>
-<p>
-For questions including about this document:
-</p>
-
-<ul>
-  <li>Join the policy group, by means of the discussion forum at
-  <a href="http://lists.cacert.org/mailman/listinfo">
-  lists.cacert.org</a> . </li>
-  <li>Send email to &lt; support AT cacert DOT org &gt; </li>
-  <li>IRC: irc.cacert.org #CAcert (ssl port 7000, non-ssl port 6667)</li>
-</ul>
-
-<h4><a name="p1.5.3" id="p1.5.3">1.5.3. Person determining CPS suitability for the policy</a></h4>
-<p>
-This CPS and all other policy documents are managed by
-the policy group, which is a group of Members of the
-Community found at policy forum.  See discussion forums above.
-</p>
-
-<h4><a name="p1.5.4" id="p1.5.4">1.5.4. CPS approval procedures</a></h4>
-<p>
-CPS is controlled and updated according to the
-Policy on Policy
-(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>)
-which is part of
-Configuration-Control Specification (COD2).
-</p>
-
-<p>
-In brief, the policy forum prepares and discusses.
-After a last call, the document moves to DRAFT status
-for a defined period.
-If no challenges have been received in the defined period,
-it moves to POLICY status.
-The process is modelled after some elements of
-the RFC process by the IETF.
-</p>
-
-<h4><a name="p1.5.5" id="p1.5.5">1.5.5 CPS updates</a></h4>
-
-<p>
-As per above.
-</p>
-
-
-<h3><a name="p1.6" id="p1.6">1.6. Definitions and acronyms</a></h3>
-<p>
-<b><a name="d_cert" id="d_cert">Certificate</a></b>.
-  A certificate is a piece of cryptographic data used
-  to validate certain statements, especially those of
-  identity and membership.
-</p>
-<p>
-<b><a name="d_cacert" id="d_cacert">CAcert</a></b>.
-  CAcert is a Community certificate authority as defined under
-  <a href="#p1.2">&sect;1.2 Identification</a>.
-</p>
-<p>
-<b><a name="d_member" id="d_member">Member</a></b>.
-  Everyone who agrees to the
-  CAcert Community Agreement
-  (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
-  This generally implies having an account registered
-  at CAcert and making use of CAcert's data, programs or services.
-  A Member may be an individual ("natural person")
-  or an organisation (sometimes, "legal person").
-</p>
-<p>
-<b><a name="d_community" id="d_community">Community</a></b>.
-  The group of Members who agree to the
-  CAcert Community Agreement
-  (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
-  or equivalent agreements.
-</p>
-<p>
-<b><a name="d_unassured" id="d_unassured">Unassured Member</a></b>.
-  A Member who has not yet been Assured.
-</p>
-<p>
-<b><a name="d_subscriber" id="d_subscriber">Subscriber</a></b>.
-  A Member who requests and receives a certificate.
-</p>
-<p>
-<b><a name="d_assured" id="d_assured">Assured Member</a></b>.
-  A Member whose identity has been sufficiently
-  verified by Assurers or other
-  approved methods under Assurance Policy.</p>
-</p>
-<p>
-<b><a name="d_assurer" id="d_assurer">Assurer</a></b>.
-  An Assured Member who is authorised under Assurance Policy
-  to verify the identity of other Members.
-</p>
-<p>
-<b><a name="d_name" id="d_name">Name</a></b>.
-    As defined in the
-    Assurance Policy
-    (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>),
-    to describe a name of a Member
-    that is verified by the Assurance process.
-<p>
-<b><a name="d_oadmin" id="d_oadmin">Organisation Administrator</a></b>.
-  ("O-Admin")
-  An Assurer who is authorised to act for an Organisation.
-  The O-Admin is authorised by an organisation
-  to vouch for the identity of other users of the organisation.
-</p>
-<p>
-<b><a name="d_org_ass" id="d_org_ass">Organisation Assurer</a></b>.
-  An Assurer who is authorised to conduct assurances on
-  organisations.
-</p>
-<p>
-<b><a name="d_user" id="d_user">Non-Related Persons</a></b>.
-  ("NRPs")
-  are general users of browsers and similar software.
-  The NRPs are generally unaware of
-  CAcert or the certificates that they may use, and
-  are unaware of the ramifications of usage.
-  They are not permitted to RELY, but may USE, under the 
-  Non-Related Persons - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
-</p>
-<p>
-<b><a name="rel" id="d_reliance">Reliance</a></b>.
-  An industry term referring to
-  the act of making a decision, including taking a risk,
-  which decision is in part or in whole
-  informed or on the basis of the contents of a certificate.
-</p>
-<p>
-<b><a name="rel" id="rel">Relying Party</a></b>.
-  An industry term refering to someone who relies
-  (that is, makes decisions or takes risks)
-  in part or in whole on a certificate.
-</p>
-<p>
-    <b>Subscriber Naming.</b>
-    The term used in this CPS to
-    describe all naming data within a certificate.
-    Approximately similar terms from Industry such as
-    "Subject naming" and "Distinguished Name"
-    are not used here.
-</p>
-<p>
-<b><a name="ver" id="d_verification">Verification</a></b>.
-  An industry term referring to
-  the act of checking and controlling
-  the accuracy and utility of a single claim.
-</p>
-<p>
-<b><a name="ver" id="d_validation">Validation</a></b>.
-  An industry term referring to the process of
-  inspecting and verifying the information and
-  subsidiary claims behind a claim.
-</p>
-<p>
-<b><a name="rel" id="rel">Usage</a></b>.
-  The event of allowing a certificate to participate in
-  a protocol, as decided and facilitated by a user's software.
-  Generally, Usage does not require significant input, if any,
-  on the part of the user.
-  This defers all decisions to the user software,
-  thus elevating the software as user's only and complete
-  Validation Authority or Agent.
-</p>
-<p>
-<b><a name="drel" id="drel">CAcert Relying Party</a></b>.
-  CAcert Members who make decisions based in part or in whole
-  on a certificate issued by CAcert.
-  Only CAcert Members are permitted to Rely on CAcert certificates,
-  subject to the CAcert Community Agreement.
-</p>
-<p>
-<b><a name="ddst" id="ddst">Vendors</a></b>.
-  Non-members who distribute CAcert's root or intermediate certificates
-  in any way, including but not limited to delivering these
-  certificates with their products, e.g. browsers, mailers or servers.
-  Vendors are covered under a separate licence.
-  <span class="q"> As of the moment, this licence is not written.</span>
-</p>
-<p>
-<b><a name="d_ccs" id="d_ccs">Configuration-Control Specification</a></b> "CCS".
-  The audit criteria that controls this CPS.
-  The CCS is documented in COD2, itself a controlled document under CCS.
-</p>
-<p>
-<p>
-<b><a name="d_cod" id="d_cod">CAcert Official Document</a></b> (COD).
-  Controlled Documents that are part of the CCS.
-</p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p2" id="p2">2. PUBLICATION AND REPOSITORY RESPONSIBILITIES</a></h2>
-
-
-<h3><a name="p2.1" id="p2.1">2.1. Repositories</a></h3>
-
-<p>
-CAcert operates no repositories in the sense
-of lookup for non-certificate-related information
-for the general public.
-</p>
-
-<p>
-Under the Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>),
-there are means for Members to search, retrieve
-and verify certain data about themselves and others.
-</p>
-
-<h3><a name="p2.2" id="p2.2">2.2. Publication of certification information</a></h3>
-
-<p>
-CAcert publishes:
-</p>
-
-<ul>
-  <li>A repository of CRLs.  An OCSP responder is in operation.</li>
-  <li>The root certificate and intermediate certificates.</li>
-</ul>
-
-<p>
-CAcert does not expressly publish information on issued certificates.
-However, due to the purpose of certificates, and the essential
-public nature of Names and email addresses, all information within
-certificates is presumed to be public and published, once
-issued and delivered to the Member.
-</p>
-
-<h3><a name="p2.3" id="p2.3">2.3. Time or frequency of publication</a></h3>
-
-<p>
-Root and Intermediate Certificates and CRLs are
-made available on issuance.
-</p>
-
-<h3><a name="p2.4" id="p2.4">2.4. Access controls on repositories</a></h3>
-<p> No stipulation.  </p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p3" id="p3">3. IDENTIFICATION AND AUTHENTICATION</a></h2>
-
-<h3><a name="p3.1" id="p3.1">3.1. Naming</a></h3>
-
-<h4><a name="p3.1.1" id="p3.1.1">3.1.1. Types of names</a></h4>
-
-<p>
-<b>Client Certificates.</b>
-The Subscriber Naming consists of:
-</p>
-<ul>
-  <li><tt>subjectAltName=</tt>
-      One, or more, of the Subscriber's verified email addresses,
-      in rfc822Name format.
-
-  <ul class="q">
-    <li>SSO in subjectAltName?.</li>
-  </ul>
-  <li><tt>EmailAddress=</tt>
-      One, or more, of the Subscriber's verified email addresses.
-      This is deprecated under 
-      RFC5280 <a href="http://tools.ietf.org/html/rfc5280#section-4.2.1.6">4
-.1.2.6</a>
-      and is to be phased out. Also includes a SHA1 hash of a random number if 
-      the member selects SSO (Single Sign On ID) during submission of CSR.
-  </li>
-  <li><tt>CN=</tt> The common name takes its value from one of:
-    <ul><li>
-      For all Members,
-      the string "<tt>CAcert WoT Member</tt>" may be used for
-      anonymous certificates.
-    </li><li>
-      For individual Members,
-      a Name of the Subscriber,
-      as Assured under AP.
-    </li><li>
-      For Organisation Members,
-      an organisation-chosen name,
-      as verified under OAP.
-    </li></ul>
-</ul>
-
-  <ul class="q">
-    <li> <a href="http://bugs.cacert.org/view.php?id=672"> bug 672</a> filed on subjectAltName.</li>
-    <li> O-Admin must verify as per <a href="http://wiki.cacert.org/wiki/PolicyDecisions">p20081016</a>. </li>
-    <li> it is a wip for OAP to state how this is done. </li>
-    <li> curiously, (RFC5280) verification is only mandated for subjectAltName not subject field. </li>
-    <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>
-  </ul>
-
-<p>
-<b>Individual Server Certificates.</b>
-The Subscriber Naming consists of:
-</p>
-<ul>
- <li><tt>CN=</tt>
-    The common name is the host name out of a domain
-    for which the Member is a domain master.
-  </li> <li>
-  <tt>subjectAltName=</tt>
-    Additional host names for which the Member
-    is a domain master may be added to permit the
-    certificate to serve multiple domains on one IP number.
-  </li> <li>
-    All other fields are optional and must either match
-    the CN or they must be empty
-</li> </ul>
-
-<p>
-<b>Certificates for Organisations.</b>
-In addition to the above, the following applies:
-</p>
-
-<ul>
-  <li><tt>OU=</tt>
-      organizationalUnitName (set by O-Admin, must be verified by O-Admin).</li>
-  <li><tt>O=</tt>
-      organizationName is the fixed name of the Organisation.</li>
-  <li><tt>L=</tt>
-      localityName</li>
-  <li><tt>ST=</tt>
-      stateOrProvinceName</li>
-  <li><tt>C=</tt>
-      countryName</li>
-  <li><tt>contact=</tt>
-      EMail Address of Contact.
-      <!--  not included in RFC5280 4.1.2.4 list, but list is not restricted -->
-  </li>
-</ul>
-
-<p>
-Except for the OU and CN, fields are taken from the Member's
-account and are as verified by the Organisation Assurance process.
-Other Subscriber information that is collected and/or retained
-does not go into the certificate.
-</p>
-
-<h4><a name="p3.1.2" id="p3.1.2">3.1.2. Need for names to be meaningful</a></h4>
-
-<p>
-Each Member's Name (<tt>CN=</tt> field)
-is assured under the Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
-or subsidiary policies (such as Organisation Assurance Policy).
-Refer to those documents for meanings and variations.
-</p>
-
-<p>
-Anonymous certificates have the same <code>subject</code>
-field common name.
-See <a href="#p1.4.5">&sect;1.4.5.</a>.
-</p>
-
-<p>
-Email addresses are verified according to
-<a href="#p4.2.2">&sect;4.2.2.</a>
-</p>
-
-<!-- <center><a href="http://xkcd.com/327/"> <img src="http://imgs.xkcd.com/comics/exploits_of_a_mom.png"> </a> </center> -->
-
-<h4><a name="p3.1.3" id="p3.1.3">3.1.3. Anonymity or pseudonymity of subscribers</a></h4>
-
-<p>
-See <a href="#p1.4.5">&sect;1.4.5</a>.
-</p>
-
-<h4><a name="p3.1.4" id="p3.1.4">3.1.4. Rules for interpreting various name forms</a></h4>
-<p>
-Interpretation of Names is controlled by the Assurance Policy,
-is administered by means of the Member's account,
-and is subject to change by the Arbitrator.
-Changes to the interpretation by means of Arbitration
-should be expected as fraud (e.g., phishing)
-may move too quickly for policies to fully document rules.
-</p>
-
-<h4><a name="p3.1.5" id="p3.1.5">3.1.5. Uniqueness of names</a></h4>
-
-<p>
-Uniqueness of Names within certificates is not guaranteed.
-Each certificate has a unique serial number which maps
-to a unique account, and thus maps to a unique Member.
-See the Assurance Statement within Assurance Policy
-(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
-</p>
-
-<p>
-Domain names and email address
-can only be registered to one Member.
-</p>
-
-<h4><a name="p3.1.6" id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</a></h4>
-
-<p>
-Organisation Assurance Policy
-(<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>)
-controls issues such as trademarks where applicable.
-A trademark can be disputed by filing a dispute.
-See
-<a href="#adr">&sect;9.13</a>.
-</p>
-
-<h4><a name="p3.1.7" id="p3.1.7">3.1.7. International Domain Names</a></h4>
-
-<p>
-Certificates containing International Domain Names, being those containing a 
-ACE prefix (<a href="http://www.ietf.org/rfc/rfc3490#section-5">RFC3490 
-Section 5</a>), will only be issued to domains satisfying one or more 
-of the following conditions:
-<ul>
-<li>The Top Level Domain (TLD) Registrar associated with the domain has a policy
-that has taken measures to prevent two homographic domains being registered to 
-different entities down to an accepted level.
-</li>
-<li>Domains contain only code points from a single unicode character script,
-excluding the "Common" script, with the additionally allowed numberic
-characters [0-9], and an ACSII hyphen '-'.
-</li>
-</ul>
-</p>
-
-<p>Email address containing International Domain Names in the domain portion of
-the email address will also be required to satisfy one of the above conditions.
-</p>
-
-<p>
-The following is a list of accepted TLD Registrars:
-    <table>
-
-      <tr>
-        <td>.ac</td>
-        <td><a href="http://www.nic.ac/">Registry</a></td>
-        <td><a href="http://www.nic.ac/pdf/AC-IDN-Policy.pdf">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.ar</td>
-
-        <td><a href="http://www.nic.ar/">Registry</a></td>
-        <td><a href="http://www.nic.ar/616.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.at</td>
-        <td><a href="http://www.nic.at/">Registry</a></td>
-        <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>
-
-      </tr>
-      <tr>
-        <td>.biz</td>
-        <td><a href="http://www.neustarregistry.biz/">Registry</a></td>
-        <td><a href="http://www.neustarregistry.biz/products/idns">Policy</a></td>
-      </tr>
-      <tr>
-
-        <td>.br</td>
-        <td><a href="http://registro.br/">Registry</a></td>
-        <td><a href="http://registro.br/faq/faq6.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.cat</td>
-        <td><a href="http://www.domini.cat/">Registry</a></td>
-
-        <td><a href="http://www.domini.cat/normativa/en_normativa_registre.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.ch</td>
-        <td><a href="http://www.switch.ch/id/">Registry</a></td>
-        <td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a></td>
-      </tr>
-
-      <tr>
-        <td>.cl</td>
-        <td><a href="http://www.nic.cl/">Registry</a></td>
-        <td><a href="http://www.nic.cl/CL-IDN-policy.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.cn</td>
-
-        <td><a href="http://www.cnnic.net.cn/">Registry</a></td>
-        <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
-      </tr>
-      <tr>
-        <td>.de</td>
-        <td><a href="http://www.denic.de/">Registry</a></td>
-
-        <td><a href="http://www.denic.de/en/richtlinien.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.dk</td>
-        <td><a href="http://www.dk-hostmaster.dk/">Registry</a></td>
-        <td><a href="http://www.dk-hostmaster.dk/index.php?id=151">Policy</a></td>
-      </tr>
-
-      <tr>
-        <td>.es</td>
-        <td><a href="https://www.nic.es/">Registry</a></td>
-        <td><a href="https://www.nic.es/media/2008-12/1228818323935.pdf">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.fi</td>
-
-        <td><a href="http://www.ficora.fi/">Registry</a></td>
-        <td><a href="http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.gr</td>
-        <td><a href="https://grweb.ics.forth.gr/english/index.html">Registry</a></td>
-        <td><a href="https://grweb.ics.forth.gr/english/ENCharacterTable1.jsp">Policy</a></td>
-
-      </tr>
-      <tr>
-        <td>.hu</td>
-        <td><a href="http://www.domain.hu/domain/">Registry</a></td>
-        <td><a href="http://www.domain.hu/domain/English/szabalyzat.html">Policy</a> (section 2.1.2)</td>
-      </tr>
-
-      <tr>
-        <td>.info</td>
-        <td><a href="http://www.afilias.info/">Registry</a></td>
-        <td><a href="http://www.afilias.info/register/idn/">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.io</td>
-
-        <td><a href="http://www.nic.io">Registry</a></td>
-        <td><a href="http://www.nic.io/IO-IDN-Policy.pdf">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.ir</td>
-        <td><a href="https://www.nic.ir/">Registry</a></td>
-        <td><a href="https://www.nic.ir/IDN">Policy</a></td>
-
-      </tr>
-      <tr>
-        <td>.is</td>
-        <td><a href="http://www.isnic.is/">Registry</a></td>
-        <td><a href="http://www.isnic.is/english/domain/rules.php">Policy</a></td>
-      </tr>
-      <tr>
-
-        <td>.jp</td>
-        <td><a href="http://jprs.co.jp/">Registry</a></td>
-        <td><a href="http://www.iana.org/assignments/idn/jp-japanese.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.kr</td>
-        <td><a href="http://domain.nic.or.kr/">Registry</a></td>
-
-        <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
-      </tr>
-      <tr>
-        <td>.li</td>
-        <td><a href="http://www.switch.ch/id/">Registry</a></td>
-        <td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a> (managed by .ch registry)</td>
-
-      </tr>
-      <tr>
-        <td>.lt</td>
-        <td><a href="http://www.domreg.lt/public?pg=&sp=&loc=en">Registry</a></td>
-        <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>
-
-      </tr>
-      <tr>
-        <td>.museum</td>
-        <td><a href="http://about.museum/">Registry</a></td>
-        <td><a href="http://about.museum/idn/idnpolicy.html">Policy</a></td>
-      </tr>
-      <tr>
-
-        <td>.no</td>
-        <td><a href="http://www.norid.no/">Registry</a></td>
-        <td><a href="http://www.norid.no/domeneregistrering/veiviser.en.html">Policy</a> (section 4)</td>
-      </tr>
-      <tr>
-        <td>.org</td>
-
-        <td><a href="http://www.pir.org/">Registry</a></td>
-        <td><a href="http://pir.org/PDFs/ORG-Extended-Characters-22-Jan-07.pdf">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.pl</td>
-        <td><a href="http://www.nask.pl/">Registry</a></td>
-        <td><a href="http://www.dns.pl/IDN/idn-registration-policy.txt">Policy</a></td>
-
-      </tr>
-      <tr>
-        <td>.pr</td>
-        <td><a href="https://www.nic.pr/">Registry</a></td>
-        <td><a href="https://www.nic.pr/idn_rules.asp">Policy</a></td>
-      </tr>
-      <tr>
-
-        <td>.se</td>
-        <td><a href="http://www.nic-se.se/">Registry</a></td>
-        <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>
-      </tr>
-      <tr>
-
-        <td>.sh</td>
-        <td><a href="http://www.nic.sh">Registry</a></td>
-        <td><a href="http://www.nic.sh/SH-IDN-Policy.pdf">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.th</td>
-        <td><a href="http://www.thnic.or.th/">Registry</a></td>
-
-        <td><a href="http://www.iana.org/assignments/idn/th-thai.html">Policy</a></td>
-      </tr>
-      <tr>
-        <td>.tm</td>
-        <td><a href="http://www.nic.tm">Registry</a></td>
-        <td><a href="http://www.nic.tm/TM-IDN-Policy.pdf">Policy</a></td>
-      </tr>
-
-      <tr>
-        <td>.tw</td>
-        <td><a href="http://www.twnic.net.tw/">Registry</a></td>
-        <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
-      </tr>
-      <tr>
-
-        <td>.vn</td>
-        <td><a href="http://www.vnnic.net.vn/">Registry</a></td>
-        <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>
-      </tr>
-  </table>
-</p>
-
-<p>
-This criteria will apply to the email address and server host name fields for all certificate types.
-</p>
-
-<p>
-The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list.
-</p>
-
-<h3><a name="p3.2" id="p3.2">3.2. Initial Identity Verification</a></h3>
-
-<p>
-Identity verification is controlled by the
-<a href="http://svn.cacert.org/CAcert/Policies/AssurancePolicy.html">
-Assurance Policy</a> (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
-The reader is refered to the Assurance Policy,
-the following is representative and brief only.
-</p>
-
-
-<h4><a name="p3.2.1" id="p3.2.1">3.2.1. Method to prove possession of private key</a></h4>
-
-<p>
-CAcert uses industry-standard techniques to
-prove the possession of the private key.
-</p>
-
-<p>
-For X.509 server certificates,
-the stale digital signature of the CSR is verified.
-For X.509 client certificates for "Netscape" browsers,
-SPKAC uses a challenge-response protocol
-to check the private key dynamically.
-For X.509 client certificates for "explorer" browsers,
-ActiveX uses a challenge-response protocol
-to check the private key dynamically.
-</p>
-
-<h4><a name="p3.2.2" id="p3.2.2">3.2.2. Authentication of Individual Identity</a></h4>
-
-<p>
-<b>Agreement.</b>
-An Internet user becomes a Member by agreeing to the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
-and registering an account on the online website.
-During the registration process Members are asked to
-supply information about themselves:
-</p>
-  <ul>
-    <li>A valid working email.
-        </li>
-    <li>Full Name and Date of Birth such as is 
-        found on Identity documents.
-        </li>
-    <li>Personal Questions used only for Password Retrieval.</li>
-  </ul>
-
-<p>
-The online account establishes the method of authentication
-for all service requests such as certificates.
-</p>
-
-<p>
-<b>Assurance.</b>
-Each Member is assured according to Assurance Policy
-(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
-</p>
-
-<!-- <center><a href="http://xkcd.com/364/"> <img src="http://imgs.xkcd.com/comics/responsible_behavior.png"> </a> </center> -->
-
-
-
-<p>
-<b>Certificates.</b>
-Based on the total number of Assurance Points
-that a Member (Name) has, the Member
-can get different levels of certificates.
-See <a href="#p1.4.5">&sect;1.4.5</a>.
-See Table 3.2.b.
-When Members have 50 or more points, they
-become <i>Assured Members</i> and may then request
-certificates that state their Assured Name(s).
-</p>
-
-
-<br><br>
-<center>
-
-<table border="1" cellpadding="5">
- <tr>
-  <th>Assurance Points</th>
-  <th>Level</th>
-  <th>Service</th>
-  <th>Comments</th>
- </tr>
- <tr>
-  <td>0</td>
-  <td>Unassured Member</td>
-  <td>Anonymous</td>
-  <td>Certificates with no Name, under Class 1 Root.  Limited to 6 months expiry.</td>
- </tr>
- <tr>
-  <td>1-49</td>
-  <td>Unassured Member</td>
-  <td>Anonymous</td>
-  <td>Certificates with no Name under Member SubRoot.  Limited to 6 months expiry.</td>
- </tr>
- <tr>
-  <td rowspan="1">50-99</td>
-  <td>Assured Member</td>
-  <td>Verified</td>
-  <td>Certificates with Verified Name for S/MIME, web servers, "digital signing."
-      Expiry after 24 months is available.</td>
- </tr>
- <tr>
-  <td rowspan="2">100++</td>
-  <td rowspan="2">Assurer</td>
-  <td>Code-signing</td>
-  <td>Can create Code-signing certificates </td>
- </tr>
-</table>
-
-<span class="figure">Table 3.2.b - How Assurance Points are used in Certificates</span>
-
-</center>
-<br>
-
-
-
-<h4><a name="p3.2.3" id="p3.2.3">3.2.3. Authentication of organization identity</a></h4>
-
-
-<p>
-Verification of organisations is delegated by
-the Assurance Policy to the
-Organisation Assurance Policy
-(<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>).
-The reader is refered to the Organisation Assurance Policy,
-the following is representative and brief only.
-</p>
-
-<p>
-Organisations present special challenges.
-The Assurance process for Organisations is
-intended to permit the organisational Name to
-appear in certificates.
-The process relies heavily on the Individual
-process described above.
-</p>
-
-<p>
-Organisation Assurance achieves the standard
-stated in the OAP, briefly presented here:
-</p>
-
-<ol type="a"><li>
-   the organisation exists,
-  </li><li>
-   the organisation name is correct and consistent,
-  </li><li>
-   signing rights: requestor can sign on behalf of the organisation, and
-  </li><li>
-   the organisation has agreed to the terms of the
-   CAcert Community Agreement
-   (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
-   and is therefore subject to Arbitration. 
-</li></ol>
-
-  <ul class="error">
-    <li> As of the current time of writing, OA lacks critical documentation and there are bugs identified with no response.</li>
-    <li> <a href="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance">documented bugs</a>. </li>
-    <li> Therefore Organisations will not participate in the current audit cycle of roots. </li>
-    <li> See <a href="http://wiki.cacert.org/wiki/OrganisationAssurance">wiki</a> for any progress on this. </li>
-  </ul>
-
-
-<h4><a name="p3.2.4" id="p3.2.4">3.2.4. Non-verified subscriber information</a></h4>
-
-<p>
-All information in the certificate is verified,
-see Relying Party Statement, &sect;4.5.2.
-</p>
-
-
-<h4><a name="p3.2.5" id="p3.2.5">3.2.5. Validation of authority</a></h4>
-
-<p>
-The authorisation to obtain a certificate is established as follows:
-</p>
-
-<p>
-<b>Addresses.</b>
-The member claims authority over a domain or email address
-when adding the address,  <a href="#p4.1.2">&sect;4.1.2</a>.
-(Control is tested by means described in <a href="#p4.2.2">&sect;4.2.2</a>.)
-</p>
-
-<p>
-<b>Individuals.</b>
-The authority to participate as a Member is established
-by the CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
-Assurances are requested by means of the signed CAP form.
-</p>
-
-<p>
-<b>Organisations.</b>
-The authority for Organisation Assurance is established
-in the COAP form, as signed by an authorised representative
-of the organisation.
-The authority for the
-Organisation Administrator
-(O-Admin) is also established on the
-COAP form.
-See Organisation Assurance Policy.
-</p>
-
-
-<h4><a name="p3.2.6" id="p3.2.6">3.2.6. Criteria for interoperation</a></h4>
-
-<p>
-CAcert does not currently issue certificates to subordinate CAs
-or other PKIs.
-Other CAs may become Members, and are then subject to the
-same reliance provisions as all Members.
-</p>
-
-<h3><a name="p3.3" id="p3.3">3.3. Re-key Requests</a></h3>
-
-<p>
-Via the Member's account.
-</p>
-
-<h3><a name="p3.4" id="p3.4">3.4. Revocations Requests</a></h3>
-
-<p>
-Via the Member's account.
-In the event that the Member has lost the password,
-or similar, the Member emails the support team who
-either work through the lost-password questions
-process or file a dispute.
-</p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p4" id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a></h2>
-
-<p>
-The general life-cycle for a new certificate for an Individual Member is:
-
-<ol><li>
-    Member adds claim to an address (domain/email).
-  </li><li>
-    System probes address for control.
-  </li><li>
-    Member creates key pair.
-  </li><li>
-    Member submits CSR with desired options (Anonymous Certificate, SSO, Root Certificate) .
-  </li><li>
-    System validates and accepts CSR based on
-    known information:  claims, assurance, controls, technicalities.
-  </li><li>
-    System signs certificate.
-  </li><li>
-    System makes signed certificate available to Member.
-  </li><li>
-    Member accepts certificate.
-</li></ol>
-    
-</p>
-
-<p>
-(Some steps are not applicable, such as anonymous certificates.)
-</p>
-
-
-<h3><a name="p4.1" id="p4.1">4.1. Certificate Application</a></h3>
-
-<h4><a name="p4.1.1" id="p4.1.1">4.1.1. Who can submit a certificate application</a></h4>
-
-<p>
-Members may submit certificate applications.
-On issuance of certificates, Members become Subscribers.
-</p>
-
-<h4><a name="p4.1.2" id="p4.1.2">4.1.2. Adding Addresses</a></h4>
-
-<p>
-The Member can claim ownership or authorised control of
-a domain or email address on the online system.
-This is a necessary step towards issuing a certificate.
-There are these controls:
-<ul><li>
-    The claim of ownership or control is legally significant
-    and may be referred to dispute resolution.
-  </li><li>
-    Each unique address can be handled by one account only.
-  </li><li>
-    When the Member makes the claim,
-    the certificate application system automatically initiates the
-    check of control, as below.
-</li></ul>
-</p>
-
-<h4><a name="p4.1.3" id="p4.1.3">4.1.3. Preparing CSR </a></h4>
-
-<p>
-Members generate their own key-pairs.
-The CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
-obliges the Member as responsible for security.
-See CCA2.5, &sect;9.6.
-</p>
-
-<p>
-The Certificate Signing Request (CSR) is prepared by the
-Member for presentation to the automated system.
-</p>
-
-<h3><a name="p4.2" id="p4.2">4.2. Certificate application processing</a></h3>
-
-<!-- states what a CA does on receipt of the request -->
-
-<p>
-The CA's certificate application process is completely automated.
-Requests, approvals and rejections are handled by the website system.
-Each application should be processed in less than a minute.
-</p>
-<p>
-Where certificates are requested for more than one
-purpose, the requirements for each purpose must be
-fulfilled.
-</p>
-
-<!-- all sub headings in 4.2 are local, not from Chokhani. -->
-
-<h4><a name="p4.2.1" id="p4.2.1">4.2.1. Authentication </a></h4>
-
-<p>
-  The Member logs in to her account on the CAcert website
-      and thereby authenticates herself with username
-      and passphrase or with her CAcert client-side digital certificate.
-</p>
-
-<h4><a name="p4.2.2" id="p4.2.2">4.2.2. Verifying Control</a></h4>
-
-<p>
-In principle, at least two controls are placed on each address.
-</p>
-
-<p>
-<b><a name="ping">Email-Ping</a>.</b>
-Email addresses are verified by means of an
-<i><a name="ping">Email-Ping test</a></i>:
-</p>
-
-<ul><li>
-      The system generates a cookie
-      (a random, hard-to-guess code)
-      and formats it as a string.
-  </li><li>
-      The system sends the cookie
-      to the Member in an email.
-  </li><li>
-      Once the Member receives the email,
-      she enters the cookie into the website.
-  </li><li>
-      The entry of the code verifies
-      control of that email account.
-</li></ul>
-
-<p>
-<b><a name="email">Email Control</a>.</b>
-Email addresses for client certificates are verified by passing the
-following checks:
-</p>
-<ol>
-  <li>An Email-ping test
-      is done on the email address.
-      </li>
-  <li>The Member must have signed a CAP form or equivalent,
-      and been awarded at least one Assurance point.
-      </li>
-</ol>
-
-<p>
-<b><a name="domain">Domain Control</a>.</b>
-Domains addresses for server certificates are verified by passing two of the
-following checks:
-</p>
-<ol> <li>
-      An Email-ping test
-      is done on an email address chosen from <i>whois</i>
-      or interpolated from the domain name.
-  </li> <li>
-      The system generates a cookie
-      which is then placed in DNS
-      by the Member.
-  </li> <li>
-      The system generates a cookie
-      which is then placed in HTTP headers or a text file on the website
-      by the Member.
-  </li> <li>
-      Statement by at least 2 Assurers about
-      ownership/control of the domain name.
-  </li> <li>
-      The system generates a cookie
-      which is then placed in whois registry information
-      by the Member.
-</li> </ol>
-
-<p>
-Notes.
-<ul><li>
-    Other methods can be added from time to time by CAcert.
-  </li><li>
-    Static cookies should remain for the duration of a certificate
-    for occasional re-testing.
-  </li><li>
-    Dynamic tests can be repeated at a later time of CAcert's choosing.
-  </li><li>
-    Domain control checks may be extended to apply to email control
-    in the future.
-</li></ul>
-</p>
-
-  <ul class="q">
-    <li> As of the time of writing, only a singular Email-ping is implemented in the technical system. </li>
-    <li> A further approved check is the 1 pt Assurance. </li>
-    <li> Practically, this would mean that certificates can only be issued under Audit Roots to Members with 1 point. </li>
-    <li> Criteria DRC C.7.f, A.2.q, A.2.i indicate registry whois reading. Also A.2.h. </li>
-    <li> Current view is that this will be resolved in BirdShack. </li>
-  </ul>
-
-<h4><a name="p4.2.3" id="p4.2.3">4.2.3. Options Available</a></h4>
-
-<p>
-The Member has options available:
-</p>
-
-<ul>
-  <li>Each Email address that is verified
-      is available for Client Certificates.
-      </li>
-  <li>Each Domain address that is verified
-      is available for Server Certificates.
-      </li>
-  <li>If the Member is unassured then only the Member SubRoot is available.
-      </li>
-  <li>If the Member is Assured then both Assured Member and Member SubRoots
-      are available.
-      </li>
-  <li>If a Name is Assured then it may be
-      put in a client certificate or an OpenPGP signature.
-      </li>
-</ul>
-
-<h4><a name="p4.2.4" id="p4.2.4">4.2.4. Client Certificate Procedures</a></h4>
-
-<p>
-For an individual client certificate, the following is required.
-<ul>
-  <li>The email address is claimed and added. </li>
-  <li>The email address is ping-tested. </li>
-  <li>For the Member Subroot, the Member must have
-      at least one point of Assurance and have signed a CAP form.</li>
-  <li>For the Assured Subroot, the Member must have
-      at least fifty points of Assurance. </li>
-  <li>To include a Name, the Name must be assured to at least fifty points. </li>
-
-</ul>
-</p>
-
-<h4><a name="p4.2.5" id="p4.2.5">4.2.5. Server Certificate Procedures</a></h4>
-
-<p>
-For a server certificate, the following is required:
-<ul>
-  <li>The domain is claimed and added. </li>
-  <li>The domain is checked twice as above. </li>
-  <li>For the Member SubRoot, the Member must have
-      at least one point of Assurance and have signed a CAP form.</li>
-  <li>For the Assured SubRoot, the Member must have
-      at least fifty points of Assurance. </li>
-</ul>
-
-</p>
-
-<h4><a name="p4.2.6" id="p4.2.6">4.2.6. Code-signing Certificate Procedures</a></h4>
-
-<p>
-Code-signing certificates are made available to Assurers only.
-They are processed in a similar manner to client certificates.
-</p>
-
-<h4><a name="p4.2.7" id="p4.2.7">4.2.7. Organisation Domain Verification</a></h4>
-
-<p>
-Organisation Domains are handled under the Organisation Assurance Policy
-and the Organisation Handbook.
-</p>
-
-  <ul class="q">
-     <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>
-     <li> <a href="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance"> Drafts </a> for ongoing story. </li>
-  </ul>
-
-<h3><a name="p4.3" id="p4.3">4.3. Certificate issuance</a></h3>
-
-
-<!-- <a href="http://xkcd.com/153/"> <img align="right" src="http://imgs.xkcd.com/comics/cryptography.png"> </a> -->
-<h4><a name="p4.3.1" id="p4.3.1">4.3.1. CA actions during certificate issuance</a></h4>
-
-<p>
-<b>Key Sizes.</b>
-Members may request keys of any size permitted by the key algorithm.
-Many older hardware devices require small keys.
-</p>
-
-<p>
-<b>Algorithms.</b>
-CAcert currently only supports the RSA algorithm for X.509 keys.
-X.509 signing uses the SHA-1 message digest algorithm.
-OpenPGP Signing uses RSA signing over RSA and DSA keys.
-
-</p>
-
-<p>
-<b>Process for Certificates:</b>
-All details in each certificate are verified
-by the website issuance system.
-Issuance is based on a 'template' system that selects
-profiles for certificate lifetime, size, algorithm.
-</p>
-
-
-<ol><li>
-   The CSR is verified.
-  </li><li>
-   Data is extracted from CSR and verified:
-    <ul>
-      <li> Name &sect;3.1, </li>
-      <li> Email address <a href="#p4.2.2">&sect;4.2.2</a>, </li>
-      <li> Domain address <a href="#p4.2.2">&sect;4.2.2</a>. </li>
-    </ul>
-  </li><li>
-   Certificate is generated from template.
-  </li><li>
-   Data is copied from CSR.
-  </li><li>
-   Certificate is signed.
-  </li><li>
-   Certificate is stored as well as mailed.
-</li></ol>
-
-
-<p>
-<b>Process for OpenPGP key signatures:</b>
-All details in each Sub-ID are verified
-by the website issuance system.
-Issuance is based on the configuration that selects
-the profile for signature lifetime, size,
-algorithm following the process:
-</p>
-
-<ol><li>
-   The public key is verified.
-  </li><li>
-   Data is extracted from the key and verified (Name, Emails).
-   Only the combinations of data in Table 4.3.1 are permitted.
-  </li><li>
-   OpenPGP Key Signature is generated.
-  </li><li>
-   Key Signature is applied to the key.
-  </li><li>
-   The signed key is stored as well as mailed.
-</li></ol>
-
-<center>
-<table border="1" align="center" valign="top" cellpadding="5"><tbody>
-  <tr>
-    <td><br></td>
-    <td>Verified Name</td>
-    <td valign="top">Unverified Name<br></td>
-    <td>Empty Name<br></td>
-  </tr>
-  <tr>
-    <td>Verified email<br></td>
-    <td><center> <font title="pass." color="green" size="+3"> &#10004; </font>  </center></td>
-    <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
-    <td><center> <font title="pass." color="green" size="+3"> &#10004; </font>  </center></td>
-  </tr>
-  <tr>
-    <td>Unverified email</td>
-    <td><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
-    <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
-    <td><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td></tr><tr><td valign="top">Empty email<br></td>
-    <td valign="top"><center> <font title="pass." color="green" size="+3"> &#10004; </font>  </center></td>
-    <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
-    <td valign="top"><center> <font title="pass." color="red" size="+3"> &#10008; </font> </center></td>
-  </tr>
-</tbody></table><br>
-
-<span class="figure">Table 4.3.1.  Permitted Data in Signed OpenPgp Keys</span>
-</center>
-
-<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>
-
-<p>
-Once signed, the certificate is
-made available via the Member's account,
-and emailed to the Member.
-It is also archived internally.
-</p>
-
-<h3><a name="p4.4" id="p4.4">4.4. Certificate acceptance</a></h3>
-
-<h4><a name="p4.4.1" id="p4.4.1">4.4.1. Conduct constituting certificate acceptance</a></h4>
-
-<p>
-There is no need for the Member to explicitly accept the certificate.
-In case the Member does not accept the certificate,
-the certificate has to be revoked and made again.
-</p>
-
-<h4><a name="p4.4.2" id="p4.4.2">4.4.2. Publication of the certificate by the CA</a></h4>
-
-<p>
-CAcert does not currently publish the issued certificates
-in any repository.
-In the event that CAcert will run a repository,
-the publication of certificates and signatures
-there will be at the Member's options.
-However note that certificates that are issued
-and delivered to the Member are presumed to be
-published.  See &sect;2.2.
-</p>
-
-<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>
-
-<p>
-There are no external entities that are notified about issued certificates.
-</p>
-
-<h3><a name="p4.5" id="p4.5">4.5. Key pair and certificate usage</a></h3>
-
-<p>
-All Members (subscribers and relying parties)
-are obliged according to the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
-See especially 2.3 through 2.5.
-</p>
-<h4><a name="p4.5.1" id="p4.5.1">4.5.1. Subscriber Usage and Responsibilities</a></h4>
-
-<p>
-Subscribers should use keys only for their proper purpose,
-as indicated by the certificate, or by wider agreement with
-others.
-</p>
-
-<h4><a name="p4.5.2" id="p4.5.2">4.5.2. Relying Party Usage and Responsibilities</a></h4>
-
-
-<p>
-Relying parties (Members) may rely on the following.
-</p>
-
-<center>
-  <table border="1" cellpadding="25"><tr><td>
-  <p align="center">
-  <big><b>Relying Party Statement</b></big>
-  <p>
-  Certificates are issued to Members only.<br><br>
-  All information in a certificate is verified.
-  </p>
-  </td></tr></table>
-</center>
-
-
-<p>
-The following notes are in addition to the Relying Party Statement,
-and can be seen as limitations on it.
-</p>
-
-<h5>4.5.2.a Methods of Verification </h5>
-<p>
-The term Verification as used in the Relying Party Statement means one of
-</p>
-<table border="1" cellpadding="5"><tr>
-  <th>Type</th><th>How</th><th>Authority</th><th>remarks</th>
-</tr><tr>
-  <th>Assurance</th><td>under CAcert Assurance Programme (CAP)</td>
-    <td>Assurance Policy</td>
-    <td>only information assured to 50 points under CAP is placed in the certificate </td>
-</tr><tr>
-  <th>Evaluation</th><td>under automated domain and email checks </td>
-    <td>this CPS</td>
-    <td>see &sect;4.2.2</td>
-</tr><tr>
-  <th>Controlled</th><td>programs or "profiles" that check the information within the CSR </td>
-    <td>this CPS</td>
-    <td>see &sect;7.1</td>
-</tr></table>
-
-<h5>4.5.2.b Who may rely</h5>
-<p>
-<b>Members may rely.</b>
-Relying parties are Members,
-and as such are bound by this CPS and the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
-The licence and permission to rely is not assignable.
-</p>
-
-<p>
-<b>Suppliers of Software.</b>
-CAcert roots may be distributed in software,
-and those providers may
-enter into agreement with CAcert by means of the
-Third Party Vendor - Disclaimer and Licence
-(wip).
-This licence brings the supplier in to the Community
-to the extent that <span class="q"> ...WIP comment:</span>
-they agree to dispute resolution
-within CAcert's forum.
-</p>
-
-  <ul class="q">
-    <li> Just exactly what the 3PV-DaL says is unclear.</li>
-    <li> The document itself is more a collection of ideas.</li>
-  </ul>
-
-
-<p>
-<b>NRPs may not rely.</b>
-If not related to CAcert by means of an agreement
-that binds the parties to dispute resolution within CAcert's forum,
-a person is a Non-Related-Person (NRP).
-An NRP is not permitted to rely and is not a Relying Party.
-For more details, see the
-NRP - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
-</p>
-
-<h5>4.5.2.c The Act of Reliance </h5>
-
-<p>
-<b>Decision making.</b>
-Reliance means taking a decision that is in part or in whole
-based on the information in the certificate.
-
-A Relying Party may incorporate
-the information in the certificate,
-and the implied information such as Membership,
-into her decision-making.
-In making a decision,
-a Relying Party should also:
-</p>
-
-<ul><li>
-    include her own overall risk equation,
-  </li><li>
-    include the general limitations of the Assurance process,
-    certificates, and wider security considerations,
-  </li><li>
-    make additional checks to provide more information,
-  </li><li>
-    consider any wider agreement with the other Member, and
-  </li><li>
-    use an appropriate protocol or custom of reliance (below).
-</li></ul>
-
-<p>
-<b>Examining the Certificate.</b>
-A Relying Party must make her own decision in using
-each certificate.  She must examine the certificate,
-a process called <i>validation</i>.
-Certificate-related information includes,
-but is not limited to:
-</p> 
-<ul><li>
-    Name,
-  </li><li>
-    expiry time of certificate,
-  </li><li>
-    current certificate revocation list (CRL),
-  </li><li>
-    certificate chain and
-    the validity check of the certificates in the chain,
-  </li><li>
-    issuer of certificate (CAcert),
-  </li><li>
-    SubRoot is intended for reliance (Assured, Organisation and Class 3)
-  </li><li>
-    purpose of certificate.
-</li></ul>
-
-<p>
-<b>Keeping Records.</b>
-Records should be kept, appropriate to the import of the decision.
-The certificate should be preserved.
-This should include sufficient
-evidence to establish who the parties are
-(especially, the certificate relied upon),
-to establish the transaction in question,
-and to establish the wider agreement that
-defines the act.
-</p>
-
-<p>
-<b>Wider Protocol.</b>
-In principle, reliance will be part of a wider protocol
-(customary method in reaching and preserving agreement)
-that presents and preserves sufficient of the evidence
-for dispute resolution under CAcert's forum of Arbitration.
-The protocol should be agreed amongst the parties,
-and tuned to the needs.
-This CPS does not define any such protocol.
-In the absence of such a protocol, reliance will be weakened;
-a dispute without sufficient evidence may be dismissed by an Arbitrator.
-</p>
-
-<p>
-<b>As Compared to Usage</b>.
-Reliance goes beyond Usage.  The latter is limited to
-letting the software act as the total and only Validation
-Authority.  When relying, the Member also augments
-the algorithmic processing of the software with her own
-checks of the business, technical and certificate aspect.
-</p>
-
-<h5>4.5.2.d Risks and Limitations of Reliance </h5>
-<p>
-<b>Roots and Naming.</b>
-Where the Class 1 root is used,
-this Subscriber may be a new Member
-including one with zero points.
-Where the Name is not provided,
-this indicates it is not available.
-In these circumstances,
-reliance is not defined,
-and Relying parties should take more care.
-See Table 4.5.2.
-</p>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
-  <td></td>
-  <td colspan="4"><center><i>Statements of Reliance for Members</center></i></td>
- </tr>
- <tr>
-  <td><i>Class of Root</i></td>
-  <td><center><b>Anonymous</b><br>(all Members)</center></td>
-  <td><center><b>Named</b><br>(Assured Members only)</center></td>
- </tr>
- <tr>
-  <td><center>Class<br><big><b>1</b></big></center></td>
-  <td rowspan="2" bgcolor="red">
-       <b>Do not rely.</b><BR>
-       Relying party must use other methods to check. </td>
-  <td rowspan="2" bgcolor="orange">
-       Do not rely.
-       Although the named Member has been Assured by CAcert,
-       reliance is not defined with Class 1 root.<BR>
-       (issued for compatibility only).</td>
- </tr>
- <tr>
-  <td><center><big><b>Member</b></big><br>SubRoot</center></td>
- </tr>
- <tr>
-  <td><center>Class<br><big><b>3</b></big></center></td>
-  <td rowspan="2" bgcolor="orange">
-       Do not rely on the Name (being available).
-       The Member has been Assured by CAcert,
-       but reliance is undefined.</td>
-  <td rowspan="2">
-       The Member named in the certificate has been Assured by CAcert.</td>
- </tr>
- <tr>
-  <td><center><big><b>Assured</b></big><br>SubRoot</center></td>
- </tr>
-</table>
-
-<span class="figure">Table 4.5.2.  Statements of Reliance</span>
-</center>
-
-<p>
-<b>Software Agent.</b>
-When relying on a certificate, relying parties should
-note that your software is responsible for the way it
-shows you the information in a certificate.
-If your software agent hides parts of the information,
-your sole remedy may be to choose another software agent.
-</p>
-
-<p>
-<b>Malware.</b>
-When relying on a certificate, relying parties should
-note that platforms that are vulnerable to viruses or
-trojans or other weaknesses may not process any certificates
-properly and may give deceptive or fraudulent results.
-It is your responsibility to ensure you are using a platform
-that is secured according to the needs of the application.
-</p>
-
-<h5>4.5.2.e When something goes wrong </h5>
-<p>
-In the event that an issue arises out of the Member's reliance,
-her sole avenue is <b>to file dispute under DRP</b>.
-See <a href="#p9.13">&sect;9.13</a>.
-<!-- DRC_A&sect;A.4.d -->
-For this purpose, the certificate (and other evidence) should be preserved.
-</p>
-
-<p>
-<b>Which person?</b>
-Members may install certificates for other individuals or in servers,
-but the Member to whom the certificate is issued
-remains the responsible person.
-E.g., under Organisation Assurance, an organisation is issued
-a certificate for the use by individuals
-or servers within that organisation,
-but the Organisation is the responsible person.
-</p>
-
-<!-- <a href="http://xkcd.com/424/"> <img align="right" src="http://imgs.xkcd.com/comics/security_holes.png"> </a>  -->
-<p>
-<b>Software Agent.</b>
-If a Member is relying on a CAcert root embedded in
-the software as supplied by a vendor,
-the risks, liabilities and obligations of the Member
-do not automatically transfer to the vendor.
-</p>
-
-<h3><a name="p4.6" id="p4.6">4.6. Certificate renewal</a></h3>
-
-<p>
-A certificate can be renewed at any time.
-The procedure of certificate renewal is the same
-as for the initial certificate issuance.
-</p>
-
-<h3><a name="p4.7" id="p4.7">4.7. Certificate re-key</a></h3>
-
-<p>
-Certificate "re-keyings" are not offered nor supported.
-A new certificate with a new key has to be requested and issued instead,
-and the old one revoked.
-</p>
-
-<h3><a name="p4.8" id="p4.8">4.8. Certificate modification</a></h3>
-
-<p>
-Certificate "modifications" are not offered nor supported.
-A new certificate has to be requested and issued instead.
-</p>
-
-<h3><a name="p4.9" id="p4.9">4.9. Certificate revocation and suspension</a></h3>
-
-<h4><a name="p4.9.1" id="p4.9.1">4.9.1. Circumstances for revocation</a></h4>
-<p>
-Certificates may be revoked under the following circumstances:
-</p>
-
-<ol><li>
-    As initiated by the Subscriber through her online account.
-  </li><li>
-    As initiated in an emergency action by a
-    support team member.
-    Such action will immediately be referred to dispute resolution
-    for ratification.
-  </li><li>
-    Under direction from the Arbitrator in a duly ordered ruling
-    from a filed dispute.
-</li></ol>
-
-<p>
-These are the only three circumstances under which a
-revocation occurs.
-</p>
-
-<h4><a name="p4.9.2" id="p4.9.2">4.9.2. Who can request revocation</a></h4>
-
-<p>
-As above.
-</p>
-
-<h4><a name="p4.9.3" id="p4.9.3">4.9.3. Procedure for revocation request</a></h4>
-<p>
-The Subscriber logs in to her online account through
-the website at http://www.cacert.org/ .
-</p>
-
-<p>
-In any other event such as lost passwords or fraud,
-a dispute should be filed
-by email at
-    &lt; support AT cacert DOT org &gt;
-</p>
-
-<h4><a name="p4.9.4" id="p4.9.4">4.9.4. Revocation request grace period</a></h4>
-
-<p>No stipulation.</p>
-
-<h4><a name="p4.9.5" id="p4.9.5">4.9.5. Time within which CA must process the revocation request</a></h4>
-
-<p>
-The revocation automated in the Web Interface for subscribers,
-and is handled generally in less than a minute.
-</p>
-
-<p>
-A filed dispute that requests a revocation should be handled
-within a five business days, however the Arbitrator has discretion.
-</p>
-
-<h4><a name="p4.9.6" id="p4.9.6">4.9.6. Revocation checking requirement for relying parties</a></h4>
-
-<p>
-Each revoked certificate is recorded in the
-certificate revocation list (CRL).
-Relying Parties must check a certificate against
-the most recent CRL issued, in order to validate
-the certificate for the intended reliance.
-</p>
-
-<h4><a name="p4.9.7" id="p4.9.7">4.9.7. CRL issuance frequency (if applicable)</a></h4>
-
-<p>
-A new CRL is issued after every certificate revocation.
-</p>
-
-<h4><a name="p4.9.8" id="p4.9.8">4.9.8. Maximum latency for CRLs (if applicable)</a></h4>
-
-<p>
-The maximum latency between revocation and issuance of the CRL is 1 hour.
-</p>
-
-<h4><a name="p4.9.9" id="p4.9.9">4.9.9. On-line revocation/status checking availability</a></h4>
-
-<p>
-OCSP is available at
-http://ocsp.cacert.org/ .
-</p>
-
-<h4><a name="p4.9.10" id="p4.9.10">4.9.10. On-line revocation checking requirements</a></h4>
-<p>
-Relying parties must check up-to-date status before relying.
-</p>
-
-<h4><a name="p4.9.11" id="p4.9.11">4.9.11. Other forms of revocation advertisements available</a></h4>
-<p>
-None.
-</p>
-
-<h4><a name="p4.9.12" id="p4.9.12">4.9.12. Special requirements re key compromise</a></h4>
-<p>
-Subscribers are obliged to revoke certificates at the earliest opportunity.
-</p>
-
-<h4><a name="p4.9.13" id="p4.9.13">4.9.13. Circumstances for suspension</a></h4>
-
-<p>
-Suspension of certificates is not available.
-</p>
-
-<h4><a name="p4.9.14" id="p4.9.14">4.9.14. Who can request suspension</a></h4>
-<p>
-Not applicable.
-</p>
-
-<h4><a name="p4.9.15" id="p4.9.15">4.9.15. Procedure for suspension request</a></h4>
-<p>
-Not applicable.
-</p>
-
-<h4><a name="p4.9.16" id="p4.9.16">4.9.16. Limits on suspension period</a></h4>
-<p>
-Not applicable.
-</p>
-
-
-
-<h3><a name="p4.10" id="p4.10">4.10. Certificate status services</a></h3>
-
-<h4><a name="p4.10.1" id="p4.10.1">4.10.1. Operational characteristics</a></h4>
-<p>
-OCSP is available
-at http://ocsp.cacert.org/ .
-</p>
-
-<h4><a name="p4.10.2" id="p4.10.2">4.10.2. Service availability</a></h4>
-
-<p>
-OCSP is made available on an experimental basis.
-</p>
-
-<h4><a name="p4.10.3" id="p4.10.3">4.10.3. Optional features</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p4.11" id="p4.11">4.11. End of subscription</a></h3>
-
-<p>
-Certificates include expiry dates.
-</p>
-
-<h3><a name="p4.12" id="p4.12">4.12. Key escrow and recovery</a></h3>
-
-<h4><a name="p4.12.1" id="p4.12.1">4.12.1. Key escrow and recovery policy and practices</a></h4>
-
-<p>
-CAcert does not generate nor escrow subscriber keys.
-</p>
-
-<h4><a name="p4.12.2" id="p4.12.2">4.12.2. Session key encapsulation and recovery policy and practices</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p5" id="p5">5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a></h2>
-
-<!-- <a href="http://xkcd.com/87/"> <img align="right" src="http://imgs.xkcd.com/comics/velociraptors.jpg"> </a>  -->
-
-<h3><a name="p5.1" id="p5.1">5.1. Physical controls</a></h3>
-
-<p>
-Refer to Security Policy (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-<ul><li>
-    Site location and construction - SP2.1
-  </li><li>
-    Physical access - SP2.3
-</li></ul>
-</p>
-
-
-<h4><a name="p5.1.3" id="p5.1.3">5.1.3. Power and air conditioning</a></h4>
-<p>
-Refer to Security Policy 2.1.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.4" id="p5.1.4">5.1.4. Water exposures</a></h4>
-<p>
-Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.5" id="p5.1.5">5.1.5. Fire prevention and protection</a></h4>
-<p>
-Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.6" id="p5.1.6">5.1.6. Media storage</a></h4>
-<p>
-Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-<h4><a name="p5.1.7" id="p5.1.7">5.1.7. Waste disposal</a></h4>
-<p>
-No stipulation.
-</p>
-<h4><a name="p5.1.8" id="p5.1.8">5.1.8. Off-site backup</a></h4>
-<p>
-Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-</p>
-
-<h3><a name="p5.2" id="p5.2">5.2. Procedural controls</a></h3>
-
-<h4><a name="p5.2.1" id="p5.2.1">5.2.1. Trusted roles</a></h4>
-
-<ul>
-   <li><b> Technical teams:</b>
-   <ul>
-       <li>User support personnel</li>
-       <li>Systems Administrators -- critical and non-critical</li>
-       <li>Softare Developers</li>
-       <li>controllers of keys</li>
-   </ul>
-   Refer to Security Policy 9.1 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
-   
-   </li>
-
-   <li><b>Assurance:</b>
-   <ul>
-       <li>Assurers</li>
-       <li> Any others authorised under COD13  </li>
-   </ul>
-   Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
-   </li>
-
-   <li><b>Governance:</b>
-   <ul>
-       <li>Directors (members of the CAcert Inc. committee, or "Board") </li>
-       <li>Internal Auditor</li>
-       <li>Arbitrator</li>
-   </ul>
-   </li>
-</ul>
-
-
-<h4><a name="p5.2.2" id="p5.2.2">5.2.2. Number of persons required per task</a></h4>
-<p>
-CAcert operates to the principles of <i>four eyes</i> and <i>dual control</i>.
-All important roles require a minimum of two persons.
-The people may be tasked to operate
-with an additional person observing (<i>four eyes</i>),
-or with two persons controlling (<i>dual control</i>).
-</p>
-
-<h4><a name="p5.2.3" id="p5.2.3">5.2.3. Identification and authentication for each role</a></h4>
-
-<p>
-All important roles are generally required to be assured
-at least to the level of Assurer, as per AP.
-Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
-</p>
-
-<p>
-<b>Technical.</b>
-Refer to Security Policy 9.1 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-
-<h4><a name="p5.2.4" id="p5.2.4">5.2.4. Roles requiring separation of duties</a></h4>
-
-<p>
-Roles strive in general for separation of duties, either along the lines of
-<i>four eyes principle</i> or <i>dual control</i>.
-</p>
-
-<h3><a name="p5.3" id="p5.3">5.3. Personnel controls</a></h3>
-
-<h4><a name="p5.3.1" id="p5.3.1">5.3.1. Qualifications, experience, and clearance requirements</a></h4>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
-  <td><b>Role</b></td> <td><b>Policy</b></td> <td><b>Comments</b></td>
- </tr><tr>
-  <td>Assurer</td>
-  <td><a href="http://www.cacert.org/policy/AssurancePolicy.php"> COD13</td>
-  <td>
-    Passes Challenge, Assured to 100 points.
-  </td>
- </tr><tr>
-  <td>Organisation Assurer</td>
-  <td><a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a></td>
-  <td>
-    Trained and tested by two supervising OAs.
-  </td>
- </tr><tr>
-  <td>Technical</td>
-  <td>SM => COD08</td>
-  <td>
-    Teams responsible for testing.
-  </td>
- </tr><tr>
-  <td>Arbitrator</td>
-  <td><a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a></td>
-  <td>
-    Experienced Assurers.
-  </td>
- </tr>
-</table>
-
-<span class="figure">Table 5.3.1.  Controls on Roles</span>
-</center>
-
-
-<h4><a name="p5.3.2" id="p5.3.2">5.3.2. Background check procedures</a></h4>
-
-<p>
-Refer to Security Policy 9.1.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-<!-- <a href="http://xkcd.com/538/"> <img align="right" src="http://imgs.xkcd.com/comics/security.png"> </a> -->
-
-<h4><a name="p5.3.3" id="p5.3.3">5.3.3. Training requirements</a></h4>
-<p>No stipulation.</p>
-<h4><a name="p5.3.4" id="p5.3.4">5.3.4. Retraining frequency and requirements</a></h4>
-<p>No stipulation.</p>
-
-<h4><a name="p5.3.5" id="p5.3.5">5.3.5. Job rotation frequency and sequence</a></h4>
-<p>No stipulation.</p>
-
-<h4><a name="p5.3.6" id="p5.3.6">5.3.6. Sanctions for unauthorized actions</a></h4>
-<p>
-Any actions that are questionable
-- whether uncertain or grossly negligent -
-may be filed as a dispute.
-The Arbitrator has wide discretion in
-ruling on loss of points, retraining,
-or termination of access or status.
-Refer to DRP.
-</p>
-
-<h4><a name="p5.3.7" id="p5.3.7">5.3.7. Independent contractor requirements</a></h4>
-<p>No stipulation.</p>
-
-<h4><a name="p5.3.8" id="p5.3.8">5.3.8. Documentation supplied to personnel</a></h4>
-<p>No stipulation.</p>
-
-<h3><a name="p5.4" id="p5.4">5.4. Audit logging procedures</a></h3>
-
-<p>
-Refer to Security Policy 4.2, 5 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-
-<h3><a name="p5.5" id="p5.5">5.5. Records archival</a></h3>
-<p>
-The standard retention period is 7 years.
-Once archived, records can only be obtained and verified
-by means of a filed dispute.
-Following types of records are archived:
-</p>
-
-<center>
-<table border="1" cellpadding="5">
- <tr>
-  <td><b>Record</b></td>
-  <td><b>Nature</b></td>
-  <td><b>Exceptions</b></td>
-  <td><b>Documentation</b></td>
- </tr>
- <tr>
-  <td>Member</td>
-  <td>username, primary and added addresses, security questions, Date of Birth</td>
-  <td>resigned non-subscribers: 0 years.</td>
-  <td>Security Policy and Privacy Policy</td>
- </tr>
- <tr>
-  <td>Assurance</td>
-  <td>CAP forms</td>
-  <td>"at least 7 years."<br> as per subsidiary policies</td>
-  <td>Assurance Policy 4.5</td>
- </tr>
- <tr>
-  <td>Organisation Assurance</td>
-  <td>COAP forms</td>
-  <td>as per subsidiary policies</td>
-  <td>Organisation Assurance Policy</td>
- </tr>
- <tr>
-  <td>certificates and revocations</td>
-  <td>  for reliance </td>
-  <td> 7 years after termination </td>
-  <td>this CPS</td>
- </tr>
- <tr>
-  <td>critical roles</td>
-  <td>background check worksheets</td>
-  <td>under direct Arbitrator control</td>
-  <td>Security Policy 9.1.3</td>
- </tr>
-</table>
-
-<span class="figure">Table 5.5.  Documents and Retention </span>
-</center>
-
-
-<h3><a name="p5.6" id="p5.6">5.6. Key changeover</a></h3>
-
-<p>
-Refer to Security Policy 9.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-</p>
-
-<h3><a name="p5.7" id="p5.7">5.7. Compromise and disaster recovery</a></h3>
-
-<p>
-Refer to Security Policy 5, 6 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
-(Refer to <a href="#p1.4">&sect;1.4</a> for limitations to service.)
-</p>
-
-</p>
-
-<h3><a name="p5.8" id="p5.8">5.8. CA or RA termination</a></h3>
-
-<h4><a name="p5.8.1" id="p5.8.1">5.8.1 CA termination</a></h4>
-
-
-<p>
-<s>
-If CAcert should terminate its operation or be
-taken over by another organisation, the actions
-will be conducted according to a plan approved
-by the CAcert Inc. Board.
-</s>
-</p>
-
-<p>
-In the event of operational termination, the
-Roots (including SubRoots)
-and all private Member information will be secured.
-The Roots will be handed over to a responsible
-party for the sole purpose of issuing revocations.
-Member information will be securely destroyed.
-</p>
-
-<span class="change">
-<p>
-The CA cannot be transferrred to another organisation.
-</p>
-</span>
-
-<p>
-<s>
-In the event of takeover,
-the Board will decide if it is in the interest
-of the Members to be converted to the
-new organisation.
-Members will be notified about the conversion
-and transfer of the Member information.
-Such takeover, conversion or transfer may involve termination
-of this CPS and other documents.
-See &sect;9.10.2.
-Members will have reasonable time in which to file a related
-dispute after notification
-(at least one month).
-See &sect;9.13.
-</s>
-</p>
-<s>
-  <ul class="error">
-    <li> The ability to transfer is not given in any of CCA, PP or AP! </li>
-    <li> The Board does not have the power to terminate a policy, that is the role of policy group! </li>
-    <li> The right to transfer was against the principles of the CAcert? </li>
-    <li> Check Association Statutes.... </li>
-  </ul>
-</s>
-
-<span class="change">
-<s>
-<p>
-New root keys and certificates will be made available
-by the new organisation as soon as reasonably practical.
-</p>
-</s>
-</span>
-
-<h4><a name="p5.8.2" id="p5.8.2">5.8.2 RA termination</a></h4>
-
-<p>
-When an Assurer desires to voluntarily terminates
-her responsibilities, she does this by filing a dispute,
-and following the instructions of the Arbitrator.
-</p>
-
-<p>
-In the case of involuntary termination, the process is
-the same, save for some other party filing the dispute.
-</p>
-
-
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p6" id="p6">6. TECHNICAL SECURITY CONTROLS</a></h2>
-
-
-<!-- <a href="http://xkcd.com/221/"> <img align="right" src="http://imgs.xkcd.com/comics/random_number.png"> </a> -->
-
-<h3><a name="p6.1" id="p6.1">6.1. Key Pair Generation and Installation</a></h3>
-
-<h4><a name="p6.1.1" id="p6.1.1">6.1.1. Key Pair Generation</a></h4>
-
-<p>
-Subscribers generate their own Key Pairs.
-</p>
-
-<h4><a name="p6.1.2" id="p6.1.2">6.1.2. Subscriber Private key security</a></h4>
-
-<p>
-There is no technical stipulation on how Subscribers generate
-and keep safe their private keys,
-however, CCA 2.5 provides for general security obligations.
-See <a href="#p9.6">&sect;9.6</a>.
-</p>
-
-<h4><a name="p6.1.3" id="p6.1.3">6.1.3. Public Key Delivery to Certificate Issuer</a></h4>
-
-<p>
-Members login to their online account.
-Public Keys are delivered by cut-and-pasting
-them into the appropriate window.
-Public Keys are delivered in signed-CSR form
-for X.509 and in self-signed form for OpenPGP.
-</p>
-
-<h4><a name="p6.1.4" id="p6.1.4">6.1.4. CA Public Key delivery to Relying Parties</a></h4>
-
-<p>
-The CA root certificates are distributed by these means:
-</p>
-
-<ul><li>
-    Published on the website of CAcert,
-    in both HTTP and HTTPS.
-  </li><li>
-    Included in Third-Party Software such as
-    Browsers, Email-Clients.
-    Such suppliers are subject to the Third Party Vendor Agreement.
-</li></ul>
-
-<p class="q"> Third Party Vendor Agreement is early wip, only </p>
-
-<h4><a name="p6.1.5" id="p6.1.5">6.1.5. Key sizes</a></h4>
-
-<p>
-No limitation is placed on Subscriber key sizes.
-</p>
-
-<p>
-CAcert X.509 root and intermediate keys are currently 4096 bits.
-X.509 roots use RSA and sign with the SHA-1 message digest algorithm.
-See <a href="#p4.3.1">&sect;4.3.1</a>.
-</p>
-
-<p>
-OpenPGP Signing uses both RSA and DSA (1024 bits).
-</p>
-
-<p>
-CAcert adds larger keys and hashes
-in line with general cryptographic trends,
-and as supported by major software suppliers.
-</p>
-
-  <ul class="q">
-    <li> old Class 3 SubRoot is signed with MD5 </li>
-    <li> likely this will clash with future plans of vendors to drop acceptance of MD5</li>
-    <li> Is this a concern? </li>
-    <li> to users who have these certs, a lot? </li>
-    <li> to audit, not much? </li>
-  </ul>
-
-
-<h4><a name="p6.1.6" id="p6.1.6">6.1.6. Public key parameters generation and quality checking</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p6.1.7" id="p6.1.7">6.1.7. Key Usage Purposes</a></h4>
-
-
-  <ul class="q">
-    <li> This section probably needs to detail the key usage bits in the certs. </li>
-  </ul>
-
-
-<p>
-CAcert roots are general purpose.
-Each root key may sign all of the general purposes
-- client, server, code.
-</p>
-
-<p>
-The website controls the usage purposes that may be signed.
-This is effected by means of the 'template' system.
-</p>
-
-
-
-<!-- <a href="http://xkcd.com/257/"> <img align="right" src="http://imgs.xkcd.com/comics/code_talkers.png"> </a> -->
-
-<h3><a name="p6.2" id="p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a></h3>
-
-
-
-
-<h4><a name="p6.2.1" id="p6.2.1">6.2.1. Cryptographic module standards and controls</a></h4>
-
-<p>
-SubRoot keys are stored on a single machine which acts
-as a Cryptographic Module, or <i>signing server</i>.
-It operates a single daemon for signing only.
-The signing server has these security features:
-</p>
-
-<ul><li>
-    It is connected only by one
-    dedicated (serial USB) link
-    to the online account server.
-    It is not connected to the network,
-    nor to any internal LAN (ethernet),
-    nor to a console switch.
-  </li><li>
-    The protocol over the dedicated link is a custom, simple
-    request protocol that only handles certificate signing requests.
-  </li><li>
-    The daemon is designed not to reveal the key.
-  </li><li>
-    The daemon incorporates a dead-man switch that monitors
-    the one webserver machine that requests access.
-  </li><li>
-    The daemon shuts down if a bad request is detected.
-  </li><li>
-    The daemon resides on an encrypted partition.
-  </li><li>
-    The signing server can only be (re)started with direct
-    systems administration access.
-  </li><li>
-    Physical Access to the signing server is under dual control.
-</li></ul>
-
-<p>
-See &sect;5. and the Security Policy 9.3.1.
-</p>
-
-<p>
-(Hardware-based, commercial and standards-based cryptographic
-modules have been tried and tested, and similar have been tested,
-but have been found wanting, e.g., for short key lengths and
-power restrictions.)
-</p>
-
-<ol class="q"><li>
-    What document is responsible for architecture?  CPS?  SM?
-    <a href="http://www.cacert.org/help.php?id=7">website</a>?
-    SM punts it to CPS, so above stays.
-  </li><li>
-    There is no criteria on Architecture.
-  </li><li>
-    Old questions moved to SM.
-  </li><li>
-    See
-    <a href="http://www.cacert.org/help.php?id=7">
-    CAcert Root key protection</a> which should be deprecated by this CPS.
-</li></ol>
-
-
-<h3><a name="p6.3" id="p6.3">6.3. Other aspects of key pair management</a></h3>
-<h4><a name="p6.3.1" id="p6.3.1">6.3.1. Public key archival</a></h4>
-
-<p>
-Subscriber certificates, including public keys,
-are stored in the database backing the online system.
-They are not made available in a public- or subscriber-accessible
-archive, see &sect;2.
-They are backed-up by CAcert's normal backup procedure,
-but their availability is a subscriber responsibility.
-</p>
-
-<h4><a name="p6.3.2" id="p6.3.2">6.3.2. Certificate operational periods and key pair usage periods</a></h4>
-
-<p>
-The operational period of a certificate and its key pair
-depends on the Assurance status of the Member,
-see <a href="#p1.4.5">&sect;1.4.5</a> and Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
-</p>
-
-<p>
-The CAcert (top-level) Root certificate
-has a 30 year expiry.
-SubRoots have 10 years, and are to be rolled over more quickly.
-The keysize of the root certificates are chosen
-in order to ensure an optimum security to CAcert
-Members based on current recommendations from the
-<a href="http://www.keylength.com/">cryptographic community</a>
-and maximum limits in generally available software.
-At time of writing this is 4096 bits.
-</p>
-
-<h3><a name="p6.4" id="p6.4">6.4. Activation data</a></h3>
-<p> No stipulation.  </p>
-
-<h3><a name="p6.5" id="p6.5">6.5. Computer security controls</a></h3>
-<p>
-Refer to Security Policy.
-</p>
-
-<h3><a name="p6.6" id="p6.6">6.6. Life cycle technical controls</a></h3>
-<p>
-Refer to SM7 "Software Development".
-</p>
-
-<h3><a name="p6.7" id="p6.7">6.7. Network security controls</a></h3>
-<p>
-Refer to SM3.1 "Logical Security - Network".
-</p>
-
-<h3><a name="p6.8" id="p6.8">6.8. Time-stamping</a></h3>
-<p>
-Each server synchronises with NTP.
-No "timestamping" service is currently offered.
-</p>
-
-  <ul class="q">
-    <li> How does the signing server syncronise if only connected over serial?</li>
-    <li>  How is timestamping done on records?</li>
-  </ul>
-
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p7" id="p7">7. CERTIFICATE, CRL, AND OCSP PROFILES</a></h2>
-
-<p>
-CAcert defines all the meanings, semantics and profiles
-applicable to issuance of certificates and signatures
-in its policies, handbooks and other documents.
-Meanings that may be written in external standards or documents
-or found in wider conventions are not
-incorporated, are not used by CAcert, and must not be implied
-by the Member or the Non-related Person.
-</p>
-
-<h3><a name="p7.1" id="p7.1">7.1. Certificate profile</a></h3>
-<h4><a name="p7.1.1" id="p7.1.1">7.1.1. Version number(s)</a></h4>
-<p class="q"> What versions of PGP are signed?  v3?  v4? </p>
-
-<p>
-Issued X.509 certificates are of v3 form.
-The form of the PGP signatures depends on several factors, therefore no stipulation.
-</p>
-
-<h4><a name="p7.1.2" id="p7.1.2">7.1.2. Certificate extensions</a></h4>
-
-<p>
-  Client certificates include the following extensions:
-</p>
-<ul>
-  <li>basicConstraints=CA:FALSE (critical)</li>
-  <li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
-  <li>extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC</li>
-  <li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
-  <li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced 
-    with the URI where the certificate revocation list relating to the 
-    certificate is found</li>
-  <li>subjectAltName=(as per <a href="#p3.1.1">&sect;3.1.1.</a>).</li>
-</ul>
-  <ul class="q">
-    <li> what about Client Certificates Adobe Signing extensions ?</li>
-    <li> SubjectAltName should become critical if DN is removed http://tools.ietf.org/html/rfc5280#section-4.2.1.6</li>
-  </ul>
-
-<p>
-  Server certificates include the following extensions:
-</p>
-<ul>
-  <li>basicConstraints=CA:FALSE (critical)</li>
-  <li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
-  <li>extendedKeyUsage=clientAuth,serverAuth,nsSGC,msSGC</li>
-  <li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
-  <li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced 
-    with the URI where the certificate revocation list relating to the 
-    certificate is found</li>
-  <li>subjectAltName=(as per <a href="#p3.1.1">&sect;3.1.1.</a>).</li>
-</ul>
-
-<p>
-  Code-Signing certificates include the following extensions:
-</p>
-<ul>
-  <li>basicConstraints=CA:FALSE (critical)</li>
-  <li>keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)</li>
-  <li>extendedKeyUsage=emailProtection,clientAuth,codeSigning,msCodeInd,msCodeCom,msEFS,msSGC,nsSGC</li>
-  <li>authorityInfoAccess = OCSP;URI:http://ocsp.cacert.org</li>
-  <li>crlDistributionPoints=URI:&lt;crlUri&gt; where &lt;crlUri&gt; is replaced 
-    with the URI where the certificate revocation list relating to the 
-    certificate is found</li>
-  <li>subjectAltName=(as per <a href="#p3.1.1">&sect;3.1.1.</a>).</li>
-</ul>
-  <ul class="q">
-    <li> what about subjectAltName for Code-signing</li>
-  </ul>
-
-<p>
-OpenPGP key signatures currently do not include extensions.
-In the future, a serial number might be included as an extension.
-</p>
-
-
-<h4><a name="p7.1.3" id="p7.1.3">7.1.3. Algorithm object identifiers</a></h4>
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p7.1.4" id="p7.1.4">7.1.4. Name forms</a></h4>
-<p>
-Refer to <a href="#p3.1.1">&sect;3.1.1</a>.
-</p>
-
-<h4><a name="p7.1.5" id="p7.1.5">7.1.5. Name constraints</a></h4>
-<p>
-Refer to <a href="#p3.1.1">&sect;3.1.1</a>.
-</p>
-
-<h4><a name="p7.1.6" id="p7.1.6">7.1.6. Certificate policy object identifier</a></h4>
-<p>
-The following OIDs are defined and should be incorporated
-into certificates:
-</p>
-
-<table border="1" cellpadding="5">
- <tr>
-  <td>
-    OID
-  </td>
-  <td>
-    Type/Meaning
-  </td>
-  <td>
-    Comment
-  </td>
- </tr>
- <tr>
-  <td>
-    1.3.6.1.4.1.18506.4.4
-  </td>
-  <td>
-    Certification Practice Statement
-  </td>
-  <td>
-    (this present document)
-  </td>
- </tr>
-</table>
-
-<p>
-Versions are defined by additional numbers appended such as .1.
-</p>
-
-<h4><a name="p7.1.7" id="p7.1.7">7.1.7. Usage of Policy Constraints extension</a></h4>
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p7.1.8" id="p7.1.8">7.1.8. Policy qualifiers syntax and semantics</a></h4>
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p7.1.9" id="p7.1.9">7.1.9. Processing semantics for the critical Certificate Policies extension</a></h4>
-<p>
-No stipulation.
-</p>
-
-
-<h3><a name="p7.2" id="p7.2">7.2. CRL profile</a></h3>
-<h4><a name="p7.2.1" id="p7.2.1">7.2.1. Version number(s)</a></h4>
-<p>
-CRLs are created in X.509 v2 format.
-</p>
-
-<h4><a name="p7.2.2" id="p7.2.2">7.2.2. CRL and CRL entry extensions</a></h4>
-
-<p>
-No extensions.
-</p>
-
-<h3><a name="p7.3" id="p7.3">7.3. OCSP profile</a></h3>
-<h4><a name="p7.3.1" id="p7.3.1">7.3.1. Version number(s)</a></h4>
-<p>
-The OCSP responder operates in Version 1.
-</p>
-<h4><a name="p7.3.2" id="p7.3.2">7.3.2. OCSP extensions</a></h4>
-<p>
-No stipulation.
-</p>
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p8" id="p8">8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS</a></h2>
-
-<p>
-There are two major threads of assessment:
-</p>
-
-<ul><li>
-  <b>Systems Audit</b>.
-  Analyses the CA for business and operations security.
-  This is conducted in two phases:  documents for compliance
-  with criteria, and operations for compliance with documentation.
-  </li><li>
-  <b>Code Audit</b>.
-  Analyses the source code.
-  This is conducted at two levels:
-  Security concepts at the web applications level,
-  and source code security and bugs review.
-</li></ul>
-
-<p>
-See the Audit page at
-<a href="http://wiki.cacert.org/wiki/Audit/">
-wiki.cacert.org/wiki/Audit/</a>
-for more information.
-</p>
-
-<h3><a name="p8.1" id="p8.1">8.1. Frequency or circumstances of assessment</a></h3>
-<p>
-The first audits started in late 2005,
-and since then, assessments have been an
-ongoing task.
-Even when completed, they are expected to
-be permanent features.
-</p>
-
-<ul><li>
-  <b>Systems Audit</b>.
-  <span class="q">
-  The first phase of the first audit is nearing completion.
-  The second phase starts in earnest when documentation is in
-  effect, at lease as DRAFT under PoP.
-  As the second phase is dependent on
-  this CPS and the Security Policy, they will
-  be in effect as DRAFT at least
-  before the first audit is completed.
-  Only prior and completed audits can be reported here.
-  </span>
-  </li><li>
-  <b>Code Audit</b>.
-  <span class="q">
-  A complete review of entire source code has not yet been completed.
-  </span>
-</li></ul>
-
-<h3><a name="p8.2" id="p8.2">8.2. Identity/qualifications of assessor</a></h3>
-
-<p>
-<b>Systems Auditors.</b>
-CAcert uses business systems auditors with broad experience
-across the full range of business, information systems
-and security fields.
-In selecting a business systems auditor, CAcert looks for
-experience that includes but is not limited to
-cryptography, PKI, governance, auditing,
-compliance and regulatory environments,
-business strategy, software engineering,
-networks, law (including multijurisdictional issues),
-identity systems, fraud, IT management.
-</p>
-
-<!-- <center><a href="http://xkcd.com/511/"> <img src="http://imgs.xkcd.com/comics/sleet.png"> </a> </center> -->
-
-<p>
-<b>Code Auditors.</b>
-See Security Policy, sections 7, 9.1.
-</p>
-
-<h3><a name="p8.3" id="p8.3">8.3. Assessor's relationship to assessed entity</a></h3>
-
-<p>
-Specific internal restrictions on audit personnel:
-</p>
-
-<ul><li>
-    Must be Assured by CAcert Assurers
-    and must be background checked.
-  </li><li>
-    Must not have been active in any (other) role in CAcert.
-    Specifically, must not be an Assurer, a member of the association,
-    or in any other defined role or office.
-  </li><li>
-    Although the Auditor may be expected to undertake various
-    of the activities (Assurance, Training)
-    during the process of the audit, any results are frozen
-    until resignation as auditor is effected.
-  </li><li>
-    The Auditor is required to declare to CAcert all
-    potential conflicts of interest on an ongoing basis.
-</li></ul>
-
-<p>
-Specific external restrictions on audit personnel:
-</p>
-
-<ul><li>
-    Should have a verifiable and lengthy history in
-    user privacy and user security.
-  </li><li>
-    Must not have worked for a competitive organisation.
-  </li><li>
-    Must not have worked for national security, intelligence,
-    LEO or similar agencies.
-</li></ul>
-
-<p>
-An Auditor may convene an audit team.
-The same restrictions apply in general
-to all members of the team, but may be varied.
-Any deviations must be documented and approved
-by the CAcert Inc. Board.
-</p>
-
-<h3><a name="p8.4" id="p8.4">8.4. Topics covered by assessment</a></h3>
-
-<p>
-Systems Audits are generally conducted to criteria.
-CAcert requires that the criteria are open:
-</p>
-
-<ul><li>
-    Published.
-    The criteria must be reviewable by all interested parties.
-  </li><li>
-    Understandable.
-    They should be understandable, in that they provide the 
-    sufficient information in a readable form for interested
-    parties to follow the gist and importance.
-    (Arcane security criteria may stretch this requirement.)
-  </li><li>
-    Complete.
-    There must be sufficent background information that the
-    whole story is there.  Especially, criteria that refer
-    to undocumented practices or conventions deliberately
-    kept secret must be avoided.
-  </li><li>
-    Applicable.  The criteria should relate directly
-    and unambiguously to a need of the identified interested parties
-    (Members, Relying Parties, Subscribers, Assurers).
-</li></ul>
-
-<p>
-See
-<a href="http://rossde.com/CA_review/">DRC</a>
-for the current criteria.
-If Auditor determines that a criteria fails to
-follow the meet the above requirements, then the criteria
-should be reworked to conform, or should be dropped
-(both with explanatory notes).
-</p>
-
-<h3><a name="p8.5" id="p8.5">8.5. Actions taken as a result of deficiency</a></h3>
-<p>
-See the current
-<a href="http://wiki.cacert.org/wiki/Audit/Done">Audit Done list</a>
-for work completed, and
-<a href="http://wiki.cacert.org/wiki/AuditToDo">Audit Todo list</a>
-for work in progress.
-</p>
-
-<p>
-Auditor may issue directives instructing changes,
-where essential to audit success or other extreme
-situations.
-Directives should be grounded on criteria,
-on established minimum or safe practices,
-or clearly described logic.
-Adequate discussion with Community
-(e.g., CAcert Inc. Board and with Policy Group)
-should precede any directive.
-They should be presented to the same standard
-as the criteria, above.
-</p>
-
-<p>
-The
-<a href="http://wiki.cacert.org/wiki/AuditDirectives">
-wiki.cacert.org/wiki/AuditDirectives</a>
-documents issued directives and actions.
-</p>
-
-<h3><a name="p8.6" id="p8.6">8.6. Communication of results</a></h3>
-
-<p>
-Current and past Audit information is available at
-<a href="http://wiki.cacert.org/wiki/Audit/">wiki.CAcert.org/wiki/Audit/</a>.
-CAcert runs an open disclosure policy and
-Audit is no exception.
-</p>
-
-<p>
-This CPS and other documents are subject to
-the process in Policy on Policy (<a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>).
-Audits cover the overall processes more
-than any one document, and documents may vary
-even as Audit reports are delivered.
-</p>
-
-
-
-
-<!-- *************************************************************** -->
-<h2><a name="p9" id="p9">9. OTHER BUSINESS AND LEGAL MATTERS</a></h2>
-<h3><a name="p9.1" id="p9.1">9.1. Fees</a></h3>
-
-
-<p>
-The current fees structure is posted at
-<a href="http://wiki.cacert.org/wiki/Price">wiki.cacert.org/wiki/Price</a>.
-Changes to the fees structure will be announced
-from time to time on the <a href="http://blog.cacert.org/">blog</a>.
-CAcert retains the right to charge fees for services.
-All fees are non-refundable.
-</p>
-
-
-<h3><a name="p9.2" id="p9.2">9.2. Financial responsibility</a></h3>
-
-<p>
-Financial risks are dealt with primarily by
-the Dispute Resolution Policy
-(<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>).
-</p>
-
-<h4><a name="p9.2.1" id="p9.2.1">9.2.1. Insurance coverage</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.2.2" id="p9.2.2">9.2.2. Other assets</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.2.3" id="p9.2.3">9.2.3. Insurance or warranty coverage for end-entities</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p9.3" id="p9.3">9.3. Confidentiality of business information</a></h3>
-
-<h4><a name="p9.3.1" id="p9.3.1">9.3.1. Scope of confidential information</a></h4>
-
-<p>
-CAcert has a policy of transparency and openness.
-The default posture is that information is public
-to the extent possible,
-unless covered by specific policy provisions
-(for example, passwords)
-or rulings by Arbitrator.
-</p>
-
-<h3><a name="p9.4" id="p9.4">9.4. Privacy of personal information</a></h3>
-
-<!-- <center><a href="http://xkcd.com/46/"> <img src="http://imgs.xkcd.com/comics/secrets.jpg"> </a> </center> -->
-<p>
-Privacy is covered by the
-CCA (COD9)
-and the Privacy Policy
-(<a href="PrivacyPolicy.html">COD5</a>).
-</p>
-
-<h4><a name="p9.4.1" id="p9.4.1">9.4.1. Privacy plan</a></h4>
-<p> No stipulation.  </p>
-<h4><a name="p9.4.2" id="p9.4.2">9.4.2. Information treated as private</a></h4>
-<p>
-Member's Date of Birth and "Lost Password" questions are treated as fully private.
-</p>
-<h4><a name="p9.4.3" id="p9.4.3">9.4.3. Information not deemed private</a></h4>
-<p>
-To the extent that information is put into an issued certificate,
-that information is not deemed private,
-as it is expected to be published by the Member as part of routine use of
-the certificate.
-Such information generally includes
-Names, domains, email addresses, and certificate serial numbers.
-</p>
-<p>
-Under Assurance Policy
-(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
-the Member's status (as Assured, Assurer, etc) is available
-to other Members.
-</p>
-<p>
-Information placed in forums outside the online system
-(wiki, blogs, policies, etc) is not deemed private, and is
-generally deemed to be published as contributions by Members.
-See
-CCA1.3 (COD9).
-</p>
-<h4><a name="p9.4.4" id="p9.4.4">9.4.4. Responsibility to protect private information</a></h4>
-<p>
-CAcert is a privacy organisation
-and takes privacy more seriously.
-Any privacy issue may be referred to dispute resolution.
-</p>
-<h4><a name="p9.4.5" id="p9.4.5">9.4.5. Notice and consent to use private information</a></h4>
-<p>
-Members are permitted to rely on certificates of other Members.
-As a direct consequence of the general right to rely,
-Members may read and store the certificates
-and/or the information within them, where duly presented in
-a relationship, and to the extent necessary for
-the agreed relationship.
-</p>
-<h4><a name="p9.4.6" id="p9.4.6">9.4.6. Disclosure pursuant to judicial or administrative process</a></h4>
-<p>
-Any disclosure pursuant to process from foreign courts
-(or similar)
-is controlled by the Arbitrator.
-</p>
-<h4><a name="p9.4.7" id="p9.4.7">9.4.7. Other information disclosure circumstances</a></h4>
-<p>
-None.
-</p>
-
-<h3><a name="p9.5" id="p9.5">9.5. Intellectual property rights</a></h3>
-
-<p>
-CAcert is committed to the philosophy of
-an open and free Internet,
-broadly as encapsulated by open and free source.
-However, due to the strict control provisions
-imposed by the audit criteria (CCS),
-and the general environment and role of CAs,
-and the commitment to security of Members,
-some deviations are necessary.
-</p>
-
-<!-- <center><a href="http://xkcd.com/225/"> <img src="http://imgs.xkcd.com/comics/open_source.png"> </a> </center> -->
-
-<h4><a name="p9.5.1" id="p9.5.1">9.5.1. Ownership and Licence</a></h4>
-
-<p>
-Assets that fall under the control of CCS
-must be transferred to CAcert.
-See PoP 6.2
-(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>),
-CCA 1.3
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
-That is, CAcert is free to use, modify,
-distribute, and otherwise conduct the business
-of the CA as CAcert sees fit with the asset.
-</p>
-
-<h4><a name="p9.5.2" id="p9.5.2">9.5.2. Brand</a></h4>
-<p>
-The brand of CAcert
-is made up of its logo, name, trademark, service marks, etc.
-Use of the brand is strictly limited by the Board,
-and permission is required.
-See <a href="http://wiki.cacert.org/wiki/TopMinutes-20070917">
-m20070917.5</a>.
-</p>
-
-<h4><a name="p9.5.3" id="p9.5.3">9.5.3. Documents</a></h4>
-
-<p>
-CAcert owns or requires full control over its documents,
-especially those covered by CCS.
-See PoP 6.2
-(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.2">COD1</a>).
-Contributors transfer the rights,
-see CCA 1.3
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
-Contributors warrant that they have the right to transfer.
-</p>
-
-<p>
-Documents are generally licensed under free and open licence.
-See
-<a href="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
-wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence</a>.
-Except where explicitly negotiated,
-CAcert extends back to contributors a
-non-exclusive, unrestricted perpetual
-licence, permitting them to to re-use
-their original work freely.
-See PoP 6.4
-(<a href="http://www.cacert.org/policy/PolicyOnPolicy.php#6.4">COD1</a>),
-CCA 1.3
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#1.3">COD9</a>).
-</p>
-
-<h4><a name="p9.5.4" id="p9.5.4">9.5.4. Code</a></h4>
-
-<p>
-CAcert owns its code or requires full control over code in use
-by means of a free and open licence.
-See CCS.
-</p>
-
-<p class="q">
-See the (new, wip)
-<a href="http://svn.cacert.cl/Documents/SourceCodeManifesto.html">
-SourceCodeManifesto</a>.
-Maybe this can replace these two paras?
-</p>
-
-<p>
-CAcert licenses its code under GPL.
-CAcert extends back to contributors a
-non-exclusive, unrestricted perpetual
-licence, permitting them to to re-use
-their original work freely.
-</p>
-
-<h4><a name="p9.5.5" id="p9.5.5">9.5.5. Certificates and Roots</a></h4>
-
-<p>
-CAcert asserts its intellectual property rights over certificates
-issued to Members and over roots.
-See CCA 4.4
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#4.4">COD9</a>),
-CCS.
-The certificates may only be used by Members under
-<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#4.4">COD9</a>,
-and,
-by others under the licences offered,
-such as
-Non-Related Persons - Disclaimer and Licence
-(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
-</p>
-
-<h3><a name="p9.6" id="p9.6">9.6. Representations and warranties</a></h3>
-
-
-<p>
-<b>Members.</b>
-All Members of the Community agree to the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
-which is the primary document for
-representations and warranties.
-Members include Subscribers, Relying Parties,
-Registration Agents and the CA itself.
-</p>
-
-<p>
-<b>RAs.</b>
-Registration Agents are obliged additionally by Assurance Policy,
-especially 3.1, 4.1
-(<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
-</p>
-
-<p>
-<b>CA.</b>
-The CA is obliged additionally by the CCS.
-</p>
-
-<p>
-<b>Third Party Vendors.</b>
-Distributors of the roots are offered the
-<span class="q">wip</span>
-3rd-Party Vendors - Disclaimer and Licence
-(3PV-DaL => CODx)
-and are offered
-<span class="q">wip</span>
-the same deal as Members to the extent that they agree
-to be Members in the Community.
-<span class="q">wip</span>
-</p>
-
-<h3><a name="p9.7" id="p9.7">9.7. Disclaimers of Warranties</a></h3>
-
-<p>
-Persons who have not accepted the above Agreements are offered the
-Non-Related Persons - Disclaimer and Licence
-(<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
-Any representations and
-warranties are strictly limited to nominal usage.
-In essence, NRPs may USE but must not RELY.
-</p>
-
-<p>
-In today's aggressive fraud environment,
-and within the context of CAcert as a community CA,
-all parties should understand that CAcert
-and its Subscribers, Assurers and other roles
-provide service on a Best Efforts basis.
-See <a href="#p1.4">&sect;1.4</a>.
-CAcert seeks to provide an adequate minimum
-level of quality in operations for its Members
-without undue risks to NRPs.
-See
-<a href="http://svn.cacert.org/CAcert/principles.html">Principles</a>.
-</p>
-
-<p>
-CAcert on behalf of the Community and itself
-makes no Warranty nor Guarantee nor promise
-that the service or certificates are adequate
-for the needs and circumstances.
-</p>
-
-<h3><a name="p9.8" id="p9.8">9.8. Limitations of liability</a></h3>
-
-<h3><a name="p9.8.1" id="p9.8.1">9.8.1 Non-Related Persons </a></h3>
-
-<p>
-CAcert on behalf of related parties
-(RAs, Subscribers, etc) and itself
-disclaims all liability to NRPs
-in their usage of CA's certificates.
-See <a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>.
-</p>
-
-<h3><a name="p9.8.2" id="p9.8.2">9.8.2 Liabilities Between Members</a></h3>
-
-<p>
-Liabilities between Members
-are dealt with by internal dispute resolution,
-which rules on liability and any limits.
-See
-<a href="#9.13">&sect;9.13</a>.
-</p>
-
-
-<h3><a name="p9.9" id="p9.9">9.9. Indemnities</a></h3>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p9.10" id="p9.10">9.10. Term and termination</a></h3>
-<h4><a name="p9.10.1" id="p9.10.1">9.10.1. Term</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.10.2" id="p9.10.2">9.10.2. Termination</a></h4>
-
-<p>
-Members file a dispute to terminate their agreement.
-See <a href="#p9.13">&sect;9.13</a> and CCA 3.3
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.3">COD9</a>).
-</p>
-
-<p>
-Documents are varied (including terminated) under <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
-</p>
-
-<p>
-For termination of the CA, see <a href="#p5.8.1">&sect;5.8.1</a>.
-</p>
-
-<h4><a name="p9.10.3" id="p9.10.3">9.10.3. Effect of termination and survival</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h3><a name="p9.11" id="p9.11">9.11. Individual notices and communications with participants</a></h3>
-
-<p>
-All participants are obliged to keep their listed
-primary email addresses in good working order.
-See CCA 3.5
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.5">COD9</a>).
-</p>
-
-
-<h3><a name="p9.12" id="p9.12">9.12. Amendments</a></h3>
-
-<p>
-Amendments to the CPS are controlled by <a href="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1</a>.
-Any changes in Member's Agreements are notified under CCA 3.4
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php#3.4">COD9</a>).
-</p>
-
-<h3><a name="p9.13" id="p9.13">9.13. Dispute resolution provisions</a></h3>
-
-<p>
-CAcert provides a forum and facility for any Member
-or other related party to file a dispute.
-</p>
-
-<ul><li>
-    The CAcert
-    Dispute Resolution Policy
-    (<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>)
-    includes rules for dispute resolution.
-  </li><li>
-    Filing is done via email to
-    &lt; support AT cacert DOT org &gt;
-</li></ul>
-
-<p>
-Members agree to file all disputes through CAcert's
-forum for dispute resolution.
-The rules include specific provisions to assist
-non-Members, etc, to file dispute in this forum.
-</p>
-
-
-<h3><a name="p9.14" id="p9.14">9.14. Governing law</a></h3>
-
-<p>
-The governing law is that of New South Wales, Australia.
-Disputes are generally heard before the Arbitrator
-under this law.
-Exceptionally, the Arbitrator may elect to apply the
-law of the parties and events, where in common,
-but this is unlikely because it may create results
-that are at odds with the Community.
-</p>
-
-<h3><a name="p9.15" id="p9.15">9.15. Compliance with Applicable Law</a></h3>
-
-<h3><a name="p9.15.1" id="p9.15.1">9.15.1 Digital Signature Law</a></h3>
-<p>
-The Commonwealth and States of Australia have passed
-various Electronic Transactions Acts that speak to
-digital signatures.  In summary, these acts follow
-the "technology neutral" model and permit but do not
-regulate the use of digital signatures.
-</p>
-
-<p>
-This especially means that the signatures created by
-certificates issued by CAcert are not in and of themselves
-legally binding human signatures, at least according to
-the laws of Australia.
-See <a href="#p1.4.3">&sect;1.4.3</a>.
-However, certificates may play a part in larger signing
-applications.  See <a href="#p1.4.1">&sect;1.4.1</a> for "digital signing" certificates.
-These applications may impose significant
-obligations, risks and liabilities on the parties.
-</p>
-
-<h3><a name="p9.15.2" id="p9.15.2">9.15.2 Privacy Law</a></h3>
-
-<p>
-See the Privacy Policy
-(<a href="PrivacyPolicy.html">COD5</a>).
-</p>
-
-<h3><a name="p9.15.3" id="p9.15.3">9.15.3 Legal Process from External Forums</a></h3>
-
-<p>
-CAcert will provide information about
-its Members only under legal subpoena or
-equivalent process
-from a court of competent jurisdiction.
-Any requests made by legal subpoena are
-treated as under the Dispute Resolution Policy
-See
-<a href="#p9.13">&sect;9.13</a>
-and
-<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a>.
-That is, all requests are treated as disputes,
-as only a duly empanelled Arbitrator has the
-authorisation and authority to rule on the
-such requests.
-<p>
-
-<p>
-A subpoena should
-include sufficient legal basis to support
-an Arbitrator in ruling that information
-be released pursuant to the filing,
-including the names of claimants in any civil case
-and an indication as to whether the claimants are
-Members or not
-(and are therefore subject to Dispute Resolution Policy).
-</p>
-
-<h3><a name="p9.16" id="p9.16">9.16. Miscellaneous provisions</a></h3>
-<h4><a name="p9.16.1" id="p9.16.1">9.16.1. Entire agreement</a></h4>
-
-<p>
-All Members of the Community agree to the
-CAcert Community Agreement
-(<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
-This agreement also incorporates other key
-documents, being this CPS, DRP and PP.
-See CCA 4.2.
-</p>
-
-<p>
-The Configuration-Control Specification
-is the set of policies that rule over the
-Community, of which the above documents are part.
-See COD2.
-Documents that have reached full POLICY status
-are located at
-<a href="http://www.cacert.org/policy/">
-www.cacert.org/policy/</a>.
-Although detailed practices may
-be found in other places on the website
-and on the wiki, the CCS documents that
-have reached DRAFT and POLICY status are
-the ruling documents.
-</p>
-
-<h4><a name="p9.16.2" id="p9.16.2">9.16.2. Assignment</a></h4>
-
-<p>
-The rights within CCA may not be ordinarily assigned.
-</p>
-
-<h4><a name="p9.16.3" id="p9.16.3">9.16.3. Severability</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h4><a name="p9.16.4" id="p9.16.4">9.16.4. Enforcement (attorneys' fees and waiver of rights)</a></h4>
-
-<p>
-The Arbitrator will specify fees and remedies, if any.
-</p>
-
-<h4><a name="p9.16.5" id="p9.16.5">9.16.5. Force Majeure</a></h4>
-
-<p>
-No stipulation.
-</p>
-
-<h2>---This is the end of the Policy---</h2>
-
-
-</body>
-</html>
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: CertificationPracticeStatement.html');
+exit();
\ No newline at end of file
diff --git a/www/policy/ConfigurationControlSpecification.html b/www/policy/ConfigurationControlSpecification.html
new file mode 100644
index 0000000..fc0e964
--- /dev/null
+++ b/www/policy/ConfigurationControlSpecification.html
@@ -0,0 +1,277 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" lang="en">
+<title>Configuration-Control Specification</title>
+<style type="text/css">
+<!--
+body {
+        font-family : verdana, helvetica, arial, sans-serif;
+}
+th {
+        text-align : left;
+}
+.comment {
+        color : steelblue;
+}
+.q {
+        color : green;
+        font-weight: bold;
+        text-align: center;
+        font-style:italic;
+}
+a:hover {
+        color : gray;
+}
+-->
+</style>
+</head>
+<body lang="en-GB">
+<h1> Configuration-Control Specification </h1>
+<!-- Absolute URL because the policies are located absolutely. -->
+<div class="comment">
+<table width="100%">
+<tbody>
+<tr>
+<td rowspan="2">
+   Name: CCS <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD2</a>
+<br>
+   Creation Date : 20091214
+<br>
+   Editor: Iang
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+<img src="images/cacert-policy.png" alt="CCA Status - POLICY" style="border-style: none;" height="31" width="88">
+</a>
+    </td>
+ </tr>
+</tbody>
+</table>
+</div>
+
+
+<h3 id="g0.0.1">Introduction </h3>
+
+<!-- This section from A.1.a through A.1.c -->
+
+<p>
+The Configuration-Control Specification (CCS COD2) controls and tracks
+those documents, processes and assets which are critical to the
+business, security and governance of the CAcert operations.
+</p>
+
+<p>
+This document is the procedure for CCS.
+This document itself is a component of the CCS,
+see §2.
+<!-- A.1.c The configuration-control specification controls its own revision process. -->
+All other documentation and process specified within
+is derivative and is ruled by the CCS.
+</p>
+
+<p>
+CCS is formated, inspired and designed to meet the needs of
+David Ross Criteria -
+<a href="http://rossde.com/CA_review/">Certificate Authority Review Checklist</a>
+- section A.1 (DRC-A.1)
+CCS may be seen as the index to systems audit under DRC.
+</p>
+
+<h3 id="g0.0.2">Documents  </h3>
+
+<!-- A.1.c-h: The configuration-control specification controls the revision process for the CCS,CP,CPS,PP,SP,R/L/O  -->
+
+<h4 id="g0.0.2.1">Controlled Document List  </h4>
+
+<p>
+This CCS creates a
+Controlled Document List (CDL)
+of Primary or "root" documents known as Policies.
+Primary documents may authorise other secondary documents
+into the CDL, or "practices" outside the list.
+</p>
+
+<p>
+The Controlled Document List
+contains numbers, locations and status
+of all controlled documents.
+The list is part of this CCS.
+</p>
+
+<!-- See A.1.k, logging of documents. -->
+
+<h4 id="g0.0.2.2">Change  </h4>
+
+
+<p>
+Change to the documents
+is as specified by
+Policy on Policy (PoP).
+Policy Officer is to manage the
+<a href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">CDL</a>.
+</p>
+
+<h4 id="g0.0.2.3">Control  </h4>
+
+<p>
+CAcert policies are required to be owned / transferred to CAcert. See PoP 6.2.
+</p>
+
+<h3 id="g0.0.3">Hardware  </h3>
+
+<!-- This section from A.1.j -->
+
+<h4 id="g0.0.3.1">Controlled Hardware List  </h4>
+
+<p>
+Critical systems are defined by Security Policy.
+</p>
+
+<h4 id="g0.0.3.2">Change  </h4>
+
+<p> See Security Policy.  </p>
+
+<h4 id="g0.0.3.3">Control  </h4>
+
+<p>
+Security Policy places executive responsibility for Hardware with the Board of CAcert Inc.
+Access is delegated to Access Engineers (SP 2) and Systems Administrators (SP 3).
+Legal ownership may be delegated by agreement to other organisations (SP 9.4).
+</p>
+
+<h3 id="g0.0.4">Software  </h3>
+<!-- A.1.i: The configuration-control specification controls changes to software involved in: certs; data; comms to public -->
+<h4 id="g0.0.4.1">Controlled Software List  </h4>
+
+<p>
+Critical software is defined by Security Policy.
+</p>
+
+<!--
+
+<ul class="q">
+
+<li> Following are questions for exec + audit, not policy.
+
+<li>One thing that is not so well covered by CAcert is the last bullet point of A.1.i</li>
+
+<li>"communicating with subscribers and with the general public."</li>
+
+<li>website is under SP;  maillists,blogs,etc are not.</li>
+
+<li>as community has deliberately gone this direction, I suggest we argue it that way.</li>
+
+<li> What is far more problematic is the failure to do CCA &amp; Challenge notification.</li>
+
+<li> What about translingo and voting? </li>
+
+<li> See <a href="https://lists.cacert.org/wws/arc/cacert-sysadm/2010-02/msg00008.html">thread</a> </li>
+  </ul>
+-->
+
+<h4 id="g0.0.4.2">Change  </h4>
+
+<p> See Security Policy.  </p>
+
+<h4 id="g0.0.4.3">Control  </h4>
+
+<p>
+CAcert owns its code, or requires control over open source code in use
+by means of an approved free and open licence.
+Such code must be identified and managed by Software Assessment.
+</p>
+
+<p>
+Developers transfer full rights to CAcert
+(in a similar fashion to documents),
+or organise their contributions under a
+proper free and open source code regime,
+as approved by Board.
+Where code is published
+(beyond scope of this document)
+care must be taken not to infringe licence conditions.
+For example, mingling issues with GPL.
+</p>
+
+<p>
+The Software Assessment Team Leader
+maintains a registry of assignments
+of title or full licence,
+and a registry of software under approved open source licences.
+</p>
+
+<h3 id="g0.0.5">Certificates  </h3>
+
+<!-- This section from A.1.b -->
+
+<p> This section applies to Root and Sub-root certificates, not to End-entity (subscriber, member) certificates. </p>
+
+<h4 id="g0.0.5.1">Certificates List  </h4>
+
+<p> Certificates (Root and sub-root) are to be listed in the CPS.  </p>
+
+<h4 id="g0.0.5.2">Changes  </h4>
+
+<p>
+Creation and handling of Certificates
+is controlled by Security Policy.
+Usage of Certificates
+is controlled by Certification Practice Statement.
+</p>
+
+<h4 id="g0.0.5.3">Archive  </h4>
+
+<p> See Security Policy. </p>
+
+<h3 id="g0.0.6">Logs  </h3>
+
+<!-- This section from A.1.k -->
+
+<h4 id="g0.0.6.1">Controlled Logs List  </h4>
+
+<p> Logs are defined by Security Policy.  </p>
+
+<h4 id="g0.0.6.2">Changes  </h4>
+
+<p> Changes to Hardware, Software and Root Certificates are logged according to Security Policy.  </p>
+
+<h4 id="g0.0.6.3">Archive  </h4>
+
+<p> See Security Policy.  </p>
+
+<h3 id="g0.0.7">Data  </h3>
+
+<!-- This section from A.1.i-j, bullets 2,3 -->
+
+<h4 id="g0.0.7.1">Types of Data  </h4>
+
+<p>
+Types of critical member data is defined by Assurance Policy.
+</p>
+
+<h4 id="g0.0.7.2">Changes  </h4>
+
+<p>
+Changes and access to critical member data
+is as defined under Assurance Policy,
+CAcert Community Agreement and
+Dispute Resolution Policy.
+Implementation of
+collection and storage of critical member data
+(user interface software and databases)
+is defined by Security Policy.
+</p>
+
+<h4 id="g0.0.7.3">Archive  </h4>
+
+<p>
+Data retention is controlled by Security Policy and CAcert Community Agreement.
+</p>
+</body>
+</html>
diff --git a/www/policy/DisputeResolutionPolicy.html b/www/policy/DisputeResolutionPolicy.html
new file mode 100644
index 0000000..a1d687d
--- /dev/null
+++ b/www/policy/DisputeResolutionPolicy.html
@@ -0,0 +1,780 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title>Dispute Resulution Policy</title>
+<style type="text/css">
+<!--
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+</head>
+<body>
+
+
+
+<div class="comment">
+<table width="100%">
+
+<tbody>
+<tr>
+<td rowspan="2">
+  Name: DRP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD7</a>
+<br>
+  Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+   Created: m20070919.3
+<br>
+   Changed: p20110108, p20121213, p20130116
+
+<br>
+  Editor: <a style="color: steelblue" href="https://wiki.cacert.org/TeusHagen">Teus Hagen
+</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy"> CC-by-sa+DRP </a>
+</td>
+<td align="right" valign="top">
+  <a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+<img src="images/cacert-policy.png" alt="DRP Status - POLICY" style="border-style: none;" height="31" width="88">
+</a>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+
+<h1> Dispute&nbsp;Resolution&nbsp;Policy </h1>
+
+<h2 id="g0.1">0. Introduction</h2>
+
+<p>
+This is the Dispute Resolution Policy
+for the CAcert Community, consisting of CAcert Inc and Members who agree to the CAcert Community Agreement (CCA).
+Disputes arising out of
+operations by CAcert
+Inc
+and interactions between
+Members
+may be addressed through this policy.
+This document also presents the rules for
+resolution of disputes.
+</p>
+
+<h3 id="g0.1.1">0.1. Nature of Disputes </h3>
+
+<p>
+Disputes include:
+</p>
+
+<ul>
+<li>
+    Requests for non-routine support actions.
+    CAcert support team has no authority to
+    act outside the normal support facilities made
+    available to
+    Members;
+  </li>
+<li>
+    Classical disputes where a Member or another
+    assert claims and demand remedies;
+  </li>
+<li>
+    Requests by external organisations, including
+    legal processes from foreign courts;
+  </li>
+<li>
+    Events initiated for training purposes.
+</li>
+</ul>
+
+<h2 id="g0.2">1. Filing</h2>
+
+<h3 id="g0.2.1">1.1. Filing Party</h3>
+<p>
+Anyone may file a dispute.
+In filing, they become <i>Claimants</i>.
+</p>
+
+<h3 id="g0.2.2">1.2. Channel for Filing</h3>
+
+<p>
+Disputes are filed by being sent to the normal
+support channel of CAcert,
+and a fee may be payable.
+</p>
+
+<p>
+Such fees as are imposed on filing will be specified
+on the dispute resolution page of the website.
+</p>
+
+<h3 id="g0.2.3">1.3. Case Manager</h3>
+<p>
+The Case Manager (CM) takes control of the filing.
+</p>
+
+<ol>
+<li>
+    CM makes an initial determination as
+    to whether this filing is a dispute
+    for resolution, or it is a request
+    for routine support.
+  </li>
+<li>
+    CM logs the case and establishes such
+    documentation and communications support as is customary.
+  </li>
+<li>
+    If any party acts immediately on the filing
+    (such as an urgent security action),
+    the CM names these parties to the case.
+  </li>
+<li>
+    CM selects the Arbitrator.
+</li>
+</ol>
+
+<p>
+The personnel within the CAcert support team
+are Case Managers, by default, or as directed
+by the Dispute Resolution Officer (DRO).
+</p>
+
+<h3 id="g0.2.4">1.4. Contents</h3>
+<p>
+The filing must specify:
+</p>
+
+<ul>
+<li>
+    The filing party(s), being the <i>Claimant(s)</i>.
+  </li>
+<li>
+    The party(s) to whom the complaint is addressed to,
+    being the <i>Respondent(s)</i>.
+    This will be CAcert in the
+    case of requests for support actions.
+    It may be a Member (possibly unidentified) in the
+    case where one Member has given rise to a complaint against another.
+  </li>
+<li>
+    The <i>Complaint</i>.
+    For example, a trademark has been infringed,
+    privacy has been breached,
+    or a Member has defrauded using a certificate.
+  </li>
+<li>
+    The action(s) requested by the filing party
+    (technically, called the <i>relief</i>).
+    For example, to delete an account,
+    to revoke a certificate, or to stop a
+    trademark infringement.
+</li>
+</ul>
+
+<p>
+If the filing is inadequate for lack of information
+or for format, the Case Manager
+may refile with the additional information,
+attaching the original messages.
+</p>
+
+<h3 id="g0.2.5">1.5. The Arbitrator</h3>
+
+<p>
+The Case Manager selects the Arbitrator according
+to the mechanism managed by the
+DRO
+and approved from time to time.
+This mechanism is to maintain a list of Arbitrators available for
+dispute resolution.
+Each selected Arbitrator has the right to decline the dispute,
+and should decline a dispute with which there exists a conflict
+of interest.
+The reason for declining should be stated.
+If no Arbitrator accepts the dispute, the case is
+closed with status "declined."
+</p>
+
+<p>
+Arbitrators are experienced Assurers.
+They should be independent and impartial, including
+of CAcert Inc. itself where it becomes a party.
+</p>
+
+<h2 id="g0.3">2. The Arbitration</h2>
+
+
+<h3 id="g0.3.1">2.1. Authority</h3>
+
+<p>
+The Board of CAcert Inc. and the
+Members of the Community
+ vest in Arbitrators
+full authority to hear disputes and deliver rulings
+which are binding on CAcert Inc. and the
+Members.
+</p>
+
+
+<h3 id="g0.3.2">2.2. Preliminaries</h3>
+
+<p>
+The Arbitrator conducts some preliminaries:
+</p>
+
+<ul>
+<li>
+   The Arbitrator reviews the available documentation
+   and affirms the rules of dispute resolution.
+   Jurisdiction is established, see below.
+  </li>
+<li>
+   The Arbitrator affirms the governing law (NSW, Australia).
+   The Arbitrator may select local law and local
+   procedures where Claimants and all Respondents
+   agree, are under such jurisdiction, and it is deemed
+   more appropriate.
+   However, this is strictly limited to those parties,
+   and especially, CAcert Inc. and other parties
+   remain under the governing law.
+  </li>
+<li>
+   The Arbitrator reviews the Respondents and Claimants
+   with a view to dismissal or joining of additional parties.
+   E.g., support personnel may be joined if emergency action was
+   taken.
+  </li>
+<li>
+   Any parties that are not
+   Members
+   and are not bound by the
+   CCA
+   are given the opportunity to enter into
+   CAcert and be bound by the
+   CCA
+   and these rules of arbitration.
+   If
+   these Non-Related Persons (NRPs)
+   remain outside,
+   their rights and remedies under CAcert's policies
+   and forum are strictly limited to
+   those
+   specified in the
+   Root Distribution License.
+   NRPs
+   may proceed with Arbitration subject to preliminary orders
+   of the Arbitrator.
+  </li>
+<li>
+   Participating
+   Members
+   may not resign
+   from the Community
+   until the completion of the case.
+  </li>
+<li>
+   The Arbitrator confirms that all parties accept
+   the forum of dispute resolution.
+   This is especially important where a
+   Member
+   might be
+   in a country with no Arbitration Act in law, or
+   where there is reason to believe that a party might
+   go to an external court.
+  </li>
+<li>
+   The Arbitrator confirms that parties are representing
+   themselves.  Parties are entitled to be legally
+   represented, but are not encouraged to do so,
+   bearing in mind the volunteer nature of the
+   organisation and the size of the dispute.
+   If they do so,
+   they must declare such, including any changes.
+  </li>
+<li>
+   The Arbitrator may appoint experienced Assurers
+   to assist and represent parties, especially for NRPs.
+   The Case Manager must not provide such assistance.
+  </li>
+<li>
+   The Arbitrator is bound to maintain the balance
+   of legal fairness.
+  </li>
+<li>
+   The Arbitrator may make any preliminary orders,
+   including protection orders and orders referring
+   to emergency actions already taken.
+  </li>
+<li>
+   The Arbitrator may request any written pleadings,
+   counterclaims, and/or statements of defence.
+</li>
+</ul>
+
+
+<h3 id="g0.3.3">2.3. Jurisdiction </h3>
+
+<p>
+Jurisdiction - the right or power to hear and rule on
+disputes - is initially established by clauses in the
+CAcert Community Agreement.
+The agreement must establish:
+</p>
+
+<ul>
+<li>
+    That all Parties agree to binding Arbitration
+    in CAcert's forum of dispute resolution;
+  </li>
+<li>
+    for all disputes relating to activities within
+    CAcert, issued certificates, roles and actions, etc;
+  </li>
+<li>
+    as defined by these rules, including the selection
+    of a single Arbitrator;
+  </li>
+<li>
+    under the Law of NSW, Australia;  and
+  </li>
+<li>
+    the Parties keep email accounts in good working order.
+</li>
+</ul>
+
+<p>
+An external court may have ("assert") jurisdiction to decide on
+issues such as trademark, privacy, contract and fraud,
+and may do so with legal remedies.
+These are areas where jurisdiction may need
+to be considered carefully:
+</p>
+
+<ul>
+<li>
+    Where NRPs, being not Members of CAcert and not
+    bound by agreement, are parties to the dispute.
+    E.g., intellectual property disputes may involve
+    NRPs and their trademarks;
+  </li>
+<li>
+    criminal actions or actions likely to result in criminal
+    proceedings,
+    e.g., fraud;
+  </li>
+<li>
+    Contracts between
+    Members
+    that were formed without
+    a clause to seek arbitration in the forum;
+  </li>
+<li>
+    Areas where laws fall outside the Arbitration Act,
+    such as privacy;
+  </li>
+<li>
+    Legal process (subpoenas, etc) delivered by
+    an external court of "competent jurisdiction."
+</li>
+</ul>
+
+<p>
+The Arbitrator must consider jurisdiction and rule on a
+case by case basis whether jurisdiction is asserted,
+either wholly or partially, or declines to hear the case.
+In the event of asserting
+jurisdiction, and a NRP later decides to pursue rights in
+another forum, the Arbitrator should seek the agreement
+of the NRP to file the ruling as part of the new case.
+</p>
+
+<h3 id="g0.3.4">2.4. Basis in Law </h3>
+
+<p>
+Each country generally has an Arbitration Act
+that elevates Arbitration as a strong dispute
+resolution forum.
+The Act generally defers to Arbitration
+if the parties have so agreed.
+That is, as
+   Members
+,
+you agree to resolve
+all disputes before CAcert's forum.
+This is sometimes called <i>private law</i>
+or <i>alternative dispute resolution</i>.
+</p>
+
+<p>
+As a matter of public policy, courts will generally
+refer any case back to Arbitration.
+Members
+should understand that they will have
+strictly limited rights to ask the courts to
+seek to have a case heard or to override a Ruling.
+</p>
+
+
+<h3 id="g0.3.5">2.5. External Courts </h3>
+
+<p>
+    When an external court claims and asserts its jurisdiction,
+    and issues a court order, subpoena or other service to CAcert,
+    the CM files the order as a dispute, with the external court
+    as <i>Claimant</i>.
+    The CM and other support staff are granted no authority to
+    act on the basis of any court order, and ordinarily
+    must await the order of the Arbitrator
+    (which might simply be a repeat of the external court order).
+</p>
+
+<p>
+    The Arbitrator establishes the bona fides of the
+    court, and rules.
+    The Arbitrator may rule to reject the order,
+    for jurisdiction or other reasons.
+    By way of example, if all Parties are
+    Members,
+    then jurisdiction more normally falls within the forum.
+    If the Arbitrator rules to reject,
+    he should do so only after consulting with CAcert Inc. counsel.
+    The Arbitrator's jurisidiction is ordinarily that of
+    dealing with the order, and
+    not that which the external court has claimed to.
+</p>
+
+
+<h3 id="g0.3.6">2.6. Process</h3>
+
+<p>
+The Arbitrator follows the procedure:
+</p>
+
+
+<ol>
+<li>
+    Establish the facts.
+    The Arbitrator collects the evidence from the parties.
+    The Arbitrator may order CAcert Inc. or
+    Members
+    under jurisdiction to provide support or information.
+    The Arbitrator may use email, phone or face-to-face
+    meetings as proceedings.
+  </li>
+<li>
+    Apply the Rules of Dispute Resolution,
+    the policies of CAcert and the governing law.
+    The Arbitrator may request that the parties
+    submit their views.
+    The Arbitrator also works to the mission of CAcert,
+    the benefit of all
+    Members
+    , and the community as a whole.
+    The Arbitrator may
+    seek
+    any assistance.
+  </li>
+<li>
+    Makes a considered Ruling.
+</li>
+</ol>
+
+<h2 id="g0.4">3. The Ruling</h2>
+
+<h3 id="g0.4.1">3.1. The Contents </h3>
+
+<p>
+The Arbitrator records:
+</p>
+
+<ol>
+<li>
+   The Identification of the Parties,
+  </li>
+<li>
+   The Facts,
+  </li>
+<li>
+   The logic of the rules and law,
+  </li>
+<li>
+   The directions and actions to be taken by each party
+   (the ruling).
+  </li>
+<li>
+   The date and place that the ruling is rendered.
+</li>
+</ol>
+
+
+<h3 id="g0.4.2">3.2. Process </h3>
+<p>
+Once the Ruling is delivered, the case is closed.
+The Case Manager is responsible for recording the
+Ruling, publishing it, and advising Members.
+</p>
+
+<p>
+Proceedings are ordinarily private.
+The Ruling is ordinarily published,
+within the bounds of the Privacy Policy.
+The Ruling is written in English.
+</p>
+
+<p>
+Only under exceptional circumstances can the
+Arbitrator declare the Ruling private <i>under seal</i>.
+Such a declaration must be reviewed in its entirety
+by the Board,
+and the Board must confirm or deny that declaration.
+If it confirms, the existence of any Rulings under seal
+must be published to the
+Members
+in a timely manner
+(within days).
+</p>
+
+<h3 id="g0.4.3">3.3. Binding and Final </h3>
+
+<p>
+The Ruling is
+ordinarily final and binding
+on CAcert Inc.and all
+   Members
+.
+Ordinarily, all
+   Members
+ agree to be bound by this dispute
+resolution policy.
+   Members
+must declare in the Preliminaries
+any default in agreement or binding.
+</p>
+
+<p>
+If a person who is not a
+   Member
+is a party to the dispute,
+then the Ruling is not binding and final on that person,
+but the Ruling must be presented in filing any dispute
+in another forum such as the person's local courts.
+</p>
+
+<h3 id="g0.4.4">3.4. Review for Appeal</h3>
+
+<p>
+In the eventof clear injustices, egregious behaviour or
+unconscionable Rulings,
+a review may be requested by filing a dispute.
+The new Arbitrator reviews the new dispute,
+re-examines and reviews the entire case, then rules on
+whether the case may be re-opened or not.
+</p>
+
+<p>
+If the Review Arbitrator rules the case be re-opened,
+then the Review Arbitrator refers the case to an Appeal Panel of 3.
+The Appeal Panel is led by a Senior Arbitrator,
+and is formed according to procedures established
+by the DRO from time to time.
+The Appeal Panel hears the case and delivers a final and binding Ruling.
+</p>
+
+<h3 id="g0.4.5">3.5. Liability </h3>
+
+<p>
+All liability of the Arbitrator for any act in
+connection with deciding a dispute is excluded
+by all parties, provided such act does not constitute
+an intentional breach of duty.
+All liability of the Arbitrators, CAcert Inc., its officers and its
+employees (including Case Manager)
+for any other act or omission in connection with
+arbitration proceedings is excluded, provided such acts do not
+constitute an intentional or grossly negligent breach of duty.
+</p>
+
+<p>
+The above provisions may only be overridden by
+appeal process
+ (by means of a new dispute causing referral to the Board).
+
+</p>
+
+<h3 id="g0.4.6">3.6. Remedies </h3>
+
+<p>
+The Arbitrator generally instructs using internal remedies,
+that is ones that are within the general domain of
+the Community,
+but there are some external remedies at his disposal.
+He may rule and instruct any of the parties on these issues.
+</p>
+
+<ul>
+<li>
+    "community service" typically including
+
+<ul>
+<li>
+        attend and assure people at trade shows / open source gatherings,
+      </li>
+<li>
+        writing documentation
+      </li>
+<li>
+        serve in a role - support, dispute arbitration
+    </li>
+</ul>
+    or others as decided.
+
+  </li>
+<li>
+    Fined by loss of assurance points, which may result
+    in losing Assurer or Assured status.
+
+  </li>
+<li>
+    Retraining in role.
+
+  </li>
+<li>
+    Revoking of any certificates.
+
+  </li>
+<li>
+    Monetary fine up to the liability cap established for
+    each party as described in the
+    CAcert Community Agreement.
+
+  </li>
+<li>
+    Exclusion from community.
+
+  </li>
+<li>
+    Reporting to applicable authorities.
+
+  </li>
+<li>
+    Changes to policies and procedures.
+
+</li>
+</ul>
+
+<p>
+The Arbitrator is not limited within the general domain
+of CAcert, and may instruct novel remedies as seen fit.
+Novel remedies outside the domain may be routinely
+confirmed by the Board by way of appeal process,
+in order to establish precedent.
+
+</p>
+
+<h2 id="g0.5">4. Appendix</h2>
+
+
+<h3 id="g0.5.1">4.1. The Advantages of this Forum </h3>
+<p>
+The advantage of this process for
+   Members
+ is:
+</p>
+
+<ul>
+<li>
+    CAcert and Members operate across many jurisdictions.
+    Arbitration allows us to select a single set of
+    rules across all jurisdictions.
+  </li>
+<li>
+    Arbitration allows CAcert to appropriately separate
+    out the routine support actions from difficult dispute
+    actions.  Support personnel have no authority to
+    act, the appropriately selected Arbitrator has all
+    authority to act.
+    Good governance is thus maintained.
+  </li>
+<li>
+    This forum allows CAcert Members to look after themselves
+    in a community, without exposing each other to potentially
+    disastrous results in strange courts from foreign lands.
+  </li>
+<li>
+    By volunteering to resolve things "in-house" the costs
+    are reduced.
+  </li>
+<li>
+    Even simple support issues such as password changing
+    can be improved by treating as a dispute.  A clear
+    chain of request, analysis, ruling and action can be established.
+  </li>
+<li>
+    CAcert Assurers can develop the understanding and the rules
+    for sorting out own problems far better than courts or
+    other external agencies.
+</li>
+</ul>
+
+<h3 id="g0.5.2">4.2. The Disadvantages of this Forum </h3>
+
+<p>
+Some disadvantages exist.
+</p>
+
+<ul>
+<li>
+     Membersmay have their rights trampled over.
+     In such a case, the community should strive to
+     re-open the case
+     and refer it to the board.
+
+
+  </li>
+<li>
+     Members may feel overwhelmed by the formality
+     of the process.
+     It is kept formal so as to establish good and proper
+     authority to act;  otherwise, support and other
+     people in power may act without thought and with
+     damaging consequences.
+  </li>
+<li>
+     A country may not have an Arbitration Act.
+     In that case, the parties should enter into
+     spirit of the forum.
+     If they choose to break that spirit,
+     they should also depart the community.
+</li>
+</ul>
+
+<h3 id="g0.5.3">4.3. Process and Flow </h3>
+
+<p>
+To the extent reasonable, the Arbitrator conducts
+the arbitration as with any legal proceedings.
+This means that the process and style should follow
+legal tradition.
+</p>
+
+<p>
+However, the Arbitrator is unlikely to be trained in
+law.  Hence, common sense must be applied, and the
+Arbitrator has wide latitude to rule on any particular
+motion, pleading, submission.  The Arbitrator's ruling
+is final within the arbitration.
+</p>
+
+<p>
+Note also that many elements of legal proceedings are
+deliberately left out of the rules.
+</p>
+
+
+</body>
+</html>
diff --git a/www/policy/DisputeResolutionPolicy.php b/www/policy/DisputeResolutionPolicy.php
index 40fca3a..565a71f 100644
--- a/www/policy/DisputeResolutionPolicy.php
+++ b/www/policy/DisputeResolutionPolicy.php
@@ -1,794 +1,4 @@
-<?='<?xml version="1.0" encoding="utf-8"?>'?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
-        "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
- <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" />
- <title>Dispute Resulution Policy</title>
-<style type="text/css">
-<!--
-.first-does-not-work {
-        color : red;
-}
-.comment {
-        color : steelblue;
-}
-.q {
-        color : green;
-        font-weight: bold;
-        text-align: center;
-        font-style:italic;
-}
-.change {
-        color : blue;
-        font-weight: bold;
-}
-.change2 {
-        color : steelblue;
-}
-.strike {
-        color : blue;
-        text-decoration:line-through;
-}
-.draftadd {
-        color : darkblue;
-        font-weight: bold;
-        font-style: italic;
-}
-.draftdrop {
-        color : darkblue;
-        text-decoration:line-through;
-        font-style: italic;
-}
--->
-</style>
-
-</head>
-<body>
-
-
-
-<div class="comment">
-<table width="100%">
-
-<tr>
-<td>
-  Name: DRP <a style="color: steelblue" href="//svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD7</a><br />
-  Status: POLICY <a style="color: steelblue" href="//wiki.cacert.org/wiki/TopMinutes-20070917">m20070919.3</a><br />
-  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;           <span class="draftadd">DRAFT p20110108 p20121213</span> <br />
-  Editor: <a style="color: steelblue" href="//wiki.cacert.org/TeusHagen">Teus Hagen
-</a><br />
-   Licence: <a style="color: steelblue" href="//wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br /></td>
-<td valign="top" align="right">
-  <a href="//www.cacert.org/policy/PolicyOnPolicy.php"><img src="/images/cacert-policy.png" alt="TTP-Assist Status - POLICY" height="31" width="88" style="border-style: none;" /></a><br />
-  <a href="//www.cacert.org/policy/PolicyOnPolicy.php"><img src="/images/cacert-draft.png" alt="TTP-Assist Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
-
-</td>
-</tr>
-</table>
-</div>
-
-
-<h1> Dispute&nbsp;Resolution&nbsp;Policy </h1>
-
-<h2 id="s0">  0. Introduction</h2>
-
-<p>
-This is the Dispute Resolution Policy
-<span class="draftdrop">for CAcert</span>
-<span class="draftadd">for the CAcert Community, consisting of CAcert Inc and Members who agree to the CAcert Community Agreement (CCA)</span>.
-Disputes arising out of
-operations by CAcert
-<span class="draftadd">Inc</span>
-and interactions between
-<span class="draftadd">
-Members
-</span>
-may be addressed through this policy.
-This document also presents the rules for
-resolution of disputes.
-</p>
-
-<h3 id="s0.1">  0.1 Nature of Disputes </h3>
-
-<p>
-Disputes include:
-</p>
-
-<ul><li>
-    Requests for non-routine support actions.
-    CAcert support team has no authority to
-    act outside the normal support facilities made
-    available to 
-    <span class="draftadd">
-    Members;
-    </span>
-  </li><li>
-    Classical disputes where a <span class="draftadd">Member</span> or another
-    assert claims and demand remedies;
-  </li><li>
-    Requests by external organisations, including
-    legal processes from foreign courts;
-  </li><li>
-    Events initiated for training purposes.
-</li></ul>
-
-<h2 id="s1">  1. Filing</h2>
-
-<h3 id="s1.1">  1.1 Filing Party</h3>
-<p>
-Anyone may file a dispute.
-In filing, they become <i>Claimants</i>.
-</p>
-
-<h3 id="s1.2"> 1.2 Channel for Filing</h3>
-
-<p>
-Disputes are filed by being sent to the normal
-support channel of CAcert,
-and a fee may be payable.
-</p>
-
-<p>
-Such fees as are imposed on filing will be specified
-on the dispute resolution page of the website.
-</p>
-
-<h3 id="s1.3"> 1.3 Case Manager</h3>
-<p>
-The Case Manager (CM) takes control of the filing.
-</p>
-
-<ol><li>
-    CM makes an initial determination as
-    to whether this filing is a dispute
-    for resolution, or it is a request
-    for routine support.
-  </li><li>
-    CM logs the case and establishes such
-    documentation and communications support as is customary.
-  </li><li>
-    If any party acts immediately on the filing
-    (such as an urgent security action),
-    the CM names these parties to the case.
-  </li><li>
-    CM selects the Arbitrator.
-</li></ol>
-
-<p>
-The personnel within the CAcert support team
-are Case Managers, by default, or as directed
-by the Dispute Resolution Officer <span class="change2">(DRO)</span>.
-</p>
-
-<h3 id="s1.4"> 1.4 Contents</h3>
-<p>
-The filing must specify:
-</p>
-
-<ul><li>
-    The filing party(s), being the <i>Claimant(s)</i>.
-  </li><li>
-    The party(s) to whom the complaint is addressed to,
-    being the <i>Respondent(s)</i>.
-    This will be CAcert in the
-    case of requests for support actions.
-    It may be a <span class="draftadd">Member</span> (possibly unidentified) in the
-    case where one <span class="draftadd">Member</span> has given rise to a complaint against another.
-  </li><li>
-    The <i>Complaint</i>.
-    For example, a trademark has been infringed,
-    privacy has been breached,
-    or a <span class="draftadd">Member</span> has defrauded using a certificate.
-  </li><li>
-    The action(s) requested by the filing party
-    (technically, called the <i>relief</i>).
-    For example, to delete an account,
-    to revoke a certificate, or to stop a
-    trademark infringement.
-</li></ul>
-
-<p>
-If the filing is inadequate for lack of information
-or for format, the Case Manager
-may refile with the additional information,
-attaching the original messages.
-</p>
-
-<h3 id="s1.5"> 1.5 The Arbitrator</h3>
-
-<p>
-The Case Manager selects the Arbitrator according
-to the mechanism managed by the
-<span class="change2">DRO</span> <!-- Dispute Resolution Officer -->
-and approved from time to time.
-This mechanism is to maintain a list of Arbitrators available for
-dispute resolution.
-Each selected Arbitrator has the right to decline the dispute,
-and should decline a dispute with which there exists a conflict
-of interest.
-The reason for declining should be stated.
-If no Arbitrator accepts the dispute, the case is
-closed with status "declined."
-</p>
-
-<p>
-Arbitrators are experienced Assurers <span class="draftdrop">of CAcert</span>.
-They should be independent and impartial, including
-of CAcert <span class="draftadd">Inc.</span> itself where it becomes a party.
-</p>
-
-<h2 id="s2">  2. The Arbitration</h2>
-
-
-<h3 id="s2.1"> 2.1  Authority</h3>
-
-<p>
-The Board of CAcert <span class="draftadd">Inc.</span> and the 
-<span class="draftadd">
-Members of the Community
-</span>
- vest in Arbitrators
-full authority to hear disputes and deliver rulings
-which are binding on CAcert <span class="draftadd">Inc.</span> and the
-<span class="draftadd">
-Members.
-</span>
-</p>
-
-
-<h3 id="s2.2"> 2.2  Preliminaries</h3>
-
-<p>
-The Arbitrator conducts some preliminaries:
-</p>
-
-<ul><li>
-   The Arbitrator reviews the available documentation
-   and affirms the rules of dispute resolution.
-   Jurisdiction is established, see below.
-  </li><li>
-   The Arbitrator affirms the governing law (NSW, Australia).
-   The Arbitrator may select local law and local
-   procedures where Claimants and all Respondents
-   agree, are under such jurisdiction, and it is deemed
-   more appropriate.
-   However, this is strictly limited to those parties,
-   and especially, CAcert <span class="draftadd">Inc.</span> and other parties
-   remain under the governing law.
-  </li><li>
-   The Arbitrator reviews the Respondents and Claimants
-   with a view to dismissal or joining of additional parties.
-   E.g., support personnel may be joined if emergency action was
-   taken.
-  </li><li>
-   Any parties that are not 
-   <span class="draftadd">
-   Members
-   </span>
-   and are not bound by the
-   <span class="draftdrop">CPS</span> <span class="draftadd">CCA</span>
-   are given the opportunity to enter into
-   CAcert and be bound by the
-   <span class="draftdrop">CPS</span> <span class="draftadd">CCA</span>
-   and these rules of arbitration.
-   If
-   <!-- <span class="draftdrop">these Non-Related Persons (NRPs)</span> <span class="change">they</span> -->
-   these Non-Related Persons (NRPs)
-   remain outside,
-   their rights and remedies under CAcert's policies
-   and forum are strictly limited to
-   <span class="strike">that</span> <span class="change2">those</span>
-   specified in the
-   <span class="draftdrop">Non-Related Persons -- Disclaimer and Licence</span> <span class="draftadd">Root Distribution License</span>.
-   NRPs
-   may proceed with Arbitration subject to preliminary orders
-   of the Arbitrator.
-  </li><li>
-   Participating 
-   <span class="draftadd">
-   Members
-   </span>
-   may not resign
-   <span class="change2">
-   from the Community
-   </span>
-   until the completion of the case.
-  </li><li>
-   The Arbitrator confirms that all parties accept
-   the forum of dispute resolution.
-   This is especially important where a
-   <span class="draftadd">
-   Member
-   </span>
-   might be
-   in a country with no Arbitration Act in law, or
-   where there is reason to believe that a party might
-   go to an external court.
-  </li><li>
-   The Arbitrator confirms that parties are representing
-   themselves.  Parties are entitled to be legally
-   represented, but are not encouraged to do so,
-   bearing in mind the volunteer nature of the
-   organisation and the size of the dispute.
-   If they do so<span class="change2">,</span>
-   they must declare such, including any changes.
-  </li><li>
-   The Arbitrator may appoint experienced Assurers
-   to assist and represent parties, especially for NRPs.
-   The Case Manager must not provide such assistance.
-  </li><li>
-   The Arbitrator is bound to maintain the balance
-   of legal fairness.
-  </li><li>
-   The Arbitrator may make any preliminary orders,
-   including protection orders and orders referring
-   to emergency actions already taken.
-  </li><li>
-   The Arbitrator may request any written pleadings,
-   counterclaims, and/or statements of defence.
-</li></ul>
-
-
-<h3 id="s2.3"> 2.3  Jurisdiction </h3>
-
-<p>
-Jurisdiction - the right or power to hear and rule on
-disputes - is initially established by clauses in the
-<span class="draftadd">
-CAcert Community Agreement.
-</span>
-The agreement must establish:
-</p>
-
-<ul><li>
-    That all Parties agree to binding Arbitration
-    in CAcert's forum of dispute resolution;
-  </li><li>
-    for all disputes relating to activities within
-    CAcert, issued certificates, roles and actions, etc;
-  </li><li>
-    as defined by these rules, including the selection
-    of a single Arbitrator;
-  </li><li>
-    under the Law of NSW, Australia;  and
-  </li><li>
-    the Parties keep email accounts in good working order.
-</li></ul>
-
-<p>
-An external court may have ("assert") jurisdiction to decide on
-issues such as trademark, privacy, contract and fraud,
-and may do so with legal remedies.
-These are areas where jurisdiction may need
-to be considered carefully:
-</p>
-
-<ul><li>
-    Where NRPs, being not Members of CAcert and not
-    bound by agreement, are parties to the dispute.
-    E.g., intellectual property disputes may involve
-    NRPs and their trademarks;
-  </li><li>
-    criminal actions or actions likely to result in criminal
-    proceedings,
-    e.g., fraud;
-  </li><li>
-    Contracts between 
-   <span class="draftadd">
-    Members
-   </span>
-    that were formed without
-    a clause to seek arbitration in the forum;
-  </li><li>
-    Areas where laws fall outside the Arbitration Act,
-    such as privacy;
-  </li><li>
-    Legal process (subpoenas, etc) delivered by
-    an external court of "competent jurisdiction."
-</li></ul>
-
-<p>
-The Arbitrator must consider jurisdiction and rule on a
-case by case basis whether jurisdiction is asserted,
-either wholly or partially, or declines to hear the case.
-In the event of asserting
-jurisdiction, and a NRP later decides to pursue rights in
-another forum, the Arbitrator should seek the agreement
-of the NRP to file the ruling as part of the new case.
-</p>
-
-<h3 id="s2.4"> 2.4  Basis in Law </h3>
-
-<p>
-Each country generally has an Arbitration Act
-that elevates Arbitration as a strong dispute
-resolution forum.
-The Act generally defers to Arbitration
-if the parties have so agreed.
-That is, as 
-   <span class="draftadd">
-   Members
-   </span>
-<span class="draftdrop">users of CAcert</span>,
-you agree to resolve
-all disputes before CAcert's forum.
-This is sometimes called <i>private law</i>
-or <i>alternative dispute resolution</i>.
-</p>
-
-<p>
-As a matter of public policy, courts will generally
-refer any case back to Arbitration.
-   <span class="draftadd">
-   Members
-   </span>
-should understand that they will have
-strictly limited rights to ask the courts to
-seek to have a case heard or to override a Ruling.
-</p>
-
-
-<h3 id="s2.5"> 2.5  External Courts </h3>
-
-<p>
-    When an external court claims and asserts its jurisdiction,
-    and issues a court order, subpoena or other service to CAcert,
-    the CM files the order as a dispute, with the external court
-    as <i>Claimant</i>.
-    The CM and other support staff are granted no authority to
-    act on the basis of any court order, and ordinarily
-    must await the order of the Arbitrator
-    (which might simply be a repeat of the external court order).
-</p>
-
-<p>
-    The Arbitrator establishes the bona fides of the
-    court, and rules.
-    The Arbitrator may rule to reject the order,
-    for jurisdiction or other reasons.
-    By way of example, if all Parties are
-    <span class="draftadd">
-    Members,
-    </span>
-    then jurisdiction more normally falls within the forum.
-    If the Arbitrator rules to reject,
-    he should do so only after consulting with CAcert <span class="draftadd">Inc.</span> counsel.
-    The Arbitrator's jurisidiction is ordinarily that of
-    dealing with the order, and
-    not that which the external court has claimed to.
-</p>
-
-
-<h3 id="s2.6"> 2.6  Process</h3>
-
-<p>
-The Arbitrator follows the procedure:
-</p>
-
-
-<ol><li>
-    Establish the facts.
-    The Arbitrator collects the evidence from the parties.
-    The Arbitrator may order CAcert <span class="draftadd">Inc.</span> or
-   <span class="draftadd">
-   Members
-   </span>
-    under jurisdiction to provide support or information.
-    The Arbitrator may use email, phone or face-to-face
-    meetings as proceedings.
-  </li><li>
-    Apply the Rules of Dispute Resolution,
-    the policies of CAcert and the governing law.
-    The Arbitrator may request that the parties
-    submit their views.
-    The Arbitrator also works to the mission of CAcert,
-    the benefit of all
-   <span class="draftadd">
-   Members
-   </span>
-    , and the community as a whole.
-    The Arbitrator may
-    <span class="draftadd">
-    seek
-    </span>
-    any assistance.
-  </li><li>
-    Makes a considered Ruling.
-</li></ol>
-
-<h2 id="s3">  3. The Ruling</h2>
-
-<h3 id="s3.1"> 3.1  The Contents </h3>
-
-<p>
-The Arbitrator records:
-</p>
-
-<ol><li>
-   The Identification of the Parties,
-  </li><li>
-   The Facts,
-  </li><li>
-   The logic of the rules and law,
-  </li><li>
-   The directions and actions to be taken by each party
-   (the ruling).
-  </li><li>
-   The date and place that the ruling is rendered.
-</li></ol>
-
-
-<h3 id="s3.2"> 3.2  Process </h3>
-<p>
-Once the Ruling is delivered, the case is closed.
-The Case Manager is responsible for recording the
-Ruling, publishing it, and advising <span class="draftadd">Members</span>.
-</p>
-
-<p>
-Proceedings are ordinarily private.
-The Ruling is ordinarily published,
-within the bounds of the Privacy Policy.
-The Ruling is written in English.
-</p>
-
-<p>
-Only under exceptional circumstances can the
-Arbitrator declare the Ruling private <i>under seal</i>.
-Such a declaration must be reviewed in its entirety
-by the Board,
-and the Board must confirm or deny that declaration.
-If it confirms, the existence of any Rulings under seal
-must be published to the
-   <span class="draftadd">
-   Members
-   </span>
-in a timely manner
-(within days).
-</p>
-
-<h3 id="s3.3"> 3.3  Binding and Final </h3>
-
-<p>
-The Ruling is
-<!-- (DRAFT p20110108) -->
-<span class="draftadd">ordinarily final and binding </span>
-<span class="draftdrop">binding and final</span>
-on CAcert <span class="draftadd">Inc.</span> and all
-   <span class="draftadd">
-   Members
-   </span>
-.
-Ordinarily, all
-   <span class="draftadd">
-   Members
-   </span>
- agree to be bound by this dispute
-resolution policy.
-   <span class="draftadd">
-   Members
-   </span>
-must declare in the Preliminaries
-any default in agreement or binding.
-</p>
-
-<p>
-If a person who is not a
-   <span class="draftadd">
-   Member
-   </span>
-is a party to the dispute,
-then the Ruling is not binding and final on that person,
-but the Ruling must be presented in filing any dispute
-in another forum such as the person's local courts.
-</p>
-
-<h3 id="s3.4"> 3.4  <span class="draftadd">Review for Appeal (DRAFT p20110108)</span> &nbsp;&nbsp;&nbsp;&nbsp;    <span class="draftdrop">Re-opening the Case or Appeal</span> </h3>
-
-<p>
-In the <span class="draftadd">event</span> <span class="draftdrop">case</span> of clear injustices, egregious behaviour or
-unconscionable Rulings,
-<span class="draftadd">
-a review may be requested by filing a dispute  (DRAFT p20110108).
-</span>
-<span class="draftdrop">
-parties may seek to re-open the
-case by filing a dispute.
-</span>
-The new Arbitrator reviews the new dispute,
-re-examines and reviews the entire case, then rules on
-whether the case may be re-opened or not.
-</p>
-
-<p>
-<span class="draftadd">
-If the Review Arbitrator rules the case be re-opened,
-then the Review Arbitrator refers the case to an Appeal Panel of 3.
-The Appeal Panel is led by a Senior Arbitrator,
-and is formed according to procedures established
-by the DRO from time to time.
-The Appeal Panel hears the case and delivers a final and binding Ruling.
- (DRAFT p20110108)
-</span>
-<span class="draftdrop">
-If the new Arbitrator rules the case be re-opened,
-then it is referred to the Board of CAcert Inc.
-The Board hears the case and delivers a final
-and binding Ruling.
-</span>
-</p>
-
-<h3 id="s3.5"> 3.5  Liability </h3>
-
-<p>
-All liability of the Arbitrator for any act in
-connection with deciding a dispute is excluded
-by all parties, provided such act does not constitute
-an intentional breach of duty.
-All liability of the Arbitrators, CAcert <span class="draftadd">Inc.</span>, its officers and its
-employees (including Case Manager)
-for any other act or omission in connection with
-arbitration proceedings is excluded, provided such acts do not
-constitute an intentional or grossly negligent breach of duty.
-</p>
-
-<p>
-The above provisions may only be overridden by
-appeal process
- (by means of a new dispute causing referral to the Board).
-
-</p>
-
-<h3 id="s3.6"> 3.6  Remedies </h3>
-
-<p>
-The Arbitrator generally instructs using internal remedies,
-that is ones that are within the general domain of
-<span class="draftdrop">CAcert</span>
-<span class="draftadd">the Community</span>,
-but there are some external remedies at his disposal.
-He may rule and instruct any of the parties on these issues.
-</p>
-
-<ul><li>
-    "community service" typically including
-    <ul><li>
-        attend and assure people at trade shows / open source gatherings,
-      </li><li>
-        writing documentation
-      </li><li>
-        serve in <span class="change2">a</span> role - support, dispute arbitration
-    </li></ul>
-    or others as decided.
-
-  </li><li>
-    Fined by loss of assurance points, which may result
-    in losing Assurer or Assured status.
-
-  </li><li>
-    Retraining in role.
-
-  </li><li>
-    Revoking of any certificates.
-
-  </li><li>
-    Monetary fine up to the liability cap established for
-    each party as described in the
-    <span class="draftadd">
-    CAcert Community Agreement.
-    </span>
-
-  </li><li>
-    Exclusion from community.
-
-  </li><li>
-    Reporting to applicable authorities.
-
-  </li><li>
-    Changes to policies and procedures.
-
-</li></ul>
-
-<p>
-The Arbitrator is not limited within the general domain
-of CAcert, and may instruct novel remedies as seen fit.
-Novel remedies outside the domain may be routinely
-confirmed by the Board by way of appeal process,
-in order to establish precedent.
-
-</p>
-
-<h2 id="s4">  4. Appendix</h2>
-
-
-<h3 id="s4.1"> 4.1  The Advantages of this Forum </h3>
-<p>
-The advantage of this process for
-   <span class="draftadd">
-   Members
-   </span>
- is:
-</p>
-
-<ul><li>
-    CAcert and <span class="draftadd">Members</span> operate across many jurisdictions.
-    Arbitration allows us to select a single set of
-    rules across all jurisdictions.
-  </li><li>
-    Arbitration allows CAcert to appropriately separate
-    out the routine support actions from difficult dispute
-    actions.  Support personnel have no authority to
-    act, the appropriately selected Arbitrator has all
-    authority to act.
-    Good governance is thus maintained.
-  </li><li>
-    This forum allows CAcert <span class="draftadd">Members</span> to look after themselves
-    in a community, without exposing each other to potentially
-    disastrous results in strange courts from foreign lands.
-  </li><li>
-    By volunteering to resolve things "in-house" the costs
-    are reduced.
-  </li><li>
-    Even simple support issues such as password changing
-    can be improved by treating as a dispute.  A clear
-    chain of request, analysis, ruling and action can be established.
-  </li><li>
-    CAcert Assurers can develop the understanding and the rules
-    for sorting out own problems far better than courts or
-    other external agencies. 
-</li></ul>
-
-<h3 id="s4.2"> 4.2  The Disadvantages of this Forum </h3>
-
-<p>
-Some disadvantages exist.
-</p>
-
-<ul><li>
-     <span class="draftadd">Members</span> may have their rights trampled over.
-     In such a case, the community should strive to
-     re-open the case
-     and refer it to the board.
-
-
-  </li><li>
-     <span class="draftadd">Members</span> may feel overwhelmed by the formality
-     of the process.
-     It is kept formal so as to establish good and proper
-     authority to act;  otherwise, support and other
-     people in power may act without thought and with
-     damaging consequences.
-  </li><li>
-     A country may not have an Arbitration Act.
-     In that case, the parties should enter into
-     spirit of the forum.
-     If they choose to break that spirit,
-     they should also depart the community.
-</li></ul>
-
-<h3 id="s4.3"> 4.3  Process and Flow </h3>
-
-<p>
-To the extent reasonable, the Arbitrator conducts
-the arbitration as with any legal proceedings.
-This means that the process and style should follow
-legal tradition.
-</p>
-
-<p>
-However, the Arbitrator is unlikely to be trained in
-law.  Hence, common sense must be applied, and the
-Arbitrator has wide latitude to rule on any particular
-motion, pleading, submission.  The Arbitrator's ruling
-is final within the arbitration.
-</p>
-
-<p>
-Note also that many elements of legal proceedings are
-deliberately left out of the rules.
-</p>
-
-
-</body>
-</html>
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: DisputeResolutionPolicy.html');
+exit();
\ No newline at end of file
diff --git a/www/policy/NRPDisclaimerAndLicence.php b/www/policy/NRPDisclaimerAndLicence.php
deleted file mode 100644
index bee8f26..0000000
--- a/www/policy/NRPDisclaimerAndLicence.php
+++ /dev/null
@@ -1,14 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-
-<html>
-<head><title>NRP-DAL was replaced by the Root Distribution License</title></head>
-<body>
-<table border="1" bgcolor="#EEEEEE"><tr><td>
-
-The document "Non Related Persons - Disclaimer And Licence" was replaced by the Root Distribution Licence, which can be found <a href="/policy/RootDistributionLicense.php">here</a>.
-
-</td>
-</tr>
-</table>
-</body>
-</html>
diff --git a/www/policy/OrganisationAssurancePolicy.html b/www/policy/OrganisationAssurancePolicy.html
new file mode 100644
index 0000000..0474953
--- /dev/null
+++ b/www/policy/OrganisationAssurancePolicy.html
@@ -0,0 +1,408 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title> Organisation Assurance Policy </title>
+<style type="text/css">
+<!--
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+</head>
+<body>
+
+<div class="comment">
+<table width="100%">
+
+<tbody>
+<tr>
+<td>
+  Name: OAP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11</a>
+<br>
+
+  Status: POLICY  <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+  Editor: Jens Paul
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy"> CC-by-sa+DRP </a>
+<br>
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+		<img src="images/cacert-policy.png" alt="OAP Status - POLICY" style="border-style: none;" height="31" width="88">
+	</a>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+<h1> Organisation&nbsp;Assurance&nbsp;Policy </h1>
+
+<h2 id="s0"> 0. Preliminaries </h2>
+
+<p>
+This policy describes how Organisation Assurers ("OAs")
+conduct Assurances on Organisations.
+It fits within the overall web-of-trust
+or Assurance process of CAcert.
+</p>
+
+<p>
+This policy is not a Controlled document, for purposes of
+Configuration Control Specification ("CCS").
+</p>
+
+<h2 id="s1"> 1. Purpose </h2>
+
+<p>
+Organisations with assured status can issue certificates
+directly with their own domains within.
+</p>
+
+<p>
+The purpose and statement of the certificate remains
+the same as with ordinary users (natural persons)
+and as described in the CPS.
+</p>
+
+<ul><li>
+    The organisation named within is identified.
+  </li><li>
+    The organisation has been verified according
+    to this policy.
+  </li><li>
+    The organisation is within the jurisdiction
+    and can be taken to CAcert Arbitration.
+</li></ul>
+
+
+<h2 id="s2"> 2. Roles and Structure </h2>
+
+<h3 id="s2.1"> 2.1 Assurance Officer </h3>
+
+<p>
+The Assurance Officer ("AO")
+manages this policy and reports to the CAcert Inc. Committee ("Board").
+</p>
+
+<p>
+The AO manages all OAs and is responsible for process,
+the CAcert Organisation Assurance Programme ("COAP") form,
+OA training and testing, manuals, quality control.
+In these responsibilities, other Officers will assist.
+</p>
+<p>
+The OA is appointed by the Board.
+Where the OA is failing the Board decides.
+</p>
+
+<h3 id="s2.2"> 2.2 Organisation Assurers </h3>
+
+<p>
+</p>
+
+<ol type="a"> <li>
+    An OA must be an experienced Assurer
+    <ol type="i">
+      <li>Have 150 assurance points.</li>
+      <li>Be fully trained and tested on all general Assurance processes.</li>
+    </ol>
+
+  </li><li>
+    Must be trained as Organisation Assurer.
+    <ol type="i">
+      <li> Global knowledge:  This policy. </li>
+      <li> Global knowledge:  A OA manual covers how to do the process.</li>
+      <li> Local knowledge:   legal forms of organisations within jurisdiction.</li>
+      <li> Basic governance. </li>
+      <li> Training may be done a variety of ways,
+           such as on-the-job, etc. </li>
+    </ol>
+
+  </li><li>
+    Must be tested.
+    <ol type="i">
+      <li> Global test:  Covers this policy and the process. </li>
+      <li> Local knowledge:   Subsidiary Policy to specify. </li>
+      <li> Tests to be created, approved, run, verified
+           by CAcert only (not outsourced). </li>
+      <li> Tests are conducted manually, not online/automatic. </li>
+      <li> Documentation to be retained. </li>
+      <li> Tests may include on-the-job components. </li>
+    </ol>
+
+  </li><li>
+    Must be approved.
+    <ol type="i">
+      <li> Two supervising OAs must sign-off on new OA,
+           as trained, tested and passed.
+           </li>
+      <li> AO must sign-off on a new OA,
+           as supervised, trained and tested.
+           </li>
+    </ol>
+    </li>
+	<li>The OA can decide when a CAcert
+	(individual) Assurer
+	has done several OA Application Advises to appoint this
+	person to OA Assurer.
+	</li>
+
+</ol>
+
+<h3 id="s2.3"> 2.3 Organisation Assurance Advisor ("OAA") </h3>
+<p>
+	In countries/states/provinces where no OA Assurers are
+	operating for an OA Application (COAP) the OA
+	can be advised by an experienced local CAcert
+	(individual) Assurer to take the decision
+	to accept the OA Application (COAP) of the organisation.
+</p>
+<p>
+	The local Assurer must have at least 150 Points,
+	should know the language, and know
+	the organisation trade office registry culture and quality.
+</p>
+
+
+<h3 id="s2.4"> 2.4 Organisation Administrator </h3>
+
+<p>
+The Administrator within each Organisation ("O-Admin")
+is the one who handles the assurance requests
+and the issuing of certificates.
+</p>
+
+<ol type="a"> <li>
+    O-Admin must be Assurer
+    <ol type="i">
+      <li>Have 100 assurance points.</li>
+      <li>Fully trained and tested as Assurer.</li>
+    </ol>
+
+  </li><li>
+    Organisation is required to appoint O-Admin,
+    and appoint ones as required.
+    <ol type="i">
+      <li> On COAP Request Form.</li>
+    </ol>
+
+  </li><li>
+    O-Admin must work with an assigned OA.
+    <ol type="i">
+      <li> Have contact details.</li>
+    </ol>
+</ol>
+
+
+<h2 id="s3"> 3. Policies </h2>
+
+<h3 id="s3.1"> 3.1 Policy </h3>
+
+<p>
+There is one policy being this present document,
+and several subsidiary policies.
+</p>
+
+<ol type="a">
+  <li>  This policy authorises the creation of subsidiary policies. </li>
+  <li>  This policy is international. </li>
+  <li>  Subsidiary policies are implementations of the policy. </li>
+  <li>  Organisations are assured under an appropriate subsidiary policy. </li>
+</ol>
+
+<h3 id="s3.2"> 3.2 Subsidiary Policies </h3>
+
+<p>
+The nature of the Subsidiary Policies ("SubPols"):
+</p>
+
+<ol type="a"><li>
+    SubPols are purposed to check the organisation
+    under the rules of the jurisdiction that creates the
+    organisation.  This does not evidence an intention
+    by CAcert to
+    enter into the local jurisdiction, nor an intention
+    to impose the rules of that jurisdiction over any other
+    organisation.
+    CAcert assurances are conducted under the jurisdiction
+    of CAcert.
+  </li><li>
+    For OAs,
+    SubPol specifies the <i>tests of local knowledge</i>
+    including the local organisation assurance COAP forms.
+  </li><li>
+    For assurances,
+    SubPol specifies the <i>local documentation forms</i>
+    which are acceptable under this SubPol to meet the
+    standard.
+  </li><li>
+   SubPols are subjected to the normal
+   policy approval process.
+</li></ol>
+
+<h3 id="s3.3"> 3.3  Freedom to Assemble </h3>
+
+<p>
+Subsidiary Policies are open, accessible and free to enter.
+</p>
+
+<ol type="a"><li>
+    SubPols compete but are compatible.
+  </li><li>
+    No SubPol is a franchise.
+  </li><li>
+    Many will be on State or National lines,
+    reflecting the legal
+    tradition of organisations created
+    ("incorporated") by states.
+  </li><li>
+    However, there is no need for strict national lines;
+    it is possible to have 2 SubPols in one country, or one
+    covering several countries with the same language
+    (e.g., Austria with Germany, England with Wales but not Scotland).
+  </li><li>
+    There could also be SubPols for special
+    organisations, one person organisations,
+    UN agencies, churches, etc.
+  </li><li>
+    Where it is appropriate to use the SubPol
+    in another situation (another country?), it
+    can be so approved.
+    (e.g., Austrian SubPol might be approved for Germany.)
+    The SubPol must record this approval.
+</li></ol>
+
+
+<h2 id="s4"> 4.  Process </h2>
+
+<h3 id="s4.1"> 4.1  Standard of Organisation Assurance </h3>
+<p>
+The essential standard of Organisation Assurance is:
+</p>
+
+<ol type="a"><li>
+    the organisation exists
+  </li><li>
+    the organisation name is correct and consistent:
+    <ol type="i">
+      <li>in official documents specified in SubPol.</li>
+      <li>on COAP form.</li>
+      <li>in CAcert database.</li>
+      <li>form or type of legal entity is consistent</li>
+    </ol>
+  </li><li>
+    signing rights:
+    requestor can sign on behalf of the organisation.
+  </li><li>
+    the organisation has agreed to the terms of the
+    CAcert Community Agreement
+    and is therefore subject to Arbitration.
+</li></ol>
+
+<p>
+    Acceptable documents to meet above standard
+    are stated in the SubPol.
+</p>
+
+<h3 id="s4.2"> 4.2  COAP </h3>
+<p>
+The COAP form documents the checks and the resultant
+assurance results to meet the standard.
+Additional information to be provided on form:
+</p>
+
+<ol type="a"><li>
+    CAcert account of O-Admin (email address?)
+  </li><li>
+    location:
+    <ol type="i">
+      <li>country (MUST).</li>
+      <li>city (MUST).</li>
+      <li>additional contact information (as required by SubPol).</li>
+    </ol>
+  </li><li>
+    administrator account name(s) (1 or more)
+  </li><li>
+    domain name(s)
+  </li><li>
+    Agreement with
+    CAcert Community Agreement.
+    Statement and initials box for organisation
+    and also for OA.
+  </li><li>
+    Date of completion of Assurance.
+    Records should be maintained for 7 years from
+    this date.
+</li></ol>
+
+<p>
+The COAP should be in English.  Where translations
+are provided, they should be matched to the English,
+and indication provided that the English is the
+ruling language (due to Arbitration requirements).
+</p>
+
+<h3 id="s4.3"> 4.3 Jurisdiction </h3>
+
+<p>
+Organisation Assurances are carried out by
+CAcert Inc. under its Arbitration jurisdiction.
+Actions carried out by OAs are under this regime.
+</p>
+
+<ol type="a"><li>
+    The organisation has agreed to the terms of the
+    CAcert Community Agreement.
+  </li><li>
+    The organisation, the Organisation Assurers, CAcert and
+    other related parties are bound into CAcert's jurisdiction
+    and dispute resolution.
+  </li><li>
+    The OA is responsible for ensuring that the
+    organisation reads, understands, intends and
+    agrees to the
+    CAcert Community Agreement.
+    This OA responsibility should be recorded on COAP
+    (statement and initials box).
+</li></ol>
+
+<h2 id="s5"> 5. Exceptions </h2>
+
+
+<ol type="a"><li>
+    <b> Conflicts of Interest.</b>
+    An OA must not assure an organisation in which
+    there is a close or direct relationship by, e.g.,
+    employment, family, financial interests.
+    Other conflicts of interest must be disclosed.
+  </li><li>
+    <b> Trusted Third Parties.</b>
+    TTPs are not generally approved to be part of
+    organisation assurance,
+    but may be approved by subsidiary policies according
+    to local needs.
+  </li><li>
+    <b>Exceptional Organisations.</b>
+    (e.g., Vatican, International Space Station, United Nations)
+    can be dealt with as a single-organisation
+    SubPol.
+    The OA creates the checks, documents them,
+    and subjects them to to normal policy approval.
+  </li><li>
+    <b>DBA.</b>
+    Alternative names for organisations
+    (DBA, "doing business as")
+    can be added as long as they are proven independently.
+    E.g., registration as DBA or holding of registered trade mark.
+    This means that the anglo law tradition of unregistered DBAs
+    is not accepted without further proof.
+  </li>
+</ol>
+
+
+</body>
+</html>
diff --git a/www/policy/OrganisationAssurancePolicy.php b/www/policy/OrganisationAssurancePolicy.php
index e462693..b126cd2 100644
--- a/www/policy/OrganisationAssurancePolicy.php
+++ b/www/policy/OrganisationAssurancePolicy.php
@@ -1,402 +1,4 @@
-<?='<?xml version="1.0" encoding="utf-8"?>'?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
-        "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-<title> Organisation Assurance Policy </title>
-<style type="text/css">
-<!--
-.comment {
-        color : steelblue;
-}
--->
-</style>
-
-</head>
-<body>
-
-<div class="comment">
-<table width="100%">
-
-<tr>
-<td>
-  Name: OAP <a style="color: steelblue" href="//svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11</a><br />
-
-  Status: POLICY/DRAFT <a style="color: steelblue" href="//wiki.cacert.org/wiki/TopMinutes-20070917">m20070918.x </a><br />
-
-  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;           <span class="draftadd">DRAFT p20080401.1   </span> <br />
-  Editor: Jens Paul <br />
-   Licence: <a style="color: steelblue" href="//wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br /></td>
-<td valign="top" align="right">
-  <a href="//www.cacert.org/policy/PolicyOnPolicy.html"><img src="/images/cacert-policy.png" alt="OAP Status - POLICY" height="31" width="88" style="border-style: none;" /></a><br />
-  <a href="//www.cacert.org/policy/PolicyOnPolicy.html"><img src="/images/cacert-draft.png" alt="OAP Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
-
-</td>
-</tr>
-</table>
-</div>
-
-
-<h1> Organisation&nbsp;Assurance&nbsp;Policy </h1>
-
-<h2 id="s0">0.   Preliminaries </h2>
-
-<p>
-This policy describes how Organisation Assurers ("OAs")
-conduct Assurances on Organisations.
-It fits within the overall web-of-trust
-or Assurance process of CAcert.
-</p>
-
-<p>
-This policy is not a Controlled document, for purposes of
-Configuration Control Specification ("CCS").
-</p>
-
-<h2 id="s1"> 1. Purpose </h2>
-
-<p>
-Organisations with assured status can issue certificates
-directly with their own domains within.
-</p>
-
-<p>
-The purpose and statement of the certificate remains
-the same as with ordinary users (natural persons)
-and as described in the CPS.
-</p>
-
-<ul><li>
-    The organisation named within is identified.
-  </li><li>
-    The organisation has been verified according
-    to this policy.
-  </li><li>
-    The organisation is within the jurisdiction
-    and can be taken to CAcert Arbitration.
-</li></ul>
-
-
-<h2 id="s2"> 2. Roles and Structure </h2> 
-
-<h3 id="s2.1"> 2.1 Assurance Officer </h3> 
-
-<p>
-The Assurance Officer ("AO")
-manages this policy and reports to the CAcert Inc. Committee ("Board").
-</p>
-
-<p>
-The AO manages all OAs and is responsible for process,
-the CAcert Organisation Assurance Programme ("COAP") form,
-OA training and testing, manuals, quality control.
-In these responsibilities, other Officers will assist.
-</p>
-<p>
-The OA is appointed by the Board. 
-Where the OA is failing the Board decides.
-</p>
-
-<h3 id="s2.2"> 2.2 Organisation Assurers </h3> 
-
-<p>
-</p>
-
-<ol type="a"> <li>
-    An OA must be an experienced Assurer
-    <ol type="i">
-      <li>Have 150 assurance points.</li>
-      <li>Be fully trained and tested on all general Assurance processes.</li>
-    </ol>
-
-  </li><li>
-    Must be trained as Organisation Assurer.
-    <ol type="i">
-      <li> Global knowledge:  This policy. </li>
-      <li> Global knowledge:  A OA manual covers how to do the process.</li>
-      <li> Local knowledge:   legal forms of organisations within jurisdiction.</li>
-      <li> Basic governance. </li>
-      <li> Training may be done a variety of ways,
-           such as on-the-job, etc. </li>
-    </ol>
-
-  </li><li>
-    Must be tested.
-    <ol type="i">
-      <li> Global test:  Covers this policy and the process. </li>
-      <li> Local knowledge:   Subsidiary Policy to specify.</li>
-      <li> Tests to be created, approved, run, verified
-           by CAcert only (not outsourced). </li>
-      <li> Tests are conducted manually, not online/automatic. </li>
-      <li> Documentation to be retained. </li>
-      <li> Tests may include on-the-job components. </li>
-    </ol>
-
-  </li><li>
-    Must be approved.
-    <ol type="i">
-      <li> Two supervising OAs must sign-off on new OA,
-           as trained, tested and passed.
-           </li>
-      <li> AO must sign-off on a new OA,
-           as supervised, trained and tested.
-           </li>
-    </ol>
-    </li>
-	<li>The OA can decide when a CAcert
-	(individual) Assurer
-	has done several OA Application Advises to appoint this
-	person to OA Assurer.
-	</li>
-
-</ol>
-
-<h3 id="s2.3"> 2.3 Organisation Assurance Advisor ("OAA") </h3>
-	<p>In countries/states/provinces where no OA Assurers are
-	operating for an OA Application (COAP) the OA
-	can be advised by an experienced local CAcert
-	(individual) Assurer to take the decision
-	to accept the OA Application (COAP) of the organisation.
-	</p>
-	<p>
-	The local Assurer must have at least 150 Points,
-	should know the language, and know
-	the organisation trade office registry culture and quality.
-	</p>
-
-
-<h3 id="s2.4"> 2.4 Organisation Administrator </h3> 
-
-<p>
-The Administrator within each Organisation ("O-Admin")
-is the one who handles the assurance requests
-and the issuing of certificates.
-</p>
-
-<ol type="a"> <li>
-    O-Admin must be Assurer
-    <ol type="i">
-      <li>Have 100 assurance points.</li>
-      <li>Fully trained and tested as Assurer.</li>
-    </ol>
-
-  </li><li>
-    Organisation is required to appoint O-Admin,
-    and appoint ones as required.
-    <ol type="i">
-      <li> On COAP Request Form.</li>
-    </ol>
-
-  </li><li>
-    O-Admin must work with an assigned OA.
-    <ol type="i">
-      <li> Have contact details.</li>
-    </ol>
-</ol>
-
-
-<h2 id="s3"> 3. Policies </h2> 
-
-<h3 id="s3.1"> 3.1 Policy </h3> 
-
-<p>
-There is one policy being this present document,
-and several subsidiary policies.
-</p>
-
-<ol type="a">
-  <li>  This policy authorises the creation of subsidiary policies. </li>
-  <li>  This policy is international. </li>
-  <li>  Subsidiary policies are implementations of the policy. </li>
-  <li>  Organisations are assured under an appropriate subsidiary policy. </li>
-</ol>
-
-<h3 id="s3.2"> 3.2 Subsidiary Policies </h3>
-
-<p>
-The nature of the Subsidiary Policies ("SubPols"):
-</p>
-
-<ol type="a"><li>
-    SubPols are purposed to check the organisation
-    under the rules of the jurisdiction that creates the
-    organisation.  This does not evidence an intention
-    by CAcert to
-    enter into the local jurisdiction, nor an intention
-    to impose the rules of that jurisdiction over any other
-    organisation.
-    CAcert assurances are conducted under the jurisdiction
-    of CAcert.
-  </li><li>
-    For OAs,
-    SubPol specifies the <i>tests of local knowledge</i>
-    including the local organisation assurance COAP forms.
-  </li><li>
-    For assurances,
-    SubPol specifies the <i>local documentation forms</i>
-    which are acceptable under this SubPol to meet the
-    standard.
-  </li><li>
-   SubPols are subjected to the normal 
-   policy approval process.
-</li></ol>
-
-<h3 id="s3.3"> 3.3  Freedom to Assemble </h3>
-
-<p>
-Subsidiary Policies are open, accessible and free to enter. 
-</p>
-
-<ol type="a"><li>
-    SubPols compete but are compatible.
-  </li><li>
-    No SubPol is a franchise.
-  </li><li>
-    Many will be on State or National lines,
-    reflecting the legal
-    tradition of organisations created
-    ("incorporated") by states.
-  </li><li>
-    However, there is no need for strict national lines;
-    it is possible to have 2 SubPols in one country, or one
-    covering several countries with the same language
-    (e.g., Austria with Germany, England with Wales but not Scotland).
-  </li><li>
-    There could also be SubPols for special
-    organisations, one person organisations,
-    UN agencies, churches, etc.
-  </li><li>
-    Where it is appropriate to use the SubPol
-    in another situation (another country?), it
-    can be so approved.
-    (e.g., Austrian SubPol might be approved for Germany.)
-    The SubPol must record this approval.
-</li></ol>
-
-
-<h2 id="s4"> 4.  Process </h2>
-
-<h3 id="s4.1"> 4.1  Standard of Organisation Assurance </h3>
-<p>
-The essential standard of Organisation Assurance is:
-</p>
-
-<ol type="a"><li>
-    the organisation exists
-  </li><li>
-    the organisation name is correct and consistent:
-    <ol type="i">
-      <li>in official documents specified in SubPol.</li>
-      <li>on COAP form.</li>
-      <li>in CAcert database.</li>
-      <li>form or type of legal entity is consistent</li>
-    </ol>
-  </li><li>
-    signing rights:
-    requestor can sign on behalf of the organisation.
-  </li><li>
-    the organisation has agreed to the terms of the
-    CAcert Community Agreement
-    and is therefore subject to Arbitration.
-</li></ol>
-
-<p>
-    Acceptable documents to meet above standard
-    are stated in the SubPol.
-</p>
-
-<h3 id="s4.2"> 4.2  COAP </h3>
-<p>
-The COAP form documents the checks and the resultant
-assurance results to meet the standard.
-Additional information to be provided on form:
-</p>
-
-<ol type="a"><li>
-    CAcert account of O-Admin (email address?)
-  </li><li>
-    location:
-    <ol type="i">
-      <li>country (MUST).</li>
-      <li>city (MUST).</li>
-      <li>additional contact information (as required by SubPol).</li>
-    </ol>
-  </li><li>
-    administrator account name(s) (1 or more)
-  </li><li>
-    domain name(s)
-  </li><li>
-    Agreement with
-    CAcert Community Agreement.
-    Statement and initials box for organisation
-    and also for OA.
-  </li><li>
-    Date of completion of Assurance.
-    Records should be maintained for 7 years from
-    this date.
-</li></ol>
-
-<p>
-The COAP should be in English.  Where translations
-are provided, they should be matched to the English,
-and indication provided that the English is the
-ruling language (due to Arbitration requirements).
-</p>
-
-<h3 id="s4.3"> 4.3 Jurisdiction </h3>
-
-<p>
-Organisation Assurances are carried out by
-CAcert Inc. under its Arbitration jurisdiction.
-Actions carried out by OAs are under this regime.
-</p>
-
-<ol type="a"><li>
-    The organisation has agreed to the terms of the
-    CAcert Community Agreement.
-  </li><li>
-    The organisation, the Organisation Assurers, CAcert and
-    other related parties are bound into CAcert's jurisdiction
-    and dispute resolution.
-  </li><li>
-    The OA is responsible for ensuring that the
-    organisation reads, understands, intends and
-    agrees to the
-    CAcert Community Agreement.
-    This OA responsibility should be recorded on COAP
-    (statement and initials box).
-</li></ol>
-
-<h2 id="s5"> 5. Exceptions </h2>
-
-
-<ol type="a"><li>
-    <b> Conflicts of Interest.</b>
-    An OA must not assure an organisation in which
-    there is a close or direct relationship by, e.g.,
-    employment, family, financial interests.
-    Other conflicts of interest must be disclosed.
-  </li><li>
-    <b> Trusted Third Parties.</b>
-    TTPs are not generally approved to be part of
-    organisation assurance,
-    but may be approved by subsidiary policies according
-    to local needs.
-  </li><li>
-    <b>Exceptional Organisations.</b>
-    (e.g., Vatican, International Space Station, United Nations)
-    can be dealt with as a single-organisation
-    SubPol.
-    The OA creates the checks, documents them,
-    and subjects them to to normal policy approval.
-  </li><li>
-    <b>DBA.</b>
-    Alternative names for organisations
-    (DBA, "doing business as")
-    can be added as long as they are proven independently.
-    E.g., registration as DBA or holding of registered trade mark.
-    This means that the anglo law tradition of unregistered DBAs
-    is not accepted without further proof.
-  </li></ol>
-</body>
-</html>
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: OrganisationAssurancePolicy.html');
+exit;
\ No newline at end of file
diff --git a/www/policy/OrganisationAssurancePolicy_Australia.html b/www/policy/OrganisationAssurancePolicy_Australia.html
new file mode 100644
index 0000000..9bfabb8
--- /dev/null
+++ b/www/policy/OrganisationAssurancePolicy_Australia.html
@@ -0,0 +1,309 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title>CACert Organisation Assurance Program sub-policy for Australia</title>
+<style type="text/css">
+<!--
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+</head>
+<body>
+
+<h1>
+	CAcert Organisation Assurance Program sub-policy for Australia
+</h1>
+<div class="comment">
+<table width="100%">
+<tbody>
+<tr>
+<td rowspan="2">
+   Name: CAcert Organisation Assurance Program sub-policy Australia<a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11.AU</a>
+<br>
+   Creation Date : 2008-04-02
+<br>
+   Editor: Sam Johnston
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+<img src="images/cacert-policy.png" alt="OAP AU Status - POLICY" style="border-style: none;" height="31" width="88">
+</a>
+    </td>
+ </tr>
+</tbody>
+</table>
+</div>
+
+<h2 id="g0.1">0. Preliminaries </h2>
+
+<p>
+This CAcert sub-policy extends the Organisation Assurance Policy
+("OAP") by specifying how the CAcert Organisation Assurance Program
+("COAP") is to be conducted by the assigned Organisation Assurer ("OA")
+under the supervision of the Assurance Officer ("AO") for entities
+within the defined scope.
+</p>
+
+<h2 id="g0.2">1. Scope</h2>
+
+<p>
+	This sub-policy is applicable to:
+	<br>
+</p>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>Australian legal entities:
+<br>
+
+<ol style="list-style-type: lower-roman;">
+
+<li>Sole Traders</li>
+
+<li>Partnerships</li>
+
+<li>Companies</li>
+
+<li>Trusts</li>
+
+<li>Government Bodies &amp; Intrumentalities</li>
+
+<li>Clubs &amp; Associations</li>
+
+</ol>
+
+</li>
+</ol>
+
+<h2 id="g0.3">2. Requirements </h2>
+
+<p>
+This section describes any scope specific requirements that are not otherwise defined in the OAP.
+</p>
+
+<h3 id="g0.3.1">2.1. Organisation </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>For sole traders operating under their own name business name registration is OPTIONAL.</li>
+
+<li>Applicants MUST be a valid legal entity but MAY have an arbitrary number of registered trading names.</li>
+
+</ol>
+
+<h3 id="g0.3.2">2.2. Records </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>Digital Signatures MAY be accepted in Australia under the Electronic Transactions Act 2000.
+</li>
+
+<li>Historic documents MAY be accepted where it can be proven that
+material changes have not been made (eg via absence of subsequent
+submissions in official document listings).</li>
+
+</ol>
+
+<h3 id="g0.3.3">2.3. Application Form </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>The licensing authority MUST be specified as 'Australian
+Securities and Investments Commission (ASIC)' (for companies, trusts
+etc) or a state office of fair trading (for sole traders, partnerships
+and trading names).</li>
+
+<li>Any applicable organisation identifiers (ACN/ABN/ARBN) MUST be
+specified where applicable (not required for sole traders operating
+under their own name).</li>
+
+</ol>
+
+<h2 id="g0.4">3. Registration </h2>
+
+<h3 id="g0.4.1">3.1. Registries </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>AusRegistry [<a title="AusRegistry" href="http://www.ausregistry.com.au/">http://www.ausregistry.com.au/</a>]
+<br>
+
+<ol>
+
+<li>.au ccTLD WHOIS [<a title="AusRegistry WHOIS" href="http://whois.ausregistry.net.au/">http://whois.ausregistry.net.au/</a>]
+<br>
+					</li>
+				</ol>
+			</li>
+
+<li>Australian Securities and Investments Commission ("ASIC") [<a title="Australian Securities and Investments Commission" href="http://www.asic.gov.au/">http://www.asic.gov.au/</a>]
+<br>
+
+<ol style="list-style-type: lower-roman;">
+
+<li>National Names Index [<a title="National Names Index" href="http://www.search.asic.gov.au/gns001.html">http://www.search.asic.gov.au/gns001.html</a>]
+<br>
+					</li>
+				</ol>
+			</li>
+
+<li>Australian state offices of fair trading [<a title="ACCC Contacts: State offices of fair trading" href="http://www.accc.gov.au/content/index.phtml/itemId/325459">http://www.accc.gov.au/content/index.phtml/itemId/325459</a>]
+<br>
+
+<ol style="list-style-type: lower-roman;">
+
+<li>ACT Office of Fair Trading (OFT) [<a title="ACT Office of Fair Trading (OFT)" href="http://www.fairtrading.act.gov.au/">http://www.fairtrading.act.gov.au/</a>]</li>
+
+<li>NT Consumer Affairs [<a title="NT Consumer Affairs" href="http://www.nt.gov.au/justice/consaffairs/">http://www.nt.gov.au/justice/consaffairs/</a>]</li>
+
+<li>NSW Office of Fair Trading (OFT) [<a title="NSW Office of Fair Trading (OFT)" href="http://www.fairtrading.nsw.gov.au/">http://www.fairtrading.nsw.gov.au</a>]</li>
+
+<li>QLD Office of Fair Trading (OFT) [<a title="QLD Office of Fair Trading (OFT)" href="http://www.fairtrading.qld.gov.au/">http://www.fairtrading.qld.gov.au</a>]</li>
+
+<li>SA Office of Fair Trading (OFT) [<a title="SA Office of Fair Trading (OFT)" href="http://www.ocba.sa.gov.au/">http://www.ocba.sa.gov.au</a>]</li>
+
+<li>TAS Office of Fair Trading (OFT) [<a title="TAS Office of Fair Trading (OFT)" href="http://www.consumer.tas.gov.au/">http://www.consumer.tas.gov.au/</a>]</li>
+
+<li>VIC Office of Fair Trading (OFT) [<a title="TAS Office of Fair Trading (OFT)" href="http://www.consumer.vic.gov.au/">http://www.consumer.vic.gov.au</a>]</li>
+
+<li>WA Department of Consumer and Employment Protection (DOCEP) [<a title="Department of Consumer and Employment Protection, WA (DOCEP)" href="http://www.docep.wa.gov.au/">http://www.docep.wa.gov.au</a>]</li>
+
+</ol>
+
+</li>
+
+<li>Australian Taxation Office ("ATO") [<a title="Australian Taxation Office" href="http://www.ato.gov.au/">http://www.ato.gov.au/</a>]
+<br>
+
+<ol style="list-style-type: lower-roman;">
+
+<li>Australian Business Register ("ABR") [<a title="Australian Business Register" href="http://www.abr.business.gov.au/">http://www.abr.business.gov.au/</a>]
+<br>
+</li>
+
+</ol>
+
+</li>
+
+<li>Credit Reporting Agencies
+<br>
+
+<ol style="list-style-type: lower-roman;">
+
+<li>Dun &amp; Bradstreet (Australia) [<a title="Dun &amp; Bradstreet (Australia)" href="http://www.dnb.com.au/">http://www.dnb.com.au/</a>]
+<br></li>
+
+<li>Veda Advantage [<a title="Veda Advantage" href="http://www.vedaadvantage.com/">http://www.vedaadvantage.com/</a>]
+<br></li>
+
+</ol>
+
+</li>
+
+</ol>
+
+<h3 id="g0.4.2">3.2. Agents </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>ASIC
+<br>
+
+<ol style="list-style-type: lower-roman;">
+
+<li>ASIC Information Brokers [<a title="ASIC Information Brokers" href="http://www.asic.gov.au/asic/asic.nsf/byheadline/Information+brokers?openDocument">http://www.asic.gov.au/asic/asic.nsf/byheadline/Information+brokers?openDocument</a>]</li>
+
+<li>ASIC Service Centers [<a title="ASIC Service Centers" href="http://www.asic.gov.au/asic/asic.nsf/byheadline/ASIC+Service+Centre+Addresses?openDocument">http://www.asic.gov.au/asic/asic.nsf/byheadline/ASIC+Service+Centre+Addresses?openDocument</a>]</li>
+
+</ol>
+
+</li>
+
+</ol>
+
+<h3 id="g0.4.3">3.3. Identifiers </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>Australian Company Number ("ACN") is a unique 9 digit identifying
+ number assigned by ASIC when a body becomes registered as a company
+under corporations law.</li>
+
+<li>Australian Registered Body Number ("ARBN") is a unique 9 digit
+identifying number assigned by ASIC when a body is registered with them
+other than as a company, for example registrable Australian bodies.
+<br></li>
+
+<li>Australian Business Number ("ABN") is a unique 11 digit
+identifying number issued to all entities registered in the Australian
+Business Register (ABR).</li>
+
+</ol>
+
+<h3 id="g0.4.4">3.4. Documents </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>ASIC Company Extract</li>
+
+<li>Credit File</li>
+
+</ol>
+
+<h2 id="g0.5">4. Processes </h2>
+
+<h3 id="g0.5.1">4.1. Assurance </h3>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>Each person listed in an application MUST be individually assured and referenced by a confirmed email.</li>
+
+<li>Sole traders operating under their own name MAY be automatically approved without further checks.</li>
+
+<li>All other trading names (including companies) MUST be verified
+against the National Names Index and/or Australian Business Register,
+where the status MUST be 'Registered' or 'Active' respectively.</li>
+
+<li>Partnership applicants MUST additionally be verified in the
+register as a current individual member and SHOULD be a managing
+partner.</li>
+
+<li>Company applications MUST be made by an individual who is duly authorised to sign on behalf of the company:
+
+<ol style="list-style-type: lower-roman;">
+
+<li>Officeholder applicants (directors or preferably secretary)
+MUST be verified in an "ASIC Company Extract" (obtained for a fee
+reclaimable from the applicant by the OA from an ASIC Service Center or
+ASIC Information Broker) or "Credit File" from a "Credit Reporting
+Agency".</li>
+
+<li>Any other applicant MUST prove that they are duly authorised to
+ sign on behalf of the entity (for example via delegation and/or under
+replacible rules) to the satisfaction of the OA, for approval by the AO.</li>
+
+</ol>
+
+</li>
+
+<li>Trust applications MUST be made by the trustee.</li>
+
+<li>Government Body &amp; Intrumentality applications MUST be made by
+ a duly authorised person and the relevant authorisation must accompany
+the application.</li>
+
+<li>Club &amp; Association applications MUST be made by the secretary of the club or association.</li>
+
+</ol>
+
+
+</body>
+</html>
diff --git a/www/policy/OrganisationAssurancePolicy_Europe.html b/www/policy/OrganisationAssurancePolicy_Europe.html
new file mode 100644
index 0000000..956c9ba
--- /dev/null
+++ b/www/policy/OrganisationAssurancePolicy_Europe.html
@@ -0,0 +1,1021 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title>CACert Organisation Assurance Program sub-policy for European countries with official Trade Office Registry</title>
+<style type="text/css">
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+</head>
+
+<body>
+
+<h1>
+	CAcert Organisation Assurance Program sub-policy
+	<br>
+	for countries in Europe
+</h1>
+
+<div class="comment">
+<table width="100%">
+<tbody>
+<tr>
+<td rowspan="2">
+   Name: CAcert Organisation Assurance Program sub-policy Europe<a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11.EU</a>
+<br>
+   Creation Date : 20080920
+<br>
+   Editor: Teus Hagen
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+<img src="images/cacert-policy.png" alt="OAP EU Status - POLICY" style="border-style: none;" height="31" width="88">
+</a>
+    </td>
+ </tr>
+</tbody>
+</table>
+</div>
+
+<p></p>
+
+<h2 id="g0.1">0. Preliminaries </h2>
+
+<p>
+This CAcert sub-policy extends the Organisation
+Assurance Policy ("OAP") by specifying how the CAcert Organisation
+Assurance Program ("COAP") is to be conducted by the assigned
+Organisation Assurer ("OA") under the supervision of the Assurance
+Officer ("AO") for entities within the defined scope.
+</p>
+
+<h2 id="g0.2">1. Scope </h2>
+
+<p> This sub-policy is applicable to:
+                </p>
+<ul>
+
+<li>Organisations registered in Europe with an
+official Trade Office Registry (CAcert "Approved Registry", also denoted
+ as "Registry").</li>
+
+</ul>
+
+<p>
+<i>Approved Registries</i> are tabled in
+paragraph Appendix 1 of this sub-policy.
+<br>
+The table in Appendix 1 will denote for every Approved Registry a date of full acceptance (<strong>Registry Entry Draft</strong>
+ status). Before that date the Registry entry is accepted as operational
+ similar in effectiveness with a policy in DRAFT as defined in the
+Policy on Policy document.
+Addition of new Registry entries is by means of the routine Policy on
+Policy process,
+and is controlled by the Policy email list group, on submission by
+Organisation Assurer.
+</p>
+<p>
+Registries subjected to acceptance as Approved Registry are tabled in
+paragraph Appendix 2. Appendix 2 is not a formal part of this
+sub-policy.
+</p>
+
+<h2 id="g0.3">2. Requirements </h2>
+
+<p>
+This section describes any scope-specific requirements that are not
+otherwise defined in the Organisation Assurance Policy (OAP).
+</p>
+
+<h3 id="g0.3.1">2.1. Organisations </h3>
+<p></p>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li>The organisation must be registered with an Approved Registry.</li>
+
+<li>The Approved Registry must have a mandate to
+ register certain types of organisations (e.g. private companies, clubs
+Societies &amp; Associations, partnerships, cooperatives, mutual
+societies, foundations, etc.)</li>
+
+</ol>
+
+<p></p>
+
+<h3 id="g0.3.2">2.2. Unincorporated Organisations </h3>
+
+<p>
+<strong>Registered Names.</strong>
+Where an approved Registry specifically maintains a register for
+local entities that trade without formal incorporation,
+the Registry entry will present independent evidence of the
+name, as demanded by
+<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php#5">OAP#5.d</a>.
+This may apply to
+organisations such as
+Sole Traders,
+Doing-Business-As traders (DBAs),
+Partnerships,
+Church and Religious groups,
+etc.
+</p>
+
+<p>
+Such entities have differing legal statuses
+with different liabilities.
+The named entity may not be capable of legally becoming
+a Member of CAcert,
+<i>independently and separately from the individuals within</i>.
+The Organisation Assurer (OA) must then take care to identify which individuals
+are Members, and which are therefore the natural legal
+entities behind the names.
+</p>
+
+<p>
+The general standard for assurance of an unincorporated entity
+with a Registered Name is that the result is
+equivalent to assurance of an individual Member, or Members,
+with the addition of the Registered Name.
+</p>
+
+<p>
+There is no limit to the number of Registered Names that
+a Member may have.
+</p>
+
+<p>
+<b>Foreign Entities.</b>
+<br>
+Where a local Registry requires foreign entities to register,
+this registration may be used for Organisation Assurance.
+<br>
+<i>
+For example: companies are frequently incorporated in the United Kingdom,
+but operated primarily in another European country.
+These foreign entities may require to register locally
+and submit financial and/or yearly reports, extracts of home documents,
+reports from professionals such as accountants, etc,
+to authorities in the operating country.
+</i>
+</p>
+
+<h3 id="g0.3.3">2.3. Records</h3>
+<p>
+Records supplied by the Registry must be one of the following forms:
+</p>
+<ol style="list-style-type: lower-alpha;">
+
+<li>
+    Formal originals on paper,
+    where they are extracted from the Registry
+    in an independent manner by the OA;
+  </li>
+
+<li>
+    Digital statements from an online service provided by the Registry,
+    acquired by the Organisation Assurer by the OA
+    in an independent manner;
+  </li>
+
+<li>
+    Historical supplemental documents may be accepted
+    where it can be shown that
+    material changes have not been made
+    (e.g., via absence of subsequent
+    submissions in official document listings).
+    Such acceptance should be applicable to the particular
+    jurisdiction, as documented by the Organisation Assurer,
+    and under any process he determines.
+  </li>
+</ol>
+
+<p>
+The set of records supplied by the Registry is called the Extract.
+</p>
+
+
+<h2 id="g0.4">3. The Trade Office Registry </h2>
+
+<p>
+                        Approved Registries follow the European style of
+ Chambers of Commerce (e.g Chambers of Commerce in continental Europe,
+Companies House in the United Kingdom and Ministry of Justice, Finance,
+or Commerce in Eastern Europe).
+                </p>
+
+<h3 id="g0.4.1">3.1. Criteria for acceptance of a Registry </h3>
+<p>
+An Organisation can be accepted for Assurance under this policy if
+registered with a formal Trade Office Registry.
+The criteria for an Approved Registry is:
+</p>
+<ol style="list-style-type: lower-alpha;">
+
+<li>The Registry follows the general model of
+    <i>Trade Offices</i>
+and thus is a formal authority for dealing with local trade matters affecting organisations;
+    </li>
+
+<li>The Registry is formally
+    empowered to register corporate entities
+    (organisations)
+    under national law;</li>
+
+<li>The Registry has a reliable search facility service
+    that provides reliable documentary evidence of the
+    registration entry of an organisation.
+    <i>The service may carry costs which are reimbursed from the organisation
+    applicant</i>;</li>
+
+<li>The Registry (or, its search facility)
+    can provide an Extract of the registration of the entity,
+    below.
+    </li>
+</ol>
+
+
+<h3 id="g0.4.2">3.2. Extracts</h3>
+<p>
+The Extract is the set of records provided by the Registry.
+The Extract is to include the following information:
+</p>
+
+<ol>
+
+<li><i>Full name</i> of the legal entity,</li>
+
+<li><i>Representative</i>(s) of organisation (e.g. Company, Partnership, Sole Trader),</li>
+
+<li><i>Type</i> of organisation,</li>
+
+<li><i>Location</i> (which must be within the area the Approved Registry is responsible for),</li>
+
+<li><i>Identifier</i> or number, a unique registration id within Registry.</li>
+
+</ol>
+
+<p>
+Organisation Assurance
+is available to any active entity which can provide the above Extract.
+</p>
+
+<h2 id="g0.5">4. Assurance Process </h2>
+
+<h3 id="g0.5.1">4.1. In general</h3>
+
+<p>
+The Organisation Assurer should take note of the following:
+</p>
+<ol style="list-style-type: lower-alpha;">
+
+<li>Each Organisation Assurance is for one legal entity only, but may include multiple names (e.g. trading names);</li>
+
+<li>The Organisation Administrator (O-Admin) must be an Assurer and must be delagated by the Applicant;</li>
+
+<li>All organisations must be verified by Extract from an Approved
+Registry. The Organisation Assurer may conduct a Registry check
+(search).</li>
+
+</ol>
+<p></p>
+
+
+
+<h3 id="g0.5.2">4.2. Process requirements for the Organisation</h3>
+<p>
+For legal entities requesting Organisation Assurance under this subsidiary policy:
+</p>
+<ul>
+
+	<li>The <i>Representative</i> must be duly authorised to sign on behalf of the organisation, and may be:
+
+		<ol style="list-style-type: lower-roman;">
+
+			<li>
+			The Secretary as verified in the Extract.
+			This is the preferred and best option;
+			</li>
+
+			<li>
+			A full Director of the managing or Executive board,
+			as verified in the Extract;
+			</li>
+
+			<li>
+			Any other Representative must prove that
+			they are duly authorised to sign on behalf of
+			the entity (e.g. via explicit written delegation or under organisation bylaws and rules).
+			This will require due diligence to be conducted by the Organisation Assurer,
+			to the standard and/or for approval
+			by the Organisation Assurer.
+			</li>
+		</ol>
+	</li>
+</ul>
+
+<h3 id="g0.5.3">4.3. Process requirements for Individuals </h3>
+<p>
+For Individuals requesting Organisation Assurance under this subsidiary policy:
+</p>
+<ol style="list-style-type: lower-alpha;">
+
+<li>The individual Member must be a CAcert Assurer;</li>
+
+<li>The individual Member may act as her own Organisation Administrator.</li>
+</ol>
+<p></p>
+
+
+<h3 id="g0.5.4">4.4. Process requirements for Partnerships </h3>
+<p>
+For Partnerships requesting Organisation Assurance under this subsidiary policy:
+</p>
+<ol style="list-style-type: lower-alpha;">
+
+<li>The Partners must be verified via the Extract;</li>
+
+<li>The applying Partner (signatory) must be an CAcert Assurer;</li>
+
+<li>
+Where the Applicant is not the managing Partner, further due diligence should be conducted
+(e.g. verification that the role and title of the Applicant is suitable).
+<i>If in doubt approval should be obtained from each of the Partners who should be individually Assured.</i>
+</li>
+</ol>
+<p></p>
+
+<h3 id="g0.5.5">4.5. Application Form: CAcert Organisation Assurance Programme (COAP) Form </h3>
+<p>
+On the CAcert Organisation Assurance Programme Form (COAP Form),
+the following must be specified:
+</p>
+
+<ol style="list-style-type: lower-alpha;">
+
+<li><i>Licensing Authority</i> must be specified as the Approved Registry which issued the Extract;</li>
+
+<li><i>The unique registration Identifier</i> must be provioded where issued (a Registry may not issue a unique Identifier for sole traders and partnerships);</li>
+
+<li><i>Type</i> of entity that is registered, according to the classification created by the Registry.</li>
+
+</ol>
+
+<p></p>
+
+<p>
+The essential purpose of the information is to permit
+the Organisation Assurer and others to clearly and accurately identify
+the Organisation as actively registered within the Registry, as well as
+its Representatives.
+</p>
+
+<!-- ******************************************************* -->
+<br>
+
+<br>
+
+<br>
+
+<hr size="5" width="50%">
+
+<h1 id="g1">Appendix I</h1>
+
+<h2 id="g1.1">Table of accepted Trade Office Registries for EU countries</h2>
+<p>
+The following table defines the accepted Registries for Europe.
+</p>
+<table>
+<thead>
+<tr valign="top">
+
+<th align="left">EU country</th>
+
+<th align="left">Registry</th>
+
+<th align="left">web address</th>
+
+<th align="left">internal ID</th>
+
+<th align="left">accepted</th>
+
+</tr>
+</thead>
+<tbody>
+<tr valign="top">
+
+<td><i>Austria</i>:</td>
+    <!-- Confirmed 2008-08-18 Philipp Dunkel -->
+
+<td>Bundesministerium
+<br>
+für Justiz</td>
+
+<td><a title="Firmenbuch" href="http://www.bmj.gv.at/buergerinfo/index.php">www.bmj.gv.at</a></td>
+
+<td>BMJ</td>
+
+<td>18-08-2008</td>
+
+<td></td>
+    </tr>
+
+<tr valign="top">
+
+<td></td>
+
+<td>HF Data GmbH</td>
+
+<td><a title="Firmenbuchdatenbank" href="http://www.firmenbuch.at/">www.firmenbuch.at</a></td>
+
+<td>FB</td>
+
+<td>18-08-2008</td>
+</tr>
+<tr valign="top">
+
+<td><i>Belgium</i>:</td>
+    <!-- Confirmed 2009-02-08 Alexander Prinsier and Wim Vandeputte -->
+
+<td>Kruispuntbank van Onderneminge</td>
+
+<td><a title="e-economiie" href="http://kbo-bce-ps.economie.fgov.be/ps/kbo_ps/kbo_search.jsp?Action=SKW">kbo-bce-ps.economie.fgov.be</a></td>
+
+<td>KBO</td>
+
+<td>10-02-2009</td>
+    </tr>
+
+<tr valign="top">
+
+<td></td>
+
+<td>Banque-Carrefour des Entreprises</td>
+
+<td><a title="e-economiie" href="http://kbo-bce-ps.economie.fgov.be/ps/kbo_ps/kbo_search.jsp?Action=SKW">kbo-bce-ps.economie.fgov.be</a></td>
+
+<td>BCE</td>
+
+<td><span color="blue">p20090210.1</span></td>
+</tr>
+<tr valign="top">
+
+<td><i>Denmark</i>:</td>
+    <!-- Confirmed 2009-02-9 Asbjoern S. Toenesen -->
+
+<td>Central Business Register</td>
+
+<td><a title="Det centrale virksomhedsregister" href="http://cvr.dk/Site/Forms/CMS/DisplayPage.aspx?pageid=0">virk.dk</a></td>
+
+<td>CVR</td>
+
+<td><span color="blue">p20090218.1</span></td>
+</tr>
+<tr valign="top">
+
+<td><i>Finland</i>:</td>
+    <!-- ack: Riku Itäpuro 2008/03/07 -->
+
+<td>Yritys-Ja
+<br>
+Yhteisötietojärjestelmä</td>
+
+<td><a title="Finnish Business Information System" href="http://www.ytj.fi/english/">www.ytj.fi</a></td>
+
+<td>BIS</td>
+
+<td>07-03-2007</td>
+</tr>
+<tr valign="top">
+
+<td><i>France</i>:</td>
+    <!-- ack: Richard Migneron 2008/06/04, Guillaume Rogmany 2008/08/19 -->
+
+<td>Chambre de Commerce
+<br>
+et d'Industrie</td>
+
+<td><a title="Chambre de Commerce et d'Industrie" href="http://www.cci.fr/">www.cci.fr</a></td>
+
+<td>CCI</td>
+
+<td>19-08-2008</td>
+    </tr>
+
+<tr valign="top">
+
+<td><i></i></td>
+
+<td>Registre National du
+<br>
+Commerce et de Sociétés</td>
+
+<td><a title="National Register for trade and associations" href="http://www.euridile.inpi.fr/">www.euridile.inpi.fr</a></td>
+
+<td>INPI</td>
+
+<td>19-08-2008</td>
+    </tr>
+
+<tr valign="top">
+
+<td><i></i></td>
+
+<td>InfoGreffe</td>
+
+<td><a title="L'Information Legale sur les Entreprises" href="http://www.infogreffe.fr/">www.infogreffe.fr</a></td>
+
+<td>IG</td>
+
+<td>19-08-2008</td>
+</tr>
+<tr valign="top">
+
+<td><i>Ireland</i>:</td>
+    <!-- ack: Andrew Barnes 2008/04/22, Sam Johnston 2008/04/16 -->
+
+<td>Companies Registration Office</td>
+
+<td><a title="Companies Registration Office" href="http://www.cro.ie/">www.cro.ie</a></td>
+
+<td>CRO</td>
+
+<td>16-04-2008</td>
+</tr>
+<tr valign="top">
+
+<td><i>Netherlands</i>:</td>
+    <!-- ack: Teus Hagen 2008/05/13 -->
+
+<td>Kamer van Koophandel</td>
+
+<td><a title="Kamer van Koophyandel" href="http://www.kvk.nl/">www.kvk.nl</a></td>
+
+<td>KvK</td>
+
+<td>13-05-2008</td>
+</tr>
+<tr valign="top">
+
+<td><i>Sweden</i>:</td>
+    <!-- ack: Erik Dalén 2008/05/22 -->
+
+<td>Skatteverket</td>
+
+<td><a title="Skatteverket" href="http://www.skatteverket.se/">www.skatteverket.se</a></td>
+
+<td>SKAT</td>
+
+<td>22-05-2008</td>
+    </tr>
+
+<tr valign="top">
+
+<td><i></i></td>
+
+<td>Bolagsverket</td>
+
+<td><a title="Bolasverket Regsitry of Ministry of Commerce" href="http://www.bolagsverket.se/">www.bolagsverket.se</a></td>
+
+<td>BOL</td>
+
+<td>22-05-2008</td>
+</tr>
+<tr valign="top">
+
+<td><i>United Kingdom</i>:</td>
+    <!-- ack: Conall O'Brien 2008/04/22, Sam Johnston 2008/04/22 -->
+
+<td>Companies House</td>
+
+<td><a title="Companies House" href="http://www.companieshouse.gov.uk/">www.companieshouse.gov.uk</a></td>
+
+<td>CH</td>
+
+<td>22-05-2008</td>
+</tr>
+</tbody>
+</table>
+<h2 id="g1.2">Table of accepted Trade Office Registries for other European countries</h2>
+<p>
+</p>
+<table>
+<thead>
+<tr valign="top">
+
+<th align="left">Europe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+    </th>
+<th align="left">Registry</th>
+
+<th align="left">web address</th>
+
+<th align="left">internal ID</th>
+
+<th align="left">acceptance</th>
+</tr>
+</thead>
+<tbody>
+<tr valign="top">
+
+<td><i>Norway</i>:</td>
+    <!-- ack: Dag Hovland 2008/05/09 -->
+
+<td>Brønnøysund Register Centre</td>
+
+<td><a title="Brønnøysundregistrene" href="http://www.brreg.no/">www.brreg.no</a></td>
+
+<td>BRC</td>
+
+<td>09-05-2008</td>
+    </tr>
+
+<tr valign="top">
+
+<td><i></i></td>
+
+<td>Nøkkelopplysninger
+<br>
+fra Enhetsregisteret</td>
+
+<td><a title="Nøkkelopplysninger fra Enhetsregisteret" href="http://w2.brreg.no/enhet/sok/">w2.brreg.no</a></td>
+
+<td>BRREQ</td>
+
+<td>09-05-2008</td>
+</tr>
+</tbody>
+</table>
+
+<!-- ******************************************************* -->
+<br>
+
+<br>
+
+<br>
+		
+<hr size="5" width="50%">
+
+<h1 id="g2">Appendix 2</h1>
+
+<p>This Appendix is part of Work in Process by definition.</p>
+
+<h2 id="g2.1">Table of Trade Office Registries for EU countries which Registries are in process of acceptation</h2>
+<p>
+The orange diamond <font color="orange" size="+2">♦</font> denotes a Registry being accepted. The red bullit <font color="red" size="+2">•</font> denotes a Registry awaiting feedback from that country to be accepted for organisation registration Extracts.
+</p>
+<table>
+<thead>
+<tr valign="top">
+
+<th align="left">EU country</th>
+
+<td></td>
+
+<th align="left">Registry</th>
+
+<th align="left">web address</th>
+
+<th align="left">internal ID</th>
+</tr>
+</thead>
+<tbody>
+<tr valign="top">
+
+<td><i>Bulgaria</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Ministry of Justice</td>
+
+<td><a title="Central Register of non-governmental Legal Entities Sector" href="http://www.mjeli.government.bg/ngo/Default.aspx?cc=en&amp;">www.mjeli.government.bg</a></td>
+
+<td>NGO</td>
+</tr>
+<tr valign="top">
+
+<td><i>Cyprus</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Dept of Registrar
+<br>
+of companies</td>
+
+<td><a title="Department of Registrar of Companies and Official Receiver" href="http://www.mcit.gov.cy/mcit/drcor/drcor.nsf/aboutus_en/aboutus_en?OpenDocument">www.mcit.gov.cy</a></td>
+
+<td>DRC</td>
+</tr>
+<tr valign="top">
+
+<td><i>Czech Republic</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Ministry of Finance</td>
+
+<td><a title="Register of Trades and Register of Economic Entites" href="http://wwwinfo.mfcr.cz/ares/">wwwinfo.mfcr.cz</a></td>
+
+<td>ARES</td>
+</tr>
+<tr valign="top">
+
+<td><i>Estonia</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>E-Äriregister</td>
+
+<td><a title="Äriregistri Teabes&amp;umml;steem (Central Commercial Register)" href="https://ariregister.rik.ee/index.py?lang=eng">ariregister.rik.ee</a></td>
+
+<td>RIK</td>
+</tr>
+<tr valign="top">
+
+<td><i>Germany</i>:</td>
+
+<td valign="top"><font color="orange" size="+2">♦</font></td>
+
+<td>Handelsregister Portal</td>
+
+<td><a title="Gemeinsames Registerportal der Länder" href="http://www.handelsregister.de/rp_web/welcome.do">www.handelsregister.de</a></td>
+
+<td>HR</td>
+</tr>
+<tr valign="top">
+
+<td><i>Greece</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Athens Chamber of
+<br>
+Commerce and Industry</td>
+
+<td><a title="Athens Chamber of Commerce and Industry" href="http://www.acci.gr/en_index2.htm">www.acci.gr</a></td>
+
+<td>ACCI</td>
+</tr>
+<tr valign="top">
+
+<td><i>Hungary</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Ministry of Justice</td>
+
+<td><a title="Commercial Register" href="http://www.im.hu/?katid=2&amp;id=53&amp;mi=2">www.im.hu</a></td>
+
+<td>IM</td>
+</tr>
+<tr valign="top">
+
+<td><i>Italy</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>InfoCamere</td>
+
+<td><a title="Italian Chamber of Commerce" href="http://web.telemaco.infocamere.it/">webtelemaco.infocamere.it</a></td>
+
+<td>IC</td>
+</tr>
+<tr valign="top">
+
+<td><i>Latvia</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Lursoft</td>
+
+<td><a title="Company Register for Latvian" href="http://www.lursoft.lv/?a=138&amp;v=lv&amp;v=en">www.lursoft.lv</a></td>
+
+<td>LS</td>
+</tr>
+<tr valign="top">
+
+<td><i>Lithuania</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Juridiniu Asmenu Registras</td>
+
+<td><a title="Commercial Register by Ministry of Justice" href="http://www.registrucentras.lt/index_en.php">www.registrucentras.lt</a></td>
+
+<td>JAR</td>
+</tr>
+<tr valign="top">
+
+<td><i>Luxembourg</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Registre de
+<br>
+Commerce et des Sociétés</td>
+
+<td><a title="Registre de Commerce et des Sociétés" href="https://www.rcsl.lu/mjrcs/index.do">www.rcsl.lu</a></td>
+
+<td>RCSL</td>
+</tr>
+<tr valign="top">
+
+<td><i>Malta</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Registry of Companies</td>
+
+<td><a title="Register of Corporations and Traders" href="http://registry.mfsa.com.mt/">registry.mfsa.com.mt</a></td>
+
+<td>RNFS</td>
+</tr>
+<tr valign="top">
+
+<td><i>Poland</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Ministry of Justice</td>
+
+<td><a title="No Company Register in Place" href="http://opp.ms.gov.pl/">opp.ms.gov.pl</a></td>
+
+<td>CORS</td>
+</tr>
+<tr valign="top">
+
+<td><i>Portugal</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Conservatórias do
+<br>
+Registo Comercial</td>
+
+<td><a title="Registo Commercial" href="http://www.dgrn.mj.pt/db_com/endcom1.asp">www.dgrn.mj.pt</a></td>
+
+<td>RC</td>
+</tr>
+<tr valign="top">
+
+<td><i>Romania</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>ReCom
+<br>
+Min. of Justice</td>
+
+<td><a title="National Trade Register Office" href="http://recom.onrc.ro/indexe.htm">recom.onrc.ro</a></td>
+
+<td>ReCom</td>
+</tr>
+<tr valign="top">
+
+<td><i>Slovakia</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Obchodný register</td>
+
+<td><a title="Min of Justice Company register" href="http://www.orsr.sk/default.asp?lan=en">www.orsr.sk</a></td>
+
+<td>ORSR</td>
+</tr>
+<tr valign="top">
+
+<td><i>Slovenia</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Register Podjetij</td>
+
+<td><a title="Slovenian Commercial Register of Min of Commerce and Industry" href="http://www.gzs.si/register%5Feng/">www.gzs.si</a></td>
+
+<td>GZS</td>
+</tr>
+<tr valign="top">
+
+<td><i>Spain</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Registro Mercantil Central</td>
+
+<td><a title="Central Mercantile Register" href="http://www.ncc.es/">www.nnc.es</a></td>
+
+<td>RMC</td>
+</tr>
+</tbody>
+</table>
+<table>
+<thead>
+
+<tr>
+<th align="left">Europe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+    </th>
+<td></td>
+
+<th align="left">Registry</th>
+
+<th align="left">web address</th>
+
+<th align="left">ID</th>
+</tr>
+</thead>
+<tbody>
+<tr valign="top">
+
+<td><i>Andorra</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Oficina de Marques</td>
+
+<td><a title="General Registry for Trade and Commerce" href="http://www.ompa.ad/indexang.html">www.ompa.ad</a></td>
+
+<td>OMPA</td>
+</tr>
+<tr valign="top">
+
+<td><i>Bosinia &amp;
+<br>
+Herzegovina</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Gosodarska komora Federacije
+<br>
+Bosne i Hercegovine</td>
+
+<td><a title="Sate and private corporations and cooperatives" href="http://www.kfbih.com/eng/">www.kfbih.com</a></td>
+
+<td>KFBiH</td>
+</tr>
+<tr valign="top">
+
+<td><i>Croatia</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Registar Poslovnih Subjekata</td>
+
+<td><a title="Register of business entities in Republic of Croatia" href="http://www1.biznet.hr/HgkWeb/do/extlogon?lang=en_GB">www1.biznet.hr</a></td>
+
+<td>BIZNET</td>
+</tr>
+<tr valign="top">
+
+<td><i>Gibraltar</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Companies House</td>
+
+<td><a title="Gibraltar Finance Centre" href="http://www.companieshouse.gi/">www.companieshouse.gi</a></td>
+
+<td>CH</td>
+</tr>
+<tr valign="top">
+
+<td><i>Serbia</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Serbian Commercial Register
+<br>
+Агенција за
+<br>
+привредне регистре</td>
+
+<td><a title="Serbian Commercial Register" href="http://www2.apr.sr.gov.yu/default.aspx">www.apr.sr.gov.yu</a></td>
+
+<td>SCR</td>
+</tr>
+<tr valign="top">
+
+<td><i>Switzerland</i>:</td>
+
+<td valign="top"><font color="red" size="+2">•</font></td>
+
+<td>Central Business
+<br>
+Names Index portal</td>
+
+<td><a title="Registry portal by Federal Office of Justice" href="http://www.zefix.admin.ch/">www.zefix.admin.ch</a></td>
+
+<td>Zefix</td>
+</tr>
+</tbody>
+</table>
+
+
+</body>
+</html>
diff --git a/www/policy/OrganisationAssurancePolicy_Germany.html b/www/policy/OrganisationAssurancePolicy_Germany.html
new file mode 100644
index 0000000..da69e80
--- /dev/null
+++ b/www/policy/OrganisationAssurancePolicy_Germany.html
@@ -0,0 +1,138 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title>CACert Organisation Assurance Program sub-policy for Germany</title>
+<style type="text/css">
+<!--
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+
+</head>
+<body>
+
+<h1> Organisation Assurance - sub-policy for German organisations</h1>
+<div class="comment">
+<table width="100%">
+<tbody>
+<tr>
+<td rowspan="2">
+   Name: Organisation Assurance - sub-policy Germany <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11.DE</a>
+<br>
+   Creation Date : 2007-10-22
+<br>
+   Editor: Jens Paul
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+		<img src="images/cacert-policy.png" alt="OAP DE Status - POLICY" style="border-style: none;" height="31" width="88">
+	</a>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+<h2 id="g0.1">0. Preliminaries</h2>
+This sub-policy describes how Organisation Assurers ("OAs") conduct assurances on German organisations.
+It fits within the overall web-of-trust or assurance process and the Organisation Assurance Policy (OAP) of CAcert.
+<br>
+
+<br>
+
+<br>
+
+<h2 id="g0.2">1. Purpose</h2>
+This is a subsidiary policy to the OAP.
+<br>
+
+<br>
+a. This sub-policy is applicable for the assurance of German organisations only.
+<br>
+b. This sub-policy is an implementation of the OAP.
+<br>
+c.  In the below, where the Assurance Officer (AO) is referred to, this includes his local delegate.
+<br>
+
+<br>
+
+<br>
+
+<h2 id="g0.3">2. Organisation Assurers</h2>
+
+<h2 id="g0.4">3. Requirements for the Organisation Assurer</h2>
+In addition to the requirements defined in the OAP, an OA must meet the
+following requirements for assuring German organisations:
+<br>
+a. Knowledge on common legal forms of organisations in Germany.
+<br>
+b. Must pass an additional test on local knowledge even if he is already an OA.
+<br>
+c. Should help the AO to define local requirements.
+<br>
+
+<br>
+
+<br>
+
+<h2 id="g0.5">4. Process</h2>
+
+<h2 id="g0.6">5. Organisations</h2>
+Acceptable organisations under this sub-policy must be:
+<br>
+
+<br>
+a. Organisations created under the rules of the German jurisdiction.
+<br>
+b. Organisations must not be revoked by a competent authority with direct oversight over the organisation.
+<br>
+
+<br>
+
+<h2 id="g0.7">6. Documents</h2>
+The organisation has to provide documents to prove the essential standard of Organisation Assurance as defined in the policy:
+<br>
+a. The primary mechanism to prove existence is to get an official
+extract from the official register, either via an online interface
+or via physical means (organisation is asked to carry the costs)
+<br>
+b. Where not available, an official document will be required from the company, subject to such checks as defined by the AO.
+<br>
+c. If copies of official extracts from the official register are provided, they must be officially certified
+<br>
+d. Extracts from the official register should not be older than 4 weeks.
+<br>
+e. The AO maintains a list of which specific documents and tests can be acceptable for the certain types
+of organisations.
+<br>
+f. The OA can ask for additional documents if needed to validate required information for the assurance action.
+<br>
+
+<br>
+
+<h2 id="g0.8">7. COAP</h2>
+<p>
+In addition to the checks defined in the policy, the COAP form for German organisations requires:
+<br>
+a. The OA must keep all documentation for 10 years.
+<br>
+b. Signatures from organisation officials must meet the following requirements
+<br>
+&nbsp;&nbsp;&nbsp; i.&nbsp;&nbsp; as legally specified for the type of organisation
+<br>
+&nbsp;&nbsp;&nbsp; ii.&nbsp; as specified in the official documents (f.e. the excerpt from the register)
+<br>
+&nbsp;&nbsp;&nbsp; iii. as delegated within the organisation (proof of delegation needed)
+</p>
+
+
+</body>
+</html>
diff --git a/www/policy/PolicyOnJuniorAssurersMembers.html b/www/policy/PolicyOnJuniorAssurersMembers.html
new file mode 100644
index 0000000..55d9ab4
--- /dev/null
+++ b/www/policy/PolicyOnJuniorAssurersMembers.html
@@ -0,0 +1,202 @@
+<!DOCTYPE HTML>
+<html>
+ <head>
+    <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" lang="en">
+  <title> CACert -- Policy On Junior Assurers / Members </title>
+<style type="text/css">
+.q {
+        color : green;
+        text-indent : 2em;
+        font-weight: bold;
+        font-style:italic;
+}
+.error {
+        color : red;
+        font-weight: bold;
+        text-align: center;
+        font-style:italic;
+}
+.change {
+        color : blue;
+        font-weight: bold;
+}
+.padding5 td{
+     padding: 5px;
+}
+.r {
+    text-align : right;
+}
+</style>
+
+ </head>
+
+ <body>
+  <h1> Policy On Junior Assurers / Members </h1>
+
+<table style="width: 100%;">
+ <tr>
+  <td>
+   Editor: Iang<br />
+   Creation Date : <a href="https://svn.cacert.org/CAcert/Assurance/Minutes/20091215HamburgMiniTOP.html">20091215</a><br />
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20130222">p20130222</a><br />
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br />
+  </td><td class="r">
+   <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-policy.png" alt="PoJAM Status - POLICY" height="31" width="88" style="border-style: none;" /></a>
+  </td>
+ </tr>
+</table>
+
+  <h2 id="s0"> 0. Preliminaries </h2>
+  <h3 id="s0.1"> 0.1 Authority.</h3>
+   <p>This sub-policy extends the
+   <a href="https://www.cacert.org/policy/AssurancePolicy.html">
+   Assurance Policy</a> ("AP" =&gt; COD13)
+   by specifying how Juniors can be brought into the
+   CAcert Community.
+  </p>
+
+  <h3 id="s0.2"> 0.2 Terms.</h3>
+
+  <ul>
+    <li> <b>Minor</b> is a person who is not empowered to enter contracts as self under local laws.</li>
+    <li> <b>Junior</b> is a person under 18. A Junior is probably a Minor.</li>
+    <li> <b>Parent</b>. A competent adult that is legally responsible under local law for the Minor. E.g., a natural or adopted parent, or a legal guardian. Unless otherwise stated, the singular term Parent is used herein, and is used to cover all forms of persons that are legally responsible for the Minor. </li>
+  </ul>
+
+  <h2 id="s1"> 1. Scope </h2>
+  <p id="s1.1"><b> 1.1 </b>
+   This policy applies to all Members of the CAcert Community.
+  </p>
+
+  <p id="s1.2"><b> 1.2 </b>
+   Although variations exist in different countries, CAcert works to a principle of no discrimination (Principles) and therefore imposes the same view across all countries.
+  </p>
+
+  <h2 id="s2"> 2. Entering the Community </h2>
+  <p id="s2.1"><b> 2.1 </b>
+   There is no limit on age for membership of CAcert.
+  </p>
+
+  <p id="s2.2"><b> 2.2 </b>
+   Membership requires a legal contract to be formed. This can be formed one of two ways:
+  </p>
+  <ol>
+   <li>the member has capacity to enter the contract themselves, or</li>
+   <li>the member is a Minor and requires the consent of the Parent.</li>
+  </ol>
+
+  <p id="s2.3"><b> 2.3 </b>
+   The Assurer is responsible in all cases for confirming that the entry into the CAcert Community Agreement is founded. This means in practice that the Assurer has to confirm the above.
+  </p>
+
+  <p id="s2.4"><b> 2.4 </b>
+   A general situation in each country is that a Minor can only enter with Parental consent. In this case, the Assurer should confirm the consent of the Parent.
+  </p>
+
+  <p id="s2.5"><b> 2.5 </b>
+   The mechanism for confirming the Parent's consent is something that varies and is not covered by policy. The simple requirement here is that the Assurer makes a reliable statement (CARS) that consent is established, following these two declarations:
+  </p>
+  <blockquote>
+    <p>
+      The Assurer's declaration
+      (specifically referring to Assurance Policy 1.1 part 4
+      <a href="https://www.cacert.org/policy/AssurancePolicy.html#s1.1">AP1.1</a>):
+    </p>
+    <blockquote>
+     <table class="padding5" border="1"><tr><td>
+      This Assurance conducted according to Assurance Policy
+     </td></tr></table>
+    </blockquote>
+  </blockquote>
+  <blockquote>
+    <p>
+     The member's declaration:
+    </p>
+     <blockquote>
+     <table class="padding5" border="1"><tr><td>
+      I agree to the CCA
+     </td></tr></table>
+    </blockquote>
+  </blockquote>
+
+  <p id="s2.6"><b> 2.6 </b>
+   The Assurance Handbook (<a href="https://wiki.cacert.org/AssuranceHandbook2">AH</a>) should expand on common methods to establish and record consent. Such as, on a separate form, a modification to CAP form, etc.
+  </p>
+
+
+  <h2 id="s3"> 3. System Block </h2>
+  <p id="s3.1"><b> 3.1 </b>
+   Although there is no age limit in this policy, it is reasonable that the Assurer should check this issue closely below 18.
+  </p>
+
+  <p id="s3.2"><b> 3.2 </b>
+   For persons over 18, the Assurer may presume that the person has capacity to enter into a contract, in absence of any alternate suggestion. This is regardless of the legal circumstances of the country.
+  </p>
+
+  <p id="s3.3"><b> 3.3 </b>
+   Therefore, a change should be put into the system:
+  </p>
+  <blockquote>
+   <p>
+      If the member is under 18 years of age,<br />
+      the system shall require the Assurer to confirm<br />
+      that consent was established during the Assurance,<br />
+      or otherwise as considered by the Assurer,<br />
+      before additional higher reliance products are available.
+   </p>
+  </blockquote>
+  <p>
+   The system therefore will block all "reliance" products
+   as defined by policy
+   (issuance of named certificates under CPS, Assurer under AP),
+   until consent is established as appropriate.
+  </p>
+  <p>
+   The absence of this feature does not remove the duty of the Assurer (for example, because of delays in implementation).
+  </p>
+
+  <p id="s3.4"><b> 3.4 </b>
+   The first Assurers of a Member may then have the greater technical burden of explaining and confirming the consent, but the confirmation is required of all Assurers as part of the CAP.
+  </p>
+
+  <p id="s3.5"><b> 3.5 </b>
+   The Assurance Handbook (<a href="https://wiki.cacert.org/AssuranceHandbook2">AH</a>) should document more efficient methods, such as a single form carried by the Junior Member for showing to the Assurer, rather than the Parent's signature over each individual CAP form.
+  </p>
+
+
+  <h2 id="s4"> 4. The Junior Assurer </h2>
+  <p id="s4.1"><b> 4.1 </b>
+   Assurer status may only be granted if the user is at least 14 years old. Other preliminaries for the Assurer status set up by other policies are untouched. Combining AP and this policy, a Junior Assurer is a CAcert member with 100 Assurance Points, has passed the CAcert Assurer Challenge, and is between the ages of 14 and 18 years.
+  </p>
+
+  <p id="s4.2"><b> 4.2 </b>
+   A Junior Assurer can issue a maximum of 10 Assurance Points to an assuree, independent of how many Experience Points the Junior already has. The Experience Points awarded to the Junior Assurer are untouched.
+  </p>
+
+  <p id="s4.3"><b> 4.3 </b>
+   The Assurance Handbook (<a href="https://wiki.cacert.org/AssuranceHandbook2">AH</a>)
+   should stipulate the convention as to how the Junior Assurer establishes bona fides.
+  </p>
+
+
+  <h2 id="s5"> 5. Arbitration </h2>
+  <p>
+   Arbitration with Juniors needs to take into account that a local court may find the CCA to be improperly imposed. Some understanding of this risk should be taken, but Arbitrators should be careful not to weaken the web of trust on this basis. Therefore, more care should be taken in explaining and ensuring the spirit of the CCA is maintained.
+  </p>
+  <ul>
+   <li>
+    The Parent may be concerned about the impact of an Arbitration. Technically, the consenting Parent is the one appearing in the Arbitration. The Arbitrator should recognise both the technical (legal) meaning, but strive to maintain the spirit of the Junior member's appearance. For example, Arbitration documentation may name the Parent primarily, and refer to the Junior in text.
+   </li>
+   <li>
+    The Arbitrator may appoint a senior Assurer to advise the Parent on the nature of the Community.
+   </li>
+   <li>
+    A ruling should be tested by comparing it to an adult scenario.
+   </li>
+  </ul>
+  <p>
+    The counter-situation to a weak CCA agreement is that if a person (of any age) feels the CCA to be inappropriate, then they have not entered into the Community. The Arbitrator is at liberty to terminate the CCA with a Member, if there is a sustainable view that it is inappropriate. Such termination should include measures needed to repair the web of trust.
+  </p>
+<p><a href="http://validator.w3.org/check?uri=referer"><img src="images/valid-html50-blue.png" alt="Valid HTML 5" height="31" width="88"></a></p>
+</body>
+</html>
diff --git a/www/policy/PolicyOnPolicy.html b/www/policy/PolicyOnPolicy.html
new file mode 100644
index 0000000..f50b415
--- /dev/null
+++ b/www/policy/PolicyOnPolicy.html
@@ -0,0 +1,356 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title>Policy on Policy</title>
+<style type="text/css">
+<!--
+body {
+        font-family : verdana, helvetica, arial, sans-serif;
+}
+
+th {
+        text-align : left;
+}
+
+.comment {
+        color : steelblue;
+}
+.q {
+        color : green;
+        font-weight: bold;
+        text-align: center;
+        font-style:italic;
+}
+-->
+</style>
+</head>
+<body>
+
+<div class="comment">
+
+<table width="100%">
+
+<tbody>
+<tr>
+
+<td rowspan="2">
+	Name: PoP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD1</a>
+<br>
+	Status: POLICY&nbsp;<a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+	Editor: Iang 20080309
+<br>
+	Changes: 20100507, 20130223, 20140731
+<br>
+	Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+<br>
+</td>
+
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+		<img src="images/cacert-policy.png" alt="PoP Status - POLICY" style="border-style: none;" height="31" width="88">
+	</a>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+<p>
+<br>
+</p>
+
+<h1> Policy&nbsp;on&nbsp;Policy </h1>
+
+
+
+<h2 id="g0.1">0. Preliminaries </h2>
+<p>
+    Policy on Policy adopts the IETF model of
+    'rough consensus' to create CAcert documents
+    within the open CAcert Policy Group <a href="https://lists.cacert.org/wws/info/cacert-policy"> mail list forum</a>.
+</p>
+
+
+<h2 id="g0.2">1. Scope and Purpose </h2>
+
+<p id="s1.1">
+1.1
+This policy documents and controls the process by which
+CAcert creates and promulgates policies.
+</p>
+
+<p id="s1.2">
+1.2
+The policy covers itself.
+The policy replaces prior ones.
+For Audit purposes,
+the policy is part of the Configuration-Control Specification
+("CCS", <a href="http://rossde.com/CA_review/CA_review_A.html#A1">DRC_A.1</a>)
+and also documents part of the CCS.
+</p>
+
+<p id="s1.3">
+1.3
+The policies so created are generally binding on
+CAcert Inc., members under CAcert Community Agreement
+(CCA =&gt; COD9) and other related parties under other agreements.
+</p>
+
+<p id="s1.4">
+1.4
+The Policy Officer manages all policies
+and the policy group.
+The policy group is formed on the open mailing list
+known as CAcert Policy Group, and is to be open to all
+Community Members of CAcert.
+</p>
+
+
+<h2 id="g0.3">2. Basic Model </h2>
+
+<p id="s2.1">
+2.1
+The basic concept was drawn from the IETF model.
+</p>
+
+<p id="s2.2">
+2.2
+Policies are documented.
+Documents start as <i>Work-In-Progress</i>, move through to
+<i>DRAFT</i> and finalise in <i>POLICY</i> status.
+</p>
+
+<p id="s2.3">
+2.3
+Decisions are taken by "Rough Consensus."
+A vote may be called to clarify.
+</p>
+
+<p id="s2.4">
+2.4
+Documents should include a minimum of information
+in a standardised format managed by the Documentation Officer:
+the Title,
+short name,
+Document Status,
+date the Status was reached,
+Editor,
+date / time of the last edit,
+Abstract.
+</p>
+
+<p id="s2.5">
+2.5
+Editors may make the following changes, where
+     it is clear that the change does not change the policy:</p>
+<ul>
+<li>
+      fixes to errors in grammar and spelling,
+    </li>
+<li>
+      anchors, HTML errors, URLs &amp; formatting,
+    </li>
+<li>
+      COD numbers and other references, and
+    </li>
+<li>
+      other minutiae, as agreed under 2.3.
+    </li>
+</ul>
+<p>
+Such changes to be notified to the policy group, and to be folded into effect, etc, without further ado.
+</p>
+
+
+<p id="s2.6">
+2.6
+Documents of lower status (work-in-progress or DRAFT)
+must not be confusable with documents of higher status
+(DRAFT or POLICY).
+Copies should be eliminated where not being worked on.
+</p>
+
+<h2 id="g0.4">3. Work-In-Progress </h2>
+
+<p id="s3.1">
+3.1
+An Editor is identified.
+This person is responsible for
+drafting the document, following the consensus of the policy group.
+</p>
+
+<p id="s3.2">
+3.2
+The Policy Officer resolves minor disputes and keeps order.
+</p>
+
+<p id="s3.3">
+3.3
+The mail list of the policy group
+is used as the primary debating
+forum. A sub-group may be formed,
+but decision-taking
+should be visible on the main group.
+</p>
+
+<p id="s3.4">
+3.4
+Documents start with the status of
+"Work-In-Progress" or WIP for short.
+</p>
+
+
+<h2 id="g0.5">4. DRAFT status </h2>
+
+<p id="s4.1">
+4.1
+On completion, a document moves to DRAFT status.
+</p>
+
+<p id="s4.2">
+4.2
+A DRAFT is a policy-in-effect for the Community and is
+to be distributed and treated as such.
+</p>
+
+<p id="s4.3">
+4.3
+As far as the Community is concerned, the DRAFT is policy.
+Challenges and concerns can be addressed to the policy group,
+and policy group discussions on a DRAFT
+may be presented in Dispute Resolution.
+</p>
+
+<p id="s4.4">
+4.4
+Revisions of DRAFTs
+must be treated as decisions on the policy group.
+</p>
+
+<p id="s4.5">
+4.5
+The period of the DRAFT status is announced widely,
+which should be at least a month and no longer than a year.
+</p>
+
+<p id="s4.6">
+4.6
+During the period of DRAFT,
+CAcert Inc. retains a veto over
+policies that effect the running of CAcert Inc.
+</p>
+
+<h2 id="g0.6">5. POLICY status </h2>
+<p id="s5.1">
+5.1
+After DRAFT period has elapsed with no revision beyond
+minor and editorial changes,
+there should be a decision
+to move the document from
+DRAFT to POLICY status.
+</p>
+
+<p id="s5.2">
+5.2
+Once POLICY, the Community may only challenge the document
+in Dispute Resolution.
+</p>
+
+<p id="s5.3">
+5.3
+Policy group may propose changes to a POLICY document
+in order to update it.  When changes move to DRAFT status,
+they may be included in the POLICY document,
+but must be clearly indicated within as DRAFT not POLICY.
+</p>
+
+<p id="s5.4">
+5.4
+POLICY documents are published on the CAcert website in plain HTML.  Change control must be in place.
+</p>
+
+<h2 id="g0.7">6. Open Process </h2>
+
+<p id="s6.1">
+6.1
+All policy discussions and documents should be open
+processes.  There should be a fair chance for
+the Community
+to have their views heard.
+Rough Consensus is the working metric.
+</p>
+
+<p id="s6.2">
+6.2
+Contributions to
+formally controlled documents such as Policies
+are transferred fully to CAcert Inc.
+Copyrights
+and similar intellectual property rights
+required to incorporate the Contribution
+are either transferred to CAcert Inc, or,
+are issued and contributed under free,
+open, non-restrictive,
+irrevocable, exclusive,
+and clear licence to CAcert Inc.
+In all cases, CAcert Inc licenses the
+contributions back to the community
+under an open licence.
+</p>
+
+<p id="s6.3">
+6.3
+Contributors declare any conflicts of interest.
+</p>
+
+<p id="s6.4">
+6.4
+Policies should be issued under free, open,
+non-restrictive,
+irrevocable, non-exclusive,
+and clear licence by CAcert, Inc.
+</p>
+
+<p id="s6.5">
+6.5
+Mailing lists should be archived,
+and important meetings should be minuted.
+A record of decisions is to be maintained.
+</p>
+
+<h2 id="g0.8">7. Disputes. </h2>
+
+<p id="s7.1">
+7.1
+Any questions not resolved by these rules
+may be voted on in the policy group, or
+may be dealt with in Dispute Resolution.
+</p>
+
+<p id="s7.2">
+7.2
+The Policy Officer may decide a tight vote in a minor matter only.
+Failure of Rough Consensus may be declared by
+dissenting members.
+</p>
+
+<p id="s7.3">
+7.3
+Matters unresolved refer back
+to further group discussion.
+</p>
+
+<p id="s7.4">
+7.4
+The external avenue for disputes is to file a dispute
+according to CAcert's
+<a href="https://www.cacert.org/policy/DisputeResolutionPolicy.php">
+Dispute Resolution Policy</a>
+DRP =&gt; COD7.
+</p>
+
+
+</body>
+</html>
diff --git a/www/policy/PolicyOnPolicy.php b/www/policy/PolicyOnPolicy.php
index 7992528..6519723 100644
--- a/www/policy/PolicyOnPolicy.php
+++ b/www/policy/PolicyOnPolicy.php
@@ -1,287 +1,4 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-
-<html>
-<head><title>Policy on Policy</title></head>
-<body>
-
-<table width="100%">
-
-<tr>
-<td> PoP </td>
-<td> </td>
-<td width="20%"> Iang  </td>
-</tr>
-
-<tr>
-<td> POLICY&nbsp;<a href="http://wiki.cacert.org/wiki/PolicyDecisions">p200800204.1</a> </td>
-<td>  </td>
-<td>
-  20080309
-</td>
-</tr>
-
-<tr>
-<td> COD1 </td>
-<td> </td>
-<td> </td>
-</tr>
-
-
-<tr>
-<td> </td>
-<td > <b>Policy&nbsp;on&nbsp;Policy</b> </td>
-<td> </td>
-</tr>
-
-</table>
-
-<h2> 0. Preliminaries </h2>
-<p>
-    Policy on Policy adopts the IETF model of
-    'rough consensus' to create CAcert documents
-    within the open [policy] mail list forum.
-</p>
-
-
-<h2> 1. Scope and Purpose </h2>
-
-<p>
-1.1
-This policy documents and controls the process by which
-CAcert creates and promulgates policies.
-</p>
-
-<p>
-1.2
-The policy covers itself.
-The policy replaces prior ones.
-For Audit purposes,
-the policy is part of the Configuration-Control Specification
-("CCS", <a href="http://rossde.com/CA_review/CA_review_A.html#A1">DRC_A.1</a>)
-and also documents part of the CCS.
-</p>
-
-<p>
-1.3
-The policies so created are generally binding on
-CAcert, registered users and related parties.
-</p>
-
-<p>
-1.4
-The Policy Officer manages all policies
-and the policy group.
-The policy group is formed on the open mailing list
-known as [policy], and is to be open to all
-Community Members of CAcert.
-</p>
-
-<h2> 2. Basic Model </h2>
-
-<p>
-2.1
-The basic concept was drawn from the IETF model.
-</p>
-
-<p>
-2.2
-Policies are documented.
-Documents start as <i>Work-In-Progress</i>, move through to
-<i>DRAFT</i> and finalise in <i>POLICY</i> status.
-</p>
-
-<p>
-2.3
-Decisions are taken by "Rough Consensus."
-A vote may be called to clarify.
-</p>
-
-<p>
-2.4
-Documents should include a minimum of information
-in a standardised format managed by the Documentation Officer:
-the Title,
-short name,
-Document Status,
-date the Status was reached,
-Editor,
-date / time of the last edit,
-Abstract.
-</p>
-
-<h2> 3. Work-In-Progress </h2>
-
-<p>
-3.1
-An Editor is identified.
-This person is responsible for
-drafting the document, following the consensus of the policy group.
-</p>
-
-<p>
-3.2
-The Policy Officer resolves minor disputes and keeps order.
-</p>
-
-<p>
-3.3
-The mail list of the policy group
-is used as the primary debating
-forum. A sub-group may be formed,
-but decision-taking
-should be visible on the main group.
-</p>
-
-<p>
-3.4
-Documents start with the status of
-"Work-In-Progress" or WIP for short.
-</p>
-
-
-<h2> 4. DRAFT status </h2>
-
-<p>
-4.1
-On completion, a document moves to DRAFT status.
-</p>
-
-<p>
-4.2
-A DRAFT is a policy-in-effect for the Community and is
-to be distributed and treated as such.
-</p>
-
-<p>
-4.3
-As far as the Community is concerned, the DRAFT is policy.
-Challenges and concerns can be addressed to the policy group,
-and policy group discussions on a DRAFT
-may be presented in Dispute Resolution.
-</p>
-
-<p>
-4.4
-Revisions of DRAFTs
-must be treated as decisions on the policy group.
-</p>
-
-<p>
-4.5
-The period of the DRAFT status is announced widely,
-which should be at least a month and no longer than a year.
-</p>
-
-<p>
-4.6
-During the period of DRAFT,
-CAcert Inc. retains a veto over 
-policies that effect the running of CAcert Inc.
-</p>
-
-
-<h2> 5. POLICY status </h2>
-<p>
-5.1
-After DRAFT period has elapsed with no revision beyond
-minor and editorial changes,
-there should be a decision
-to move the document from
-DRAFT to POLICY status.
-</p>
-
-<p>
-5.2
-Once POLICY, the Community may only challenge the document
-in Dispute Resolution.
-</p>
-
-<p>
-5.3
-Policy group may propose changes to a POLICY document
-in order to update it.  When changes move to DRAFT status,
-they may be included in the POLICY document,
-but must be clearly indicated within as DRAFT not POLICY.
-</p>
-
-<h2> 6. Open Process </h2>
-
-<p>
-6.1
-All policy discussions and documents should be open
-processes.  There should be a fair chance for
-the Community
-to have their views heard.
-Rough Consensus is the working metric.
-</p>
-
-<p>
-6.2
-Contributions to
-formally controlled documents such as Policies
-are transferred fully to CAcert Inc.
-Copyrights
-and similar intellectual property rights
-required to incorporate the Contribution
-are either transferred to CAcert Inc, or,
-are issued and contributed under free,
-open, non-restrictive,
-irrevocable, exclusive,
-and clear licence to CAcert Inc.
-In all cases, CAcert Inc licenses the
-contributions back to the community
-under an open licence.
-</p>
-
-<p>
-6.3
-Contributors declare any conflicts of interest.
-</p>
-
-<p>
-6.4
-Policies should be issued under free, open,
-non-restrictive,
-irrevocable, non-exclusive,
-and clear licence by CAcert, Inc.
-</p>
-
-<p>
-6.5
-Mailing lists should be archived,
-and important meetings should be minuted.
-</p>
-
-<h2> 7. Disputes. </h2>
-
-<p>
-7.1
-Any questions not resolved by these rules
-may be voted on in the policy group, or
-may be dealt with in Dispute Resolution.
-</p>
-
-<p>
-7.2
-The Policy Officer may decide a tight vote in a minor matter only.
-Failure of Rough Consensus may be declared by
-dissenting members.
-</p>
-
-<p>
-7.3
-Matters unresolved refer back
-to further group discussion.
-</p>
-
-<p>
-7.4
-The external avenue for disputes is to file a dispute
-according to CAcert's
-<a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">
-Dispute Resolution Policy</a>
-DRP => COD7.
-</p>
-
-</body>
-</html>
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: PolicyOnPolicy.html');
+exit();
\ No newline at end of file
diff --git a/www/policy/PrivacyPolicy.html b/www/policy/PrivacyPolicy.html
index 8aa0837..a39162f 100644
--- a/www/policy/PrivacyPolicy.html
+++ b/www/policy/PrivacyPolicy.html
@@ -1,53 +1,51 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-
+<!DOCTYPE html>
 <html>
-<head><title>Privacy Policy</title></head>
+<head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" lang="en">
+    <style>
+        .r {
+            text-align : right;
+        }
+    </style>
+    <title>Privacy Policy</title>
+</head>
 <body>
 
-<table width="100%">
+<table style="width: 100%;">
 
 <tr>
-<td> PP </td>
-<td>&nbsp;</td>
-<td width="20%"> &nbsp; </td>
-</tr>
-
-<tr>
-<td> POLICY&nbsp;<a href="http://wiki.cacert.org/wiki/PolicyDecisions">m20060629</a> </td>
-<td> &nbsp; </td>
 <td>
-  20060629
+Name: PP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD5</a><br />
+Status: POLICY <a style="color: steelblue" href="https://wiki.cacert.org/PolicyDecisions#m20060629">m20060629</a> <br />
+Changes: 20060629<br />
+Editor: <br />
+</td>
+<td class="r">
+  <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-policy.png" alt="PP Status - POLICY" height="31" width="88" style="border-style: none;" /></a>
 </td>
 </tr>
-
-<tr>
-<td> COD5 </td>
-<td>&nbsp;</td>
-<td>&nbsp;</td>
-</tr>
-
-
-<tr>
-<td>&nbsp;</td>
-<td > <b>Privacy&nbsp;Policy</b> </td>
-<td>&nbsp;</td>
-</tr>
-
 </table>
 
-<h2> 0. Preliminaries </h2>
+
+<p><br /><br /></p>
+
+
+
+<h1>Privacy&nbsp;Policy</h1>
+
+<h2 id="s0"> 0. Preliminaries </h2>
 <p>
     This policy discloses what information we gather about you when you visit any of our Web site, and when you issue or use our certificates. It describes how we use that information and how you can control it.
 </p>
 
 
 
-<h2>1. Website information</h2>
+<h2 id="s1">1. Website information</h2>
 <p>
 We collect two kinds of information about website users: 1) data that users volunteer by signing up to our website or when you send us an email via our contact form; and 2) aggregated tracking data we collect when users interact with our site.
 </p>
 
-<h2>2. Personal information</h2>
+<h2 id="s2">2. Personal information</h2>
 <p>
 When you post to the contact form, you must provide your name and email address. When you sign up to the website, you must provide your name, email address, date of birth and some lost pass phrase question and answers.
 </p>
@@ -55,12 +53,12 @@ When you post to the contact form, you must provide your name and email address.
 We only share your information with any other organisation when so instructed by a CAcert arbitrator.
 </p>
 
-<h2>3. Aggregated tracking information</h2>
+<h2 id="s3">3. Aggregated tracking information</h2>
 <p>
 We analyse visitors' use of our sites by tracking information such as page views, traffic flow, search terms, and click through. We use this information to improve our sites. We also share this anonymous traffic and demographic information in aggregate form with advertisers and other business partners. We do not share any information with advertisers that can identify an individual user.
 </p>
 
-<h2>4. Cookies</h2>
+<h2 id="s4">4. Cookies</h2>
 <p>
 Some of our advertisers use a third-party ad server to display ads. These ads may contain cookies. The ad server receives these cookies, and we don't have access to them.
 </p>
@@ -68,33 +66,33 @@ Some of our advertisers use a third-party ad server to display ads. These ads ma
 We don't use cookies to store personal information, we do use sessions, and if cookies are enabled, the session will be stored in a cookie, and we do not look for cookies, apart from the session id. However if cookies are disabled then no information will be stored on or looked for on your computer.
 </p>
 
-<h2>5. Notification of changes</h2>
+<h2 id="s5">5. Notification of changes</h2>
 <p>
 If we change our Privacy Policy, we will post those changes on www.CAcert.org. If we decide to use personally identifiable information in a manner different from that stated at the time it was collected, we will notify users via email. Users will be able to opt out of any new use of their personal information.
 </p>
 
-<h2>6. How to update, correct, or delete your information</h2>
+<h2 id="s6">6. How to update, correct, or delete your information</h2>
 <p>
 You are able to update, add and remove your information at any time via our web interface, log into the 'My Account' and then click on the 'My Details' section, and then click the relevant link
 </p>
 
-<h2>7. Privacy of certificates</h2>
+<h2 id="s7">7. Privacy of certificates</h2>
 <p>
 CAcert does not automatically publish the certificates through a directory service or the website to other people than the user who requested the certificate. In the future, the user might be able to opt-in for publication of the certificates through a directory server by CAcert.
 </p>
 
-<h2>8. Privacy of user data</h2>
+<h2 id="s8">8. Privacy of user data</h2>
 <p>
 CAcert Assurers can see the name, birthday and the number of points by looking up the correct email address. No other person related data is published by CAcert.
 </p>
 
-<h2>9. Exceptions</h2>
+<h2 id="s9">9. Exceptions</h2>
 <p>
 A CAcert arbitrator may override this policy in a dispute.
 To obtain access to confidential data, a dispute has to be filed.
 </p>
 
-<h2>10. Legal mandates</h2>
+<h2 id="s10">10. Legal mandates</h2>
 <p>
 CAcert adopts the Australian privacy regulations.
 Please see <a href='http://www.privacy.gov.au/'>http://www.privacy.gov.au/</a> for further details.
@@ -104,11 +102,11 @@ Governmental warrants and civil supoenas will be processed through the dispute r
 
 <p>If you need to contact us in writing, address your mail to:</p>
 <p>
-CAcert Inc.<br>
-PO Box 66 <br>
-Oatley NSW 2223<br>
+CAcert Inc.<br />
+PO Box 66 <br />
+Oatley NSW 2223<br />
 Australia
 </p>
-
+<p><a href="http://validator.w3.org/check?uri=referer"><img src="images/valid-html50-blue.png" alt="Valid HTML 5" height="31" width="88"></a></p>
 </body>
 </html>
diff --git a/www/policy/PrivacyPolicy.php b/www/policy/PrivacyPolicy.php
new file mode 100644
index 0000000..77a07c1
--- /dev/null
+++ b/www/policy/PrivacyPolicy.php
@@ -0,0 +1,4 @@
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: PrivacyPolicy.html');
+exit();
\ No newline at end of file
diff --git a/www/policy/RootDistributionLicense.html b/www/policy/RootDistributionLicense.html
new file mode 100644
index 0000000..5a8c5a9
--- /dev/null
+++ b/www/policy/RootDistributionLicense.html
@@ -0,0 +1,177 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title> CAcert - Root Distribution License </title>
+<style type="text/css">
+<!--
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+</head>
+<body>
+<div class="comment">
+<table width="100%">
+<tbody>
+<tr rowspan="2">
+<td>
+Name: RDL <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD14</a>
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+Editor: Mark Lipscombe
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+		<img src="images/cacert-policy.png" alt="RDL Status - POLICY" style="border-style: none;" height="31" width="88">
+	</a>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+<p>
+<br>
+
+<br>
+</p>
+
+<table border="1">
+<tbody>
+<tr>
+<td>
+
+<h1> Root Distribution License </h1>
+
+<h2 id="g0.1">1. Terms </h2>
+
+<p>
+"CAcert Inc" means CAcert Incorporated, a non-profit association incorporated in New South Wales, Australia.
+<br>
+"CAcert Community Agreement" means the agreement entered into by each person wishing to RELY.
+<br>
+"Member" means a natural or legal person who has agreed to the CAcert Community Agreement.
+<br>
+"Certificate" means any certificate or like device to which CAcert Inc's digital signature has been affixed.
+<br>
+"CAcert Root Certificates" means any certificate issued by CAcert Inc to
+ itself for the purposes of signing further CAcert Roots or for signing
+certificates of Members.
+<br>
+"RELY" means the human act in taking on a risk or liability on the basis
+ of the claim(s) bound within a certificate issued by CAcert.
+<br>
+"Embedded" means a certificate that is contained within a software
+application or hardware system, when and only when, that software
+application or system is distributed in binary form only.
+<br>
+</p>
+
+<h2 id="g0.2">2. Copyright </h2>
+
+<p>
+CAcert Root Certificates are Copyright CAcert Incorporated. All rights reserved.
+</p>
+
+<h2 id="g0.3">3. License </h2>
+
+<p>
+You may copy and distribute CAcert Root Certificates only in accordance with this license.
+</p>
+
+<p>
+CAcert Inc grants you a free, non-exclusive license to copy and
+distribute CAcert Root Certificates in any medium, with or without
+modification, provided that the following conditions are met:
+</p>
+
+<ul>
+<li>
+    Redistributions of Embedded CAcert Root Certificates must take
+reasonable steps to inform the recipient of the disclaimer in section 4
+or reproduce this license and copyright notice in full in the
+documentation provided with the distribution.
+  </li>
+<li>
+    Redistributions in all other forms must reproduce this license and copyright notice in full.
+</li>
+</ul>
+
+<h2 id="g0.4">4. Disclaimer </h2>
+
+<p>
+THE CACERT ROOT CERTIFICATES ARE PROVIDED "AS IS" AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED TO THE MAXIMUM EXTENT PERMITTED BY LAW. IN NO EVENT SHALL
+CACERT INC, ITS MEMBERS, AGENTS, SUBSIDIARIES OR RELATED PARTIES BE
+LIABLE TO THE LICENSEE OR ANY THIRD PARTY FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ THESE CERTIFICATES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+IN ANY EVENT, CACERT'S LIABILITY SHALL NOT EXCEED $1,000.00 AUSTRALIAN
+DOLLARS.
+</p>
+
+<p>
+THIS LICENSE SPECIFICALLY DOES NOT PERMIT YOU TO RELY UPON ANY
+CERTIFICATES ISSUED BY CACERT INC. IF YOU WISH TO RELY ON CERTIFICATES
+ISSUED BY CACERT INC, YOU MUST ENTER INTO A SEPARATE AGREEMENT WITH
+CACERT INC.
+</p>
+
+<h2 id="g0.5">5. Statutory Rights </h2>
+
+<p>
+Nothing in this license affects any statutory rights that cannot be
+waived or limited by contract. In the event that any provision of this
+license is held to be invalid or unenforceable, the remaining provisions
+ of this license remain in full force and effect.
+</p>
+
+</td>
+</tr>
+</tbody>
+</table>
+
+<div class="comment">
+<h2 id="g0.6">Alternatives </h2>
+
+<p>
+If you find the terms of the above
+Root Distribution License
+difficult or inadequate for your purposes, you may wish to:
+</p>
+
+<ul>
+<li>
+    Enter into the CAcert Community Agreement by
+    <a href="https://www.cacert.org/index.php?id=1">
+    registering as a Member</a>.
+    This is free.
+  </li>
+<li>
+    Delete CAcert Root Certificates from your software.
+    Your software documentation should give
+    directions and assistance for this.
+</li>
+</ul>
+
+<p>
+These alternatives are outside the above
+Root Distribution License
+and do not incorporate.
+</p>
+</div>
+
+
+</body>
+</html>
diff --git a/www/policy/RootDistributionLicense.php b/www/policy/RootDistributionLicense.php
index 01d68fc..c807aeb 100644
--- a/www/policy/RootDistributionLicense.php
+++ b/www/policy/RootDistributionLicense.php
@@ -1,126 +1,4 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
-	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
- <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" />
- <title> CAcert - Root Distribution License - DRAFT </title>
-<style type="text/css">  <!-- only for WIP -->
-<!--
-.change {
-        color : blue;
-        font-weight: bold;
-}
-.comment {
-        color : steelblue;
-}
--->
-</style>
-
-</head>
-<body>
-
-<div class="comment">
-<table width="100%">
-
-<tr>
-<td>
-Name: RDL <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD14</a><br />
-Status: DRAFT <a style="color: steelblue" href="https://wiki.cacert.org/PolicyDecisions#p20100710">p20100710</a> <br />
-Editor: Mark Lipscombe<br />
-</td>
-<td align="right">
-  <a href="//www.cacert.org/policy/PolicyOnPolicy.php"><img src="/images/cacert-draft.png" alt="RDL Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
-
-</td>
-</tr>
-</table>
-</div>
-
-<p><br /><br /></p>
-
-<table border="1"><tr><td>
-
-<h1> Root Distribution License </h1>
-
-<h2 id="s1"> 1. Terms </h2>
-
-<p>
-"CAcert Inc" means CAcert Incorporated, a non-profit association incorporated in New South Wales, Australia.<br />
-"CAcert Community Agreement" means the agreement entered into by each person wishing to RELY. <br />
-"Member" means a natural or legal person who has agreed to the CAcert Community Agreement.<br />
-"Certificate" means any certificate or like device to which CAcert Inc's digital signature has been affixed.<br />
-"CAcert Root Certificates" means any certificate issued by CAcert Inc to itself for the purposes of signing further CAcert Roots or for signing certificates of Members.<br />
-"RELY" means the human act in taking on a risk or liability on the basis of the claim(s) bound within a certificate issued by CAcert.<br />
-"Embedded" means a certificate that is contained within a software application or hardware system, when and only when, that software application or system is distributed in binary form only.<br />
-</p>
-
-<h2 id="s2"> 2. Copyright </h2>
-
-<p>
-CAcert Root Certificates are Copyright CAcert Incorporated. All rights reserved.
-</p>
-
-<h2 id="s3"> 3. License </h2>
-
-<p>
-You may copy and distribute CAcert Root Certificates only in accordance with this license.
-</p>
-
-<p>
-CAcert Inc grants you a free, non-exclusive license to copy and distribute CAcert Root Certificates in any medium, with or without modification, provided that the following conditions are met:
-</p>
-
-<ul><li>
-    Redistributions of Embedded CAcert Root Certificates must take reasonable steps to inform the recipient of the disclaimer in section 4 or reproduce this license and copyright notice in full in the documentation provided with the distribution.
-  </li><li>
-    Redistributions in all other forms must reproduce this license and copyright notice in full.
-</li></ul>
-
-<h2 id="s4"> 4. Disclaimer </h2>
-
-<p>
-THE CACERT ROOT CERTIFICATES ARE PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED TO THE MAXIMUM EXTENT PERMITTED BY LAW. IN NO EVENT SHALL CACERT INC, ITS MEMBERS, AGENTS, SUBSIDIARIES OR RELATED PARTIES BE LIABLE TO THE LICENSEE OR ANY THIRD PARTY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THESE CERTIFICATES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. IN ANY EVENT, CACERT'S LIABILITY SHALL NOT EXCEED $1,000.00 AUSTRALIAN DOLLARS.
-</p>
-
-<p>
-THIS LICENSE SPECIFICALLY DOES NOT PERMIT YOU TO RELY UPON ANY CERTIFICATES ISSUED BY CACERT INC. IF YOU WISH TO RELY ON CERTIFICATES ISSUED BY CACERT INC, YOU MUST ENTER INTO A SEPARATE AGREEMENT WITH CACERT INC.
-</p>
-
-<h2 id="s5"> 5. Statutory Rights </h2>
-
-<p>
-Nothing in this license affects any statutory rights that cannot be waived or limited by contract. In the event that any provision of this license is held to be invalid or unenforceable, the remaining provisions of this license remain in full force and effect. 
-</p>
-
-</td></tr></table>
-
-<div class="comment">
-<h2> Alternatives </h2>
-
-<p>
-If you find the terms of the above
-Root Distribution License
-difficult or inadequate for your purposes, you may wish to:
-</p>
-
-<ul><li>
-    Enter into the CAcert Community Agreement by
-    <a href="https://www.cacert.org/index.php?id=1">
-    registering as a Member</a>.
-    This is free.
-  </li><li>
-    Delete CAcert Root Certificates from your software.
-    Your software documentation should give
-    directions and assistance for this.
-</li></ul>
-
-<p>
-These alternatives are outside the above
-Root Distribution License
-and do not incorporate.
-</p>
-</div>
-
-
-</body>
-</html>
+<?php
+header('HTTP/1.0 301 Moved Permanently');
+header('Location: RootDistributionLicense.html');
+exit();
\ No newline at end of file
diff --git a/www/policy/SecurityPolicy.html b/www/policy/SecurityPolicy.html
new file mode 100644
index 0000000..f85a35d
--- /dev/null
+++ b/www/policy/SecurityPolicy.html
@@ -0,0 +1,1308 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" lang="en">
+<title>Security Policy</title>
+<style type="text/css">
+<!--
+body {
+    font-family : verdana, helvetica, arial, sans-serif;
+}
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+</head>
+<body lang="en-GB">
+<h1>Security Policy for CAcert Systems</h1>
+<div class="comment">
+<table width="100%">
+<tbody>
+<tr>
+<td rowspan="2">
+ Name: SP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD8</a>
+<br>
+  Creation date: 20090216
+<br>
+  Editor: iang
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a>
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+		<img src="images/cacert-policy.png" alt="SP Status - POLICY" style="border-style: none;" height="31" width="88">
+	</a>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+<h2 id="s1">1. INTRODUCTION</h2>
+
+<h3 id="s1.1">1.1. Motivation and Scope </h3>
+<p>
+This Security Policy sets out the policy
+for the secure operation of the CAcert critical computer systems.
+These systems include:
+</p>
+<ol><li>
+     Physical hardware mounting the logical services
+   </li><li>
+     Webserver + database (core server(s))
+   </li><li>
+     Signing service (signing server)
+   </li><li>
+     Source code (changes and patches)
+</li></ol>
+<p>
+The Committee of CAcert, Inc. (hereafter, "Board")
+may add additional components into the Security Manual.
+</p>
+
+<h4 id="s1.1.1">1.1.1. Covered Personnel </h4>
+
+<p>
+Critical roles are covered.
+These roles are defined as:
+</p>
+
+<ul><li>
+      Access Engineer
+    </li><li>
+      Systems Administrator
+    </li><li>
+      Support Engineer
+    </li><li>
+      Software Assessor
+</li></ul>
+
+<h4 id="s1.1.2">1.1.2. Out of Scope </h4>
+
+<p>
+Non-critical systems are not covered by this manual,
+but may be guided by it, and impacted where they are
+found within the security context.
+Architecture is out of scope, see CPS#6.2.
+</p>
+
+<h3 id="s1.2">1.2. Principles </h3>
+<p>
+Important principles of this Security Policy are:
+</p>
+
+<ul><li>
+      <i>dual control</i> -- at least two individuals must control a task
+    </li><li>
+      <i>four eyes</i> -- at least two individuals must participate in a task,
+      one to execute and one to observe.
+    </li><li>
+      <i>redundancy</i> -- no single individual is the only one authorized
+      to perform a task.
+    </li><li>
+      <i>escrow</i> -- where critical information (backups, passphrases)
+      is kept with other parties
+    </li><li>
+      <i>logging</i> -- where events are recorded in a file
+    </li><li>
+      <i>separation of concerns</i> -- when a core task is split between
+      two people from different areas
+    </li><li>
+      <i>Audit</i> -- where external reviewers do checks on practices and policies
+    </li><li>
+      <i>Authority</i> -- every action is authorised by either a policy or by the Arbitrator.
+</li></ul>
+
+<p>
+Each task or asset is covered by a variety of protections
+deriving from the above principles.
+</p>
+
+<h3 id="s1.3">1.3. Definition of Terms</h3>
+<dl>
+
+<dt><i>Access Engineer</i> </dt>
+<dd>
+    A Member who manages the critical hardware,
+    including maintenance, access control and physical security.
+    See &sect;1.1.
+</dd>
+
+<dt><i>Software Assessor</i> </dt>
+<dd>
+    A Member who reviews patches for security and workability,
+    signs-off on them, and incorporates them into the repository.
+    See &sect;7.2.
+</dd>
+
+<dt><i>Support Engineer</i> </dt>
+<dd>
+    A Member who mans the support list,
+    and has access to restricted
+    data through the online interface.
+    See &sect;8.
+</dd>
+
+<dt><i>Systems Administrator</i> </dt>
+<dd>
+    A Member who manages a critical system, and has access
+    to security-sensitive functions or data.
+</dd>
+
+</dl>
+
+<h3 id="s1.4">1.4. Documents and Version control</h3>
+
+<h4 id="s1.4.1">1.4.1. The Security Policy Document </h4>
+<p>
+This Security Policy is part of the Configuration-Control Specification
+for audit purposes (DRC-A.1).
+It is under the control of Policy on Policy for version purposes.
+</p>
+
+<p>
+This policy document says what is done, rather than how to do it.
+<b>Some sections are empty, which means "refer to the Manual."</b>
+</p>
+
+<h4 id="s1.4.2">1.4.2. The Security Manual (Practices) Document </h4>
+
+<p>
+This Policy explicitly defers detailed security practices to the
+<a href="http://wiki.cacert.org/SecurityManual">Security Manual</a>
+("SM").
+The SM says how things are done.
+As practices are things that vary from time to time,
+including between each event of practice,
+the SM is under the direct control of the
+applicable team leaders.
+It is located and version-controlled on the CAcert wiki.
+</p>
+
+<p>
+Section Headings are the same in both documents.
+Where Sections are empty in one document,
+they are expected to be documented in the other.
+"Document further in Security Manual" can be implied from
+any section heading in the Policy.
+</p>
+
+<h4 id="s1.4.3">1.4.3. The Security Procedures </h4>
+
+<p>
+The team leaders may from time to time
+explicitly defer single, cohesive components of the
+security practices into separate procedures documents.
+Each procedure should be managed in a wiki page under
+their control, probably at
+<a href="http://wiki.cacert.org/SystemAdministration/Procedures">
+SystemAdministration/Procedures</a>.
+Each procedure must be referenced explicitly in the Security Manual.
+</p>
+
+<h2 id="s2">2. PHYSICAL SECURITY</h2>
+
+<h3 id="s2.1">2.1. Facility </h3>
+
+<p>
+CAcert shall host critical servers in a highly secure facility.
+There shall be independent verification of the physical and
+access security.
+</p>
+
+<h3 id="s2.2">2.2. Physical Assets </h3>
+
+<h4 id="s2.2.1">2.2.1. Computers </h4>
+<p>
+Computers shall be inventoried before being put into service.
+Inventory list shall be available to all
+Access Engineers and all Systems Administrators.
+List must be subject to change control.
+</p>
+
+<p>
+Each unit shall be distinctly and uniquely identified on all visible sides.
+Machines shall be housed in secured facilities (cages and/or locked racks).
+</p>
+
+<h4 id="s2.2.1.1">2.2.1.1 Acquisition </h4>
+<p>
+Equipment for critical purposes should be acquired
+in a way to minimise pre-acquisition security risks.
+</p>
+
+<h4 id="s2.2.2">2.2.2. Service </h4>
+
+<p>
+Equipment that is subject to a service security risk
+must be retired if service is required.
+See also &sect;2.2.3.3.
+</p>
+
+<h4 id="s2.2.3">2.2.3. Media </h4>
+
+<h4 id="s2.2.3.1">2.2.3.1 Provisioning </h4>
+
+<p>
+Storage media (disk drives, tapes, removable media)
+are inventoried upon acquisition and tracked in their use.
+</p>
+
+<p>
+New storage media (whether disk or removable) shall be
+securely erased and reformatted before use.
+</p>
+
+<h4 id="s2.2.3.2">2.2.3.2 Storage </h4>
+
+<p>
+Removable media shall be securely stored at all times,
+including when not in use.
+Drives that are kept for reuse are
+erased securely before storage.
+Reuse can only be within critical systems.
+</p>
+
+<p>
+When there is a change to status of media,
+a report is made to the log specifying the new status.
+</p>
+
+<h4 id="s2.2.3.3">2.2.3.3 Retirement </h4>
+
+<p>
+Storage media that is exposed to critical data and is
+to be retired from service shall be destroyed or otherwise secured.
+The following steps are to be taken:
+</p>
+
+<ol><li>
+    The media is securely destroyed, <b>or</b>
+  </li><li>
+    the media is securely erased,
+    and stored securely.
+</li></ol>
+
+<p>
+Records of secure erasure and method of final disposal
+shall be tracked in the asset inventory.
+Where critical data is involved,
+two Systems Administrators must sign-off on each step.
+</p>
+
+<h3 id="s2.3">2.3. Physical Access </h3>
+
+<p>
+In accordance with the principle of dual control,
+at least two persons authorized for access must
+be on-site at the same time for physical access to be granted.
+</p>
+
+<h4 id="s2.3.1">2.3.1. Access Authorisation </h4>
+
+<p>
+Access to physical equipment must be authorised.
+</p>
+
+<h4 id="s2.3.2">2.3.2. Access Profiles </h4>
+
+<p>
+The Security Manual must present the different access profiles.
+At least one Access Engineer must control access in all cases.
+At least one Systems Administrator will be present for
+logical access.
+Only the most basic and safest of accesses should be done with
+one Systems Administrator present.
+</p>
+
+<p>
+There is no inherent authorisation to access the data.
+Systems Administrators
+are authorised to access
+the raw data under the control of this policy.
+All others must not access the raw data.
+All are responsible for protecting the data
+from access by those not authorised.
+</p>
+
+<h4 id="s2.3.3">2.3.3. Access Logging </h4>
+
+<p>
+All physical accesses are logged and reported to all.
+</p>
+
+<h4 id="s2.3.4">2.3.4. Emergency Access </h4>
+
+<p>
+There must not be a procedure for emergency access.
+If, in the judgement of the Systems Administrator,
+emergency access is required and gained,
+in order to avoid a greater harm,
+independent authorisation before the
+Arbitrator must be sought as soon as possible.
+See DRP.
+</p>
+
+<h4 id="s2.3.5">2.3.5. Physical Security codes &amp; devices </h4>
+
+<p>
+All personel who are in possession of physical security
+codes and devices (keys) are to be authorised and documented.
+</p>
+
+
+<h2 id="s3">3. LOGICAL SECURITY</h2>
+
+<h3 id="s3.1">3.1. Network </h3>
+<h4 id="s3.1.1">3.1.1. Infrastructure </h4>
+
+<p>
+Current and complete diagrams of the physical and logical
+CAcert network infrastructure shall be maintained by
+Systems Administration team leader.
+These diagrams should include cabling information,
+physical port configuration details,
+expected/allowed data flow directions,
+and any further pertinent information,
+as applicable.
+Diagrams should be revision controlled,
+and must be updated when any change is made.
+</p>
+
+<h5 id="s3.1.1.1"> 3.1.1.1. External connectivity </h5>
+
+<p>
+Only such services as are required for normal operation
+should be visible externally;
+systems and servers which do not require access
+to the Internet for their normal operation
+must not be granted that access.
+If such access becomes temporarily necessary for an
+authorized administrative task,
+such access may be granted under the procedures of the SM
+and must be reported and logged.
+</p>
+
+<h5 id="s3.1.1.2"> 3.1.1.2. Internal connectivity </h5>
+
+<p>
+System and server connections internal to the CAcert infrastructure should be kept to the minimum required for routine operations. Any new connectivity desired must be requested and approved by System administration team leader and then must be reflected in the appropriate infrastructure diagram(s).
+</p>
+
+
+<h4 id="s3.1.2">3.1.2. Operating Configuration </h4>
+
+<h5 id="s3.1.2.1"> 3.1.2.1. Ingress </h5>
+
+<p>
+All ports on which incoming traffic is expected shall be documented; traffic to other ports must be blocked. Unexpected traffic must be logged as an exception.
+</p>
+
+<h5 id="s3.1.2.2"> 3.1.2.2. Egress </h5>
+
+<p>
+All outbound traffic that is initiated shall be documented; traffic to other destinations must be blocked. Unexpected traffic must be logged as an exception.
+</p>
+
+<h4 id="s3.1.3">3.1.3. Intrusion detection </h4>
+
+<p>
+Logs should be examined regularly (by manual or automatic means) for unusual patterns and/or traffic; anomalies should be investigated as they are discovered and should be reported to appropriate personnel in near-real-time (e.g. text message, email) and investigated as soon as possible. Suspicious activity which may indicate an actual system intrusion or compromise should trigger the incident response protocol described in section 5.1.
+</p>
+
+<h3 id="s3.2">3.2. Operating System </h3>
+
+<p>
+Any operating system used for critical server machines must be available under an OSI-approved open source software license.
+</p>
+
+<h4 id="s3.2.1"> 3.2.1. Disk Encryption </h4>
+
+<p>
+Any operating system used for critical server machines must support software full-disk or disk volume encryption, and this encryption option must be enabled for all relevant disks/volumes when the operating system is first installed on the machine.
+</p>
+
+
+<h4 id="s3.2.2"> 3.2.2. Operating configuration </h4>
+
+<p>
+Servers must enable only the operating system functions required to support the necessary services. Options and packages chosen at OS install shall be documented, and newly-installed systems must be inspected to ensure that only required services are active, and their functionality is limited through configuration options. Any required application software must follow similar techniques to ensure minimal exposure footprint.
+</p>
+
+<p>
+Documentation for installing and configuring servers with the appropriate software packages and configurations will be maintained by the System Administrators.
+</p>
+
+
+<h4 id="s3.2.3"> 3.2.3. Patching </h4>
+
+<p>
+Software used on production servers must be kept current with respect to patches affecting software security. Patch application
+must be approved by the Systems Administration team leader, fully documented in the logs and reported by email to the Systems Administration list on completion (see &sect;4.2).
+</p>
+
+<h5 id="s3.2.3.1"> 3.2.3.1. “emergency” patching </h5>
+
+<p>
+Application of a patch is deemed an <i>emergency</i>
+when a remote exploit for a weakness in the particular piece
+of software has become known
+(on servers allowing direct local user access,
+an emergent local exploit may also be deemed to be an emergency).
+Application of patches in this case may occur as soon as possible,
+bypassing the normal configuration-change process.
+The Systems Administration team leader must either approve the patch
+or instruct remedial action, and refer the case to dispute resolution.
+</p>
+
+<p>
+<b> <!-- this comment left in bold deliberately -->
+Declaration of an emergency patching situation should not occur with any regularity.
+</b>
+Emergency patch events must be documented
+within the regular summaries
+by the team leader to Board
+independent of filed disputes.
+</p>
+
+<h3 id="s3.3"> 3.3. Application </h3>
+
+<p>
+Requests for ad hoc queries over the application database for business
+or similar purposes must be approved by the Arbitrator.
+</p>
+
+<h3 id="s3.4"> 3.4. Access control </h3>
+
+<p>
+All access to critical data and services shall be
+controlled and logged.
+</p>
+
+<h4 id="s3.4.1"> 3.4.1. Application Access </h4>
+
+<p>
+General access for Members shall be provided via
+a dedicated application.
+General features are made available according to
+Assurance Points and similar methods controlled in
+the software system.
+</p>
+
+<h4 id="s3.4.2"> 3.4.2. Special Authorisation </h4>
+
+<p>
+Additional or special access is granted according to the
+authorisations on the below access control lists
+(see &sect;1.1.1):
+</p>
+
+<table style="text-align: center" border="1"> <tr>
+  <td>List Name</td>
+  <td>Who</td>
+  <td>Purpose of access</td>
+  <td>Relationship</td>
+  <td> Manager </td>
+ </tr><tr>
+  <td>Physical Control List</td>
+  <td>Access Engineers</td>
+  <td>control of access by personnel to hardware</td>
+  <td>exclusive of all other roles </td>
+  <td>Access team leader</td>
+ </tr><tr>
+  <td>Physical Access List</td>
+  <td>Systems Administrators</td>
+  <td>hardware-level for installation and recovery</td>
+  <td>exclusive with Access Engineers and Software Assessors</td>
+  <td>Systems Administration team leader </td>
+ </tr><tr>
+  <td>SSH Access List</td>
+  <td>Systems Administrators </td>
+  <td>Unix / account / shell level</td>
+  <td> includes by default all on Physical Access List </td>
+  <td>Systems Administration team leader</td>
+ </tr><tr>
+  <td>Repository Access List</td>
+  <td>Software Assessors</td>
+  <td>change the source code repository </td>
+  <td>exclusive with Access Engineers and Systems Administrators</td>
+  <td>Software Assessment team leader</td>
+ </tr><tr>
+  <td>Support Access List</td>
+  <td>Support Engineer</td>
+  <td>support features in the web application</td>
+  <td> exclusive with Access Engineers and Systems Administrators </td>
+  <td>Support team leader</td>
+</tr></table>
+
+<p>
+All changes of personnel to the above lists are
+subject to Board approval.
+</p>
+
+<h4 id="s3.4.3"> 3.4.3. Authentication </h4>
+
+<p>
+Strong methods of authentication shall be used
+wherever possible.
+All authentication schemes must be documented.
+</p>
+
+<h4 id="s3.4.4"> 3.4.4. Removing access </h4>
+
+<p>
+Follow-up actions to termination must be documented.
+See &sect;9.1.7.
+</p>
+
+
+
+
+<h2 id="s4">4. OPERATIONAL SECURITY </h2>
+
+<h3 id="s4.1">4.1. System administration </h3>
+
+<p>
+Primary Systems Administration tasks
+shall be conducted under four eyes principle.
+These shall include backup performance verification,
+software patch application,
+account creation and deletion,
+and hardware maintenance.
+</p>
+
+<h4 id="s4.1.1">4.1.1. Privileged accounts and passphrases </h4>
+<p>
+Access to privileged accounts
+(root and user via SSH or console)
+must be strictly controlled.
+Passphrases and SSH private keys used for entering into the systems
+will be kept private
+to CAcert sysadmins
+in all cases.
+</p>
+
+<h5 id="s4.1.1.1">4.1.1.1. Authorized users </h5>
+<p>
+Only Systems Administrators
+designated on the Access Lists
+in &sect;3.4.2 are authorized to access accounts.
+Systems Administration team leader may temporarily permit Software
+Assessors access to the application via SSH in order to do advanced
+debugging, or as specifically directed by the Arbitrator.
+</p>
+
+<p>
+</p>
+
+<h5 id="s4.1.1.2">4.1.1.2. Access to Systems</h5>
+<p>
+All access is secured, logged and monitored.
+</p>
+
+<h5 id="s4.1.1.3">4.1.1.3. Changing </h5>
+
+<p>
+The procedure for changing passphrases and SSH keys shall be documented.
+</p>
+
+<h4 id="s4.1.2">4.1.2. Required staff response time </h4>
+<p>
+Response times should be documented for Disaster Recovery planning.  See &sect;6.
+</p>
+
+<h4 id="s4.1.3">4.1.3. Change management procedures </h4>
+<p>
+All changes made to system configuration must be recorded
+and reported in regular summaries to the Board of CAcert.
+</p>
+
+<h4 id="s4.1.4">4.1.4. Outsourcing </h4>
+
+<h3 id="s4.2">4.2. Logging </h3>
+
+<h4 id="s4.2.1">4.2.1. Coverage </h4>
+
+<p>
+All sensitive events should be logged reliably.
+Logs should be deleted after an appropriate amount of time
+as documented in the Security Manual.
+</p>
+
+<h4 id="s4.2.2">4.2.2. Access and Security </h4>
+
+<p>
+Access to logs must be restricted.
+The security of the logs should be documented.
+The records retention should be documented.
+</p>
+
+<h4 id="s4.2.3">4.2.3. Automated logs </h4>
+<p>
+Logging should be automated,
+and use should be made of appropriate system-provided automated tools.
+Automated logs should be reviewed periodically;
+suspicious events should be flagged and investigated in a timely fashion.
+</p>
+
+<h4 id="s4.2.4">4.2.4. Operational (manual) logs </h4>
+<p>
+Configuration changes, no matter how small, must be logged.
+</p>
+
+<p>
+All physical visits must be logged and a
+report provided by the accessor and by
+the Access Engineer.
+</p>
+
+<h3 id="s4.3">4.3. Backup </h3>
+
+<p>
+The procedure for all backups must be documented,
+according to the following sub-headings.
+</p>
+
+<h4 id="s4.3.1">4.3.1. Type </h4>
+<p>
+Backups must be taken for operational
+and for disaster recovery purposes.
+Operational backups may be online and local.
+Disaster recovery backups must be offline and remote.
+</p>
+
+<h4 id="s4.3.2">4.3.2. Frequency </h4>
+
+<h4 id="s4.3.3">4.3.3. Storage </h4>
+<p>
+Backups must be protected to the same level as the critical systems themselves.
+Disaster recovery backups may be distributed.
+</p>
+
+<h4 id="s4.3.4">4.3.4. Retention period and Re-use </h4>
+<p>
+See &sect;2.2.3.
+</p>
+
+<h4 id="s4.3.5">4.3.5. Encryption </h4>
+<p>
+Backups must be encrypted and must only be transmitted via secured channels.
+Off-site backups must be dual-encrypted using divergent methods.
+</p>
+
+<h4 id="s4.3.6">4.3.6. Verifying Backups </h4>
+<p>
+Two CAcert System Administrators must be
+present for verification of a backup.
+Four eyes principle must be maintained when the key and backup are together.
+For any other purpose than verification of the success of the backup, see next.
+</p>
+
+<h4 id="s4.3.7">4.3.7. Key Management </h4>
+<p>
+The encryption keys must be stored securely by the
+CAcert Systems Administrators.
+Paper documentation must be stored with manual backups.
+</p>
+
+<h4 id="s4.3.8">4.3.8. Reading Backups </h4>
+<p>
+Conditions and procedures for examining the backups
+must be documented,
+and must be under Arbitrator control for purposes
+other than verification and recovery.
+</p>
+
+<h3 id="s4.4">4.4. Data retention </h3>
+
+<h4 id="s4.4.1">4.4.1. User data </h4>
+
+<p>
+Termination of user data is under direction of the Arbitrator.
+See CCA.
+</p>
+
+<h4 id="s4.4.2">4.4.2. System logs </h4>
+<p>
+See &sect;4.2.1.
+</p>
+
+<h4 id="s4.4.3">4.4.3. Incident reports </h4>
+<p>
+See &sect;5.6.
+</p>
+
+
+
+
+<h2 id="s5">5. INCIDENT RESPONSE</h2>
+
+<h3 id="s5.1">5.1. Incidents </h3>
+
+<h3 id="s5.2">5.2. Detection </h3>
+<p>
+The standard of monitoring, alerting and reporting must be documented.
+</p>
+
+<h3 id="s5.3">5.3. Immediate Action </h3>
+<h4 id="s5.3.1">5.3.1. Severity and Priority </h4>
+<p>
+On discovery of an incident,
+an initial assessment of severity and priority must be made.
+</p>
+
+<h4 id="s5.3.2">5.3.2. Communications </h4>
+<p>
+An initial report should be circulated.
+</p>
+
+<p>
+A communications forum should be established for direct
+support of high priority or high severity incidents.
+</p>
+
+<h4 id="s5.3.3">5.3.3. Escalation </h4>
+<p>
+A process of escalation should be established
+for oversight and management purposes,
+proportional to severity and priority.
+Oversight starts with four eyes and ends with the Arbitrator.
+Management starts with the team leader and ends with the Board.
+</p>
+
+<h3 id="s5.4">5.4. Investigation </h3>
+<p>
+Incidents must be investigated.
+The investigation must be documented.
+If the severity is high,
+evidence must be secured and escalated to Arbitration.
+</p>
+
+<h3 id="s5.5">5.5. Response </h3>
+
+<h3 id="s5.6">5.6. Report </h3>
+
+<p>
+Incident reports shall be be published.
+The Incident Report is written on closing the investigation.
+A full copy should be appended to the
+documentation of the investigation.
+Sensitive information may be pushed out into
+a restricted appendix of the report.
+The Systems Administration team leader is responsible
+for publication and maintenance.
+</p>
+
+<p>
+Incidents are not normally kept secret nor confidential,
+and progress information should be published as soon as
+possible.
+The knowledge of the existence of the event must not be kept
+secret, nor the manner and methods be kept confidential.
+See &sect;9.5.
+</p>
+
+<h2 id="s6">6. DISASTER RECOVERY</h2>
+
+<p>
+Disaster Recovery is the responsibility of the Board of CAcert Inc.
+</p>
+
+<h3 id="s6.1"> 6.1.  Business Processes </h3>
+<p>
+Board must develop and maintain documentation on Business Processes.
+From this list, Core Processes for business continuity / disaster recovery
+purposes must be identified.
+</p>
+
+<h3 id="s6.2"> 6.2.  Recovery Times </h3>
+<p>
+Board should identify standard process times for all processes,
+and must designate Maximum Acceptable Outages
+and Recovery Time Objectives for the Core Processes.
+</p>
+
+<h3 id="s6.3"> 6.3.  Plan </h3>
+<p>
+Board must have a basic plan to recover.
+</p>
+
+<h3 id="s6.4"> 6.4.  Key Persons List </h3>
+<p>
+Board must maintain a Key Persons List with all the
+contact information needed.
+See &sect;10.1.
+The list shall be accessible even if CAcert's
+infrastructure is not available.
+</p>
+
+
+
+<h2 id="s7">7. SOFTWARE ASSESSMENT</h2>
+
+<p>
+Software assessment team is responsible
+for the security and maintenance of the code.
+</p>
+
+<h3 id="s7.1"> 7.1.  Authority </h3>
+
+<p>
+The source code is under CCS.
+Additions to the team are
+subject to Board approval.
+See &sect;3.4.2.
+</p>
+
+<h3 id="s7.2"> 7.2.  Tasks </h3>
+<p>
+The primary tasks for Software Assessors are:
+</p>
+<ol><li>
+    Keep the code secure in its operation,
+  </li><li>
+    Fix security bugs, including incidents,
+  </li><li>
+    Audit, Verify and sign-off proposed patches,
+  </li><li>
+    Provide guidance for architecture,
+</li></ol>
+
+<p>
+Software assessment is not primarily tasked to write the code.
+In principle, anyone can submit code changes for approval.
+</p>
+
+<h3 id="s7.3"> 7.3.  Repository </h3>
+
+<h3 id="s7.4"> 7.4.  Review </h3>
+
+<p>
+At the minimum,
+patches are signed off by the team leader
+or his designated reviewer.
+Each software change should be reviewed
+by a person other than the author.
+Author and signers-off must be logged.
+The riskier the source is, the more reviews have to be done.
+</p>
+
+<h3 id="s7.5"> 7.5.  Test and Bugs </h3>
+
+<p>
+Software assessment team maintains a test system.
+Each patch should be built and tested.
+Test status of each patch must be logged.
+</p>
+
+<p>
+Software assessment team maintains a bug system.
+Primary communications should go through this system.
+Management access should be granted to all Software Assessors,
+software developers, and Systems Administrators.
+Bug submission access should be provided to
+any Member that requests it.
+</p>
+
+<h3 id="s7.6"> 7.6.  Production </h3>
+
+<h2 id="s8">8. SUPPORT</h2>
+
+
+<h3 id="s8.1"> 8.1.  Authority </h3>
+<p>
+The software interface gives features to Support Engineer.
+Access to the special features is under tight control.
+Additions to the team are subject to Board approval,
+and the software features are under CCS.
+See &sect;3.4.2.
+</p>
+
+<p>
+Support Engineers do not have any inherent authority
+to take any action,
+and they have to get authority on a case-by-case basis.
+The authority required in each case must be guided
+by this policy or the Security Manual or other clearly
+applicable document.
+If the Member's authority is not in doubt,
+the Member can give that authority.
+If not, the Arbitrator's authority must be sought.
+</p>
+
+<p>
+Support Engineers are responsible to follow the
+policies and practices.
+</p>
+
+<h3 id="s8.2"> 8.2.  Responsibilities </h3>
+
+<p>
+Support Engineers have these responsibilities:
+</p>
+
+<ul><li>
+     Member account recovery, as documented in the Security Manual.
+  </li><li>
+     Respond to general requests for information or explanation by Members.
+     Support Engineers cannot make a binding statement.
+     Responses must be based on policies and practices.
+  </li><li>
+     Tasks and responsibilities as specified in other policies, such as DRP.
+</li></ul>
+
+<h3 id="s8.3"> 8.3.  Channels </h3>
+
+<p>
+Support may always be contacted by email at
+support at cacert dot org.
+Other channels may be made available and documented
+in Security Manual.
+</p>
+
+<h3 id="s8.4"> 8.4.  Records and Logs </h3>
+
+<ul>
+  <li> use of restricted interfaces must be logged. </li>
+  <li> all support channels should be logged. </li>
+  <li> private requests for support should be referred to proper channels and logged there (e.g., by CCs)  </li>
+</ul>
+
+<h3 id="s8.5"> 8.5.  Arbitration </h3>
+<p>
+Support Engineers refer questions requiring authority
+to Arbitration, and may also be called upon to act as
+default Case Managers.
+See DRP and
+<a href="https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html">Case Manager's Handbook.</a>
+Support Engineers should be familiar with
+these topics, even if not listed as Arbitrators
+or Case Managers.
+</p>
+
+<h3 id="s8.6"> 8.6.  References </h3>
+
+
+
+<h2 id="s9">9. ADMINISTRATIVE</h2>
+
+<h3 id="s9.1"> 9.1.  Staffing</h3>
+
+<h4 id="s9.1.1"> 9.1.1.  Roles and responsibilities</h4>
+
+<ul>
+    <li> Access Engineer: responsible for controlling access to hardware, and maintaining hardware. </li>
+    <li> System Administrator: responsible for maintaining core services and integrity. </li>
+    <li> Software Assessor: maintain the code base and confirm security ("sign-off") of patches and releases.</li>
+    <li> Support Engineer: human interface with users.</li>
+    <li> Team leaders: coordinate with teams, report to Board.</li>
+    <li> All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.</li>
+    <li> Board: authorise new individuals and accesses. Coordinate overall. </li>
+    <li> Arbitrator: conducts ABCs.  Authorises exceptions to policy. </li>
+</ul>
+
+<h4 id="s9.1.2"> 9.1.2.  Staffing levels</h4>
+
+<p>
+Each team should have a minimum of two members available at any time.
+Individuals should not be active
+in more than one team at any one time,
+but are expected to observe the other teams.
+See &sect;3.4.2 for exclusivities.
+</p>
+
+<p>
+One individual in each team is designated team leader
+and reports to Board.
+</p>
+
+<h4 id="s9.1.3"> 9.1.3.  Process of new Team Members</h4>
+
+<p>
+New team members need:
+</p>
+
+<ul>
+    <li> Recommendation by team leader </li>
+    <li> Arbitrated Background Check ("ABC") </li>
+    <li> Authorisation by Board </li>
+</ul>
+
+<p>
+The team supports the process of adding new team members.
+</p>
+
+<h4 id="s9.1.4"> 9.1.4.  Arbitrated Background Check - Procedures</h4>
+<p>
+The Arbitrated Background Check ("ABC")
+must be conducted under the direction of the Arbitrator,
+with a separate Case Manager to provide four eyes.
+ABCs are carried out with full seriousness.
+</p>
+
+<h4 id="s9.1.4.1"> 9.1.4.1.  Scope </h4>
+<p>
+An investigation within ABC should include examination of:
+</p>
+
+<ul>
+    <li> realm-specific knowledge </li>
+    <li> realm-specific understanding of good security practice </li>
+    <li> history of activity within Community </li>
+    <li> reputation and standing within Community </li>
+    <li> provided references </li>
+    <li> conflicts of interest </li>
+</ul>
+
+<h4 id="s9.1.4.2"> 9.1.4.2.  Coverage </h4>
+<p>
+ABC is to be done on every individual in a critical role.
+See &sect;1.1.1.
+</p>
+
+<h4 id="s9.1.4.3"> 9.1.4.3.  Documentation </h4>
+
+<p>
+The process of the ABC should be documented as a procedure.
+</p>
+
+<p>
+Documentation of each individual check should be preserved
+and should be reviewable under any future Arbitration.
+It must include:
+</p>
+
+<ul>
+    <li> Agreement with appropriate policies, etc. </li>
+    <li> Contact information. See &sect;10.1. </li>
+</ul>
+
+<h4 id="s9.1.4.4"> 9.1.4.4.  Privacy for Critical Roles</h4>
+
+<p>
+The following privacy considerations exist:
+</p>
+
+<ul>
+    <li> procedure and ruling (recommendation) should be public </li>
+    <li> interview, documents should not be public, </li>
+    <li> summary of evidence should be in the ruling. </li>
+    <li> Arbitrator can rule on the escrow questions of evidence  </li>
+    <li> contact information goes into the contact addressbook </li>
+</ul>
+
+<p>
+CAcert trusted roles give up some privacy for the privacy of others.
+</p>
+
+<h4 id="s9.1.5"> 9.1.5.  Authorisation </h4>
+
+<p>
+Individuals and access (both) must be authorised by the Board.
+Only the Board may approve new individuals or any access to the systems.
+Each individual should be proposed to the Board,
+with the relevant supporting information as above.
+</p>
+
+<p>
+The Board should deliberate directly and in full.
+Board members who are also active in the area should
+abstain from the vote,
+but should support the deliberations.
+Deliberations and decisions should be documented.
+All conflicts of interest should be examined.
+</p>
+
+<h4 id="s9.1.6"> 9.1.6.  Security</h4>
+
+<p>
+It is the responsibility of all individuals to
+observe and report on security issues.
+All of CAcert observes all where possible.
+It is the responsibility of each individual to resolve
+issues satisfactorily, or to ensure that they are reported fully.
+</p>
+
+<p>
+See &sect;9.5.
+</p>
+
+<h4 id="s9.1.7"> 9.1.7.  Termination of staff</h4>
+
+<p>
+Termination of access may be for resignation, Arbitration ruling,
+or decision of Board or team leader.
+On termination (for any reason), access and information must be secured.
+See &sect;3.4.4.
+</p>
+
+<p>
+The provisions on Arbitration survive any termination
+by persons fulfilling a critical role.
+That is, even after a person has left a critical role,
+they are still bound by the DRP (COD7),
+and the Arbitrator may reinstate any provision
+of this agreement or bind the person to a ruling.
+</p>
+
+<h4 id="s9.1.8"> 9.1.8.  HR and Training</h4>
+
+<p>
+It is the responsibility of the team leaders
+to coordinate technical testing and training,
+especially of new team members.
+</p>
+
+<h3 id="s9.2"> 9.2.  Root Key Management</h3>
+
+<h4 id="s9.2.1"> 9.2.1.  Root Key generation</h4>
+
+<p>
+Root keys are generated only on instruction from Board.
+They must be generated to a fully documented and reviewed procedure.
+The procedure must include:
+</p>
+
+<ul>
+   <li> Use of hardware built securely for the purpose
+        only and cleaned/erased/destroyed immediately afterwards. </li>
+   <li> Dual control over all phases, including by Board. </li>
+   <li> Strong collection of primary entropy, separated from use of entropy. </li>
+   <li> Test cycles of the process on the day. </li>
+   <li> Documentation of each step as it happens against the procedure. </li>
+   <li> Confirmation by each participant over the process and the results.  </li>
+</ul>
+
+<h4 id="s9.2.2"> 9.2.2.  Backup and escrow</h4>
+
+<p>
+Root keys must be kept on reliable removable media used for that purpose only.
+Private Keys must be encrypted and should be dual-encrypted.
+Passphrase must be strong and must be separately escrowed from media.
+Dual control must be maintained.
+</p>
+
+<p>
+The top-level root must be escrowed under Board control.
+Subroots may be escrowed by either Board or Systems Administration Team.
+</p>
+
+<h4 id="s9.2.3"> 9.2.3.  Recovery</h4>
+
+<p>
+Recovery must only be conducted under Arbitrator authority.
+</p>
+
+<h4 id="s9.2.4"> 9.2.4.  Revocation </h4>
+
+<h3 id="s9.3"> 9.3.  Legal</h3>
+
+<h4 id="s9.3.1"> 9.3.1.  Responsibility</h4>
+
+<p>
+Board is responsible to the Community to manage
+the CA at the executive level.
+</p>
+
+<h4 id="s9.3.2"> 9.3.2.  Response to external (legal) inquiry</h4>
+
+<p>
+All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP.
+Board and applicable team leaders must be notified.
+</p>
+
+<p>
+Only the Arbitrator has the authority
+to deal with external requests and/or create a procedure.
+Access Engineers, Systems Administrators,
+support engineers,
+Board members and other key roles
+do not have the authority to answer legal inquiry.
+The Arbitrator's ruling may instruct individuals,
+and becomes your authority to act.
+</p>
+
+<h3 id="s9.4">9.4. Outsourcing </h3>
+
+<p>
+Components may be outsourced.
+Any outsourcing arrangements must be documented.
+All arrangements must be:
+</p>
+
+<ul><li>
+     with Members of CAcert that are
+      <ul><li>
+          Assurers, as individuals, or
+        </li><li>
+          Assured Organisations, in which
+          all involved personnel are Assurers,
+      </li></ul>
+  </li><li>
+    with Members that have the requisite knowledge
+    and in good contact with the team leader(s),
+  </li><li>
+    subject to audit,
+  </li><li>
+    transparent and no barrier to security,
+  </li><li>
+    under this Policy and the Security Manual,
+  </li><li>
+    fully under Arbitration and DRP for the purposes of Security, and
+  </li><li>
+    under the spirit of the Community and within the Principles of CAcert.
+</li></ul>
+
+<p>
+Contracts should be written with the above in mind.
+Outsourcing of critical components must be approved by the Board.
+</p>
+
+<h3 id="s9.5">9.5 Confidentiality, Secrecy </h3>
+
+<p>
+CAcert is an open organisation and adopts a principle
+of open disclosure wherever possible.
+See <a href="https://svn.cacert.org/CAcert/principles.html">
+Principles</a>.
+This is not a statement of politics but a statement of security;
+if a security issue can only be sustained
+under some confidentiality or secrecy, then find another way.
+</p>
+
+<p>
+In concrete terms,
+confidentiality or secrecy may be maintained only
+under a defined method in policy,
+or under the oversight of the Arbitrator
+(which itself is under DRP).
+The exception itself must not be secret or confidential.
+All secrets and confidentials are reviewable under Arbitration,
+and may be reversed.
+All should strive to reduce or remove any such
+restriction.
+</p>
+
+<h2 id="s10">10. REFERENCES</h2>
+
+<h3 id="s10.1">10.1 Contacts </h3>
+<p>
+Contact information for all key people and teams must be documented.
+</p>
+
+<h3 id="s10.2">10.2 Documents </h3>
+<p>
+All incorporated Documents must be documented.
+</p>
+
+<h3 id="s10.3">10.3 Related Documents </h3>
+<p>
+Relevant and helpful Documents should be referenced for convenience.
+</p>
+
+<hr />
+</body></html>
+
diff --git a/www/policy/TTPAssistedAssurancePolicy.html b/www/policy/TTPAssistedAssurancePolicy.html
new file mode 100644
index 0000000..38b31b9
--- /dev/null
+++ b/www/policy/TTPAssistedAssurancePolicy.html
@@ -0,0 +1,271 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" lang="en">
+<title> CAcert -- TTP-Assisted Assurance Policy </title>
+<style type="text/css">
+<!--
+.comment {
+        color : steelblue;
+}
+-->
+</style>
+</head>
+<body>
+
+<div class="comment">
+<table width="100%">
+
+<tbody>
+<tr>
+<td rowspan="2">
+  Name: TTP-Assist <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD13.2</a>
+<br>
+   Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+<br>
+  Editor: <a style="color: steelblue" href="https://wiki.cacert.org/UlrichSchroeter">Ulrich Schroeter</a>
+<br>
+   Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy"> CC-by-sa+DRP </a>
+<br>
+</td>
+<td align="right" valign="top">
+	<a href="https://www.cacert.org/policy/PolicyOnPolicy.php">
+		<img src="images/cacert-policy.png" alt="TTP-Assist Status - POLICY" style="border-style: none;" height="31" width="88">
+	</a>
+</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+
+<h1> TTP-Assisted Assurance Policy </h1>
+
+
+<h2 id="g0.1">0. Preliminaries </h2>
+
+<p>
+   This sub-policy extends the
+   <a href="https://www.cacert.org/policy/AssurancePolicy.php">
+   Assurance Policy</a> ("AP" =&gt; COD13)
+   by specifying how Assurers can be assisted by
+   outsourcing the identity documents verification
+   component of assurance to trusted third parties (TTPs).
+   Other definitions and terms can be found in AP or in
+   <a href="https://wiki.cacert.org/AssuranceHandbook">Assurance Handbook</a>
+   ("AH").
+  </p>
+
+
+<h2 id="g0.2">1. Scope </h2>
+
+<p>
+   This sub-policy is restricted to members located
+   in areas not well-served with Assurers.
+   It serves a goal of promoting both Assurers and Members in those areas.
+</p>
+
+
+<h2 id="g0.3">2. Roles </h2>
+
+
+<h3 id="g0.3.1">2.1 Trusted Third Party </h3>
+
+<p>
+   A Trusted Third Party ("TTP") is a person who is traditionally respected
+   for making reliable statements to others, especially over identification
+   documents.  Typically, notaries public (anglo),
+   Notaries (European), bank managers, accountants
+   and lawyers.
+</p>
+
+
+<h3 id="g0.3.2">2.2 The Assurer (aka TTP-admin) </h3>
+
+<p>
+   To employ a TTP in an assurance,
+   the Assurer must be a <a href="https://wiki.cacert.org/SeniorAssurer">Senior Assurer</a>.
+   The Assurer must be familiar with the local
+   language and customs.
+</p>
+
+
+<h3 id="g0.3.3">2.3 Member </h3>
+
+
+<p>
+   A Member ("assuree") who is located in a place not well-served
+   by Assurers may use the TTP-assisted assurance.
+</p>
+
+
+<h2 id="g0.4">3. The Assurance </h2>
+
+
+<p>
+  Assurance assisted by TTP must meet these requirements:
+</p>
+
+<ol style="list-style-type: lower-alpha;">
+<li id="s3.a">
+      The Assurer must positively confirm the identity and
+      suitability of the TTP.
+    </li>
+<li id="s3.b">
+      The TTP and the Member must meet face-to-face.
+    </li>
+<li id="s3.c">
+      The TTP confirms the details supporting the Assurance Statement.
+    </li>
+<li id="s3.d">
+      The Assurer makes a reliable statement to confirm the
+      Assurance Statement.
+    </li>
+<li id="s3.e">
+      Assurance must be marked as TTP-Assisted
+      (e.g., by use of TTPAdmin flag).
+  </li>
+</ol>
+
+
+
+
+<h2 id="g0.5">4. Assurance Officer ("AO") </h2>
+
+<p>
+   The Board routinely delegates its responsibilities to the
+   Assurance Officer (and this section assumes that, but does
+   not require it).
+</p>
+
+
+<p>
+   A report is requested annually from the Assurance Officer
+   on performance of this policy for the association's
+   annual report.
+</p>
+
+<h3 id="g0.5.1">4.1 Practice </h3>
+
+<p>
+    Assurance Officer should prepare a
+    <a href="https://wiki.cacert.org/TTP">detailed documentation</a>
+    under
+    <a href="https://wiki.cacert.org/AssuranceHandbook">AH</a>
+    that meets the needs of this policy, including:
+</p>
+
+<ul>
+<li>
+    Form for TTPs
+</li>
+<li>
+    Guide for TTPs.
+</li>
+<li>
+    Form for TTP-assisted assurance (used by Assurer)
+</li>
+<li>
+    Guide and protocol for Assurers.
+</li>
+<li>
+    Mechanisms for contacting Assurers available for
+    TTP-assisted assurances.
+</li>
+<li>
+    Definition of
+    <a href="https://wiki.cacert.org/SeniorAssurer">
+    Senior Assurer</a>.
+</li>
+</ul>
+
+
+<h3 id="g0.5.2">4.2 Deserts </h3>
+
+<p>
+    The Assurance Officer maintains a
+     <a href="https://wiki.cacert.org/deserts">list of regions</a>
+    that are designated as '<i>deserts,</i>' being areas that are so short
+    of Assurers as to render face-to-face Assurance impractical.
+    In each region, approved types of TTP are listed (e.g., Notary).
+    The list is expected to vary according to the
+    different juridical traditions of different regions.
+    Changes to the regional lists are prepared by
+    either an Organisation Assurer for that region
+    (as described by OAP)
+    or by two Assurers familiar with the traditions
+    in that region.
+    Changes are then submitted to the Board for approval.
+</p>
+
+<p>
+    Use of a type of TTP not on the list must be approved by
+    AO and notified to Board.
+    It is an explicit goal to reduce the usage of
+    TTP-assisted assurances in favour of face-to-face Assurance.
+</p>
+
+
+<p>
+    In coordination with internal and external auditors,
+    the Assurance Officer shall design and implement a
+    suitable programme to meet the needs of audit.
+    Where approved by auditors or Board, the Assurance
+    Officer may document and implement minor variations to this policy.
+</p>
+
+
+<h2 id="g0.6">5. Topup Assurance </h2>
+
+
+<p>
+    AO is to operate a <cite>Topup Assurance Programme</cite>
+    to help seed deserts with Assurers.
+    A topup assurance will add additional Assurance Points
+    to those gained from two previously conducted TTP-assisted assurances,
+    in order for a Member to reach 100 Assurance Points
+    for the express purpose of becoming an Assurer.
+</p>
+
+
+<p>
+    A topup assurance is conducted by a third Senior Assurer
+    according to the following requirements:
+</p>
+
+
+<ol>
+<li id="s5.1">
+      Assurer Challenge must be completed as passed by Member.
+</li>
+<li id="s5.2">
+      The topup must be requested by Member for
+      purpose of enabling the Member to reach Assurer level.
+</li>
+<li id="s5.3">
+      Topup Assurer must be a Senior Assurer,
+      and must be independent of the TTP-assist Assurers.
+</li>
+<li id="s5.4">
+      The Topup Assurer reviews the two TTP-assisted assurances,
+      and conducts other checks as set by the Assurance Officer.
+      The normal face-to-face meeting is not conducted.
+</li>
+<li id="s5.5">
+      Topup Assurer may award up to 35 points.
+</li>
+<li id="s5.6">
+        Assurance must be marked as Topup
+        (e.g., by use of new feature with TTPAdmin flag).
+</li>
+</ol>
+
+
+<p>
+    Each topup is to be reported to AO.
+    Topup is only available in designated deserts.
+</p>
+
+
+</body>
+</html>
diff --git a/www/policy/cacert-draft.png b/www/policy/cacert-draft.png
deleted file mode 100644
index 9d33eb184826021f746dbe6328e2fca46242dd08..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 4796
zcmV;t5<~5YP)<h;3K|Lk000e1NJLTq003A30018d1^@s6W5^2N00009a7bBm000b}
z000b}0h5oGng9S2Zb?KzRA_<ins<~{)xF0*`<!!onLfb43?R)xij+YSL_|a^JS?EG
zp+Su$8dvh7CND*7FGdm#u`lDZEPaU;MFd2ON|81&bQoYNFvBqY&aJ2H_s6+&XNDP#
zFY&FIxAI%-tabL@zrFWwf6uS(dxd3Ll7G?v87cp00sg;}_Ky}IMHTB2AK#m5%JYAP
z*!(<l!tGFaIVehZo{9G&wmc8%1CT|x!k`PfEi2xh2PgO1{MRpr^n#xEoB9jHXOG#9
zp)(=Y3RN4ClYWfY@RZ#@_(BMugqjlM?O%fC{Hw?M?r89U$)LHQW{3SK4#*pW`12gZ
ziu-%!@n%BrQLyJN#49u4$eQl!hK_geS8n*~{ZuD%_6uO@&{zSDhaoK=ETe;`sT^5w
zj{PpJZ*;8h4!{7Kx8q$1WZpRYedAM5vAzc$1=+VK*^r1sE4r>%xdHNvI@qhe{F?m~
z=vRcC^EwFCUUA|*bc1NjP2kS>#z*>Y0emWncJU;l^y9B!>WI-Y|Lm^Q_q>k`^zG=V
z-uU(V9a#g_n~?wZ4D!qyp<q&X9#unLywKMEZ$RH|fIHKPz1{oF1mf5>`+evoFznJ(
z=In+uuIgyl?t(<P=k=pah$VMHv<cin7=0Z$+&%M-n-4;KBeDN^0Pe}>g=%5<TM+Dr
z>~~ftjmHi~zHA8gf%N`%pJl+&tzW%|`1axW=K(lxZ1=wO0^|h?p!FzX&4aM{*^aRz
zYmohl;K*tSc5)L{U*RS^8OT}BfG7Q175kqCVA+#D1aSCMucEQC<Gp+>WDi5^eGk+Q
ze<`Xref1`TromZv{@t>6CPfHA`y+wQZ6O44-6R~>iNp<{>sU|xLfCzAQ9-4cN1gZu
z2%`tS?hn%J073{vw83r^-HsSGvpbJvATkGboTjE2QSt^tkHEoYh(Xg}_VY0Pp$?v^
zFA-AqyjD+gb>hL)d*qRTX-Vi|ELCV&mPAo($GvuE1uJ)yv;9adjiD$B!$cK=px4dd
zybR77md8co22qd`v_S?sM{`4ls1-lpP{kyw;xAEkFvb__&nFlN)6|yWj*G`}-PAKM
zEs2`klZy3Fy(zUC;d)s6C=}fev!3pmXT|++_jbrX+wQL~g}&q9)tS(G4AwpZGyW6y
zFX@;QZG^2aLa&kC*BUyrYjzNAhBXU1cn+<A(iJve5>z2T5duZ+Ip_%~rEEXwzN(Y_
z=*3T2x2KAPVdB(OoSK57*q+2NEn*1+i6q_U=I&YJdH9AYNNFLGxg$uLtj}pv?%~O&
zKgB)l0(R~m#qwom;Yo`U4eLxCS-|=yZc1tVw?fTT;L8DrC)FhZr0h@vA^5ho>rAD`
z8hK@92}Q&Da^*S0x+sojSSFgH^7-ycu6cYh4WTIMJ{PK@U|JTTXo5ssM@kb#RS5W8
z_*_m-Hb?k$M;Q;_a2`UaNKC*&;2=YpLbZ|0kVzMEtS*CX#pB8CZ6c)$zuV33ijx!{
zuAyjXUKh(bm81kqN~Dy@4<P`Fl(q{|lI{rTD1ou9QG$KQQ$X#kbshUiPQCJK2S_Hz
zWzwxELSR`E-85Oc<uGrq-NTm$j#67y&!V5s#*z}#vJgT+0Gg(#RM&>N@yW%sM&o4o
z-B?o67EPcif(yr-#^}>>$@OGXS<}X{?FTv3a2$uKlHm)WQ$q!J5@jE{OrYW=z+hy2
z06X?+y#LWfG&cKjyLH^II4-9}Bp&Cjb^9qAnnx%7>O$>WpbBxycvoH<Y&yW`^uY|%
zqA?UDrkglah3udgho+=HLOY)jf}SkAT?SzX7JHtw=hZbv_}*_91CZf!qXs?r-A)uC
zaB6C54ehY8kN<dg6UVC*vU)o)rAahylAoQ%i}zf@c_VGjSQ}eT)$wKgXvWzzY?;o3
ze_2jA?4pLB(QJn4C4W!8RzN*FiLsNC>QziEYUa}E#q2#ekk#u(vTJW44UGX*RbfSO
zDG%K+8K2A54Pq&64N4d$n-3mmXW0oV>Y541bX*RNzFB_84C>8<p?L(ot}Z|eMX<H>
zIIphW&DPRmG=^e!3{eD`0S^;~=5fa*;}|_KHwEC)`VhM->Tqf*R#H<Z752m9vP0DV
z>Ut_qG*i$kox=QV%1<;?R@+RP*F`(_5;)!%qO7(F!?X}W*yF3pi{<pCx8QFajBD4q
zn7W4Qjj{5v?=kkYJS-_$+3+d9sr(JM^tpwX>tEoB!bfN+8OVEI9^=>dEG29R9xXMQ
zl|7lcy=HNu9;W^3InuIsp$I4EPcG)7$u%^Go7r4Ef+Z^_vuj5$-g$TybI$FLX$jP%
zpKmwC*H-Of(T7_&aIArN!bDMQ^ORB|kvLS9-Wfg?-F^|X&KiPYS|~#B>o-2<$qzQ8
z>n56}lF&^g5~rr(P!+;)oq)&5b9Y_L_2-WO;H6J?@Ppqi!58$9&`sP<jfz+AX5F4@
ze*5l5N{=<taH54D&Yj3Jch2PW+n=YtHHwtByzSQGP!%*)K?n#%bmq?(g;u`Dg?sH>
z%nLpye9a$;Zy3Y<qkhQP)AGOqMG@?b?4ZEgk9m1Fkmd+d-xA}}q5(`VD!`OuaX5Bz
zSH8jY?K7FvtC4p$lri_(g$TVL3l@BzLkGw3gE3dLWX<E`_J5n_9(kITUk+g1p){_X
zcr!wkDPM<#AHTGcMT<A%^*Hgnop_uUZBZS|k|01;6apR><uy(0sXWQ7vxcCl3O{>g
z4Zr=%da^SE=&Fg+p)z4~9_fBJdn)QUT+>8ux{qi~=Z<HVF|1z}<A?M?RTMO@y;oc_
z3Amly^ZX}#u(1?`B+ci>;dkS4+8W&uiqaH{k?!v(r4<3;n4YqhcqBn6nm}8B_%K#N
zCGFFB#0T!e8o!cv2i%D`as_j9=W=FXG!GO!!2ARAxqkQcD4N1+g|FF*qM!&58(ZA`
zsPtB@?K2l)IXTd@lpAMP@Ys_VqPUy5?3{t*=lJj@uH?Q4G8r|dfy-vDW8$=jsaJGz
z_&%m3&=i$Fe7J>0?{6kI%a4>0iR+~M-ORgS6vOkg3CDGc57n@$qyh{ZM1WN#<@|o}
zW^%IvL=y&mGX1>q)7caa%>$q@6y^GbAF^g=1(^X4b<JV^@WB?|xNo){<Sc0iK%gy_
z;O%w$(NqP~uxJQH(L>Q>EdWzT_NTTf%)YAnln>Vplc9Yx>6;b6v?S5E!SI4?w1$=#
zLX}va5NcT=!RkVO@?Z`djK$2|JqNeyW{7tP1?~b`^;Sl>N3f`R5p{YUha-pCAK6dT
z2y=a}c|1JmLALG-gYOf(2+AvaVW}3EO(;Z4$=vhuc=}_5BUL#peEJ4_!76@pX9IUk
z(b0s5`ql`4_+T@^fCtNx#C4P0G#?*5cr|DA&*>6?_Ew$bwx^b2nD!mTf34h!Oa`D(
zG{GOQo|FO?AT!|M7uQT;RY^IfW#M%>*mUq1re(X2c2jS6Q@u0%Nx=MQs>0Fw5Cu7D
z0KD__tEi}JVa(lsLI}_lL1QG&U6+pIwwYtP$f-r*hMlrV1?h?*RlyZmS8-RLYX})_
zY;P-OSKBUX6SV{!0d|CTpeY(zjx5Fp#&cWVZA?j@f?Ki8<^4_j3FaR~2bx1LFfW~H
zqXz&`n4inI!F~B+PbJxz26fE=-dcJ(w@vn-DzJXvQI0pZk>+zl(&Qe$`E1VUpF={o
z{cwA_c1A%CpDmn6TTCYs*V$cBhuf*4n-&3&lNH5B*i%uLtTsU)sA~xm@Hnw7i9=Ip
z3CCy-$8cy$Do9Ess-m#?S92IYxDTh2B_#rZZgjtVGA%ouGfbKC#ag=0g_Sf71%-IR
z<anfx9N7!M>gT-l^C%7#bGr9*9y{%^Zi}{)Aq^}`vSjl?zBgFK0VK>gmyI7pn%9G2
zT4<`mmFJw!>XHg{Lm}M<+sgJ)d}urqhUIbicw;gG+bNdc<7Dy~`B>5xxO2X2Nn7(W
z{VK;ALNtYAsEUG=HhAx>+mB_KUDFdq!S8V*BqS?a4Abm#4k<xX1^tuSYM5rK>}}7T
zJ7sO%$mW%)ajjpn+yzioK{%|lud;!$r{xhh6F5|r0(Sv(x6LIwI?DV$^D!&~RcJUA
z4GR;?5@?FXXZy<7U)De(mVq0|fW8q{msB(3mv4|TB$}cSiY5qnotTylcsOSA?uPwL
z7?wwCByJ0dZKh65CC%rulY6>W0*Vmm$;`pDB&L}>lmrVH&?^nML&It}eUU6&lFDQz
ziw8}$wYLk%KwP)|t*R&;#mwJ8+Qeafd2!ixdtoVYs0x4nY%e!X8;K?~gcQulnM0aC
zjpYq1xTW{4xK$S**i(6u;rZFAE4jDV??W0UN6PcjfKkJ%czMU^)V7AOEH#zix}6$^
zX<=Csugk%bO{F~k{b}^c@TXu@6hSnuQ`^)=es<7K@RQX*d*$U&?VWut2R^rha4dn-
zsnQaP^7~t-bJaPg6E_STYDePVUL9(xz@=$;TpDrR=vGbsEueP$P!g2$M-L!BJ4jqN
zu_Oe%PFC$KXVHgSQf65buc0j-W_WN2s-n;qOYp;ImvhH6%Wcz91of>^KG{}|I|$o%
z4WhwPm^!HhMNJTjm_*__(S%MYn&4zhBy~`aQ{&L_CcfBH#l*tCXsUuGZ9f>*4Hj=a
zh@yy;rnTSTsfu9xky^GLsv#rbrhiV5gkdJf6h7KqN}A6_Zkmq_zdQA02Ha!^J*4~G
z6d$SiUxWB{<j|Dl&6@3>g#e{jx{vuY&Lq?p!=Wlzmc;LN^7Gf$aMyFo*;(4ieMjyG
z#bAPY39qi$&6EdT=eZBIB=bW1vn}6tn2Nd(X?}}}>OL&}d@REUR<rQl2v6L6ISX%@
z!V~kS@w;25^XR;(xSbtU6TmB<?&QqVdNX=pE^W~S0BK$q&n+wF>5sP35{V~+6`W`e
z^TM+2O!@cM_;~AK6d{;1xsZ6mKmY-claIF^;nqbTbMR<G>c9ZCO<~^MaDd78y~g~f
zK1%iqPVqp0m0S)Lk5jX)3D8u9O$Ux50GGqgms=xoG|Q6QJG+S0JIh(Uy`0=kKZext
zNH;HiaDbPi3rS2`OQ85N?tbYYHQ|$Zolb)3?Z3#{0KL2ZK=Oh_Ae1PpSKP#$^IN#+
z!lxL{<-oaJ1S}~#!H1g;;&P}2y-rqcFQc(7%9FQU$c$h9H_^C(&+R~%@Y6r7=Gmpi
z^v_MhG%d<%o2hMTBW{|c`|VQs=INt&f8#+`?I<HR!%w=;#p`Q!v1D^8gZgBU8Su~&
zj&rObL``D|-LM!txOYmP_Q3UZ0nFyJ?|-v{Ub53Xl-I^_XevRki+9%Vr?x4~pu7yW
zAFk!BVR<MB@VXqldEez+JYg_(O>GeIBV2J@H@%86Wi5fvX5;$uV!~D{nSL*dB4}+2
z6N&2xVb|)P?XJY_&`21PSiFsM3&%5@)wJpT_}m;xh4~1&8OPAUFeO(^9EPr&Bn-Q5
zuWbnN=GwhX8BxHS_g_xX>*PdJTMFo-^{srqyOQ<$syW#b#-(XkZBZgII~ci~8h?4<
zaxR%Lgu13Sn!_=CE+@KSva|dIt4qo$K3qe6YXpx|!!k^o+hTz2s!YQ|@AP~nz}SJ(
z<J7om`e@o(qeS95mIO^zSyfWbvrD(Jen&YikvQr@3l=PpQsVbGxpwLqWCy)`s=r6`
z1uvk>7~;JfU{?`wHI&*oFEhY3(?;;~t0$3{72x&NyI8lkikvhbPKS!u?c$*u&!%5i
zKE1_!+-eT>%F8q;Z{Soi@hij0P4}{*xC~25{B9STrlOk`b0!xuqJIu^&mB(C>mri;
zHAMod5I7ww9;br=z0$bu!qMC~Z6ujN4^o29?c}<tBN&{QNi=TI8i|uI%#`LiRTY;*
zqj#pCi;4#ElPk_<SidaxR@n-Y8SvnAs02Jt=Fd2jfXA7d+nL($L?#yYBP+v4SxqyM
zxPfk(XsU|e<HX~2GIeBs`@$Wd{a$!W{0kncc!<jb*CI=bs5};-#cD>83i&xf#tiDs
z*uj0s>{N$0wZ+g)llGfeMF_Hj9_)mv<7dBSRuZR_Ty96;pg9~Pp_{1#NF>=oZz|gW
zJ0Gq(*-A}g8{t?2O;hNV?qg8z4BXDH|NN4jd^$i)V;e_mnrMy0i5n(9mxHXJm%(`%
zq<K4jxrinVLXmivxmf|vSKd>fO3{SD!J`e-w?;5b3y;e|es+L9nSpOK|6lZX(Ek8L
W>`$~$WD7I^0000<MNUMnLSTZR+*_9b

diff --git a/www/policy/index.php b/www/policy/index.php
index 7101c1f..1715bf9 100644
--- a/www/policy/index.php
+++ b/www/policy/index.php
@@ -14,7 +14,7 @@
     You should have received a copy of the GNU General Public License
     along with this program; if not, write to the Free Software
     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
-*/ 
+*/
 loadem("index");
 showheader(_("CAcert - Policies"));
 ?>
@@ -23,17 +23,11 @@ showheader(_("CAcert - Policies"));
 <ul>
 <?php
 
-foreach (glob("*.html") as $filename) 
+foreach (glob("*.html") as $filename)
 {
-	echo "<li><a href='$filename'>$filename</a></li>\n";
-}
-
-foreach (glob("*.php") as $filename) 
-{
-   if($filename != "index.php" && $filename != "NRPDisclaimerAndLicence.php")
-   {
-     echo "<li><a href='$filename'>$filename</a></li>\n";
-   }
+	if($filename != "NRPDisclaimerAndLicence.html"){
+		echo "<li><a href='".htmlspecialchars($filename)."'>".htmlspecialchars($filename)."</a></li>\n";
+	}
 }