Source: https://git.cacert.org/gitweb/?p=cacert-devel.git;a=commitdiff;h=c6fe86e02ea5fa46ea52879de0bdb453f703adae
Timestamp: 2019-07-17 05:33:14
Document Index: 357348318

Matched Legal Cases: ['§2', '§1', '§7', '§8', '§2', '§4', '§1', '§9', '§3', '§6', '§2', '§4', '§5', '§9', '§10', '§3', '§3', '§1', '§10', '§3']

raw | patch | inline | side by side (parent: 4fc2a5e)
bug 1131: Updated Policies based on new versions send by Policy Officer
Tue, 16 Sep 2014 20:16:39 +0000 (22:16 +0200)
Additionally trailing whitespaces, indentation and line breaks have been
partially edited to ease reading of the HTML code.
The CCA has been skipped to avoid race conditions with other currently
www/policy/AssurancePolicy.html patch | blob | history
www/policy/CertificationPracticeStatement.html patch | blob | history
www/policy/DisputeResolutionPolicy.html patch | blob | history
www/policy/NRPDisclaimerAndLicence.html [deleted file] patch | blob | history
www/policy/OrganisationAssurancePolicy.html patch | blob | history
www/policy/PolicyOnPolicy.html patch | blob | history
www/policy/RootDistributionLicense.html patch | blob | history
diff --git a/www/policy/AssurancePolicy.html b/www/policy/AssurancePolicy.html
index ef72454..cfa8400 100644 (file)
--- a/www/policy/AssurancePolicy.html
+++ b/www/policy/AssurancePolicy.html
<title>Assurance Policy</title>
<!--meta name="CREATED" content="20080530;0" -->
diff --git a/www/policy/CertificationPracticeStatement.html b/www/policy/CertificationPracticeStatement.html
index 7cfbc15..3aa616d 100644 (file)
--- a/www/policy/CertificationPracticeStatement.html
+++ b/www/policy/CertificationPracticeStatement.html
- <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" lang="en">
<!--meta name="copyright" content="CAcert Inc http://www.cacert.org/" -->
<title>Certification Practice Statement (CPS)</title>
diff --git a/www/policy/ConfigurationControlSpecification.html b/www/policy/ConfigurationControlSpecification.html
index 0000000..fc0e964
+++ b/www/policy/ConfigurationControlSpecification.html
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" lang="en">
+<title>Configuration-Control Specification</title>
+ font-family : verdana, helvetica, arial, sans-serif;
+ text-align : left;
+ color : gray;
+<body lang="en-GB">
+<h1> Configuration-Control Specification </h1>
+<!-- Absolute URL because the policies are located absolutely. -->
+<td rowspan="2">
+ Name: CCS <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD2</a>
+ Creation Date : 20091214
+ Editor: Iang
+ Status: POLICY <a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+ 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>
+ <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">
+<h3 id="g0.0.1">Introduction </h3>
+<!-- This section from A.1.a through A.1.c -->
+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.
+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.
+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.
+<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>
+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.
+The Controlled Document List
+contains numbers, locations and status
+of all controlled documents.
+The list is part of this CCS.
+<!-- See A.1.k, logging of documents. -->
+<h4 id="g0.0.2.2">Change </h4>
+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>.
+<h4 id="g0.0.2.3">Control </h4>
+CAcert policies are required to be owned / transferred to CAcert. See PoP 6.2.
+<h3 id="g0.0.3">Hardware </h3>
+<!-- This section from A.1.j -->
+<h4 id="g0.0.3.1">Controlled Hardware List </h4>
+Critical systems are defined by Security Policy.
+<h4 id="g0.0.3.2">Change </h4>
+<p> See Security Policy. </p>
+<h4 id="g0.0.3.3">Control </h4>
+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).
+<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>
+Critical software is defined by Security Policy.
+<ul class="q">
+<li> Following are questions for exec + audit, not policy.
+<li>One thing that is not so well covered by CAcert is the last bullet point of A.1.i</li>
+<li>"communicating with subscribers and with the general public."</li>
+<li>website is under SP; maillists,blogs,etc are not.</li>
+<li>as community has deliberately gone this direction, I suggest we argue it that way.</li>
+<li> What is far more problematic is the failure to do CCA &amp; Challenge notification.</li>
+<li> What about translingo and voting? </li>
+<li> See <a href="https://lists.cacert.org/wws/arc/cacert-sysadm/2010-02/msg00008.html">thread</a> </li>
+<h4 id="g0.0.4.2">Change </h4>
+<h4 id="g0.0.4.3">Control </h4>
+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.
+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.
+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.
+<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>
+Creation and handling of Certificates
+is controlled by Security Policy.
+Usage of Certificates
+is controlled by Certification Practice Statement.
+<h4 id="g0.0.5.3">Archive </h4>
+<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>
+<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>
+Types of critical member data is defined by Assurance Policy.
+<h4 id="g0.0.7.2">Changes </h4>
+Changes and access to critical member data
+is as defined under Assurance Policy,
+CAcert Community Agreement and
+Dispute Resolution Policy.
+collection and storage of critical member data
+(user interface software and databases)
+is defined by Security Policy.
+<h4 id="g0.0.7.3">Archive </h4>
+Data retention is controlled by Security Policy and CAcert Community Agreement.
diff --git a/www/policy/DisputeResolutionPolicy.html b/www/policy/DisputeResolutionPolicy.html
index e10e778..6c95953 100644 (file)
--- a/www/policy/DisputeResolutionPolicy.html
+++ b/www/policy/DisputeResolutionPolicy.html
- <title>Dispute Resulution Policy</title>
+<title>Dispute Resulution Policy</title>
@@ -21,103 +21,98 @@
-.draftadd {
- color : darkblue;
-.draftdrop {
-.r {
- text-align : right;
-.size3{
-.vTop{
- Name: DRP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD7</a><br />
- Status: POLICY <a style="color: steelblue" href="https://wiki.cacert.org/TopMinutes-20070917">m20070919.3</a><br />
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span class="draftadd">DRAFT <a href="https://wiki.cacert.org/PolicyDecisions#p20110108">p20110108</a>, <a href="https://wiki.cacert.org/PolicyDecisions#p20121213">p20121213</a>, <a href="https://wiki.cacert.org/PolicyDecisions#p20130116">p20130116</a></span> <br />
+ Name: DRP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD7</a>
+ Created: m20070919.3
+ Changed: p20110108, p20121213, p20130116
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 &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP. More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br /></td>
-<td class="r vTop">
- <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-policy.png" alt="DRP Status - POLICY" height="31" width="88" style="border-style: none;" /></a><br />
- <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-draft.png" alt="DRP Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
+ 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>
+<img src="images/cacert-policy.png" alt="TTP-Assist Status - POLICY" style="border-style: none;" height="31" width="88" uri="file:///home/iphigenie/data/CAcert/Policy/Dispute%20Resulution%20Policy_draft_files/cacert-policy.png">
<h1> Dispute&nbsp;Resolution&nbsp;Policy </h1>
-<h2 id="s0"> 0. Introduction</h2>
+<h2 id="g0.1">Introduction</h2>
-This is the Dispute Resolution Policy for the CAcert Community, consisting of CAcert Inc and Members who agree to the CAcert Community Agreement (CCA).
+for the CAcert Community, consisting of CAcert Inc and Members who agree to the CAcert Community Agreement (CCA).
-operations by CAcert Inc
-and interactions between Members may be addressed through this policy.
-<h3 id="s0.1"> 0.1 Nature of Disputes </h3>
+<h3 id="g0.1.1">Nature of Disputes </h3>
- available to Members;
Classical disputes where a Member or another
legal processes from foreign courts;
-<h2 id="s1"> 1. Filing</h2>
+<h2 id="g0.2">Filing</h2>
-<h3 id="s1.1"> 1.1 Filing Party</h3>
+<h3 id="g0.2.1">Filing Party</h3>
-In filing, they become <em>Claimants</em>.
+In filing, they become <i>Claimants</i>.
-<h3 id="s1.2"> 1.2 Channel for Filing</h3>
+<h3 id="g0.2.2">Channel for Filing</h3>
@@ -130,26 +125,31 @@ Such fees as are imposed on filing will be specified
-<h3 id="s1.3"> 1.3 Case Manager</h3>
+<h3 id="g0.2.3">Case Manager</h3>
CM makes an initial determination as
to whether this filing is a dispute
for resolution, or it is a request
for routine support.
CM logs the case and establishes such
documentation and communications support as is customary.
If any party acts immediately on the filing
(such as an urgent security action),
the CM names these parties to the case.
CM selects the Arbitrator.
@@ -157,32 +157,37 @@ are Case Managers, by default, or as directed
by the Dispute Resolution Officer (DRO).
-<h3 id="s1.4"> 1.4 Contents</h3>
+<h3 id="g0.2.4">Contents</h3>
- The filing party(s), being the <em>Claimant(s)</em>.
+ The filing party(s), being the <i>Claimant(s)</i>.
The party(s) to whom the complaint is addressed to,
- being the <em>Respondent(s)</em>.
+ being the <i>Respondent(s)</i>.
It may be a Member (possibly unidentified) in the
case where one Member has given rise to a complaint against another.
- The <em>Complaint</em>.
+ The <i>Complaint</i>.
or a Member has defrauded using a certificate.
- (technically, called the <em>relief</em>).
+ (technically, called the <i>relief</i>).
For example, to delete an account,
to revoke a certificate, or to stop a
If the filing is inadequate for lack of information
@@ -191,11 +196,13 @@ may refile with the additional information,
-<h3 id="s1.5"> 1.5 The Arbitrator</h3>
+<h3 id="g0.2.5">The Arbitrator</h3>
-to the mechanism managed by the DRO <!-- Dispute Resolution Officer --> and approved from time to time.
+DRO
+and approved from time to time.
Each selected Arbitrator has the right to decline the dispute,
@@ -207,15 +214,15 @@ closed with status "declined."
+Arbitrators are experienced Assurers.
of CAcert Inc. itself where it becomes a party.
-<h2 id="s2"> 2. The Arbitration</h2>
+<h2 id="g0.3">The Arbitration</h2>
-<h3 id="s2.1"> 2.1 Authority</h3>
+<h3 id="g0.3.1">Authority</h3>
The Board of CAcert Inc. and the
@@ -227,17 +234,19 @@ Members.
-<h3 id="s2.2"> 2.2 Preliminaries</h3>
+<h3 id="g0.3.2">Preliminaries</h3>
The Arbitrator reviews the available documentation
and affirms the rules of dispute resolution.
Jurisdiction is established, see below.
The Arbitrator affirms the governing law (NSW, Australia).
The Arbitrator may select local law and local
procedures where Claimants and all Respondents
@@ -246,81 +255,110 @@ The Arbitrator conducts some preliminaries:
and especially, CAcert Inc. and other parties
remain under the governing law.
E.g., support personnel may be joined if emergency action was
- 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)
and forum are strictly limited to
- <span class="strike">that</span>those
- specified in the Root Distribution License. NRPs may proceed with Arbitration subject to preliminary orders
+ Root Distribution License.
- Participating Members
- may not resign from the Community
until the completion of the case.
- This is especially important where a Member might be
The Arbitrator confirms that parties are representing
themselves. Parties are entitled to be legally
- If they do so, they must declare such, including any changes.
+ If they do so,
The Case Manager must not provide such assistance.
The Arbitrator may make any preliminary orders,
including protection orders and orders referring
counterclaims, and/or statements of defence.
-<h3 id="s2.3"> 2.3 Jurisdiction </h3>
+<h3 id="g0.3.3">Jurisdiction </h3>
Jurisdiction - the right or power to hear and rule on
-CAcert Community Agreement. The agreement must establish:
+The agreement must establish:
That all Parties agree to binding Arbitration
in CAcert's forum of dispute resolution;
for all disputes relating to activities within
CAcert, issued certificates, roles and actions, etc;
as defined by these rules, including the selection
of a single Arbitrator;
under the Law of NSW, Australia; and
the Parties keep email accounts in good working order.
An external court may have ("assert") jurisdiction to decide on
@@ -330,25 +368,33 @@ These are areas where jurisdiction may need
to be considered carefully:
Where NRPs, being not Members of CAcert and not
criminal actions or actions likely to result in criminal
- Contracts between Members that were formed without
such as privacy;
Legal process (subpoenas, etc) delivered by
an external court of "competent jurisdiction."
The Arbitrator must consider jurisdiction and rule on a
@@ -360,7 +406,7 @@ another forum, the Arbitrator should seek the agreement
-<h3 id="s2.4"> 2.4 Basis in Law </h3>
+<h3 id="g0.3.4">Basis in Law </h3>
@@ -368,27 +414,32 @@ that elevates Arbitration as a strong dispute
-That is, as Members, you agree to resolve
-This is sometimes called <em>private law</em>
-or <em>alternative dispute resolution</em>.
+This is sometimes called <i>private law</i>
+or <i>alternative dispute resolution</i>.
-refer any case back to Arbitration. Members should understand that they will have
+refer any case back to Arbitration.
-<h3 id="s2.5"> 2.5 External Courts </h3>
+<h3 id="g0.3.5">External Courts </h3>
and issues a court order, subpoena or other service to CAcert,
the CM files the order as a dispute, with the external court
- as <em>Claimant</em>.
+ 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
@@ -401,7 +452,8 @@ seek to have a case heard or to override a Ruling.
By way of example, if all Parties are
- Members, then jurisdiction more normally falls within the forum.
+ then jurisdiction more normally falls within the forum.
he should do so only after consulting with CAcert Inc. counsel.
@@ -410,55 +462,70 @@ seek to have a case heard or to override a Ruling.
-<h3 id="s2.6"> 2.6 Process</h3>
+<h3 id="g0.3.6">Process</h3>
- The Arbitrator may order CAcert Inc. or Members
+ The Arbitrator may order CAcert Inc. or
under jurisdiction to provide support or information.
Apply the Rules of Dispute Resolution,
the policies of CAcert and the governing law.
- the benefit of all Members, and the community as a whole.
- The Arbitrator may seek any assistance.
-<h2 id="s3"> 3. The Ruling</h2>
+<h2 id="g0.4">The Ruling</h2>
-<h3 id="s3.1"> 3.1 The Contents </h3>
+<h3 id="g0.4.1">The Contents </h3>
The directions and actions to be taken by each party
(the ruling).
The date and place that the ruling is rendered.
-<h3 id="s3.2"> 3.2 Process </h3>
+<h3 id="g0.4.2">Process </h3>
@@ -474,39 +541,49 @@ The Ruling is written in English.
Only under exceptional circumstances can the
-Arbitrator declare the Ruling private <em>under seal</em>.
+Arbitrator declare the Ruling private <i>under seal</i>.
If it confirms, the existence of any Rulings under seal
-must be published to the Members in a timely manner (within days).
+(within days).
-<h3 id="s3.3"> 3.3 Binding and Final </h3>
+<h3 id="g0.4.3">Binding and Final </h3>
The Ruling is
-<!-- (DRAFT p20110108) -->
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
+on CAcert Inc.and all
-If a person who is not a Member is a party to the dispute,
-<h3 id="s3.4"> 3.4 Review for Appeal (DRAFT p20110108)</h3>
+<h3 id="g0.4.4">Review for Appeal</h3>
-In the event of clear injustices, egregious behaviour or
+In the eventof clear injustices, egregious behaviour or
unconscionable Rulings,
-a review may be requested by filing a dispute (DRAFT p20110108).
+a review may be requested by filing a dispute.
The new Arbitrator reviews the new dispute,
@@ -519,10 +596,9 @@ 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)
-<h3 id="s3.5"> 3.5 Liability </h3>
+<h3 id="g0.4.5">Liability </h3>
@@ -539,120 +615,158 @@ constitute an intentional or grossly negligent breach of duty.
-<h3 id="s3.6"> 3.6 Remedies </h3>
+<h3 id="g0.4.6">Remedies </h3>
that is ones that are within the general domain of
-the Community, but there are some external remedies at his disposal.
+the Community,
+but there are some external remedies at his disposal.
"community service" typically including
attend and assure people at trade shows / open source gatherings,
- serve in <span class="change2">a</span> role - support, dispute arbitration
+ serve in a role - support, dispute arbitration
Fined by loss of assurance points, which may result
in losing Assurer or Assured status.
Retraining in role.
Revoking of any certificates.
- each party as described in the CAcert Community Agreement.
Reporting to applicable authorities.
Changes to policies and procedures.
-Remedies remain subject to appeal.
+Novel remedies outside the domain may be routinely
+in order to establish precedent.
-<h2 id="s4"> 4. Appendix</h2>
+<h2 id="g0.5">Appendix</h2>
-<h3 id="s4.1"> 4.1 The Advantages of this Forum </h3>
+<h3 id="g0.5.1">The Advantages of this Forum </h3>
-The advantage of this process for Members is:
CAcert and Members operate across many jurisdictions.
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
This forum allows CAcert Members to look after themselves
By volunteering to resolve things "in-house" the costs
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.
CAcert Assurers can develop the understanding and the rules
for sorting out own problems far better than courts or
-<h3 id="s4.2"> 4.2 The Disadvantages of this Forum </h3>
+<h3 id="g0.5.2">The Disadvantages of this Forum </h3>
- Members may have their rights trampled over.
- In such a case, the community should strive to re-open the case.
+ Membersmay have their rights trampled over.
+ In such a case, the community should strive to
Members may feel overwhelmed by the formality
people in power may act without thought and with
damaging consequences.
A country may not have an Arbitration Act.
In that case, the parties should enter into
If they choose to break that spirit,
-<h3 id="s4.3"> 4.3 Process and Flow </h3>
+<h3 id="g0.5.3">Process and Flow </h3>
@@ -673,6 +787,5 @@ is final within the arbitration.
Note also that many elements of legal proceedings are
-<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>
diff --git a/www/policy/NRPDisclaimerAndLicence.html b/www/policy/NRPDisclaimerAndLicence.html
index 7affd50..0000000
--- a/www/policy/NRPDisclaimerAndLicence.html
- <title>NRP-DaL was replaced by the Root Distribution License</title>
- <table border="1" style="background-color: #eeeeee">
- The document "Non Related Persons - Disclaimer And Licence" was replaced by the Root Distribution Licence, which can be found <a href="https://www.cacert.org/policy/RootDistributionLicense.html">here</a>.
- <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>
index 28f6315..0000000
--- a/www/policy/NRPDisclaimerAndLicence.php
-header('HTTP/1.0 301 Moved Permanently');
-header('Location: RootDistributionLicense.html');
-exit();
diff --git a/www/policy/OrganisationAssurancePolicy.html b/www/policy/OrganisationAssurancePolicy.html
index 0861c50..25b7fc4 100644 (file)
--- a/www/policy/OrganisationAssurancePolicy.html
+++ b/www/policy/OrganisationAssurancePolicy.html
<title> Organisation Assurance Policy </title>
- Name: OAP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11</a><br>
- Status: POLICY/DRAFT <a style="color: steelblue" href="https://wiki.cacert.org/TopMinutes-20070917">m20070918.x </a><br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span class="draftadd">DRAFT <a href="https://wiki.cacert.org/PolicyDecisions#p20080401.1">p20080401.1</a></span><br>
- Editor: Jens Paul <br>
- Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP. More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br></td>
- <a href="https://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="https://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>
+ Name: OAP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11</a>
+ Editor: Jens Paul
<h1> Organisation&nbsp;Assurance&nbsp;Policy </h1>
-<h2 id="s0">0. Preliminaries </h2>
+<h2 id="g0.1">Preliminaries </h2>
@@ -58,7 +57,7 @@ This policy is not a Controlled document, for purposes of
-<h2 id="s1"> 1. Purpose </h2>
+<h2 id="g0.2">Purpose </h2>
@@ -71,20 +70,24 @@ the same as with ordinary users (natural persons)
and as described in the CPS.
The organisation named within is identified.
The organisation has been verified according
and can be taken to CAcert Arbitration.
-<h2 id="s2"> 2. Roles and Structure </h2>
+<h2 id="g0.3">Roles and Structure </h2>
-<h3 id="s2.1"> 2.1 Assurance Officer </h3>
+<h3 id="g0.3.1">Assurance Officer </h3>
@@ -102,75 +105,108 @@ The OA is appointed by the Board.
Where the OA is failing the Board decides.
-<h3 id="s2.2"> 2.2 Organisation Assurers </h3>
+<h3 id="g0.3.2">Organisation Assurers </h3>
-<p>&nbsp;
-<ol style="list-style-type: lower-latin;"> <li>
An OA must be an experienced Assurer
- <ol style="list-style-type: lower-roman;">
- <li>Have 150 assurance points.</li>
- <li>Be fully trained and tested on all general Assurance processes.</li>
+ <ol type="i">
+ <li>Have 150 assurance points.</li>
+ <li>Be fully trained and tested on all general Assurance processes.</li>
Must be trained as Organisation Assurer.
- <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>
+ <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>
Must be tested.
- <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>
+ <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>
- <li> Two supervising OAs must sign-off on new OA,
- as trained, tested and passed.
- <li> AO must sign-off on a new OA,
- as supervised, trained and tested.
+ <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>
- <li>The OA can decide when a CAcert
+<li>The OA can decide when a CAcert
(individual) Assurer
has done several OA Application Advises to appoint this
person to OA Assurer.
-<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.
- The local Assurer must have at least 150 Points,
- should know the language, and know
- the organisation trade office registry culture and quality.
+<h3 id="g0.3.3">Organisation Assurance Advisor ("OAA") </h3>
+<p>In countries/states/provinces where no OA Assurers are
-<h3 id="s2.4"> 2.4 Organisation Administrator </h3>
+<h3 id="g0.3.4">Organisation Administrator </h3>
@@ -178,52 +214,74 @@ is the one who handles the assurance requests
and the issuing of certificates.
O-Admin must be Assurer
- <li>Have 100 assurance points.</li>
- <li>Fully trained and tested as Assurer.</li>
+ <li>Have 100 assurance points.</li>
+ <li>Fully trained and tested as Assurer.</li>
Organisation is required to appoint O-Admin,
and appoint ones as required.
- <li> On COAP Request Form.</li>
+ <li> On COAP Request Form.</li>
O-Admin must work with an assigned OA.
- <li> Have contact details.</li>
+ <li> Have contact details.</li>
-<h2 id="s3"> 3. Policies </h2>
+<h2 id="g0.4">Policies </h2>
-<h3 id="s3.1"> 3.1 Policy </h3>
+<h3 id="g0.4.1">Policy </h3>
and several subsidiary policies.
-<ol style="list-style-type: lower-latin;">
- <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>
+<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>
-<h3 id="s3.2"> 3.2 Subsidiary Policies </h3>
+<h3 id="g0.4.2">Subsidiary Policies </h3>
-<ol style="list-style-type: lower-latin;"><li>
SubPols are purposed to check the organisation
under the rules of the jurisdiction that creates the
organisation. This does not evidence an intention
@@ -233,114 +291,159 @@ The nature of the Subsidiary Policies ("SubPols"):
CAcert assurances are conducted under the jurisdiction
of CAcert.
including the local organisation assurance COAP forms.
which are acceptable under this SubPol to meet the
SubPols are subjected to the normal
-<h3 id="s3.3"> 3.3 Freedom to Assemble </h3>
+<h3 id="g0.4.3">Freedom to Assemble </h3>
SubPols compete but are compatible.
No SubPol is a franchise.
Many will be on State or National lines,
reflecting the legal
tradition of organisations created
("incorporated") by states.
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).
There could also be SubPols for special
organisations, one person organisations,
UN agencies, churches, etc.
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.
-<h2 id="s4"> 4. Process </h2>
+<h2 id="g0.5">Process </h2>
-<h3 id="s4.1"> 4.1 Standard of Organisation Assurance </h3>
+<h3 id="g0.5.1">Standard of Organisation Assurance </h3>
the organisation exists
the organisation name is correct and consistent:
- <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>
+ <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>
signing rights:
Acceptable documents to meet above standard
-<h3 id="s4.2"> 4.2 COAP </h3>
+<h3 id="g0.5.2">COAP </h3>
Additional information to be provided on form:
CAcert account of O-Admin (email address?)
- <li>country (MUST).</li>
- <li>city (MUST).</li>
- <li>additional contact information (as required by SubPol).</li>
+ <li>country (MUST).</li>
+ <li>city (MUST).</li>
+ <li>additional contact information (as required by SubPol).</li>
administrator account name(s) (1 or more)
CAcert Community Agreement.
Statement and initials box for organisation
Records should be maintained for 7 years from
The COAP should be in English. Where translations
@@ -349,7 +452,7 @@ and indication provided that the English is the
-<h3 id="s4.3"> 4.3 Jurisdiction </h3>
+<h3 id="g0.5.3">Jurisdiction </h3>
@@ -357,45 +460,60 @@ CAcert Inc. under its Arbitration jurisdiction.
agrees to the
-<h2 id="s5"> 5. Exceptions </h2>
+<h2 id="g0.6">Exceptions </h2>
<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.
<b> Trusted Third Parties.</b>
TTPs are not generally approved to be part of
organisation assurance,
but may be approved by subsidiary policies according
<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.
<b>DBA.</b>
Alternative names for organisations
(DBA, "doing business as")
@@ -403,10 +521,9 @@ Actions carried out by OAs are under this regime.
- <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>
diff --git a/www/policy/OrganisationAssurancePolicy_Australia.html b/www/policy/OrganisationAssurancePolicy_Australia.html
index 0000000..2f55851
+++ b/www/policy/OrganisationAssurancePolicy_Australia.html
+<title>CACert Organisation Assurance Program sub-policy for Australia</title>
+ CAcert Organisation Assurance Program sub-policy for Australia
+ Name: CAcert Organisation Assurance Program sub-policy Australia<a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11.AU</a>
+ Creation Date : 2008-04-02
+ Editor: Sam Johnston
+<img src="images/cacert-policy.png" alt="PoP Status - POLICY" style="border-style: none;" height="31" width="88">
+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.
+<h2 id="g0.2">Scope</h2>
+ This sub-policy is applicable to:
+<li>Australian legal entities:
+<ol style="list-style-type: lower-roman;">
+<li>Sole Traders</li>
+<li>Partnerships</li>
+<li>Companies</li>
+<li>Trusts</li>
+<li>Government Bodies &amp; Intrumentalities</li>
+<li>Clubs &amp; Associations</li>
+<h2 id="g0.3">Requirements </h2>
+This section describes any scope specific requirements that are not otherwise defined in the OAP.
+<h3 id="g0.3.1">Organisation </h3>
+<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>
+<h3 id="g0.3.2">Records </h3>
+<li>Digital Signatures MAY be accepted in Australia under the Electronic Transactions Act 2000.
+<li>Statutory Declarations MAY be accepted in support of other documentary evidence.</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>
+<h3 id="g0.3.3">Application Form </h3>
+<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>Any applicable organisation identifiers (ACN/ABN/ARBN) MUST be
+specified where applicable (not required for sole traders operating
+under their own name).
+<h2 id="g0.4">Registration </h2>
+<h3 id="g0.4.1">Registries </h3>
+<li>AusRegistry [<a title="AusRegistry" href="http://www.ausregistry.com.au/">http://www.ausregistry.com.au/</a>]
+<li>.au ccTLD WHOIS [<a title="AusRegistry WHOIS" href="http://whois.ausregistry.net.au/">http://whois.ausregistry.net.au/</a>]
+<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>]
+<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>]
+<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>]
+<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>
+<li>Australian Taxation Office ("ATO") [<a title="Australian Taxation Office" href="http://www.ato.gov.au/">http://www.ato.gov.au/</a>]
+<li>Australian Business Register ("ABR") [<a title="Australian Business Register" href="http://www.abr.business.gov.au/">http://www.abr.business.gov.au/</a>]
+<li>Credit Reporting Agencies
+<li>Dun &amp; Bradstreet (Australia) [<a title="Dun &amp; Bradstreet (Australia)" href="http://www.dnb.com.au/">http://www.dnb.com.au/</a>]
+<li>Veda Advantage [<a title="Veda Advantage" href="http://www.vedaadvantage.com/">http://www.vedaadvantage.com/</a>]
+<h3 id="g0.4.2">Agents </h3>
+<li>ASIC
+<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>
+<h3 id="g0.4.3">Identifiers </h3>
+<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.
+<li>Australian Business Number ("ABN") is a unique 11 digit
+identifying number issued to all entities registered in the Australian
+Business Register (ABR).</li>
+<h3 id="g0.4.4">Documents </h3>
+<li>ASIC Company Extract</li>
+<li>Credit File</li>
+<h2 id="g0.5">Processes </h2>
+<h3 id="g0.5.1">Assurance </h3>
+<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:
+<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>
+<li>Trust applications MUST be made by the trustee.</li>
+<li>Government Body &amp; Intrumentality applications MUST be made by
+ a duly authorised person and the relevant authorisation must accompany
+the application.</li>
+<li>Club &amp; Association applications MUST be made by the secretary of the club or association.</li>
diff --git a/www/policy/OrganisationAssurancePolicy_Europe.html b/www/policy/OrganisationAssurancePolicy_Europe.html
index 0000000..6a29481
+++ b/www/policy/OrganisationAssurancePolicy_Europe.html
+<title>CACert Organisation Assurance Program sub-policy for European countries with official Trade Office Registry</title>
+ CAcert Organisation Assurance Program sub-policy
+ for countries in Europe
+ Name: CAcert Organisation Assurance Program sub-policy Europe<a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11.EU</a>
+ Creation Date : 20080920
+ Editor: Teus Hagen
+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.
+<h2 id="g0.2">Scope </h2>
+<p> This sub-policy is applicable to:
+<li>Organisations registered in Europe with an
+official Trade Office Registry (CAcert "Approved Registry", also denoted
+ as "Registry").
+<i>Approved Registries</i> are tabled in
+paragraph Appendix 1 of this sub-policy.
+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.
+Registries subjected to acceptance as Approved Registry are tabled in
+paragraph Appendix 2. Appendix 2 is not a formal part of this
+sub-policy.
+This section describes any scope-specific requirements that are not
+otherwise defined in the Organisation Assurance Policy (OAP).
+<h3 id="g0.3.1">Organisations </h3>
+<li>The organisation must be registered with an Approved Registry.</li>
+<li>The Approved Registry must have a mandate to
+ register certain types of organisations (e.g. private companies, clubs
+Societies &amp; Associations, partnerships, cooperatives, mutual
+societies, foundations, etc.)
+<h3 id="g0.3.2">Unincorporated Organisations </h3>
+<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,
+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.
+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.
+There is no limit to the number of Registered Names that
+a Member may have.
+<b>Foreign Entities.</b>
+Where a local Registry requires foreign entities to register,
+this registration may be used for Organisation Assurance.
+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.
+<h3 id="g0.3.3">Records</h3>
+Records supplied by the Registry must be one of the following forms:
+ Formal originals on paper,
+ where they are extracted from the Registry
+ in an independent manner by the OA;
+ Digital statements from an online service provided by the Registry,
+ acquired by the Organisation Assurer by the OA
+ in an independent manner;
+ 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.
+The set of records supplied by the Registry is called the Extract.
+<h2 id="g0.4">The Trade Office Registry </h2>
+ 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).
+<h3 id="g0.4.1">Criteria for acceptance of a Registry </h3>
+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:
+<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>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,
+<h3 id="g0.4.2">Extracts</h3>
+The Extract is the set of records provided by the Registry.
+The Extract is to include the following information:
+<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>
+Organisation Assurance
+is available to any active entity which can provide the above Extract.
+<h2 id="g0.5">Assurance Process </h2>
+<h3 id="g0.5.1">In general</h3>
+The Organisation Assurer should take note of the following:
+<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>
+<h3 id="g0.5.2">Process requirements for the Organisation</h3>
+For legal entities requesting Organisation Assurance under this subsidiary policy:
+<li>The <i>Representative</i> must be duly authorised to sign on behalf of the organisation, and may be:
+ The Secretary as verified in the Extract.
+ This is the preferred and best option;
+ A full Director of the managing or Executive board,
+ as verified in the Extract;
+ Any other Representative must prove that
+ they are duly authorised to sign on behalf of
+ the entity (e.g. via explicit written delegation or under organisation bylaws and rules).
+ This will require due diligence to be conducted by the Organisation Assurer,
+ to the standard and/or for approval
+ by the Organisation Assurer. </li>
+<h3 id="g0.5.3">Process requirements for Individuals </h3>
+For Individuals requesting Organisation Assurance under this subsidiary policy:
+<li>The individual Member must be a CAcert Assurer;</li>
+<li>The individual Member may act as her own Organisation Administrator.</li>
+<h3 id="g0.5.4">Process requirements for Partnerships </h3>
+For Partnerships requesting Organisation Assurance under this subsidiary policy:
+<li>The Partners must be verified via the Extract;</li>
+<li>The applying Partner (signatory) must be an CAcert Assurer;</li>
+Where the Applicant is not the managing Partner, further due diligence should be conducted
+(e.g. verification that the role and title of the Applicant is suitable).
+<i>If in doubt approval should be obtained from each of the Partners who should be individually Assured.</i>
+<h3 id="g0.5.5">Application Form: CAcert Organisation Assurance Programme (COAP) Form </h3>
+On the CAcert Organisation Assurance Programme Form (COAP Form),
+the following must be specified:
+<li><i>Licensing Authority</i> must be specified as the Approved Registry which issued the Extract;</li>
+<li><i>The unique registration Identifier</i> must be provioded where issued (a Registry may not issue a unique Identifier for sole traders and partnerships);</li>
+<li><i>Type</i> of entity that is registered, according to the classification created by the Registry.</li>
+The essential purpose of the information is to permit
+the Organisation Assurer and others to clearly and accurately identify
+the Organisation as actively registered within the Registry, as well as
+its Representatives.
+<!-- ******************************************************* -->
+<hr size="5" width="50%">
+<h1 id="g1">Appendix I</h1>
+<h2 id="g1.1">Table of accepted Trade Office Registries for EU countries</h2>
+The following table defines the accepted Registries for Europe.
+<th align="left">EU country</th>
+<th align="left">Registry</th>
+<th align="left">web address</th>
+<th align="left">internal ID</th>
+<th align="left">accepted</th>
+<td><i>Austria</i>:</td>
+ <!-- Confirmed 2008-08-18 Philipp Dunkel -->
+<td>Bundesministerium
+für Justiz</td>
+<td><a title="Firmenbuch" href="http://www.bmj.gv.at/buergerinfo/index.php">www.bmj.gv.at</a></td>
+<td>BMJ</td>
+<td>18-08-2008</td>
+<td>HF Data GmbH</td>
+<td><a title="Firmenbuchdatenbank" href="http://www.firmenbuch.at/">www.firmenbuch.at</a></td>
+<td>FB</td>
+<td><i>Belgium</i>:</td>
+ <!-- Confirmed 2009-02-08 Alexander Prinsier and Wim Vandeputte -->
+<td>Kruispuntbank van Onderneminge</td>
+<td><a title="e-economiie" href="http://kbo-bce-ps.economie.fgov.be/ps/kbo_ps/kbo_search.jsp?Action=SKW">kbo-bce-ps.economie.fgov.be</a></td>
+<td>KBO</td>
+<td>10-02-2009</td>
+<td>Banque-Carrefour des Entreprises</td>
+<td>BCE</td>
+<td><span color="blue">p20090210.1</span></td>
+<td><i>Denmark</i>:</td>
+ <!-- Confirmed 2009-02-9 Asbjoern S. Toenesen -->
+<td>Central Business Register</td>
+<td><a title="Det centrale virksomhedsregister" href="http://cvr.dk/Site/Forms/CMS/DisplayPage.aspx?pageid=0">virk.dk</a></td>
+<td>CVR</td>
+<td><span color="blue">p20090218.1</span></td>
+<td><i>Finland</i>:</td>
+ <!-- ack: Riku Itäpuro 2008/03/07 -->
+<td>Yritys-Ja
+Yhteisötietojärjestelmä</td>
+<td><a title="Finnish Business Information System" href="http://www.ytj.fi/english/">www.ytj.fi</a></td>
+<td>BIS</td>
+<td>07-03-2007</td>
+<td><i>France</i>:</td>
+ <!-- ack: Richard Migneron 2008/06/04, Guillaume Rogmany 2008/08/19 -->
+<td>Chambre de Commerce
+et d'Industrie</td>
+<td><a title="Chambre de Commerce et d'Industrie" href="http://www.cci.fr/">www.cci.fr</a></td>
+<td>CCI</td>
+<td>19-08-2008</td>
+<td><i></i></td>
+<td>Registre National du
+Commerce et de Sociétés</td>
+<td><a title="National Register for trade and associations" href="http://www.euridile.inpi.fr/">www.euridile.inpi.fr</a></td>
+<td>INPI</td>
+<td>InfoGreffe</td>
+<td><a title="L'Information Legale sur les Entreprises" href="http://www.infogreffe.fr/">www.infogreffe.fr</a></td>
+<td>IG</td>
+<td><i>Ireland</i>:</td>
+ <!-- ack: Andrew Barnes 2008/04/22, Sam Johnston 2008/04/16 -->
+<td>Companies Registration Office</td>
+<td><a title="Companies Registration Office" href="http://www.cro.ie/">www.cro.ie</a></td>
+<td>CRO</td>
+<td>16-04-2008</td>
+<td><i>Netherlands</i>:</td>
+ <!-- ack: Teus Hagen 2008/05/13 -->
+<td>Kamer van Koophandel</td>
+<td><a title="Kamer van Koophyandel" href="http://www.kvk.nl/">www.kvk.nl</a></td>
+<td>KvK</td>
+<td>13-05-2008</td>
+<td><i>Sweden</i>:</td>
+ <!-- ack: Erik Dalén 2008/05/22 -->
+<td>Skatteverket</td>
+<td><a title="Skatteverket" href="http://www.skatteverket.se/">www.skatteverket.se</a></td>
+<td>SKAT</td>
+<td>22-05-2008</td>
+<td>Bolagsverket</td>
+<td><a title="Bolasverket Regsitry of Ministry of Commerce" href="http://www.bolagsverket.se/">www.bolagsverket.se</a></td>
+<td>BOL</td>
+<td><i>United Kingdom</i>:</td>
+ <!-- ack: Conall O'Brien 2008/04/22, Sam Johnston 2008/04/22 -->
+<td>Companies House</td>
+<td><a title="Companies House" href="http://www.companieshouse.gov.uk/">www.companieshouse.gov.uk</a></td>
+<td>CH</td>
+<h2 id="g1.2">Table of accepted Trade Office Registries for other European countries</h2>
+<th align="left">Europe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+<th align="left">acceptance</th>
+<td><i>Norway</i>:</td>
+ <!-- ack: Dag Hovland 2008/05/09 -->
+<td>Brønnøysund Register Centre</td>
+<td><a title="Brønnøysundregistrene" href="http://www.brreg.no/">www.brreg.no</a></td>
+<td>BRC</td>
+<td>09-05-2008</td>
+<td>Nøkkelopplysninger
+fra Enhetsregisteret</td>
+<td><a title="Nøkkelopplysninger fra Enhetsregisteret" href="http://w2.brreg.no/enhet/sok/">w2.brreg.no</a></td>
+<td>BRREQ</td>
+<h1 id="g2">Appendix 2</h1>
+<p>This Appendix is part of Work in Process by definition.</p>
+<h2 id="g2.1">Table of Trade Office Registries for EU countries which Registries are in process of acceptation</h2>
+The orange diamond <font color="orange" size="+2">♦</font> denotes a Registry being accepted. The red bullit <font color="red" size="+2">•</font> denotes a Registry awaiting feedback from that country to be accepted for organisation registration Extracts.
+<td><i>Bulgaria</i>:</td>
+<td valign="top"><font color="red" size="+2">•</font></td>
+<td>Ministry of Justice</td>
+<td><a title="Central Register of non-governmental Legal Entities Sector" href="http://www.mjeli.government.bg/ngo/Default.aspx?cc=en&amp;">www.mjeli.government.bg</a></td>
+<td>NGO</td>
+<td><i>Cyprus</i>:</td>
+<td>Dept of Registrar
+of companies</td>
+<td><a title="Department of Registrar of Companies and Official Receiver" href="http://www.mcit.gov.cy/mcit/drcor/drcor.nsf/aboutus_en/aboutus_en?OpenDocument">www.mcit.gov.cy</a></td>
+<td>DRC</td>
+<td><i>Czech Republic</i>:</td>
+<td>Ministry of Finance</td>
+<td><a title="Register of Trades and Register of Economic Entites" href="http://wwwinfo.mfcr.cz/ares/">wwwinfo.mfcr.cz</a></td>
+<td>ARES</td>
+<td><i>Estonia</i>:</td>
+<td>E-Äriregister</td>
+<td><a title="Äriregistri Teabes&amp;umml;steem (Central Commercial Register)" href="https://ariregister.rik.ee/index.py?lang=eng">ariregister.rik.ee</a></td>
+<td>RIK</td>
+<td><i>Germany</i>:</td>
+<td valign="top"><font color="orange" size="+2">♦</font></td>
+<td>Handelsregister Portal</td>
+<td><a title="Gemeinsames Registerportal der Länder" href="http://www.handelsregister.de/rp_web/welcome.do">www.handelsregister.de</a></td>
+<td>HR</td>
+<td><i>Greece</i>:</td>
+<td>Athens Chamber of
+Commerce and Industry</td>
+<td><a title="Athens Chamber of Commerce and Industry" href="http://www.acci.gr/en_index2.htm">www.acci.gr</a></td>
+<td>ACCI</td>
+<td><i>Hungary</i>:</td>
+<td><a title="Commercial Register" href="http://www.im.hu/?katid=2&amp;id=53&amp;mi=2">www.im.hu</a></td>
+<td>IM</td>
+<td><i>Italy</i>:</td>
+<td>InfoCamere</td>
+<td><a title="Italian Chamber of Commerce" href="http://web.telemaco.infocamere.it/">webtelemaco.infocamere.it</a></td>
+<td>IC</td>
+<td><i>Latvia</i>:</td>
+<td>Lursoft</td>
+<td><a title="Company Register for Latvian" href="http://www.lursoft.lv/?a=138&amp;v=lv&amp;v=en">www.lursoft.lv</a></td>
+<td>LS</td>
+<td><i>Lithuania</i>:</td>
+<td>Juridiniu Asmenu Registras</td>
+<td><a title="Commercial Register by Ministry of Justice" href="http://www.registrucentras.lt/index_en.php">www.registrucentras.lt</a></td>
+<td><i>Luxembourg</i>:</td>
+<td>Registre de
+Commerce et des Sociétés</td>
+<td><a title="Registre de Commerce et des Sociétés" href="https://www.rcsl.lu/mjrcs/index.do">www.rcsl.lu</a></td>
+<td>RCSL</td>
+<td><i>Malta</i>:</td>
+<td>Registry of Companies</td>
+<td><a title="Register of Corporations and Traders" href="http://registry.mfsa.com.mt/">registry.mfsa.com.mt</a></td>
+<td>RNFS</td>
+<td><i>Poland</i>:</td>
+<td><a title="No Company Register in Place" href="http://opp.ms.gov.pl/">opp.ms.gov.pl</a></td>
+<td>CORS</td>
+<td><i>Portugal</i>:</td>
+<td>Conservatórias do
+Registo Comercial</td>
+<td><a title="Registo Commercial" href="http://www.dgrn.mj.pt/db_com/endcom1.asp">www.dgrn.mj.pt</a></td>
+<td>RC</td>
+<td><i>Romania</i>:</td>
+<td>ReCom
+Min. of Justice</td>
+<td><a title="National Trade Register Office" href="http://recom.onrc.ro/indexe.htm">recom.onrc.ro</a></td>
+<td>ReCom</td>
+<td><i>Slovakia</i>:</td>
+<td>Obchodný register</td>
+<td><a title="Min of Justice Company register" href="http://www.orsr.sk/default.asp?lan=en">www.orsr.sk</a></td>
+<td>ORSR</td>
+<td><i>Slovenia</i>:</td>
+<td>Register Podjetij</td>
+<td><a title="Slovenian Commercial Register of Min of Commerce and Industry" href="http://www.gzs.si/register%5Feng/">www.gzs.si</a></td>
+<td>GZS</td>
+<td><i>Spain</i>:</td>
+<td>Registro Mercantil Central</td>
+<td><a title="Central Mercantile Register" href="http://www.ncc.es/">www.nnc.es</a></td>
+<td>RMC</td>
+<th align="left">ID</th>
+<td><i>Andorra</i>:</td>
+<td>Oficina de Marques</td>
+<td><a title="General Registry for Trade and Commerce" href="http://www.ompa.ad/indexang.html">www.ompa.ad</a></td>
+<td>OMPA</td>
+<td><i>Bosinia &amp;
+Herzegovina</i>:</td>
+<td>Gosodarska komora Federacije
+Bosne i Hercegovine</td>
+<td><a title="Sate and private corporations and cooperatives" href="http://www.kfbih.com/eng/">www.kfbih.com</a></td>
+<td>KFBiH</td>
+<td><i>Croatia</i>:</td>
+<td>Registar Poslovnih Subjekata</td>
+<td><a title="Register of business entities in Republic of Croatia" href="http://www1.biznet.hr/HgkWeb/do/extlogon?lang=en_GB">www1.biznet.hr</a></td>
+<td>BIZNET</td>
+<td><i>Gibraltar</i>:</td>
+<td><a title="Gibraltar Finance Centre" href="http://www.companieshouse.gi/">www.companieshouse.gi</a></td>
+<td><i>Serbia</i>:</td>
+<td>Serbian Commercial Register
+Агенција за
+привредне регистре</td>
+<td><a title="Serbian Commercial Register" href="http://www2.apr.sr.gov.yu/default.aspx">www.apr.sr.gov.yu</a></td>
+<td>SCR</td>
+<td><i>Switzerland</i>:</td>
+<td>Central Business
+Names Index portal</td>
+<td><a title="Registry portal by Federal Office of Justice" href="http://www.zefix.admin.ch/">www.zefix.admin.ch</a></td>
+<td>Zefix</td>
diff --git a/www/policy/OrganisationAssurancePolicy_Germany.html b/www/policy/OrganisationAssurancePolicy_Germany.html
index 0000000..2469fdc
+++ b/www/policy/OrganisationAssurancePolicy_Germany.html
+<title>CACert Organisation Assurance Program sub-policy for Germany</title>
+<h1> Organisation Assurance - sub-policy for German organisations</h1>
+ Name: Organisation Assurance - sub-policy Germany <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD11.DE</a>
+ Creation Date : 2007-10-22
+<h2 id="g0.1">Preliminaries</h2>
+This sub-policy describes how Organisation Assurers ("OAs") conduct assurances on German organisations.
+It fits within the overall web-of-trust or assurance process and the Organisation Assurance Policy (OAP) of CAcert.
+<h2 id="g0.2">Purpose</h2>
+This is a subsidiary policy to the OAP.
+a. This sub-policy is applicable for the assurance of German organisations only.
+b. This sub-policy is an implementation of the OAP.
+c. In the below, where the Assurance Officer (AO) is referred to, this includes his local delegate.
+<h2 id="g0.3">Organisation Assurers</h2>
+<h2 id="g0.4">Requirements for the Organisation Assurer</h2>
+In addition to the requirements defined in the OAP, an OA must meet the following requirements for assuring German organisations:
+a. Knowledge on common legal forms of organisations in Germany.
+b. Must pass an additional test on local knowledge even if he is already an OA.
+c. Should help the AO to define local requirements.
+<h2 id="g0.5">Process</h2>
+<h2 id="g0.6">Organisations</h2>
+Acceptable organisations under this sub-policy must be:
+a. Organisations created under the rules of the German jurisdiction.
+b. Organisations must not be revoked by a competent authority with direct oversight over the organisation.
+<h2 id="g0.7">Documents</h2>
+The organisation has to provide documents to prove the essential standard of Organisation Assurance as defined in the policy:
+a. The primary mechanism to prove existence is to get an official extract from the official register, either via an online interface
+or via physical means (organisation is asked to carry the costs)
+b. Where not available, an official document will be required from the company, subject to such checks as defined by the AO.
+c. If copies of official extracts from the official register are provided, they must be officially certified
+d. Extracts from the official register should not be older than 4 weeks.
+e. The AO maintains a list of which specific documents and tests can be acceptable for the certain types
+of organisations.
+f. The OA can ask for additional documents if needed to validate required information for the assurance action.
+<h2 id="g0.8">COAP</h2>
+In addition to the checks defined in the policy, the COAP form for German organisations requires:
+a. The OA must keep all documentation for 10 years.
+b. Signatures from organisation officials must meet the following requirements
+&nbsp;&nbsp;&nbsp; i.&nbsp;&nbsp; as legally specified for the type of organisation
+&nbsp;&nbsp;&nbsp; ii.&nbsp; as specified in the official documents (f.e. the excerpt from the register)
+&nbsp;&nbsp;&nbsp; iii. as delegated within the organisation (proof of delegation needed)
diff --git a/www/policy/PolicyOnPolicy.html b/www/policy/PolicyOnPolicy.html
index bac2637..aaf1734 100644 (file)
--- a/www/policy/PolicyOnPolicy.html
+++ b/www/policy/PolicyOnPolicy.html
-<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" lang="en">
- <title>Policy on Policy</title>
-<style type="text/css"> /*only for WIP*/
+<title>Policy on Policy</title>
@@ -12,62 +13,67 @@ th {
-<body lang="en-GB">
-<td>Name: PoP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD1</a><br />
-Status: POLICY&nbsp;<a href="https://wiki.cacert.org/PolicyDecisions#p20080204.1">p20080204.1</a>, DRAFT&nbsp;<a href="https://wiki.cacert.org/PolicyDecisions#p20130223">p20130223</a><br />
-Editor: Iang 20080309<br />
-Changes: <!-- span class="change">20100507, 20130223</span --><br />
-Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP. More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a>
-<td class="r">
- <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-policy.png" alt="PoP Status - POLICY" height="31" width="88" style="border-style: none;" /></a><br />
- <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-draft.png" alt="PoP Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
+ Name: PoP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD1</a>
+ Status: POLICY&nbsp;<a href="https://wiki.cacert.org/PolicyDecisions#p20140731">p20140731</a>
+ Editor: Iang 20080309
+ Changes: 20100507, 20130223, 20140731
<h1> Policy&nbsp;on&nbsp;Policy </h1>
-<h2 id="s0"> 0. Preliminaries </h2>
Policy on Policy adopts the IETF model of
'rough consensus' to create CAcert documents
- within the open <span class="strike">[policy] mail list forum.</span> <span class="change">CAcert Policy Group <a href="https://lists.cacert.org/wws/info/cacert-policy"> mail list forum</a></span>.
+ within the open CAcert Policy Group <a href="https://lists.cacert.org/wws/info/cacert-policy"> mail list forum</a>.
-<h2 id="s1"> 1. Scope and Purpose </h2>
+<h2 id="g0.2">Scope and Purpose </h2>
<p id="s1.1">
@@ -88,9 +94,8 @@ and also documents part of the CCS.
<p id="s1.3">
The policies so created are generally binding on
-<span class="strike">CAcert, registered users and related parties</span>
-<span class="change">CAcert Inc., members under CAcert Community Agreement
-(CCA =&gt; COD9) and other related parties under other agreements</span>.
+CAcert Inc., members under CAcert Community Agreement
+(CCA =&gt; COD9) and other related parties under other agreements.
<p id="s1.4">
@@ -98,11 +103,12 @@ The policies so created are generally binding on
The Policy Officer manages all policies
and the policy group.
The policy group is formed on the open mailing list
-known as <span class="strike">[cacert-policy]</span> <span class="change">CAcert Policy Group</span>, and is to be open to all
+known as CAcert Policy Group, and is to be open to all
Community Members of CAcert.
-<h2 id="s2"> 2. Basic Model </h2>
+<h2 id="g0.3">Basic Model </h2>
<p id="s2.1">
@@ -135,26 +141,30 @@ date / time of the last edit,
-<p class="change">
+<p id="s2.5">
Editors may make the following changes, where
it is clear that the change does not change the policy:</p>
- <span class="change">fixes to errors in grammar and spelling,</span>
- <span class="change">anchors, HTML errors, URLs &amp; formatting,</span>
- <span class="change">COD numbers and other references, and</span>
- <span class="change">other minutiae, as agreed under 2.3.</span>
+ fixes to errors in grammar and spelling,
+ anchors, HTML errors, URLs &amp; formatting,
+ COD numbers and other references, and
+ other minutiae, as agreed under 2.3.
Such changes to be notified to the policy group, and to be folded into effect, etc, without further ado.
+<p id="s2.6">
Documents of lower status (work-in-progress or DRAFT)
@@ -162,7 +172,6 @@ must not be confusable with documents of higher status
Copies should be eliminated where not being worked on.
-<h2 id="s3"> 3. Work-In-Progress </h2>
<p id="s3.1">
@@ -192,7 +201,7 @@ Documents start with the status of
-<h2 id="s4"> 4. DRAFT status </h2>
+<h2 id="g0.4">DRAFT status </h2>
<p id="s4.1">
@@ -232,8 +241,7 @@ CAcert Inc. retains a veto over
policies that effect the running of CAcert Inc.
-<h2 id="s5"> 5. POLICY status </h2>
+<h2 id="g0.5">POLICY status </h2>
<p id="s5.1">
After DRAFT period has elapsed with no revision beyond
@@ -257,13 +265,12 @@ they may be included in the POLICY document,
but must be clearly indicated within as DRAFT not POLICY.
+<p id="s5.4">
POLICY documents are published on the CAcert website in plain HTML. Change control must be in place.
-<h2 id="s6"> 6. Open Process </h2>
+<h2 id="g0.6">Open Process </h2>
<p id="s6.1">
@@ -309,10 +316,10 @@ and clear licence by CAcert, Inc.
Mailing lists should be archived,
and important meetings should be minuted.
-<span class="change">A record of decisions is to be maintained.</span>
+A record of decisions is to be maintained.
-<h2 id="s7"> 7. Disputes. </h2>
+<h2 id="g0.7">Disputes. </h2>
<p id="s7.1">
@@ -338,10 +345,9 @@ to further group discussion.
The external avenue for disputes is to file a dispute
according to CAcert's
-<a href="https://www.cacert.org/policy/DisputeResolutionPolicy.html">
+<a href="https://www.cacert.org/policy/DisputeResolutionPolicy.php">
Dispute Resolution Policy</a>
DRP =&gt; COD7.
-<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>
index 3bb8ca8..a39162f 100644 (file)
- .r {
@@ -24,7 +22,6 @@ Editor: <br />
<a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-policy.png" alt="PP Status - POLICY" height="31" width="88" style="border-style: none;" /></a>
diff --git a/www/policy/RootDistributionLicense.html b/www/policy/RootDistributionLicense.html
index a2d819f..0c07f56 100644 (file)
--- a/www/policy/RootDistributionLicense.html
+++ b/www/policy/RootDistributionLicense.html
@@ -1,102 +1,149 @@
- <title> CAcert - Root Distribution License - DRAFT </title>
-<style type="text/css"> /* only for WIP */
+<title> CAcert - Root Distribution License </title>
+<tr rowspan="2">
-Name: RDL <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD14</a><br />
-Status: DRAFT <a style="color: steelblue" href="https://wiki.cacert.org/PolicyDecisions#p20100710">p20100710</a> <br />
-Editor: Mark Lipscombe<br />
+Name: RDL <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD14</a>
+Editor: Mark Lipscombe
- <a href="https://www.cacert.org/policy/PolicyOnPolicy.html"><img src="images/cacert-draft.png" alt="RDL Status - DRAFT" height="31" width="88" style="border-style: none;" /></a>
-<p><br /><br /></p>
-<table border="1"><tr><td>
<h1> Root Distribution License </h1>
-<h2 id="s1"> 1. Terms </h2>
+<h2 id="g0.1">Terms </h2>
-"CAcert Inc" means CAcert Incorporated, a non-profit association incorporated in New South Wales, Australia.<br />
-"CAcert Community Agreement" means the agreement entered into by each person wishing to RELY. <br />
-"Member" means a natural or legal person who has agreed to the CAcert Community Agreement.<br />
-"Certificate" means any certificate or like device to which CAcert Inc's digital signature has been affixed.<br />
-"CAcert Root Certificates" means any certificate issued by CAcert Inc to itself for the purposes of signing further CAcert Roots or for signing certificates of Members.<br />
-"RELY" means the human act in taking on a risk or liability on the basis of the claim(s) bound within a certificate issued by CAcert.<br />
-"Embedded" means a certificate that is contained within a software application or hardware system, when and only when, that software application or system is distributed in binary form only.<br />
+"CAcert Inc" means CAcert Incorporated, a non-profit association incorporated in New South Wales, Australia.
+"CAcert Community Agreement" means the agreement entered into by each person wishing to RELY.
+"Member" means a natural or legal person who has agreed to the CAcert Community Agreement.
+"Certificate" means any certificate or like device to which CAcert Inc's digital signature has been affixed.
+"CAcert Root Certificates" means any certificate issued by CAcert Inc to
+ itself for the purposes of signing further CAcert Roots or for signing
+certificates of Members.
+"RELY" means the human act in taking on a risk or liability on the basis
+ of the claim(s) bound within a certificate issued by CAcert.
+"Embedded" means a certificate that is contained within a software
+application or hardware system, when and only when, that software
+application or system is distributed in binary form only.
-<h2 id="s2"> 2. Copyright </h2>
+<h2 id="g0.2">Copyright </h2>
-<h2 id="s3"> 3. License </h2>
+<h2 id="g0.3">License </h2>
-CAcert Inc grants you a free, non-exclusive license to copy and distribute CAcert Root Certificates in any medium, with or without modification, provided that the following conditions are met:
+CAcert Inc grants you a free, non-exclusive license to copy and
+distribute CAcert Root Certificates in any medium, with or without
+modification, provided that the following conditions are met:
+ Redistributions of Embedded CAcert Root Certificates must take
+reasonable steps to inform the recipient of the disclaimer in section 4
+or reproduce this license and copyright notice in full in the
+documentation provided with the distribution.
-<h2 id="s4"> 4. Disclaimer </h2>
+<h2 id="g0.4">Disclaimer </h2>
-THE CACERT ROOT CERTIFICATES ARE PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED TO THE MAXIMUM EXTENT PERMITTED BY LAW. IN NO EVENT SHALL CACERT INC, ITS MEMBERS, AGENTS, SUBSIDIARIES OR RELATED PARTIES BE LIABLE TO THE LICENSEE OR ANY THIRD PARTY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THESE CERTIFICATES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. IN ANY EVENT, CACERT'S LIABILITY SHALL NOT EXCEED $1,000.00 AUSTRALIAN DOLLARS.
+THE CACERT ROOT CERTIFICATES ARE PROVIDED "AS IS" AND ANY EXPRESS OR
+DISCLAIMED TO THE MAXIMUM EXTENT PERMITTED BY LAW. IN NO EVENT SHALL
+CACERT INC, ITS MEMBERS, AGENTS, SUBSIDIARIES OR RELATED PARTIES BE
+LIABLE TO THE LICENSEE OR ANY THIRD PARTY FOR ANY DIRECT, INDIRECT,
+ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ THESE CERTIFICATES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+IN ANY EVENT, CACERT'S LIABILITY SHALL NOT EXCEED $1,000.00 AUSTRALIAN
-THIS LICENSE SPECIFICALLY DOES NOT PERMIT YOU TO RELY UPON ANY CERTIFICATES ISSUED BY CACERT INC. IF YOU WISH TO RELY ON CERTIFICATES ISSUED BY CACERT INC, YOU MUST ENTER INTO A SEPARATE AGREEMENT WITH CACERT INC.
+THIS LICENSE SPECIFICALLY DOES NOT PERMIT YOU TO RELY UPON ANY
+CERTIFICATES ISSUED BY CACERT INC. IF YOU WISH TO RELY ON CERTIFICATES
+ISSUED BY CACERT INC, YOU MUST ENTER INTO A SEPARATE AGREEMENT WITH
+CACERT INC.
-<h2 id="s5"> 5. Statutory Rights </h2>
+<h2 id="g0.5">Statutory Rights </h2>
-Nothing in this license affects any statutory rights that cannot be waived or limited by contract. In the event that any provision of this license is held to be invalid or unenforceable, the remaining provisions of this license remain in full force and effect.
+Nothing in this license affects any statutory rights that cannot be
+waived or limited by contract. In the event that any provision of this
+license is held to be invalid or unenforceable, the remaining provisions
+ of this license remain in full force and effect.
-<h2> Alternatives </h2>
+<h2 id="g0.6">Alternatives </h2>
If you find the terms of the above
@@ -104,16 +151,19 @@ Root Distribution License
difficult or inadequate for your purposes, you may wish to:
Enter into the CAcert Community Agreement by
<a href="https://www.cacert.org/index.php?id=1">
registering as a Member</a>.
Delete CAcert Root Certificates from your software.
Your software documentation should give
directions and assistance for this.
These alternatives are outside the above
@@ -121,6 +171,5 @@ Root Distribution License
and do not incorporate.
diff --git a/www/policy/SecurityPolicy.html b/www/policy/SecurityPolicy.html
index 0000000..b4332ea
+++ b/www/policy/SecurityPolicy.html
+<title>Security Policy</title>
+<h1>Security Policy for CAcert Systems</h1>
+ Name: SP <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD8</a>
+ Creation date: 20090216
+<h3 id="g0.1.1">Motivation and Scope </h3>
+This Security Policy sets out the policy
+for the secure operation of the CAcert critical computer systems.
+These systems include:
+ Physical hardware mounting the logical services
+ Webserver + database (core server(s))
+ Signing service (signing server)
+ Source code (changes and patches)
+The Committee of CAcert, Inc. (hereafter, "Board")
+may add additional components into the Security Manual.
+<h4 id="g0.1.1.1">Covered Personnel </h4>
+Critical roles are covered.
+These roles are defined as:
+ Access Engineer
+ Systems Administrator
+ Software Assessor
+<h4 id="g0.1.1.2">Out of Scope </h4>
+Non-critical systems are not covered by this manual,
+but may be guided by it, and impacted where they are
+found within the security context.
+Architecture is out of scope, see CPS#6.2.
+<h3 id="g0.1.2">Principles </h3>
+Important principles of this Security Policy are:
+ <i>dual control</i> -- at least two individuals must control a task
+ <i>four eyes</i> -- at least two individuals must participate in a task,
+ one to execute and one to observe.
+ <i>redundancy</i> -- no single individual is the only one authorized
+ to perform a task.
+ <i>escrow</i> -- where critical information (backups, passphrases)
+ is kept with other parties
+ <i>logging</i> -- where events are recorded in a file
+ <i>separation of concerns</i> -- when a core task is split between
+ two people from different areas
+ <i>Audit</i> -- where external reviewers do checks on practices and policies
+ <i>Authority</i> -- every action is authorised by either a policy or by the Arbitrator.
+Each task or asset is covered by a variety of protections
+deriving from the above principles.
+<h3 id="g0.1.3">Definition of Terms</h3>
+<dt><i>Access Engineer</i> </dt>
+ A Member who manages the critical hardware,
+ including maintenance, access control and physical security.
+ See §1.1.
+<dt><i>Software Assessor</i> </dt>
+ A Member who reviews patches for security and workability,
+ signs-off on them, and incorporates them into the repository.
+ See §7.2.
+<dt><i>Support Engineer</i> </dt>
+ A Member who mans the support list,
+ and has access to restricted
+ data through the online interface.
+ See §8.
+<dt><i>Systems Administrator</i> </dt>
+ A Member who manages a critical system, and has access
+ to security-sensitive functions or data.
+<h3 id="g0.1.4">Documents and Version control</h3>
+<h4 id="g0.1.4.1">The Security Policy Document </h4>
+This Security Policy is part of the Configuration-Control Specification
+for audit purposes (DRC-A.1).
+It is under the control of Policy on Policy for version purposes.
+This policy document says what is done, rather than how to do it.
+<b>Some sections are empty, which means "refer to the Manual."</b>
+<h4 id="g0.1.4.2">The Security Manual (Practices) Document </h4>
+This Policy explicitly defers detailed security practices to the
+<a href="http://wiki.cacert.org/SecurityManual">Security Manual</a>
+("SM").
+The SM says how things are done.
+As practices are things that vary from time to time,
+including between each event of practice,
+the SM is under the direct control of the
+applicable team leaders.
+It is located and version-controlled on the CAcert wiki.
+Section Headings are the same in both documents.
+Where Sections are empty in one document,
+they are expected to be documented in the other.
+"Document further in Security Manual" can be implied from
+any section heading in the Policy.
+<h4 id="g0.1.4.3">The Security Procedures </h4>
+The team leaders may from time to time
+explicitly defer single, cohesive components of the
+security practices into separate procedures documents.
+Each procedure should be managed in a wiki page under
+their control, probably at
+<a href="http://wiki.cacert.org/SystemAdministration/Procedures">
+SystemAdministration/Procedures</a>.
+Each procedure must be referenced explicitly in the Security Manual.
+<h2 id="g0.2">PHYSICAL SECURITY</h2>
+<h3 id="g0.2.1">Facility </h3>
+CAcert shall host critical servers in a highly secure facility.
+There shall be independent verification of the physical and
+access security.
+<h3 id="g0.2.2">Physical Assets </h3>
+<h4 id="g0.2.2.1">Computers </h4>
+Computers shall be inventoried before being put into service.
+Inventory list shall be available to all
+Access Engineers and all Systems Administrators.
+List must be subject to change control.
+Each unit shall be distinctly and uniquely identified on all visible sides.
+Machines shall be housed in secured facilities (cages and/or locked racks).
+<h4 id="g0.2.2.2">Acquisition </h4>
+Equipment for critical purposes should be acquired
+in a way to minimise pre-acquisition security risks.
+<h4 id="g0.2.2.3">Service </h4>
+Equipment that is subject to a service security risk
+must be retired if service is required.
+See also §2.2.3.3.
+<h4 id="g0.2.2.4">Media </h4>
+<h4 id="g0.2.2.5">Provisioning </h4>
+Storage media (disk drives, tapes, removable media)
+are inventoried upon acquisition and tracked in their use.
+New storage media (whether disk or removable) shall be
+securely erased and reformatted before use.
+<h4 id="g0.2.2.6">Storage </h4>
+Removable media shall be securely stored at all times,
+including when not in use.
+Drives that are kept for reuse are
+erased securely before storage.
+Reuse can only be within critical systems.
+When there is a change to status of media,
+a report is made to the log specifying the new status.
+<h4 id="g0.2.2.7">Retirement </h4>
+Storage media that is exposed to critical data and is
+to be retired from service shall be destroyed or otherwise secured.
+The following steps are to be taken:
+ The media is securely destroyed, <b>or</b>
+ the media is securely erased,
+ and stored securely.
+Records of secure erasure and method of final disposal
+shall be tracked in the asset inventory.
+Where critical data is involved,
+two Systems Administrators must sign-off on each step.
+<h3 id="g0.2.3">Physical Access </h3>
+In accordance with the principle of dual control,
+at least two persons authorized for access must
+be on-site at the same time for physical access to be granted.
+<h4 id="g0.2.3.1">Access Authorisation </h4>
+Access to physical equipment must be authorised.
+<h4 id="g0.2.3.2">Access Profiles </h4>
+The Security Manual must present the different access profiles.
+At least one Access Engineer must control access in all cases.
+At least one Systems Administrator will be present for
+logical access.
+Only the most basic and safest of accesses should be done with
+one Systems Administrator present.
+There is no inherent authorisation to access the data.
+Systems Administrators
+are authorised to access
+the raw data under the control of this policy.
+All others must not access the raw data.
+All are responsible for protecting the data
+from access by those not authorised.
+<h4 id="g0.2.3.3">Access Logging </h4>
+All physical accesses are logged and reported to all.
+<h4 id="g0.2.3.4">Emergency Access </h4>
+There must not be a procedure for emergency access.
+If, in the judgement of the Systems Administrator,
+emergency access is required and gained,
+in order to avoid a greater harm,
+independent authorisation before the
+Arbitrator must be sought as soon as possible.
+See DRP.
+<h4 id="g0.2.3.5">Physical Security codes &amp; devices </h4>
+All personel who are in possession of physical security
+codes and devices (keys) are to be authorised and documented.
+<h2 id="g0.3">LOGICAL SECURITY</h2>
+<h3 id="g0.3.1">Network </h3>
+<h4 id="g0.3.1.1">Infrastructure </h4>
+Current and complete diagrams of the physical and logical
+CAcert network infrastructure shall be maintained by
+Systems Administration team leader.
+These diagrams should include cabling information,
+physical port configuration details,
+expected/allowed data flow directions,
+and any further pertinent information,
+Diagrams should be revision controlled,
+and must be updated when any change is made.
+<h5 id="g0.3.1.1.1">External connectivity </h5>
+Only such services as are required for normal operation
+should be visible externally;
+systems and servers which do not require access
+to the Internet for their normal operation
+must not be granted that access.
+If such access becomes temporarily necessary for an
+authorized administrative task,
+such access may be granted under the procedures of the SM
+and must be reported and logged.
+<h5 id="g0.3.1.1.2">Internal connectivity </h5>
+System and server connections internal to the CAcert infrastructure
+should be kept to the minimum required for routine operations. Any new
+connectivity desired must be requested and approved by System
+administration team leader and then must be reflected in the appropriate
+ infrastructure diagram(s).
+<h4 id="g0.3.1.2">Operating Configuration </h4>
+<h5 id="g0.3.1.2.1">Ingress </h5>
+All ports on which incoming traffic is expected shall be documented;
+traffic to other ports must be blocked. Unexpected traffic must be
+logged as an exception.
+<h5 id="g0.3.1.2.2">Egress </h5>
+All outbound traffic that is initiated shall be documented; traffic to
+other destinations must be blocked. Unexpected traffic must be logged as
+<h4 id="g0.3.1.3">Intrusion detection </h4>
+Logs should be examined regularly (by manual or automatic means) for
+unusual patterns and/or traffic; anomalies should be investigated as
+they are discovered and should be reported to appropriate personnel in
+near-real-time (e.g. text message, email) and investigated as soon as
+possible. Suspicious activity which may indicate an actual system
+intrusion or compromise should trigger the incident response protocol
+described in section 5.1.
+<h3 id="g0.3.2">Operating System </h3>
+Any operating system used for critical server machines must be available under an OSI-approved open source software license.
+<h4 id="g0.3.2.1">Disk Encryption </h4>
+Any operating system used for critical server machines must support
+software full-disk or disk volume encryption, and this encryption option
+ must be enabled for all relevant disks/volumes when the operating
+system is first installed on the machine.
+<h4 id="g0.3.2.2">Operating configuration </h4>
+Servers must enable only the operating system functions required to
+support the necessary services. Options and packages chosen at OS
+install shall be documented, and newly-installed systems must be
+inspected to ensure that only required services are active, and their
+functionality is limited through configuration options. Any required
+application software must follow similar techniques to ensure minimal
+exposure footprint.
+Documentation for installing and configuring servers with the
+appropriate software packages and configurations will be maintained by
+the System Administrators.
+<h4 id="g0.3.2.3">Patching </h4>
+Software used on production servers must be kept current with respect to
+ patches affecting software security. Patch application
+must be approved by the Systems Administration team leader, fully
+documented in the logs and reported by email to the Systems
+Administration list on completion (see §4.2).
+<h5 id="g0.3.2.3.1">“emergency” patching </h5>
+Application of a patch is deemed an <i>emergency</i>
+when a remote exploit for a weakness in the particular piece
+of software has become known
+(on servers allowing direct local user access,
+an emergent local exploit may also be deemed to be an emergency).
+Application of patches in this case may occur as soon as possible,
+bypassing the normal configuration-change process.
+The Systems Administration team leader must either approve the patch
+or instruct remedial action, and refer the case to dispute resolution.
+<b> <!-- this comment left in bold deliberately -->
+Declaration of an emergency patching situation should not occur with any regularity.
+Emergency patch events must be documented
+within the regular summaries
+by the team leader to Board
+independent of filed disputes.
+<h3 id="g0.3.3">Application </h3>
+Requests for ad hoc queries over the application database for business
+or similar purposes must be approved by the Arbitrator.
+<h3 id="g0.3.4">Access control </h3>
+All access to critical data and services shall be
+controlled and logged.
+<h4 id="g0.3.4.1">Application Access </h4>
+General access for Members shall be provided via
+a dedicated application.
+General features are made available according to
+Assurance Points and similar methods controlled in
+the software system.
+<h4 id="g0.3.4.2">Special Authorisation </h4>
+Additional or special access is granted according to the
+authorisations on the below access control lists
+(see §1.1.1):
+<table style="text-align: center" border="1">
+<td>List Name</td>
+<td>Who</td>
+<td>Purpose of access</td>
+<td>Relationship</td>
+<td> Manager </td>
+<td>Physical Control List</td>
+<td>Access Engineers</td>
+<td>control of access by personnel to hardware</td>
+<td>exclusive of all other roles </td>
+<td>Access team leader</td>
+<td>Physical Access List</td>
+<td>Systems Administrators</td>
+<td>hardware-level for installation and recovery</td>
+<td>exclusive with Access Engineers and Software Assessors</td>
+<td>Systems Administration team leader </td>
+<td>SSH Access List</td>
+<td>Systems Administrators </td>
+<td>Unix / account / shell level</td>
+<td> includes by default all on Physical Access List </td>
+<td>Systems Administration team leader</td>
+<td>Repository Access List</td>
+<td>Software Assessors</td>
+<td>change the source code repository </td>
+<td>exclusive with Access Engineers and Systems Administrators</td>
+<td>Software Assessment team leader</td>
+<td>Support Access List</td>
+<td>Support Engineer</td>
+<td>support features in the web application</td>
+<td> exclusive with Access Engineers and Systems Administrators </td>
+<td>Support team leader</td>
+All changes of personnel to the above lists are
+subject to Board approval.
+<h4 id="g0.3.4.3">Authentication </h4>
+Strong methods of authentication shall be used
+wherever possible.
+All authentication schemes must be documented.
+<h4 id="g0.3.4.4">Removing access </h4>
+Follow-up actions to termination must be documented.
+See §9.1.7.
+<h2 id="g0.4">OPERATIONAL SECURITY </h2>
+<h3 id="g0.4.1">System administration </h3>
+Primary Systems Administration tasks
+shall be conducted under four eyes principle.
+These shall include backup performance verification,
+software patch application,
+account creation and deletion,
+and hardware maintenance.
+<h4 id="g0.4.1.1">Privileged accounts and passphrases </h4>
+Access to privileged accounts
+(root and user via SSH or console)
+must be strictly controlled.
+Passphrases and SSH private keys used for entering into the systems
+will be kept private
+to CAcert sysadmins
+in all cases.
+<h5 id="g0.4.1.1.1">Authorized users </h5>
+Only Systems Administrators
+designated on the Access Lists
+in §3.4.2 are authorized to access accounts.
+Systems Administration team leader may temporarily permit Software
+Assessors access to the application via SSH in order to do advanced
+debugging, or as specifically directed by the Arbitrator.
+<h5 id="g0.4.1.1.2">Access to Systems</h5>
+All access is secured, logged and monitored.
+<h5 id="g0.4.1.1.3">Changing </h5>
+The procedure for changing passphrases and SSH keys shall be documented.
+<h4 id="g0.4.1.2">Required staff response time </h4>
+Response times should be documented for Disaster Recovery planning. See §6.
+<h4 id="g0.4.1.3">Change management procedures </h4>
+All changes made to system configuration must be recorded
+and reported in regular summaries to the Board of CAcert.
+<h4 id="g0.4.1.4">Outsourcing </h4>
+<h3 id="g0.4.2">Logging </h3>
+<h4 id="g0.4.2.1">Coverage </h4>
+All sensitive events should be logged reliably.
+Logs should be deleted after an appropriate amount of time
+as documented in the Security Manual.
+<h4 id="g0.4.2.2">Access and Security </h4>
+Access to logs must be restricted.
+The security of the logs should be documented.
+The records retention should be documented.
+<h4 id="g0.4.2.3">Automated logs </h4>
+Logging should be automated,
+and use should be made of appropriate system-provided automated tools.
+Automated logs should be reviewed periodically;
+suspicious events should be flagged and investigated in a timely fashion.
+<h4 id="g0.4.2.4">Operational (manual) logs </h4>
+Configuration changes, no matter how small, must be logged.
+All physical visits must be logged and a
+report provided by the accessor and by
+the Access Engineer.
+<h3 id="g0.4.3">Backup </h3>
+The procedure for all backups must be documented,
+according to the following sub-headings.
+<h4 id="g0.4.3.1">Type </h4>
+Backups must be taken for operational
+and for disaster recovery purposes.
+Operational backups may be online and local.
+Disaster recovery backups must be offline and remote.
+<h4 id="g0.4.3.2">Frequency </h4>
+<h4 id="g0.4.3.3">Storage </h4>
+Backups must be protected to the same level as the critical systems themselves.
+Disaster recovery backups may be distributed.
+<h4 id="g0.4.3.4">Retention period and Re-use </h4>
+See §2.2.3.
+<h4 id="g0.4.3.5">Encryption </h4>
+Backups must be encrypted and must only be transmitted via secured channels.
+Off-site backups must be dual-encrypted using divergent methods.
+<h4 id="g0.4.3.6">Verifying Backups </h4>
+Two CAcert System Administrators must be
+present for verification of a backup.
+Four eyes principle must be maintained when the key and backup are together.
+For any other purpose than verification of the success of the backup, see next.
+<h4 id="g0.4.3.7">Key Management </h4>
+The encryption keys must be stored securely by the
+CAcert Systems Administrators.
+Paper documentation must be stored with manual backups.
+<h4 id="g0.4.3.8">Reading Backups </h4>
+Conditions and procedures for examining the backups
+must be documented,
+and must be under Arbitrator control for purposes
+other than verification and recovery.
+<h3 id="g0.4.4">Data retention </h3>
+<h4 id="g0.4.4.1">User data </h4>
+Termination of user data is under direction of the Arbitrator.
+See CCA.
+<h4 id="g0.4.4.2">System logs </h4>
+See §4.2.1.
+<h4 id="g0.4.4.3">Incident reports </h4>
+See §5.6.
+<h2 id="g0.5">INCIDENT RESPONSE</h2>
+<h3 id="g0.5.1">Incidents </h3>
+<h3 id="g0.5.2">Detection </h3>
+The standard of monitoring, alerting and reporting must be documented.
+<h3 id="g0.5.3">Immediate Action </h3>
+<h4 id="g0.5.3.1">Severity and Priority </h4>
+On discovery of an incident,
+an initial assessment of severity and priority must be made.
+<h4 id="g0.5.3.2">Communications </h4>
+An initial report should be circulated.
+A communications forum should be established for direct
+support of high priority or high severity incidents.
+<h4 id="g0.5.3.3">Escalation </h4>
+A process of escalation should be established
+for oversight and management purposes,
+proportional to severity and priority.
+Oversight starts with four eyes and ends with the Arbitrator.
+Management starts with the team leader and ends with the Board.
+<h3 id="g0.5.4">Investigation </h3>
+Incidents must be investigated.
+The investigation must be documented.
+If the severity is high,
+evidence must be secured and escalated to Arbitration.
+<h3 id="g0.5.5">Response </h3>
+<h3 id="g0.5.6">Report </h3>
+Incident reports shall be be published.
+The Incident Report is written on closing the investigation.
+A full copy should be appended to the
+documentation of the investigation.
+Sensitive information may be pushed out into
+a restricted appendix of the report.
+The Systems Administration team leader is responsible
+for publication and maintenance.
+Incidents are not normally kept secret nor confidential,
+and progress information should be published as soon as
+The knowledge of the existence of the event must not be kept
+secret, nor the manner and methods be kept confidential.
+See §9.5.
+<h2 id="g0.6">DISASTER RECOVERY</h2>
+Disaster Recovery is the responsibility of the Board of CAcert Inc.
+<h3 id="g0.6.1">Business Processes </h3>
+Board must develop and maintain documentation on Business Processes.
+From this list, Core Processes for business continuity / disaster recovery
+purposes must be identified.
+<h3 id="g0.6.2">Recovery Times </h3>
+Board should identify standard process times for all processes,
+and must designate Maximum Acceptable Outages
+and Recovery Time Objectives for the Core Processes.
+<h3 id="g0.6.3">Plan </h3>
+Board must have a basic plan to recover.
+<h3 id="g0.6.4">Key Persons List </h3>
+Board must maintain a Key Persons List with all the
+contact information needed.
+See §10.1.
+The list shall be accessible even if CAcert's
+infrastructure is not available.
+<h2 id="g0.7">SOFTWARE ASSESSMENT</h2>
+Software assessment team is responsible
+for the security and maintenance of the code.
+<h3 id="g0.7.1">Authority </h3>
+The source code is under CCS.
+Additions to the team are
+See §3.4.2.
+<h3 id="g0.7.2">Tasks </h3>
+The primary tasks for Software Assessors are:
+ Keep the code secure in its operation,
+ Fix security bugs, including incidents,
+ Audit, Verify and sign-off proposed patches,
+ Provide guidance for architecture,
+Software assessment is not primarily tasked to write the code.
+In principle, anyone can submit code changes for approval.
+<h3 id="g0.7.3">Repository </h3>
+<h3 id="g0.7.4">Review </h3>
+At the minimum,
+patches are signed off by the team leader
+or his designated reviewer.
+Each software change should be reviewed
+by a person other than the author.
+Author and signers-off must be logged.
+The riskier the source is, the more reviews have to be done.
+<h3 id="g0.7.5">Test and Bugs </h3>
+Software assessment team maintains a test system.
+Each patch should be built and tested.
+Test status of each patch must be logged.
+Software assessment team maintains a bug system.
+Primary communications should go through this system.
+Management access should be granted to all Software Assessors,
+software developers, and Systems Administrators.
+Bug submission access should be provided to
+any Member that requests it.
+<h3 id="g0.7.6">Production </h3>
+<h2 id="g0.8">SUPPORT</h2>
+<h3 id="g0.8.1">Authority </h3>
+The software interface gives features to Support Engineer.
+Access to the special features is under tight control.
+Additions to the team are subject to Board approval,
+and the software features are under CCS.
+Support Engineers do not have any inherent authority
+to take any action,
+and they have to get authority on a case-by-case basis.
+The authority required in each case must be guided
+by this policy or the Security Manual or other clearly
+applicable document.
+If the Member's authority is not in doubt,
+the Member can give that authority.
+If not, the Arbitrator's authority must be sought.
+Support Engineers are responsible to follow the
+policies and practices.
+<h3 id="g0.8.2">Responsibilities </h3>
+Support Engineers have these responsibilities:
+ Member account recovery, as documented in the Security Manual.
+ Respond to general requests for information or explanation by Members.
+ Support Engineers cannot make a binding statement.
+ Responses must be based on policies and practices.
+ Tasks and responsibilities as specified in other policies, such as DRP.
+<h3 id="g0.8.3">Channels </h3>
+Support may always be contacted by email at
+support at cacert dot org.
+Other channels may be made available and documented
+in Security Manual.
+<h3 id="g0.8.4">Records and Logs </h3>
+<li> use of restricted interfaces must be logged. </li>
+<li> all support channels should be logged. </li>
+<li> private requests for support should be referred to proper channels and logged there (e.g., by CCs) </li>
+<h3 id="g0.8.5">Arbitration </h3>
+Support Engineers refer questions requiring authority
+to Arbitration, and may also be called upon to act as
+default Case Managers.
+See DRP and
+<a href="https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html">Case Manager's Handbook.</a>
+Support Engineers should be familiar with
+these topics, even if not listed as Arbitrators
+or Case Managers.
+<h3 id="g0.8.6">References </h3>
+<h2 id="g0.9">ADMINISTRATIVE</h2>
+<h3 id="g0.9.1">Staffing</h3>
+<h4 id="g0.9.1.1">Roles and responsibilities</h4>
+<li> Access Engineer: responsible for controlling access to hardware, and maintaining hardware. </li>
+<li> System Administrator: responsible for maintaining core services and integrity. </li>
+<li> Software Assessor: maintain the code base and confirm security ("sign-off") of patches and releases.</li>
+<li> Support Engineer: human interface with users.</li>
+<li> Team leaders: coordinate with teams, report to Board.</li>
+<li> All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.</li>
+<li> Board: authorise new individuals and accesses. Coordinate overall. </li>
+<li> Arbitrator: conducts ABCs. Authorises exceptions to policy. </li>
+<h4 id="g0.9.1.2">Staffing levels</h4>
+Each team should have a minimum of two members available at any time.
+Individuals should not be active
+in more than one team at any one time,
+but are expected to observe the other teams.
+See §3.4.2 for exclusivities.
+One individual in each team is designated team leader
+and reports to Board.
+<h4 id="g0.9.1.3">Process of new Team Members</h4>
+New team members need:
+<li> Recommendation by team leader </li>
+<li> Arbitrated Background Check ("ABC") </li>
+<li> Authorisation by Board </li>
+The team supports the process of adding new team members.
+<h4 id="g0.9.1.4">Arbitrated Background Check - Procedures</h4>
+The Arbitrated Background Check ("ABC")
+must be conducted under the direction of the Arbitrator,
+with a separate Case Manager to provide four eyes.
+ABCs are carried out with full seriousness.
+<h4 id="g0.9.1.5">Scope </h4>
+An investigation within ABC should include examination of:
+<li> realm-specific knowledge </li>
+<li> realm-specific understanding of good security practice </li>
+<li> history of activity within Community </li>
+<li> reputation and standing within Community </li>
+<li> provided references </li>
+<li> conflicts of interest </li>
+<h4 id="g0.9.1.6">Coverage </h4>
+ABC is to be done on every individual in a critical role.
+See §1.1.1.
+<h4 id="g0.9.1.7">Documentation </h4>
+The process of the ABC should be documented as a procedure.
+Documentation of each individual check should be preserved
+and should be reviewable under any future Arbitration.
+It must include:
+<li> Agreement with appropriate policies, etc. </li>
+<li> Contact information. See §10.1. </li>
+<h4 id="g0.9.1.8">Privacy for Critical Roles</h4>
+The following privacy considerations exist:
+<li> procedure and ruling (recommendation) should be public </li>
+<li> interview, documents should not be public, </li>
+<li> summary of evidence should be in the ruling. </li>
+<li> Arbitrator can rule on the escrow questions of evidence </li>
+<li> contact information goes into the contact addressbook </li>
+CAcert trusted roles give up some privacy for the privacy of others.
+<h4 id="g0.9.1.9">Authorisation </h4>
+Individuals and access (both) must be authorised by the Board.
+Only the Board may approve new individuals or any access to the systems.
+Each individual should be proposed to the Board,
+with the relevant supporting information as above.
+The Board should deliberate directly and in full.
+Board members who are also active in the area should
+abstain from the vote,
+but should support the deliberations.
+Deliberations and decisions should be documented.
+All conflicts of interest should be examined.
+<h4 id="g0.9.1.10">Security</h4>
+It is the responsibility of all individuals to
+observe and report on security issues.
+All of CAcert observes all where possible.
+It is the responsibility of each individual to resolve
+issues satisfactorily, or to ensure that they are reported fully.
+<h4 id="g0.9.1.11">Termination of staff</h4>
+Termination of access may be for resignation, Arbitration ruling,
+or decision of Board or team leader.
+On termination (for any reason), access and information must be secured.
+See §3.4.4.
+The provisions on Arbitration survive any termination
+by persons fulfilling a critical role.
+That is, even after a person has left a critical role,
+they are still bound by the DRP (COD7),
+and the Arbitrator may reinstate any provision
+of this agreement or bind the person to a ruling.
+<h4 id="g0.9.1.12">HR and Training</h4>
+It is the responsibility of the team leaders
+to coordinate technical testing and training,
+especially of new team members.
+<h3 id="g0.9.2">Root Key Management</h3>
+<h4 id="g0.9.2.1">Root Key generation</h4>
+Root keys are generated only on instruction from Board.
+They must be generated to a fully documented and reviewed procedure.
+The procedure must include:
+<li> Use of hardware built securely for the purpose
+ only and cleaned/erased/destroyed immediately afterwards. </li>
+<li> Dual control over all phases, including by Board. </li>
+<li> Strong collection of primary entropy, separated from use of entropy. </li>
+<li> Test cycles of the process on the day. </li>
+<li> Documentation of each step as it happens against the procedure. </li>
+<li> Confirmation by each participant over the process and the results. </li>
+<h4 id="g0.9.2.2">Backup and escrow</h4>
+Root keys must be kept on reliable removable media used for that purpose only.
+Private Keys must be encrypted and should be dual-encrypted.
+Passphrase must be strong and must be separately escrowed from media.
+Dual control must be maintained.
+The top-level root must be escrowed under Board control.
+Subroots may be escrowed by either Board or Systems Administration Team.
+<h4 id="g0.9.2.3">Recovery</h4>
+Recovery must only be conducted under Arbitrator authority.
+<h4 id="g0.9.2.4">Revocation </h4>
+<h3 id="g0.9.3">Legal</h3>
+<h4 id="g0.9.3.1">Responsibility</h4>
+Board is responsible to the Community to manage
+the CA at the executive level.
+<h4 id="g0.9.3.2">Response to external (legal) inquiry</h4>
+All external inquiries of security import are filed as disputes and placed before the Arbitrator under DRP.
+Board and applicable team leaders must be notified.
+Only the Arbitrator has the authority
+to deal with external requests and/or create a procedure.
+Access Engineers, Systems Administrators,
+support engineers,
+Board members and other key roles
+do not have the authority to answer legal inquiry.
+The Arbitrator's ruling may instruct individuals,
+and becomes your authority to act.
+<h3 id="g0.9.4">Outsourcing </h3>
+Components may be outsourced.
+Any outsourcing arrangements must be documented.
+All arrangements must be:
+ with Members of CAcert that are
+ Assurers, as individuals, or
+ Assured Organisations, in which
+ all involved personnel are Assurers,
+ with Members that have the requisite knowledge
+ and in good contact with the team leader(s),
+ subject to audit,
+ transparent and no barrier to security,
+ under this Policy and the Security Manual,
+ fully under Arbitration and DRP for the purposes of Security, and
+ under the spirit of the Community and within the Principles of CAcert.
+Contracts should be written with the above in mind.
+Outsourcing of critical components must be approved by the Board.
+<h3 id="g0.9.5">Confidentiality, Secrecy </h3>
+CAcert is an open organisation and adopts a principle
+of open disclosure wherever possible.
+See <a href="https://svn.cacert.org/CAcert/principles.html">
+Principles</a>.
+This is not a statement of politics but a statement of security;
+if a security issue can only be sustained
+under some confidentiality or secrecy, then find another way.
+In concrete terms,
+confidentiality or secrecy may be maintained only
+under a defined method in policy,
+or under the oversight of the Arbitrator
+(which itself is under DRP).
+The exception itself must not be secret or confidential.
+All secrets and confidentials are reviewable under Arbitration,
+and may be reversed.
+All should strive to reduce or remove any such
+restriction.
+<h2 id="g0.10">REFERENCES</h2>
+<h3 id="g0.10.1">Contacts </h3>
+Contact information for all key people and teams must be documented.
+<h3 id="g0.10.2">Documents </h3>
+All incorporated Documents must be documented.
+<h3 id="g0.10.3">Related Documents </h3>
+Relevant and helpful Documents should be referenced for convenience.
diff --git a/www/policy/TTPAssistedAssurancePolicy.html b/www/policy/TTPAssistedAssurancePolicy.html
index 0000000..0e8404a
+++ b/www/policy/TTPAssistedAssurancePolicy.html
+<title> CAcert -- TTP-Assisted Assurance Policy </title>
+ Name: TTP-Assist <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD13.2</a>
+ Editor: <a style="color: steelblue" href="https://wiki.cacert.org/UlrichSchroeter">Ulrich Schroeter</a>
+<img src="images/cacert-policy.png" alt="TTP-Assist Status - DRAFT" style="border-style: none;" height="31" width="88" uri="file:///home/iphigenie/data/CAcert/Policy/CAcert%20--%20TTP-Assisted%20Assurance%20Policy_draft_files/cacert-draft.bin">
+<h1> TTP-Assisted Assurance Policy </h1>
+ This sub-policy extends the
+ <a href="https://www.cacert.org/policy/AssurancePolicy.php">
+ Assurance Policy</a> ("AP" =&gt; COD13)
+ by specifying how Assurers can be assisted by
+ outsourcing the identity documents verification
+ component of assurance to trusted third parties (TTPs).
+ Other definitions and terms can be found in AP or in
+ <a href="https://wiki.cacert.org/AssuranceHandbook">Assurance Handbook</a>
+ ("AH").
+ This sub-policy is restricted to members located
+ in areas not well-served with Assurers.
+ It serves a goal of promoting both Assurers and Members in those areas.
+<h2 id="g0.3">Roles </h2>
+<h3 id="g0.3.1">Trusted Third Party </h3>
+ A Trusted Third Party ("TTP") is a person who is traditionally respected
+ for making reliable statements to others, especially over identification
+ documents. Typically, notaries public (anglo),
+ Notaries (European), bank managers, accountants
+ and lawyers.
+<h3 id="g0.3.2">The Assurer (aka TTP-admin) </h3>
+ To employ a TTP in an assurance,
+ the Assurer must be a <a href="https://wiki.cacert.org/SeniorAssurer">Senior Assurer</a>.
+ The Assurer must be familiar with the local
+ language and customs.
+<h3 id="g0.3.3">Member </h3>
+ A Member ("assuree") who is located in a place not well-served
+ by Assurers may use the TTP-assisted assurance.
+<h2 id="g0.4">The Assurance </h2>
+ Assurance assisted by TTP must meet these requirements:
+<li id="s3.a">
+ The Assurer must positively confirm the identity and
+ suitability of the TTP.
+<li id="s3.b">
+ The TTP and the Member must meet face-to-face.
+<li id="s3.c">
+ The TTP confirms the details supporting the Assurance Statement.
+<li id="s3.d">
+ The Assurer makes a reliable statement to confirm the
+ Assurance Statement.
+<li id="s3.e">
+ Assurance must be marked as TTP-Assisted
+ (e.g., by use of TTPAdmin flag).
+<h2 id="g0.5">Assurance Officer ("AO") </h2>
+ The Board routinely delegates its responsibilities to the
+ Assurance Officer (and this section assumes that, but does
+ not require it).
+ A report is requested annually from the Assurance Officer
+ on performance of this policy for the association's
+ annual report.
+<h3 id="g0.5.1">Practice </h3>
+ Assurance Officer should prepare a
+ <a href="https://wiki.cacert.org/TTP">detailed documentation</a>
+ <a href="https://wiki.cacert.org/AssuranceHandbook">AH</a>
+ that meets the needs of this policy, including:
+ Form for TTPs
+ Guide for TTPs.
+ Form for TTP-assisted assurance (used by Assurer)
+ Guide and protocol for Assurers.
+ Mechanisms for contacting Assurers available for
+ TTP-assisted assurances.
+ Definition of
+ <a href="https://wiki.cacert.org/SeniorAssurer">
+ Senior Assurer</a>.
+<h3 id="g0.5.2">Deserts </h3>
+ The Assurance Officer maintains a
+ <a href="https://wiki.cacert.org/deserts">list of regions</a>
+ that are designated as '<i>deserts,</i>' being areas that are so short
+ of Assurers as to render face-to-face Assurance impractical.
+ In each region, approved types of TTP are listed (e.g., Notary).
+ The list is expected to vary according to the
+ different juridical traditions of different regions.
+ Changes to the regional lists are prepared by
+ either an Organisation Assurer for that region
+ (as described by OAP)
+ or by two Assurers familiar with the traditions
+ in that region.
+ Changes are then submitted to the Board for approval.
+ Use of a type of TTP not on the list must be approved by
+ AO and notified to Board.
+ It is an explicit goal to reduce the usage of
+ TTP-assisted assurances in favour of face-to-face Assurance.
+ In coordination with internal and external auditors,
+ the Assurance Officer shall design and implement a
+ suitable programme to meet the needs of audit.
+ Where approved by auditors or Board, the Assurance
+ Officer may document and implement minor variations to this policy.
+<h2 id="g0.6">Topup Assurance </h2>
+ AO is to operate a <cite>Topup Assurance Programme</cite>
+ to help seed deserts with Assurers.
+ A topup assurance will add additional Assurance Points
+ to those gained from two previously conducted TTP-assisted assurances,
+ in order for a Member to reach 100 Assurance Points
+ for the express purpose of becoming an Assurer.
+ A topup assurance is conducted by a third Senior Assurer
+ according to the following requirements:
+<li id="s5.1">
+ Assurer Challenge must be completed as passed by Member.
+<li id="s5.2">
+ The topup must be requested by Member for
+ purpose of enabling the Member to reach Assurer level.
+<li id="s5.3">
+ Topup Assurer must be a Senior Assurer,
+ and must be independent of the TTP-assist Assurers.
+<li id="s5.4">
+ The Topup Assurer reviews the two TTP-assisted assurances,
+ and conducts other checks as set by the Assurance Officer.
+ The normal face-to-face meeting is not conducted.
+<li id="s5.5">
+ Topup Assurer may award up to 35 points.
+<li id="s5.6">
+ Assurance must be marked as Topup
+ (e.g., by use of new feature with TTPAdmin flag).
+ Each topup is to be reported to AO.
+ Topup is only available in designated deserts.