summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rwxr-xr-xCommModule/client.pl129
-rw-r--r--includes/account.php7
-rw-r--r--includes/general.php114
-rw-r--r--includes/general_stuff.php12
-rw-r--r--includes/keygen.php2
-rw-r--r--pages/account/16.php1
-rw-r--r--pages/account/17.php9
-rw-r--r--pages/account/19.php4
-rw-r--r--pages/index/0.php4
-rw-r--r--pages/index/1.php2
-rw-r--r--pages/index/10.php2
-rw-r--r--pages/index/16.php2
-rw-r--r--pages/index/3.php2
-rw-r--r--pages/wot/6.php2
-rw-r--r--scripts/54at-ate-linz-email.txt91
-rw-r--r--scripts/54at-ate-linz-mail.php.txt140
-rw-r--r--scripts/55de-ate-wiesbaden-email.txt46
-rw-r--r--scripts/55de-ate-wiesbaden-mail.php.txt122
-rw-r--r--scripts/56at-ate-oberwart-email.txt93
-rw-r--r--scripts/56at-ate-oberwart-mail.php.txt147
-rw-r--r--scripts/57at-ate-graz-email.txt91
-rw-r--r--scripts/57at-ate-graz-mail.php.txt130
-rw-r--r--scripts/58at-ate-wien-email.txt91
-rw-r--r--scripts/58at-ate-wien-mail.php.txt134
-rw-r--r--www/.htaccess2
-rw-r--r--www/cap.html.php4
-rw-r--r--www/cap.php6
-rw-r--r--www/capnew.php52
-rw-r--r--www/coap.html.php14
-rw-r--r--www/coapnew.php64
-rw-r--r--www/policy/AssurancePolicy.html750
-rw-r--r--www/policy/AssurancePolicy.php727
-rw-r--r--www/policy/CAcertCommunityAgreement.html407
-rw-r--r--www/policy/CAcertCommunityAgreement.php597
-rw-r--r--www/policy/CertificationPracticeStatement.html4698
-rw-r--r--www/policy/CertificationPracticeStatement.php4091
-rw-r--r--www/policy/ConfigurationControlSpecification.html277
-rw-r--r--www/policy/DisputeResolutionPolicy.html780
-rw-r--r--www/policy/DisputeResolutionPolicy.php798
-rw-r--r--www/policy/NRPDisclaimerAndLicence.php14
-rw-r--r--www/policy/OrganisationAssurancePolicy.html408
-rw-r--r--www/policy/OrganisationAssurancePolicy.php406
-rw-r--r--www/policy/OrganisationAssurancePolicy_Australia.html309
-rw-r--r--www/policy/OrganisationAssurancePolicy_Europe.html1021
-rw-r--r--www/policy/OrganisationAssurancePolicy_Germany.html138
-rw-r--r--www/policy/PolicyOnJuniorAssurersMembers.html202
-rw-r--r--www/policy/PolicyOnPolicy.html356
-rw-r--r--www/policy/PolicyOnPolicy.php291
-rw-r--r--www/policy/PrivacyPolicy.html76
-rw-r--r--www/policy/PrivacyPolicy.php4
-rw-r--r--www/policy/RootDistributionLicense.html177
-rw-r--r--www/policy/RootDistributionLicense.php130
-rw-r--r--www/policy/SecurityPolicy.html1308
-rw-r--r--www/policy/TTPAssistedAssurancePolicy.html271
-rw-r--r--www/policy/images/cacert-draft.png (renamed from www/policy/cacert-draft.png)bin4796 -> 4796 bytes
-rw-r--r--www/policy/images/cacert-policy.pngbin0 -> 5030 bytes
-rw-r--r--www/policy/images/valid-html401-blue.pngbin0 -> 1669 bytes
-rw-r--r--www/policy/images/valid-html50-blue.pngbin0 -> 1438 bytes
-rw-r--r--www/policy/images/valid-xhtml11-blue.pngbin0 -> 2037 bytes
-rw-r--r--www/policy/index.php16
60 files changed, 12533 insertions, 7238 deletions
diff --git a/CommModule/client.pl b/CommModule/client.pl
index 25e6a73..0874477 100755
--- a/CommModule/client.pl
+++ b/CommModule/client.pl
@@ -172,7 +172,7 @@ else
$PortObj->baudrate(115200);
$PortObj->parity("none");
$PortObj->databits(8);
-$PortObj->stopbits(1);
+$PortObj->stopbits(1);
}
}
@@ -286,8 +286,8 @@ sub SendIt($)
# {
# $PortObj->write(substr($_[0],$_,1));
# }
-
-}
+
+}
my $modus=0;
@@ -313,17 +313,17 @@ sub SendHandshaked($)
$xor ^= unpack("C",substr($_[0],$_,1));
}
#print "XOR: $xor\n";
-
+
my $tryagain=1;
while($tryagain)
{
SendIt($_[0].pack("C",$xor)."rie4Ech7");
-
+
Error "Packet receipt was not confirmed in 5 seconds. Connection lost!\n" if(!scalar($sel->can_read(5)));
$data="";
$length=read SER,$data,1;
-
+
if($length && $data eq "\x10")
{
SysLog "Sent successfully!...\n";
@@ -335,14 +335,14 @@ sub SendHandshaked($)
}
else
{
- Error "I cannot send! $length ".unpack("C",$data)."\n";
+ Error "I cannot send! $length ".unpack("C",$data)."\n";
}
}
}
else
{
- print "!Cannot send! $length \n";
+ print "!Cannot send! $length \n";
Error "!Stopped sending.\n";
}
}
@@ -423,7 +423,7 @@ sub Request($$$$$$$$$$$)
my @fields=unpack3array(substr($data,3,-9));
SysLog "Answer from Server: ".hexdump($data)."\n" if($debug);
-
+
#if(open OUT,">result.dat")
#{
# print OUT $data;
@@ -461,8 +461,8 @@ sub X509extractSAN($)
{
$SAN.="," if($SAN ne "");
$SAN.= trim($bit[1]);
- }
- else
+ }
+ else
{
$newsubject .= "/".$val;
}
@@ -470,7 +470,7 @@ sub X509extractSAN($)
$newsubject=~s{^//}{/};
$newsubject=~s/[\n\r\t\x00"\\']//g;
$SAN=~s/[ \n\r\t\x00"\\']//g;
- return($SAN,$newsubject);
+ return($SAN,$newsubject);
}
sub X509extractExpiryDate($)
@@ -526,25 +526,25 @@ sub X509extractSerialNumber($)
return "";
}
-sub OpenPGPextractExpiryDate ($)
+sub OpenPGPextractExpiryDate ($)
{
my $r="";
my $cts;
my @date;
-
+
open(RGPG, $gpgbin.' -vv '.$_[0].' 2>&1 |') or Error('Can\'t start GnuPG($gpgbin): '.$!."\n");
open(OUT, '> infogpg.txt' ) or Error('Can\'t open output file: infogpg.txt: '.$!);
$/="\n";
- while (<RGPG>)
+ while (<RGPG>)
{
print OUT $_;
- unless ($r)
+ unless ($r)
{
if ( /^\s*version \d+, created (\d+), md5len 0, sigclass (?:0x[0-9a-fA-F]+|\d+)\s*$/ )
{
SysLog "Detected CTS: $1\n";
$cts = int($1);
- } elsif ( /^\s*critical hashed subpkt \d+ len \d+ \(sig expires after ((\d+)y)?((\d+)d)?((\d+)h)?(\d+)m\)\s*$/ )
+ } elsif ( /^\s*critical hashed subpkt \d+ len \d+ \(sig expires after ((\d+)y)?((\d+)d)?((\d+)h)?(\d+)m\)\s*$/ )
{
SysLog "Detected FRAME $2 $4 $6 $8\n";
$cts += $2 * 31536000; # secs per year (60 * 60 * 24 * 365)
@@ -560,19 +560,19 @@ sub OpenPGPextractExpiryDate ($)
}
}
- close(OUT );
+ close(OUT );
close(RGPG);
SysLog "CTS: $cts R: $r\n";
-
- if ( $r )
+
+ if ( $r )
{
@date = gmtime($r);
$r = sprintf('%.4i-%.2i-%.2i %.2i:%.2i:%.2i', # date format
$date[5] + 1900, $date[4] + 1, $date[3], # day
$date[2], $date[1], $date[0], # time
);
-
+
}
SysLog "$r\n";
return $r;
@@ -605,7 +605,7 @@ sub setUsersLanguage($)
if($lang ne "")
{
$ENV{"LANG"}=$lang;
- setlocale(LC_ALL, $lang);
+ setlocale(LC_ALL, $lang);
} else {
$ENV{"LANG"}="en_AU";
setlocale(LC_ALL, "en_AU");
@@ -642,7 +642,7 @@ sub sendmail($$$$$$$)
my ($to, $subject, $message, $from, $replyto, $toname, $fromname)=@_;
my $errorsto="returns\@cacert.org";
my $extra="";
-
+
# sendmail($user{email}, "[CAcert.org] Your GPG/PGP Key", $body, "support\@cacert.org", "", "", "CAcert Support");
my @lines=split("\n",$message);
@@ -653,14 +653,14 @@ sub sendmail($$$$$$$)
if($line eq ".")
{
$message .= " .\n";
- } else
+ } else
{
$message .= $line."\n";
- }
+ }
}
$fromname = $from if($fromname eq "");
-
+
my @bits = split(",", $from);
$from = addslashes($bits['0']);
$fromname = addslashes($fromname);
@@ -672,7 +672,7 @@ sub sendmail($$$$$$$)
SysLog "SMTP: ".<$smtp>;
print $smtp "MAIL FROM:<returns\@cacert.org>\r\n";
SysLog "MAIL FROM: ".<$smtp>;
-
+
@bits = split(",", $to);
foreach my $user (@bits)
{
@@ -707,7 +707,7 @@ sub sendmail($$$$$$$)
print $smtp "Content-Type: text/plain; charset=\"utf-8\"\r\n";
print $smtp "Content-Transfer-Encoding: 8bit\r\n";
}
- else
+ else
{
print $smtp "Content-Type: text/plain; charset=\"iso-8859-1\"\r\n";
print $smtp "Content-Transfer-Encoding: quoted-printable\r\n";
@@ -756,7 +756,7 @@ sub HandleCerts($$)
{
#Weird SQL structure ...
my @sqlres=$dbh->selectrow_array("select memid from domains where id='".int($row{'domid'})."'");
- $row{'memid'}=$sqlres[0];
+ $row{'memid'}=$sqlres[0];
SysLog("Fetched memid: $row{'memid'}\n") if($debug);
}
@@ -857,7 +857,7 @@ sub HandleCerts($$)
print OUT $crt;
close OUT;
system "$opensslbin x509 -in $crtname.der -inform der -out $crtname";
- }
+ }
}
else
{
@@ -901,7 +901,7 @@ sub HandleCerts($$)
$body .= _("Best regards")."\n"._("CAcert.org Support!")."\n\n";
sendmail($user{email}, "[CAcert.org] "._("Your certificate"), $body, "support\@cacert.org", "", "", "CAcert Support");
}
- else
+ else
{
SysLog("Could not find the issued certificate. $crtname ".$row{"id"}."\n");
$dbh->do("update `$table` set warning=warning+1 where `id`='".$row{'id'}."'");
@@ -914,7 +914,7 @@ sub DoCRL($$)
{
my $crl=$_[0];
my $crlname=$_[1];
-
+
if(length($crl))
{
if($crl=~m/^-----BEGIN X509 CRL-----/)
@@ -929,7 +929,7 @@ sub DoCRL($$)
open OUT,">$crlname.patch";
print OUT $crl;
close OUT;
- my $res=system "xdelta patch $crlname.patch $crlname $crlname.tmp";
+ my $res=system "xdelta patch $crlname.patch $crlname $crlname.tmp";
#print "xdelta res: $res\n";
if($res==512)
{
@@ -939,7 +939,7 @@ sub DoCRL($$)
}
}
- my $res=`openssl crl -verify -in $crlname.tmp -inform der -noout 2>&1`;
+ my $res=`openssl crl -verify -in $crlname.tmp -inform der -noout 2>&1`;
SysLog "verify: $res\n";
if($res=~m/verify OK/)
{
@@ -1023,17 +1023,29 @@ sub RevokeCerts($$)
if($result)
{
- setUsersLanguage($row{memid});
-
- my %user=getUserData($row{memid});
-
$dbh->do("update `$table` set `revoked`=now() where `id`='".$row{'id'}."'");
- my $body = _("Hi")." $user{fname},\n\n";
- $body .= sprintf(_("Your certificate for %s has been revoked, as per request.")."\n\n", $row{'CN'});
- $body .= _("Best regards")."\n"._("CAcert.org Support!")."\n\n";
- SysLog("Sending email to ".$user{"email"}."\n") if($debug);
- sendmail($user{email}, "[CAcert.org] "._("Your certificate"), $body, "support\@cacert.org", "", "", "CAcert Support");
+ if($org eq "")
+ {
+ if($server)
+ {
+ my @a=$dbh->selectrow_array("select `memid` from `domains` where `id`='".int($row{domid})."'");
+ sendRevokeMail($a[0], $row{'CN'}, $row{'serial'});
+ }
+ else
+ {
+ sendRevokeMail($row{memid}, $row{'CN'}, $row{'serial'});
+ }
+ }
+ else
+ {
+ my $orgsth = $dbh->prepare("select `memid` from `org` where `orgid`='".int($row{orgid})."'");
+ $orgsth->execute();
+ while ( my ($memid) = $orgsth->fetchrow_array() )
+ {
+ sendRevokeMail($memid, $row{'CN'}, $row{'serial'});
+ }
+ }
}
}
@@ -1046,6 +1058,21 @@ sub RevokeCerts($$)
}
+sub sendRevokeMail()
+{
+ my $memid = $_[0];
+ my $certName = $_[1];
+ my $serial = $_[2];
+ setUsersLanguage($memid);
+
+ my %user=getUserData($memid);
+
+ my $body = _("Hi")." $user{fname},\n\n";
+ $body .= sprintf(_("Your certificate for '%s' with the serial number '%s' has been revoked, as per request.")."\n\n", $certName, $serial);
+ $body .= _("Best regards")."\n"._("CAcert.org Support!")."\n\n";
+ SysLog("Sending email to ".$user{"email"}."\n") if($debug);
+ sendmail($user{email}, "[CAcert.org] "._("Your certificate"), $body, "support\@cacert.org", "", "", "CAcert Support");
+}
@@ -1057,7 +1084,7 @@ sub HandleGPG()
while ( $rowdata = $sth->fetchrow_hashref() )
{
my %row=%{$rowdata};
-
+
my $prefix="gpg";
my $short=int($row{'id'}/1000);
my $csrname = "../csr/$prefix-".$row{'id'}.".csr";
@@ -1071,11 +1098,11 @@ sub HandleGPG()
#my $csrname = "../csr/gpg-".$row{'id'}.".csr";
#my $crtname = "../crt/gpg-".$row{'id'}.".crt";
-
+
SysLog "Opening $csrname\n";
-
+
my $crt="";
-
+
if(-s $csrname && open(IN,"<$csrname"))
{
undef $/;
@@ -1101,12 +1128,12 @@ sub HandleGPG()
{
SysLog "Opening $crtname\n";
setUsersLanguage($row{memid});
-
+
my $date=OpenPGPextractExpiryDate($crtname);
my %user=getUserData($row{memid});
-
+
$dbh->do("update `gpg` set `crt`='$crtname', issued=now(), `expire`='$date' where `id`='".$row{'id'}."'");
-
+
my $body = _("Hi")." $user{fname},\n\n";
$body .= sprintf(_("Your CAcert signed key for %s is available online at:")."\n\n", $row{'email'});
$body .= "https://www.cacert.org/gpg.php?id=3&cert=$row{id}\n\n";
@@ -1153,5 +1180,5 @@ while ( -f "./client.pl-active" )
my $timestamp=strftime("%m%d%H%M%Y.%S",gmtime);
Request($ver,0,0,0,0,0,0,0,$timestamp,"","");
sleep(1);
- usleep(1700000);
+ usleep(1700000);
}
diff --git a/includes/account.php b/includes/account.php
index 26845cd..6dacf2d 100644
--- a/includes/account.php
+++ b/includes/account.php
@@ -1560,7 +1560,12 @@ function buildSubjectFromSession() {
}
mysql_query("update `orgemailcerts` set `csr_name`='$CSRname' where `id`='$emailid'");
} else if($_REQUEST['keytype'] == "MS" || $_REQUEST['keytype']=="VI") {
- $csr = "-----BEGIN CERTIFICATE REQUEST-----\n".clean_csr($_REQUEST['CSR'])."-----END CERTIFICATE REQUEST-----\n";
+ $csr = clean_csr($_REQUEST['CSR']);
+ if(strpos($csr,"---BEGIN") === FALSE)
+ {
+ // In case the CSR is missing the ---BEGIN lines, add them automatically:
+ $csr = "-----BEGIN CERTIFICATE REQUEST-----\n".$csr."\n-----END CERTIFICATE REQUEST-----\n";
+ }
if (($weakKey = checkWeakKeyCSR($csr)) !== "")
{
diff --git a/includes/general.php b/includes/general.php
index 596cc49..17b449b 100644
--- a/includes/general.php
+++ b/includes/general.php
@@ -538,45 +538,109 @@
if(preg_match("/^([a-zA-Z0-9])+([a-zA-Z0-9\+\._-])*@([a-zA-Z0-9_-])+([a-zA-Z0-9\._-]+)+$/" , $email))
{
list($username,$domain)=explode('@',$email,2);
- $dom = escapeshellarg($domain);
- $line = trim(shell_exec("dig +short MX $dom 2>&1"));
-#echo $email."-$dom-$line-\n";
-#echo shell_exec("dig +short mx heise.de 2>&1")."-<br>\n";
-
- $list = explode("\n", $line);
- foreach($list as $row) {
- if(!strstr($row, " ")) {
- continue;
+ $mxhostrr = array();
+ $mxweight = array();
+ if( !getmxrr($domain, $mxhostrr, $mxweight) ) {
+ $mxhostrr = array($domain);
+ $mxweight = array(0);
+ } else if ( empty($mxhostrr) ) {
+ $mxhostrr = array($domain);
+ $mxweight = array(0);
+ }
+
+ $mxhostprio = array();
+ for($i = 0; $i < count($mxhostrr); $i++) {
+ $mx_host = trim($mxhostrr[$i], '.');
+ $mx_prio = $mxweight[$i];
+ if(empty($mxhostprio[$mx_prio])) {
+ $mxhostprio[$mx_prio] = array();
+ }
+ $mxhostprio[$mx_prio][] = $mx_host;
+ }
+
+ array_walk($mxhostprio, function(&$mx) { shuffle($mx); } );
+ ksort($mxhostprio);
+
+ $mxhosts = array();
+ foreach($mxhostprio as $mx_prio => $mxhostnames) {
+ foreach($mxhostnames as $mx_host) {
+ $mxhosts[] = $mx_host;
}
- list($pri, $mxhosts[]) = explode(" ", trim($row), 2);
}
- $mxhosts[] = $domain;
- array_walk($mxhosts, function(&$mx) { $mx = trim($mx, '.'); } );
foreach($mxhosts as $key => $domain)
{
- $fp = @fsockopen($domain,25,$errno,$errstr,5);
+ $fp_opt = array(
+ 'ssl' => array(
+ 'verify_peer' => false, // Opportunistic Encryption
+ )
+ );
+ $fp_ctx = stream_context_create($fp_opt);
+ $fp = @stream_socket_client("tcp://$domain:25",$errno,$errstr,5,STREAM_CLIENT_CONNECT,$fp_ctx);
if($fp)
{
+ stream_set_blocking($fp, true);
+
+ $has_starttls = false;
- $line = fgets($fp, 4096);
- while(substr($line, 0, 4) == "220-")
- $line = fgets($fp, 4096);
- if(substr($line, 0, 3) != "220")
+ do {
+ $line = fgets($fp, 4096);
+ } while(substr($line, 0, 4) == "220-");
+ if(substr($line, 0, 3) != "220") {
+ fclose($fp);
continue;
- fputs($fp, "HELO www.cacert.org\r\n");
- $line = fgets($fp, 4096);
- while(substr($line, 0, 3) == "220")
+ }
+
+ fputs($fp, "EHLO www.cacert.org\r\n");
+ do {
$line = fgets($fp, 4096);
- if(substr($line, 0, 3) != "250")
+ $has_starttls |= substr(trim($line),4) == "STARTTLS";
+ } while(substr($line, 0, 4) == "250-");
+ if(substr($line, 0, 3) != "250") {
+ fclose($fp);
continue;
- fputs($fp, "MAIL FROM:<returns@cacert.org>\r\n");
- $line = fgets($fp, 4096);
+ }
+
+ if($has_starttls) {
+ fputs($fp, "STARTTLS\r\n");
+ do {
+ $line = fgets($fp, 4096);
+ } while(substr($line, 0, 4) == "220-");
+ if(substr($line, 0, 3) != "220") {
+ fclose($fp);
+ continue;
+ }
+
+ stream_socket_enable_crypto($fp, true, STREAM_CRYPTO_METHOD_TLS_CLIENT);
+
+ fputs($fp, "EHLO www.cacert.org\r\n");
+ do {
+ $line = fgets($fp, 4096);
+ } while(substr($line, 0, 4) == "250-");
+ if(substr($line, 0, 3) != "250") {
+ fclose($fp);
+ continue;
+ }
+ }
- if(substr($line, 0, 3) != "250")
+ fputs($fp, "MAIL FROM:<returns@cacert.org>\r\n");
+ do {
+ $line = fgets($fp, 4096);
+ } while(substr($line, 0, 4) == "250-");
+ if(substr($line, 0, 3) != "250") {
+ fclose($fp);
continue;
+ }
+
fputs($fp, "RCPT TO:<$email>\r\n");
- $line = trim(fgets($fp, 4096));
+ do {
+ $line = fgets($fp, 4096);
+ } while(substr($line, 0, 4) == "250-");
+ if(substr($line, 0, 3) != "250") {
+ fclose($fp);
+ continue;
+ }
+
fputs($fp, "QUIT\r\n");
fclose($fp);
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/includes/keygen.php b/includes/keygen.php
index 2713a81..15dee8a 100644
--- a/includes/keygen.php
+++ b/includes/keygen.php
@@ -121,7 +121,7 @@ if (array_key_exists('HTTP_USER_AGENT',$_SERVER) && strstr($_SERVER['HTTP_USER_A
<input type="hidden" name="keytype" value="NS">
<?=_("Keysize:")?> <keygen name="SPKAC" challenge="<? $_SESSION['spkac_hash']=make_hash(); echo $_SESSION['spkac_hash']; ?>">
- <input type="submit" name="submit" value="<?=_("Create Certificate Request")?>">
+ <input type="submit" name="submit" value="<?=_("Generate key pair within browser")?>">
<input type="hidden" name="oldid" value="<?=intval($id)?>">
</form>
</p>
diff --git a/pages/account/16.php b/pages/account/16.php
index 8783bc5..829897f 100644
--- a/pages/account/16.php
+++ b/pages/account/16.php
@@ -104,6 +104,7 @@ if (array_key_exists('emails',$_SESSION['_config']) && is_array($_SESSION['_conf
</table>
<input type="hidden" name="oldid" value="<?=$id?>">
</form>
+<?=_("Please fill out the form, when all data is entered and you click \"Next\" you can add either a CSR (certificate signing request) or create a new key with your browser. Even in the case that a CSR is given the data from this form will be used for the certificate. Only the public key information of the CSR will be copied.")?>
<script language="javascript">
function showExpert(a)
diff --git a/pages/account/17.php b/pages/account/17.php
index 8ac8b65..0d5c2c7 100644
--- a/pages/account/17.php
+++ b/pages/account/17.php
@@ -17,3 +17,12 @@
*/
require_once($_SESSION['_config']['filepath'].'/includes/keygen.php');
+
+?>
+ -- <?=_("or")?> --
+ <form method="post" action="account.php">
+ <input type="hidden" name="keytype" value="VI">
+ <textarea rows="20" cols="40" name="CSR"></textarea>
+ <input type="submit" name="submit" value="<?=_("Submit CSR")?>">
+ <input type="hidden" name="oldid" value="17">
+ </form>
diff --git a/pages/account/19.php b/pages/account/19.php
index 959111f..d7259f3 100644
--- a/pages/account/19.php
+++ b/pages/account/19.php
@@ -52,6 +52,10 @@
showfooter();
exit;
}
+ } else if($row['keytype'] == "VI"){
+ showheader(_("My CAcert.org Account!"));
+ echo "<pre>".$cert."</pre>";
+ showfooter();
} else {
showheader(_("My CAcert.org Account!"));
?>
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/scripts/54at-ate-linz-email.txt b/scripts/54at-ate-linz-email.txt
new file mode 100644
index 0000000..1e9020e
--- /dev/null
+++ b/scripts/54at-ate-linz-email.txt
@@ -0,0 +1,91 @@
+[Deutsch]
+
+Es hat sich viel getan in den letzten Jahren. Eine ganze Reihe von bisher
+eher "muendlich ueberlieferten" Regeln wurden in Policies gegossen.
+Neue Prozeduren (z.B. die Assurer Challenge) und Verpflichtungen (z.B.
+in dem CAcert Community Agreement) wurden beschlossen. Die Assurer
+Training Events wollen versuchen, die ganzen Informationen unter's
+Volk zu bringen:
+
+- Welcher Satz fehlt auf alten CAP Formularen?
+- Warum soll ich mir R/L/O einpraegen?
+- Wie verhaelst du dich,
+ wenn du ein fremdes Ausweisdokument das erste Mal pruefst?
+
+Antworten auf diese und weitere Fragen erhaelst du bei den
+Assurer Training Events (ATEs).
+
+Darueberhinaus wird beim ATE der Vorgang der Identitaetsueberpruefung
+trainiert und auditiert, um die Qualitaet der Assurances in der
+taeglichen Praxis zu erfassen. Dabei gilt es moegliche Fehler und
+Fallstricke zu erkennen und aufzudecken. Die Assurer haben also die
+Moeglichkeit, sich mit den Fehlern auseinanderzusetzen und zu erfahren,
+wie diese vermieden werden koennen.
+
+Wie IanG sagte: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers, and include parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+Die kommende Veranstaltung in deiner Naehe findet statt am:
+
+- Freitag, den 16. Mai 2014
+- in der Zeit von: 19:00 - ca. 22:00 Uhr
+- Fachhochschule Oberoesterreich, Hauptgebaeude, 1.Stock, Raum SR A-103
+- Garnisonstrasse 21
+- 4020 Linz
+
+
+Details zum Veranstaltungsort und Anfahrthinweise findet Ihr im
+Wiki [https://wiki.cacert.org/Events/2014-05-16-ATELinz]
+
+
+Teilnehmer Registrierung mit Rueckantwort:
+ 'Ich moechte am ATE-Linz teilnehmen'
+
+Das Veranstaltungs-Team freut sich schon auf Eure Teilnahme.
+
+Kontakt: events@cacert.org
+
+
+
+[English]
+
+During the last years many changes took place inside CAcert. Many "oral"
+rules have been put into Policies. New procedures
+(e.g. Assurer Challenge) and obligations
+(e.g. CAcert Community Agreement) have been put into live.
+The Assurer Training Events (ATE) try to spread this information:
+
+- What is missing on the "old" CAP forms?
+- Why should I remember R/L/O?
+- What can you do if an Assuree shows an ID document unknown to you?
+
+These and more questions will be answered during the
+Assurer Training Events (ATEs)
+
+Furthermore, the ATE trains how to do assurances and audits assurances,
+to measure the quality of assurances in the daily routine. Here are some
+possible errors and pitfalls which need to be found. Assurers have the
+opportunity to see those errors and how to avoid them.
+
+As IanG said: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers and includes parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+The next event held in your area will be:
+
+- Friday, May 16th 2014
+- during: 19:00 - ca. 22:00
+- University of Applied Sciences Upper Austria, Room SR A-103
+- Garnisonstrasse 21
+- 4020 Linz
+
+
+Details to the location can be found:
+Wiki [https://wiki.cacert.org/Events/2014-05-16-ATELinz]
+
+User reply for registration: 'I will attend the ATE-Linz'
+
+The event team is looking forward for your attendance:
+
+Contact: events@cacert.org
diff --git a/scripts/54at-ate-linz-mail.php.txt b/scripts/54at-ate-linz-mail.php.txt
new file mode 100644
index 0000000..5ffdb24
--- /dev/null
+++ b/scripts/54at-ate-linz-mail.php.txt
@@ -0,0 +1,140 @@
+#!/usr/bin/php -q
+<? /*
+ LibreSSL - CAcert web application
+ Copyright (C) 2004-2013 CAcert Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 of the License.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ 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
+*/
+ include_once("../includes/mysql.php");
+
+ $lines = "";
+ $fp = fopen("54at-ate-linz-email.txt", "r");
+ while(!feof($fp))
+ {
+ $line = trim(fgets($fp, 4096));
+ $lines .= wordwrap($line, 75, "\n")."\n";
+ }
+ fclose($fp);
+
+
+// $locid = intval($_REQUEST['location']);
+// $maxdist = intval($_REQUEST['maxdist']);
+// maxdist in [Km]
+ $maxdist = 200;
+
+
+// location location.ID
+// verified: 29.4.09 u.schroeter
+// $locid = 7902857; // Paris
+// $locid = 238568; // Bielefeld
+// $locid = 715191; // Hamburg
+// $locid = 1102495; // London
+// $locid = 606058; // Frankfurt
+// $locid = 1775784; // Stuttgart
+// $locid = 228950; // Berlin
+// $locid = 606058; // Frankfurt
+// $locid = 599389; // Flensburg
+// $locid = 61065; // Amsterdam, Eemnes
+// $locid = 228950; // Berlin
+// $locid = 2138880; // Baltimore (Baltimore (city)), Maryland, United States
+// $locid = 1486658; // Potsdam
+// $locid = 664715; // Goteborg, Vastra Gotaland, Sweden
+// $locid = 2094781; // Mission Hills (Los Angeles), California, United States
+// $locid = 423655; // Copenhagen, Kobenhavn*, Denmark
+// $locid = 2093625; // Los Angeles, CA ???
+// $locid = 2094326 // Los Angeles (Los Angeles), California, United States
+// $locid = 2257312; // Sydney, New South Wales, Australia
+// $locid = 572764; // Essen, Nordrhein-Westfalen, Germany
+// $locid = 78; // Aachen, Nordrhein-Westfalen, Germany
+// $locid = 1260319; // Muenchen
+// $locid = 266635; // Bonn, Nordrhein-Westfalen, Germany
+// $locid = 873779; // Karlsruhe, Baden-Wuerttemberg, Germany
+// $locid = 520340; // Dusseldorf, Nordrhein-Westfalen, Germany
+// $locid = 2262656; // Melbourne, Victoria, Australia
+// $locid = 2185076; // Raleigh (Wake), North Carolina, United States
+
+// CAcert Assurance and Keysigning event at FUDcon, Lawrence, KS, Jan 19th 2013
+// $locid = 2126955; // Lawrence (Douglas), Kansas, United States
+// $eventname = "CAcert Assurance and Keysigning at FUDcon Lawrence, KS";
+// $city = "January 19th 2013";
+
+// ATE-Kiel 2013-02-11
+// $locid = 919560; // Kiel, Schleswig-Holstein, Germany
+// $eventname = "ATE-Kiel";
+// $city = "11. Februar 2013";
+
+// Linuxtag, Berlin, May 22-25, 2013,
+// $locid = 228950; // Berlin
+// $eventname = "Linuxtag Berlin";
+// $city = "22.-25. Mai, 2013";
+
+// $locid = 1117395; // Lubeck Hansestadt, Schleswig-Holstein, Germany
+// $eventname = "ATE-Luebeck";
+// $city = "07. Juni 2013";
+
+// $locid = 675661; // Graz, Steiermark, Austria
+// $eventname = "ATE-Graz";
+// $city = "16. August 2013";
+
+// $locid = 1992733; // Wien, Wien, Austria
+// $eventname = "ATE-Wien";
+// $city = "15. Oktober 2013";
+
+// $locid = 54334; // Amberg, Bayern, Germany
+// $eventname = "ATE-Amberg";
+// $city = "06. Januar 2014";
+
+ $locid = 1089877; // Linz, Oberoesterreich, Austria
+ $eventname = "ATE-Linz";
+ $city = "16. Mai 2014";
+
+
+
+ $query = "select * from `locations` where `id`='$locid'";
+ $loc = mysql_fetch_assoc(mysql_query($query));
+
+ $query = "SELECT ROUND(6378.137 * ACOS(0.9999999*((SIN(PI() * $loc[lat] / 180) * SIN(PI() * `locations`.`lat` / 180)) +
+ (COS(PI() * $loc[lat] / 180 ) * COS(PI() * `locations`.`lat` / 180) *
+ COS(PI() * `locations`.`long` / 180 - PI() * $loc[long] / 180)))), -1) AS `distance`, sum(`points`) as pts, `users`.*
+ FROM `locations`
+ inner join `users` on `users`.`locid` = `locations`.`id`
+ inner join `alerts` on `users`.`id`=`alerts`.`memid`
+ inner join `notary` on `users`.`id`=`notary`.`to`
+ WHERE (`alerts`.`general`=1 OR `alerts`.`country`=1 OR `alerts`.`regional`=1 OR `alerts`.`radius`=1)
+ GROUP BY `users`.`id`
+ HAVING `distance` <= '$maxdist'
+ ORDER BY `distance` ";
+ echo $query;
+
+ // comment next line when starting to send mail not only to me
+ // $query = "select * from `users` where `email` like 'cacerttest%'";
+
+ $res = mysql_query($query);
+ $xrows = mysql_num_rows($res);
+
+ while($row = mysql_fetch_assoc($res))
+ {
+ // uncomment next line to send mails ...
+ sendmail($row['email'], "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ }
+ // 1x cc to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ // 1x mailing report to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+
+ // 1x mailing report to Arbitrator of case http://wiki.cacert.org/wiki/Arbitrations/a20090525.1
+ sendmail("p.dunkel@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ echo "invitation sent to $xrows recipients.\n";
+
+?>
diff --git a/scripts/55de-ate-wiesbaden-email.txt b/scripts/55de-ate-wiesbaden-email.txt
new file mode 100644
index 0000000..4880388
--- /dev/null
+++ b/scripts/55de-ate-wiesbaden-email.txt
@@ -0,0 +1,46 @@
+Es hat sich viel getan in den letzten Jahren. Eine ganze Reihe von bisher
+eher "muendlich ueberlieferten" Regeln wurden in Policies gegossen.
+Neue Prozeduren (z.B. die Assurer Challenge) und Verpflichtungen (z.B.
+in dem CAcert Community Agreement) wurden beschlossen. Die Assurer
+Training Events wollen versuchen, die ganzen Informationen unter's
+Volk zu bringen:
+
+- Welcher Satz fehlt auf alten CAP Formularen?
+- Warum soll ich mir R/L/O einpraegen?
+- Wie verhaelst du dich,
+ wenn du ein fremdes Ausweisdokument das erste Mal pruefst?
+
+Antworten auf diese und weitere Fragen erhaelst du bei den
+Assurer Training Events (ATEs).
+
+Darueberhinaus wird beim ATE der Vorgang der Identitaetsueberpruefung
+trainiert und auditiert, um die Qualitaet der Assurances in der
+taeglichen Praxis zu erfassen. Dabei gilt es moegliche Fehler und
+Fallstricke zu erkennen und aufzudecken. Die Assurer haben also die
+Moeglichkeit, sich mit den Fehlern auseinanderzusetzen und zu erfahren,
+wie diese vermieden werden koennen.
+
+Wie IanG sagte: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers, and include parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+Die kommende Veranstaltung in deiner Naehe findet statt am:
+
+- Donnerstag, den 22. Mai 2014
+- in der Zeit von: 19:00 - ca. 22:00 Uhr
+- CCCMZ e.V.
+- Sedanplatz 7
+- 65183 Wiesbaden
+
+
+
+Details zum Veranstaltungsort und Anfahrthinweise findet Ihr im Wiki
+[https://wiki.cacert.org/Events/2014-05-22ATE-Wiesbaden] und Blog
+[https://www.cccmz.de/cacert-assurer-training-event-22-mai-2014-in-wiesbaden]
+
+Teilnehmer Registrierung mit Rueckantwort:
+ 'Ich moechte am ATE-Wiesbaden teilnehmen'
+
+Das Veranstaltungs-Team freut sich schon auf Eure Teilnahme.
+
+Kontakt: events@cacert.org
diff --git a/scripts/55de-ate-wiesbaden-mail.php.txt b/scripts/55de-ate-wiesbaden-mail.php.txt
new file mode 100644
index 0000000..26666e4
--- /dev/null
+++ b/scripts/55de-ate-wiesbaden-mail.php.txt
@@ -0,0 +1,122 @@
+#!/usr/bin/php -q
+<? /*
+ LibreSSL - CAcert web application
+ Copyright (C) 2004-2013 CAcert Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 of the License.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ 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
+*/
+ include_once("../includes/mysql.php");
+
+ $lines = "";
+ $fp = fopen("55de-ate-wiesbaden-email.txt", "r");
+ while(!feof($fp))
+ {
+ $line = trim(fgets($fp, 4096));
+ $lines .= wordwrap($line, 75, "\n")."\n";
+ }
+ fclose($fp);
+
+
+// $locid = intval($_REQUEST['location']);
+// $maxdist = intval($_REQUEST['maxdist']);
+// maxdist in [Km]
+ $maxdist = 200;
+
+
+// location location.ID
+// verified: 29.4.09 u.schroeter
+// $locid = 7902857; // Paris
+// $locid = 238568; // Bielefeld
+// $locid = 715191; // Hamburg
+// $locid = 1102495; // London
+// $locid = 606058; // Frankfurt
+// $locid = 1775784; // Stuttgart
+// $locid = 228950; // Berlin
+// $locid = 606058; // Frankfurt
+// $locid = 599389; // Flensburg
+// $locid = 61065; // Amsterdam, Eemnes
+// $locid = 228950; // Berlin
+// $locid = 2138880; // Baltimore (Baltimore (city)), Maryland, United States
+// $locid = 1486658; // Potsdam
+// $locid = 664715; // Goteborg, Vastra Gotaland, Sweden
+// $locid = 2094781; // Mission Hills (Los Angeles), California, United States
+// $locid = 423655; // Copenhagen, Kobenhavn*, Denmark
+// $locid = 2093625; // Los Angeles, CA ???
+// $locid = 2094326 // Los Angeles (Los Angeles), California, United States
+// $locid = 2257312; // Sydney, New South Wales, Australia
+// $locid = 572764; // Essen, Nordrhein-Westfalen, Germany
+// $locid = 78; // Aachen, Nordrhein-Westfalen, Germany
+// $locid = 1260319; // Muenchen
+// $locid = 266635; // Bonn, Nordrhein-Westfalen, Germany
+// $locid = 873779; // Karlsruhe, Baden-Wuerttemberg, Germany
+// $locid = 520340; // Dusseldorf, Nordrhein-Westfalen, Germany
+// $locid = 2262656; // Melbourne, Victoria, Australia
+// $locid = 2185076; // Raleigh (Wake), North Carolina, United States
+// $locid = 2126955; // Lawrence (Douglas), Kansas, United States
+// $locid = 919560; // Kiel, Schleswig-Holstein, Germany
+// $locid = 228950; // Berlin
+// $locid = 1117395; // Lubeck Hansestadt, Schleswig-Holstein, Germany
+// $locid = 675661; // Graz, Steiermark, Austria
+// $locid = 1992733; // Wien, Wien, Austria
+
+// $locid = 54334; // Amberg, Bayern, Germany
+// $eventname = "ATE-Amberg";
+// $city = "06. Januar 2014";
+
+// $locid = 1089877; // Linz, Oberoesterreich, Austria
+// $eventname = "ATE-Linz";
+// $city = "16. Mai 2014";
+
+ $locid = 1993029; // Wiesbaden, Hessen, Germany
+ $eventname = "ATE-Wiesbaden";
+ $city = "22. Mai 2014";
+
+
+ $query = "select * from `locations` where `id`='$locid'";
+ $loc = mysql_fetch_assoc(mysql_query($query));
+
+ $query = "SELECT ROUND(6378.137 * ACOS(0.9999999*((SIN(PI() * $loc[lat] / 180) * SIN(PI() * `locations`.`lat` / 180)) +
+ (COS(PI() * $loc[lat] / 180 ) * COS(PI() * `locations`.`lat` / 180) *
+ COS(PI() * `locations`.`long` / 180 - PI() * $loc[long] / 180)))), -1) AS `distance`, sum(`points`) as pts, `users`.*
+ FROM `locations`
+ inner join `users` on `users`.`locid` = `locations`.`id`
+ inner join `alerts` on `users`.`id`=`alerts`.`memid`
+ inner join `notary` on `users`.`id`=`notary`.`to`
+ WHERE (`alerts`.`general`=1 OR `alerts`.`country`=1 OR `alerts`.`regional`=1 OR `alerts`.`radius`=1)
+ GROUP BY `users`.`id`
+ HAVING `distance` <= '$maxdist'
+ ORDER BY `distance` ";
+ echo $query;
+
+ // comment next line when starting to send mail not only to me
+ // $query = "select * from `users` where `email` like 'cacerttest%'";
+
+ $res = mysql_query($query);
+ $xrows = mysql_num_rows($res);
+
+ while($row = mysql_fetch_assoc($res))
+ {
+ // uncomment next line to send mails ...
+ sendmail($row['email'], "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ }
+ // 1x cc to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ // 1x mailing report to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+
+ // 1x mailing report to Arbitrator of case http://wiki.cacert.org/wiki/Arbitrations/a20090525.1
+ sendmail("p.dunkel@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ echo "invitation sent to $xrows recipients.\n";
+
+?>
diff --git a/scripts/56at-ate-oberwart-email.txt b/scripts/56at-ate-oberwart-email.txt
new file mode 100644
index 0000000..b15f82e
--- /dev/null
+++ b/scripts/56at-ate-oberwart-email.txt
@@ -0,0 +1,93 @@
+[Deutsch]
+
+Es hat sich viel getan im letzten Jahr. Eine ganze Reihe von bisher
+eher "muendlich ueberlieferten" Regeln wurden in Policies gegossen.
+Neue Prozeduren (z.B. die Assurer Challenge) und Verpflichtungen (z.B.
+in dem CAcert Community Agreement) wurden beschlossen. Die Assurer
+Training Events wollen versuchen, die ganzen Informationen unter's
+Volk zu bringen:
+
+- Welcher Satz fehlt auf alten CAP Formularen?
+- Warum soll ich mir R/L/O einpraegen?
+- Wie verhaelst du dich,
+ wenn du ein fremdes Ausweisdokument das ersteMal pruefst?
+
+Antworten auf diese und weitere Fragen erhaelst du bei den
+Assurer Training Events (ATEs).
+
+Darueberhinaus wird beim ATE der Vorgang der Identitaetsueberpruefung
+trainiert und auditiert, um die Qualitaet der Assurances in der
+taeglichen Praxis zu erfassen. Dabei gilt es moegliche Fehler und
+Fallstricke zu erkennen und aufzudecken. Die Assurer haben also die
+Moeglichkeit, sich mit den Fehlern auseinanderzusetzen und zu erfahren,
+wie diese vermieden werden koennen.
+
+Wie IanG sagte: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers, and include parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+Die kommende Veranstaltung in deiner Naehe findet statt am:
+
+- Freitag, den 27. Juni 2014
+- in der Zeit von: 19:00 - ca. 22:00 Uhr
+- Rotes Kreuz Schulungszentrum Süd (Hotel zur Pinka), Seminarraum "Pinkasaal"
+- Grazerstrasse 71
+- A-7400 Oberwart
+
+Die Arbeitssprache der Veranstaltung ist Deutsch
+
+Details zum Veranstaltungsort und Anfahrthinweise findet Ihr im
+Wiki [https://wiki.cacert.org/Events/2014-06-27-ATEOberwart]
+
+
+Teilnehmer Registrierung mit Rueckantwort:
+ 'Ich moechte am ATE-Oberwart teilnehmen'
+
+Das Veranstaltungs-Team freut sich schon auf Eure Teilnahme.
+
+Kontakt: events@cacert.org
+
+
+
+[English]
+
+During the last year many changes took place inside CAcert. Many "oral"
+rules have been put into Policies. New procedures
+(e.g. Assurer Challenge) and obligations
+(e.g. CAcert Community Agreement) have been put into live.
+The Assurer Training Events (ATE) try to spread this information:
+
+- What is missing on the "old" CAP forms?
+- Why should I remember R/L/O?
+- What can you do if an Assuree shows an ID document unknown to you?
+
+These and more questions will be answered during the
+Assurer Training Events (ATEs)
+
+Furthermore, the ATE trains how to do assurances and audits assurances,
+to measure the quality of assurances in the daily routine. Here are some
+possible errors and pitfalls which need to be found. Assurers have the
+opportunity to see those errors and how to avoid them.
+
+As IanG said: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers and includes parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+The next event held in your area will be:
+
+- Friday, May 16th 2014
+- during: 19:00 - ca. 22:00
+- Rotes Kreuz Schulungszentrum Süd (Hotel zur Pinka), Seminarraum "Pinkasaal"
+- Grazerstrasse 71
+- A-7400 Oberwart
+
+The working language of this event is GERMAN
+
+Details to the location can be found:
+Wiki [https://wiki.cacert.org/Events/2014-06-27-ATEOberwart]
+
+User reply for registration: 'I will attend the ATE-Oberwart'
+
+The event team is looking forward for your attendance:
+
+Contact: events@cacert.org
diff --git a/scripts/56at-ate-oberwart-mail.php.txt b/scripts/56at-ate-oberwart-mail.php.txt
new file mode 100644
index 0000000..1035f17
--- /dev/null
+++ b/scripts/56at-ate-oberwart-mail.php.txt
@@ -0,0 +1,147 @@
+#!/usr/bin/php -q
+<? /*
+ LibreSSL - CAcert web application
+ Copyright (C) 2004-2013 CAcert Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 of the License.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ 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
+*/
+ include_once("../includes/mysql.php");
+
+ $lines = "";
+ $fp = fopen("56at-ate-oberwart-email.txt", "r");
+ while(!feof($fp))
+ {
+ $line = trim(fgets($fp, 4096));
+ $lines .= wordwrap($line, 75, "\n")."\n";
+ }
+ fclose($fp);
+
+
+// $locid = intval($_REQUEST['location']);
+// $maxdist = intval($_REQUEST['maxdist']);
+// maxdist in [Km]
+ $maxdist = 200;
+
+
+// location location.ID
+// verified: 29.4.09 u.schroeter
+// $locid = 7902857; // Paris
+// $locid = 238568; // Bielefeld
+// $locid = 715191; // Hamburg
+// $locid = 1102495; // London
+// $locid = 606058; // Frankfurt
+// $locid = 1775784; // Stuttgart
+// $locid = 228950; // Berlin
+// $locid = 606058; // Frankfurt
+// $locid = 599389; // Flensburg
+// $locid = 61065; // Amsterdam, Eemnes
+// $locid = 228950; // Berlin
+// $locid = 2138880; // Baltimore (Baltimore (city)), Maryland, United States
+// $locid = 1486658; // Potsdam
+// $locid = 664715; // Goteborg, Vastra Gotaland, Sweden
+// $locid = 2094781; // Mission Hills (Los Angeles), California, United States
+// $locid = 423655; // Copenhagen, Kobenhavn*, Denmark
+// $locid = 2093625; // Los Angeles, CA ???
+// $locid = 2094326 // Los Angeles (Los Angeles), California, United States
+// $locid = 2257312; // Sydney, New South Wales, Australia
+// $locid = 572764; // Essen, Nordrhein-Westfalen, Germany
+// $locid = 78; // Aachen, Nordrhein-Westfalen, Germany
+// $locid = 1260319; // Muenchen
+// $locid = 266635; // Bonn, Nordrhein-Westfalen, Germany
+// $locid = 873779; // Karlsruhe, Baden-Wuerttemberg, Germany
+// $locid = 520340; // Dusseldorf, Nordrhein-Westfalen, Germany
+// $locid = 2262656; // Melbourne, Victoria, Australia
+// $locid = 2185076; // Raleigh (Wake), North Carolina, United States
+
+// CAcert Assurance and Keysigning event at FUDcon, Lawrence, KS, Jan 19th 2013
+// $locid = 2126955; // Lawrence (Douglas), Kansas, United States
+// $eventname = "CAcert Assurance and Keysigning at FUDcon Lawrence, KS";
+// $city = "January 19th 2013";
+
+// ATE-Kiel 2013-02-11
+// $locid = 919560; // Kiel, Schleswig-Holstein, Germany
+// $eventname = "ATE-Kiel";
+// $city = "11. Februar 2013";
+
+// Linuxtag, Berlin, May 22-25, 2013,
+// $locid = 228950; // Berlin
+// $eventname = "Linuxtag Berlin";
+// $city = "22.-25. Mai, 2013";
+
+// $locid = 1117395; // Lubeck Hansestadt, Schleswig-Holstein, Germany
+// $eventname = "ATE-Luebeck";
+// $city = "07. Juni 2013";
+
+// $locid = 675661; // Graz, Steiermark, Austria
+// $eventname = "ATE-Graz";
+// $city = "16. August 2013";
+
+// $locid = 1992733; // Wien, Wien, Austria
+// $eventname = "ATE-Wien";
+// $city = "15. Oktober 2013";
+
+// $locid = ; 54334 // Amberg, Bayern, Germany
+// $eventname = "ATE-Amberg";
+// $city = "06. Januar 2014";
+
+// $locid = 1089877; // Linz, Oberoesterreich, Austria
+// $eventname = "ATE-Linz";
+// $city = "16. Mai 2014";
+
+// $locid = 1993029; // Wiesbaden, Hessen, Germany
+// $eventname = "ATE-Wiesbaden";
+// $city = "22. Mai 2014";
+
+
+ $locid = 1356196; // Oberwart, Burgenland, Germany
+ $eventname = "ATE-Oberwart (Korrektur)";
+ $city = "27. Juni 2014";
+
+ $query = "select * from `locations` where `id`='$locid'";
+ $loc = mysql_fetch_assoc(mysql_query($query));
+
+ $query = "SELECT ROUND(6378.137 * ACOS(0.9999999*((SIN(PI() * $loc[lat] / 180) * SIN(PI() * `locations`.`lat` / 180)) +
+ (COS(PI() * $loc[lat] / 180 ) * COS(PI() * `locations`.`lat` / 180) *
+ COS(PI() * `locations`.`long` / 180 - PI() * $loc[long] / 180)))), -1) AS `distance`, sum(`points`) as pts, `users`.*
+ FROM `locations`
+ inner join `users` on `users`.`locid` = `locations`.`id`
+ inner join `alerts` on `users`.`id`=`alerts`.`memid`
+ inner join `notary` on `users`.`id`=`notary`.`to`
+ WHERE (`alerts`.`general`=1 OR `alerts`.`country`=1 OR `alerts`.`regional`=1 OR `alerts`.`radius`=1)
+ GROUP BY `users`.`id`
+ HAVING `distance` <= '$maxdist'
+ ORDER BY `distance` ";
+ echo $query;
+
+ // comment next line when starting to send mail not only to me
+ // $query = "select * from `users` where `email` like 'cacerttest%'";
+
+ $res = mysql_query($query);
+ $xrows = mysql_num_rows($res);
+
+ while($row = mysql_fetch_assoc($res))
+ {
+ // uncomment next line to send mails ...
+ sendmail($row['email'], "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ }
+ // 1x cc to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ // 1x mailing report to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+
+ // 1x mailing report to Arbitrator of case http://wiki.cacert.org/wiki/Arbitrations/a20090525.1
+ sendmail("p.dunkel@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ echo "invitation sent to $xrows recipients.\n";
+
+?>
diff --git a/scripts/57at-ate-graz-email.txt b/scripts/57at-ate-graz-email.txt
new file mode 100644
index 0000000..e9b4a63
--- /dev/null
+++ b/scripts/57at-ate-graz-email.txt
@@ -0,0 +1,91 @@
+[Deutsch]
+
+Es hat sich viel getan im letzten Jahr. Eine ganze Reihe von bisher
+eher "muendlich ueberlieferten" Regeln wurden in Policies gegossen.
+Neue Prozeduren (z.B. die Assurer Challenge) und Verpflichtungen (z.B.
+in dem CAcert Community Agreement) wurden beschlossen. Die Assurer
+Training Events wollen versuchen, die ganzen Informationen unter's
+Volk zu bringen:
+
+- Welcher Satz fehlt auf alten CAP Formularen?
+- Warum soll ich mir R/L/O einpraegen?
+- Wie verhaelst du dich,
+ wenn du ein fremdes Ausweisdokument das erste Mal pruefst?
+
+Antworten auf diese und weitere Fragen erhaelst du bei den
+Assurer Training Events (ATEs).
+
+Darueberhinaus wird beim ATE der Vorgang der Identitaetsueberpruefung
+trainiert und auditiert, um die Qualitaet der Assurances in der
+taeglichen Praxis zu erfassen. Dabei gilt es moegliche Fehler und
+Fallstricke zu erkennen und aufzudecken. Die Assurer haben also die
+Moeglichkeit, sich mit den Fehlern auseinanderzusetzen und zu erfahren,
+wie diese vermieden werden koennen.
+
+Wie IanG sagte: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers, and include parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+Die kommende Veranstaltung in deiner Naehe findet statt am:
+
+- Donnerstag, den 13. November 2014
+- in der Zeit von: 19:00 - ca. 22:00 Uhr
+- realraum
+- Brockmanngasse 15
+- 8010 Graz
+
+
+Details zum Veranstaltungsort und Anfahrthinweise findet Ihr im
+Wiki [http://wiki.cacert.org/Events/2014-11-13-ATEGraz]
+Blog [http://blog.cacert.org/2014/10/ate-graz-2014-11-13/]
+
+Teilnehmer Registrierung mit Rueckantwort:
+ 'Ich moechte am ATE-Graz teilnehmen'
+
+Das Veranstaltungs-Team freut sich schon auf Eure Teilnahme.
+
+Kontakt: events@cacert.org
+
+
+
+[English]
+
+During the last year many changes took place inside CAcert. Many "oral"
+rules have been put into Policies. New procedures
+(e.g. Assurer Challenge) and obligations
+(e.g. CAcert Community Agreement) have been put into live.
+The Assurer Training Events (ATE) try to spread this information:
+
+- What is missing on the "old" CAP forms?
+- Why should I remember R/L/O?
+- What can you do if an Assuree shows an ID document unknown to you?
+
+These and more questions will be answered during the
+Assurer Training Events (ATEs)
+
+Furthermore, the ATE trains how to do assurances and audits assurances,
+to measure the quality of assurances in the daily routine. Here are some
+possible errors and pitfalls which need to be found. Assurers have the
+opportunity to see those errors and how to avoid them.
+
+As IanG said: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers and includes parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+The next event held in your area will be:
+
+- Thursday, November 13th 2014
+- during: 19:00 - ca. 22:00
+- realraum
+- Brockmanngasse 15
+- 8010 Graz
+
+Details to the location can be found:
+Wiki [http://wiki.cacert.org/Events/2014-11-13-ATEGraz]
+Blog [http://blog.cacert.org/2014/10/ate-graz-2014-11-13/]
+
+User reply for registration: 'I will attend the ATE-Graz'
+
+The event team is looking forward for your attendance:
+
+Contact: events@cacert.org
diff --git a/scripts/57at-ate-graz-mail.php.txt b/scripts/57at-ate-graz-mail.php.txt
new file mode 100644
index 0000000..0e6786f
--- /dev/null
+++ b/scripts/57at-ate-graz-mail.php.txt
@@ -0,0 +1,130 @@
+#!/usr/bin/php -q
+<? /*
+ LibreSSL - CAcert web application
+ Copyright (C) 2004-2013 CAcert Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 of the License.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ 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
+*/
+ include_once("../includes/mysql.php");
+
+ $lines = "";
+ $fp = fopen("57at-ate-graz-email.txt", "r");
+ while(!feof($fp))
+ {
+ $line = trim(fgets($fp, 4096));
+ $lines .= wordwrap($line, 75, "\n")."\n";
+ }
+ fclose($fp);
+
+
+// $locid = intval($_REQUEST['location']);
+// $maxdist = intval($_REQUEST['maxdist']);
+// maxdist in [Km]
+ $maxdist = 200;
+
+
+// location location.ID
+// verified: 29.4.09 u.schroeter
+// $locid = 7902857; // Paris
+// $locid = 238568; // Bielefeld
+// $locid = 715191; // Hamburg
+// $locid = 1102495; // London
+// $locid = 606058; // Frankfurt
+// $locid = 1775784; // Stuttgart
+// $locid = 228950; // Berlin
+// $locid = 606058; // Frankfurt
+// $locid = 599389; // Flensburg
+// $locid = 61065; // Amsterdam, Eemnes
+// $locid = 228950; // Berlin
+// $locid = 2138880; // Baltimore (Baltimore (city)), Maryland, United States
+// $locid = 1486658; // Potsdam
+// $locid = 664715; // Goteborg, Vastra Gotaland, Sweden
+// $locid = 2094781; // Mission Hills (Los Angeles), California, United States
+// $locid = 423655; // Copenhagen, Kobenhavn*, Denmark
+// $locid = 2093625; // Los Angeles, CA ???
+// $locid = 2094326 // Los Angeles (Los Angeles), California, United States
+// $locid = 2257312; // Sydney, New South Wales, Australia
+// $locid = 572764; // Essen, Nordrhein-Westfalen, Germany
+// $locid = 78; // Aachen, Nordrhein-Westfalen, Germany
+// $locid = 1260319; // Muenchen
+// $locid = 266635; // Bonn, Nordrhein-Westfalen, Germany
+// $locid = 873779; // Karlsruhe, Baden-Wuerttemberg, Germany
+// $locid = 520340; // Dusseldorf, Nordrhein-Westfalen, Germany
+// $locid = 2262656; // Melbourne, Victoria, Australia
+// $locid = 2185076; // Raleigh (Wake), North Carolina, United States
+// $locid = 2126955; // Lawrence (Douglas), Kansas, United States
+// $locid = 919560; // Kiel, Schleswig-Holstein, Germany
+// $locid = 228950; // Berlin
+// $locid = 1117395; // Lubeck Hansestadt, Schleswig-Holstein, Germany
+// $locid = 675661; // Graz, Steiermark, Austria
+// $locid = 1992733; // Wien, Wien, Austria
+
+// $locid = ; 54334 // Amberg, Bayern, Germany
+// $eventname = "ATE-Amberg";
+// $city = "06. Januar 2014";
+
+// $locid = 1089877; // Linz, Oberoesterreich, Austria
+// $eventname = "ATE-Linz";
+// $city = "16. Mai 2014";
+
+// $locid = 1993029; // Wiesbaden, Hessen, Germany
+// $eventname = "ATE-Wiesbaden";
+// $city = "22. Mai 2014";
+
+
+// $locid = 1356196; // Oberwart, Burgenland, Germany
+// $eventname = "ATE-Oberwart (Korrektur)";
+// $city = "27. Juni 2014";
+
+ $locid = 675661; // Graz, Steiermark, Austria
+ $eventname = "ATE-Graz";
+ $city = "13. November 2014";
+
+ $query = "select * from `locations` where `id`='$locid'";
+ $loc = mysql_fetch_assoc(mysql_query($query));
+
+ $query = "SELECT ROUND(6378.137 * ACOS(0.9999999*((SIN(PI() * $loc[lat] / 180) * SIN(PI() * `locations`.`lat` / 180)) +
+ (COS(PI() * $loc[lat] / 180 ) * COS(PI() * `locations`.`lat` / 180) *
+ COS(PI() * `locations`.`long` / 180 - PI() * $loc[long] / 180)))), -1) AS `distance`, sum(`points`) as pts, `users`.*
+ FROM `locations`
+ inner join `users` on `users`.`locid` = `locations`.`id`
+ inner join `alerts` on `users`.`id`=`alerts`.`memid`
+ inner join `notary` on `users`.`id`=`notary`.`to`
+ WHERE (`alerts`.`general`=1 OR `alerts`.`country`=1 OR `alerts`.`regional`=1 OR `alerts`.`radius`=1)
+ GROUP BY `users`.`id`
+ HAVING `distance` <= '$maxdist'
+ ORDER BY `distance` ";
+ echo $query;
+
+ // comment next line when starting to send mail not only to me
+ // $query = "select * from `users` where `email` like 'cacerttest%'";
+
+ $res = mysql_query($query);
+ $xrows = mysql_num_rows($res);
+
+ while($row = mysql_fetch_assoc($res))
+ {
+ // uncomment next line to send mails ...
+ sendmail($row['email'], "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ }
+ // 1x cc to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ // 1x mailing report to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+
+ // 1x mailing report to Arbitrator of case http://wiki.cacert.org/wiki/Arbitrations/a20090525.1
+ sendmail("p.dunkel@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ echo "invitation sent to $xrows recipients.\n";
+
+?>
diff --git a/scripts/58at-ate-wien-email.txt b/scripts/58at-ate-wien-email.txt
new file mode 100644
index 0000000..4e55b56
--- /dev/null
+++ b/scripts/58at-ate-wien-email.txt
@@ -0,0 +1,91 @@
+[Deutsch]
+
+Es hat sich viel getan im letzten Jahr. Eine ganze Reihe von bisher
+eher "muendlich ueberlieferten" Regeln wurden in Policies gegossen.
+Neue Prozeduren (z.B. die Assurer Challenge) und Verpflichtungen (z.B.
+in dem CAcert Community Agreement) wurden beschlossen. Die Assurer
+Training Events wollen versuchen, die ganzen Informationen unter's
+Volk zu bringen:
+
+- Welcher Satz fehlt auf alten CAP Formularen?
+- Warum soll ich mir R/L/O einpraegen?
+- Wie verhaelst du dich,
+ wenn du ein fremdes Ausweisdokument das erste Mal pruefst?
+
+Antworten auf diese und weitere Fragen erhaelst du bei den
+Assurer Training Events (ATEs).
+
+Darueberhinaus wird beim ATE der Vorgang der Identitaetsueberpruefung
+trainiert und auditiert, um die Qualitaet der Assurances in der
+taeglichen Praxis zu erfassen. Dabei gilt es moegliche Fehler und
+Fallstricke zu erkennen und aufzudecken. Die Assurer haben also die
+Moeglichkeit, sich mit den Fehlern auseinanderzusetzen und zu erfahren,
+wie diese vermieden werden koennen.
+
+Wie IanG sagte: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers, and include parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+Die kommende Veranstaltung in deiner Naehe findet statt am:
+
+- Mittwoch, den 19. November 2014
+- in der Zeit von: 19:00 - ca. 22:00 Uhr
+- Metalab Wien
+- Rathausstrasse 6
+- 1010 Wien
+
+
+Details zum Veranstaltungsort und Anfahrthinweise findet Ihr im
+Wiki [http://wiki.cacert.org/Events/2014-11-19-ATEWien]
+Blog [http://blog.cacert.org/2014/10/ate-wien-2014-11-19/]
+
+Teilnehmer Registrierung mit Rueckantwort:
+ 'Ich moechte am ATE-Wien teilnehmen'
+
+Das Veranstaltungs-Team freut sich schon auf Eure Teilnahme.
+
+Kontakt: events@cacert.org
+
+
+
+[English]
+
+During the last year many changes took place inside CAcert. Many "oral"
+rules have been put into Policies. New procedures
+(e.g. Assurer Challenge) and obligations
+(e.g. CAcert Community Agreement) have been put into live.
+The Assurer Training Events (ATE) try to spread this information:
+
+- What is missing on the "old" CAP forms?
+- Why should I remember R/L/O?
+- What can you do if an Assuree shows an ID document unknown to you?
+
+These and more questions will be answered during the
+Assurer Training Events (ATEs)
+
+Furthermore, the ATE trains how to do assurances and audits assurances,
+to measure the quality of assurances in the daily routine. Here are some
+possible errors and pitfalls which need to be found. Assurers have the
+opportunity to see those errors and how to avoid them.
+
+As IanG said: The ATE or Assurer Training Event is exceptionally
+recommended for all Assurers and includes parts which contribute
+directly to our audit. Come and find out how you can also contribute.
+
+The next event held in your area will be:
+
+- Wednesday, November 19th 2014
+- during: 19:00 - ca. 22:00
+- Metalab Vienna
+- Rathausstrasse 6
+- 1010 Vienna
+
+Details to the location can be found:
+Wiki [http://wiki.cacert.org/Events/2014-11-19-ATEWien]
+Blog [http://blog.cacert.org/2014/10/ate-wien-2014-11-19/]
+
+User reply for registration: 'I will attend the ATE-Vienna'
+
+The event team is looking forward for your attendance:
+
+Contact: events@cacert.org
diff --git a/scripts/58at-ate-wien-mail.php.txt b/scripts/58at-ate-wien-mail.php.txt
new file mode 100644
index 0000000..fe95455
--- /dev/null
+++ b/scripts/58at-ate-wien-mail.php.txt
@@ -0,0 +1,134 @@
+#!/usr/bin/php -q
+<? /*
+ LibreSSL - CAcert web application
+ Copyright (C) 2004-2013 CAcert Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 of the License.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ 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
+*/
+ include_once("../includes/mysql.php");
+
+ $lines = "";
+ $fp = fopen("58at-ate-wien-email.txt", "r");
+ while(!feof($fp))
+ {
+ $line = trim(fgets($fp, 4096));
+ $lines .= wordwrap($line, 75, "\n")."\n";
+ }
+ fclose($fp);
+
+
+// $locid = intval($_REQUEST['location']);
+// $maxdist = intval($_REQUEST['maxdist']);
+// maxdist in [Km]
+ $maxdist = 200;
+
+
+// location location.ID
+// verified: 29.4.09 u.schroeter
+// $locid = 7902857; // Paris
+// $locid = 238568; // Bielefeld
+// $locid = 715191; // Hamburg
+// $locid = 1102495; // London
+// $locid = 606058; // Frankfurt
+// $locid = 1775784; // Stuttgart
+// $locid = 228950; // Berlin
+// $locid = 606058; // Frankfurt
+// $locid = 599389; // Flensburg
+// $locid = 61065; // Amsterdam, Eemnes
+// $locid = 228950; // Berlin
+// $locid = 2138880; // Baltimore (Baltimore (city)), Maryland, United States
+// $locid = 1486658; // Potsdam
+// $locid = 664715; // Goteborg, Vastra Gotaland, Sweden
+// $locid = 2094781; // Mission Hills (Los Angeles), California, United States
+// $locid = 423655; // Copenhagen, Kobenhavn*, Denmark
+// $locid = 2093625; // Los Angeles, CA ???
+// $locid = 2094326 // Los Angeles (Los Angeles), California, United States
+// $locid = 2257312; // Sydney, New South Wales, Australia
+// $locid = 572764; // Essen, Nordrhein-Westfalen, Germany
+// $locid = 78; // Aachen, Nordrhein-Westfalen, Germany
+// $locid = 1260319; // Muenchen
+// $locid = 266635; // Bonn, Nordrhein-Westfalen, Germany
+// $locid = 873779; // Karlsruhe, Baden-Wuerttemberg, Germany
+// $locid = 520340; // Dusseldorf, Nordrhein-Westfalen, Germany
+// $locid = 2262656; // Melbourne, Victoria, Australia
+// $locid = 2185076; // Raleigh (Wake), North Carolina, United States
+// $locid = 2126955; // Lawrence (Douglas), Kansas, United States
+// $locid = 919560; // Kiel, Schleswig-Holstein, Germany
+// $locid = 228950; // Berlin
+// $locid = 1117395; // Lubeck Hansestadt, Schleswig-Holstein, Germany
+// $locid = 675661; // Graz, Steiermark, Austria
+// $locid = 1992733; // Wien, Wien, Austria
+
+// $locid = ; 54334 // Amberg, Bayern, Germany
+// $eventname = "ATE-Amberg";
+// $city = "06. Januar 2014";
+
+// $locid = 1089877; // Linz, Oberoesterreich, Austria
+// $eventname = "ATE-Linz";
+// $city = "16. Mai 2014";
+
+// $locid = 1993029; // Wiesbaden, Hessen, Germany
+// $eventname = "ATE-Wiesbaden";
+// $city = "22. Mai 2014";
+
+
+// $locid = 1356196; // Oberwart, Burgenland, Germany
+// $eventname = "ATE-Oberwart (Korrektur)";
+// $city = "27. Juni 2014";
+
+// $locid = 675661; // Graz, Steiermark, Austria
+// $eventname = "ATE-Graz";
+// $city = "13. November 2014";
+
+ $locid = 1992733; // Wien, Wien, Austria
+ $eventname = "ATE-Wien";
+ $city = "19. November 2014";
+
+ $query = "select * from `locations` where `id`='$locid'";
+ $loc = mysql_fetch_assoc(mysql_query($query));
+
+ $query = "SELECT ROUND(6378.137 * ACOS(0.9999999*((SIN(PI() * $loc[lat] / 180) * SIN(PI() * `locations`.`lat` / 180)) +
+ (COS(PI() * $loc[lat] / 180 ) * COS(PI() * `locations`.`lat` / 180) *
+ COS(PI() * `locations`.`long` / 180 - PI() * $loc[long] / 180)))), -1) AS `distance`, sum(`points`) as pts, `users`.*
+ FROM `locations`
+ inner join `users` on `users`.`locid` = `locations`.`id`
+ inner join `alerts` on `users`.`id`=`alerts`.`memid`
+ inner join `notary` on `users`.`id`=`notary`.`to`
+ WHERE (`alerts`.`general`=1 OR `alerts`.`country`=1 OR `alerts`.`regional`=1 OR `alerts`.`radius`=1)
+ GROUP BY `users`.`id`
+ HAVING `distance` <= '$maxdist'
+ ORDER BY `distance` ";
+ echo $query;
+
+ // comment next line when starting to send mail not only to me
+ // $query = "select * from `users` where `email` like 'cacerttest%'";
+
+ $res = mysql_query($query);
+ $xrows = mysql_num_rows($res);
+
+ while($row = mysql_fetch_assoc($res))
+ {
+ // uncomment next line to send mails ...
+ sendmail($row['email'], "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ }
+ // 1x cc to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city", $lines, "events@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ // 1x mailing report to events.cacert.org
+ sendmail("events@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+
+ // 1x mailing report to Arbitrator of case http://wiki.cacert.org/wiki/Arbitrations/a20090525.1
+ sendmail("p.dunkel@cacert.org", "[CAcert.org] $eventname - $city Report", "invitation sent to $xrows recipients.", "support@cacert.org", "", "", "CAcert Events Organisation", "returns@cacert.org", 1);
+ echo "invitation sent to $xrows recipients.\n";
+
+?>
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 cc3fad6..8e5fe01 100644
--- a/www/cap.html.php
+++ b/www/cap.html.php
@@ -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 41a0894..273b0e6 100644
--- a/www/capnew.php
+++ b/www/capnew.php
@@ -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');
@@ -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 8c2479c..6291ea2 100644
--- a/www/coap.html.php
+++ b/www/coap.html.php
@@ -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 4f69247..5a161b4 100644
--- a/www/coapnew.php
+++ b/www/coapnew.php
@@ -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');
@@ -427,7 +427,7 @@ class COAPPDF extends TCPDF {
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..3c1edd0
--- /dev/null
+++ b/www/policy/CAcertCommunityAgreement.html
@@ -0,0 +1,407 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" >
+ <title>CAcert Community Agreement</title>
+ <style type="text/css">
+/*<![CDATA[*/
+ .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;
+ }
+ .strike {
+ color : blue;
+ text-decoration:line-through;
+ }
+ img.c2 {border-style: none;}
+ a.c1 {color: steelblue}
+ /*]]>*/
+ </style>
+</head>
+
+<body>
+ <div class="comment">
+ <table width="100%">
+ <tr>
+ <td rowspan="2">Name: CCA <a class="c1" href=
+ "https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD9</a><br >
+
+ Status: POLICY <a class="c1" href=
+ "https://wiki.cacert.org/PolicyDecisions#p20141008">p20141008</a><br >
+ Editor: <a class="c1" href=
+ "https://wiki.cacert.org/Community/HomePagesMembers/BenediktHeintel">Benedikt</a><br >
+
+ Licence: <a class="c1" 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 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" class="c2" ></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.</li>
+
+ <li>(withdrawn)</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") is an official managed and
+ controlled document (e. g. a Policy) of CAcert.</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 agree to the terms and conditions in this agreement. Your agreement is
+ given by but not limited to</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 supersedes any
+ prior agreements.</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>Personal data</li>
+
+ <li>Postings under competing licences if clearly stated when posted</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>to assist the Arbitrator by truthfully providing information, or with
+ any other reasonable request.</li>
+
+ <li>to not share your CAcert account.</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, ensuring that they are only used as
+ indicated by the certificate, or by wider agreement with others,</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>The CAcert Community Agreement is terminated</p>
+
+ <ol>
+ <li>based on a Policy Group decision following (PoP =&gt; COD1). This
+ terminates the Agreement with every member.</li>
+
+ <li>with a ruling of the Arbitrator or the completion of a termination
+ process defined by an Arbitrator ruling (DRP =&gt; COD7).</li>
+
+ <li>by the end of existence of a member (i.e. death in the case of
+ individuals).</li>
+ </ol>
+
+ <p>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.</p>
+
+ <h4><a name="3.3">3.3a</a> Consequences of Termination</h4>
+
+ <p>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.</p>
+
+ <p>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.</p>
+
+ <p>As far as Organisations are concerned details are also defined in the
+ Organisation Assurance Policy (OAP =&gt; COD11).</p>
+
+ <p>Every member learning about the death of a member or termination of
+ existence of a member should notify <em>support AT cacert.org</em>.</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>You are responsible for keeping your primary email account in good working
+ order and able to receive emails from CAcert.</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</p>
+
+ <h3><a name="4">4.</a> Miscellaneous</h3>
+
+ <h4><a name="4.1">4.1</a> (withdrawn)</h4>
+
+ <h4><a name="4.2">4.2</a> References and Other Binding Documents</h4>
+
+ <p>You are also bound by 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>.</p>
+
+ <p>Controlled documents are primary, and may not be replaced or waived except
+ by formal policy channels and Arbitration.</p>
+
+ <p>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>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> (withdrawn)</h4>
+</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 b18273c..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>
<