diff options
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&noauto=1"><?=_("Net Cafe Login")?></a> + <a href="https://<?=$_SESSION['_config']['normalhostname']?>/index.php?id=4&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> | ©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>© +<div style="text-align: right;"><small><small><span>© <?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 © 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">>=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> => 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> +=> 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">>=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 => 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> -=> 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" => 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" => 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" => 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" => 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 => 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 => 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 => 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 + => 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 => 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 => 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 => 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" => 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 /> - <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 © 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" => 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">=> - 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" => 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" => 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" => 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 - => 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 - => 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 => 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 - => 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 - => 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 - => 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 => - 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" => 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 => COD6).</span></li> - - <li><span class="strike11"><a href= - "http://www.cacert.org/policy/DisputeResolutionPolicy.php">Dispute - Resolution Policy</a> (DRP => COD7).</span></li> - - <li><span class="strike11"><a href="PrivacyPolicy.html">Privacy Policy</a> - (PP => 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>=> 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&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&A for Re-key Requests</a> </li> + +<li><a href="#p3.4">3.4. I&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 < support AT cacert DOT org > </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=&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> + + </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 + < support AT cacert DOT org > +</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 => 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:<crlUri> where <crlUri> 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:<crlUri> where <crlUri> 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:<crlUri> where <crlUri> 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 => 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 + < support AT cacert DOT org > +</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&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&A for Re-key Requests</a> </li> - <li><a href="#p3.4">3.4. I&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> - © 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">§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"> - <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">§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> -</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">§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">§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 † </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"> • </font> </center> </th> - <td> <center> <font title="pass." color="green" size="+3"> • </font> </center> </th> - <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> </th> - <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> </th> - <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </th> - <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> </th> - <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </th> - <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></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"> ✔ </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> </th> - <td> <center> <font title="pass." color="red" size="+3"> ✘ </font> </center> </th> - <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. </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 < support AT cacert DOT org > </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">§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">§1.4.5.</a>. -</p> - -<p> -Email addresses are verified according to -<a href="#p4.2.2">§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">§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">§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">§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, §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">§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><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, §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 §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 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"> ✔ </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><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 §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 §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></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">§9.13</a>. -<!-- DRC_A§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 - < support AT cacert DOT org > -</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">§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 §9.10.2. -Members will have reasonable time in which to file a related -dispute after notification -(at least one month). -See §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">§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">§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 §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 §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">§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:<crlUri> where <crlUri> 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> - <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:<crlUri> where <crlUri> 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:<crlUri> where <crlUri> 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> - <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">§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">§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">§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">§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">§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><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 - < support AT cacert DOT org > -</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">§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><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">§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 & 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 Resolution 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 /> - <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 © 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 Resolution 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> <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 Assurance 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 /> - - <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 © 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 Assurance 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 & Intrumentalities</li> + +<li>Clubs & 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 & Bradstreet (Australia) [<a title="Dun & 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 & Intrumentality applications MUST be made by + a duly authorised person and the relevant authorisation must accompany +the application.</li> + +<li>Club & 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 & 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). + |