From 4cf31863455f7fb2370ff2f9ebb9ab489e5bb324 Mon Sep 17 00:00:00 2001 From: Ian Grigg Date: Mon, 28 Jan 2008 00:01:03 +0000 Subject: [PATCH] moving these all into Policies so that they can be managed from one central place, now that the finished ones are POLICY, and others such as Foundations / Privacy are closely held. git-svn-id: http://svn.cacert.org/CAcert/Policies@567 14b1bab8-4ef6-0310-b690-991c95c89dfd --- Agreements/3PVDisclaimerAndLicence.html | 395 +++++++++++ Agreements/CAcertCommunityAgreement.html | 512 ++++++++++++++ Agreements/NRPDisclaimerAndLicence.html | 136 ++++ DisputeResolutionPolicy.html | 639 ++++++++++++++++++ .../OrganisationAssurancePolicy.html | 379 +++++++++++ PolicyOnFoundations.html | 222 ++++++ PrivacyPolicy.php | 3 + PrivacyPolicy.txt | 85 +++ 8 files changed, 2371 insertions(+) create mode 100644 Agreements/3PVDisclaimerAndLicence.html create mode 100644 Agreements/CAcertCommunityAgreement.html create mode 100644 Agreements/NRPDisclaimerAndLicence.html create mode 100644 DisputeResolutionPolicy.html create mode 100644 OrganisationAssurancePolicy/OrganisationAssurancePolicy.html create mode 100644 PolicyOnFoundations.html create mode 100644 PrivacyPolicy.php create mode 100644 PrivacyPolicy.txt diff --git a/Agreements/3PVDisclaimerAndLicence.html b/Agreements/3PVDisclaimerAndLicence.html new file mode 100644 index 0000000..bc3755b --- /dev/null +++ b/Agreements/3PVDisclaimerAndLicence.html @@ -0,0 +1,395 @@ + + + +CAcert - 3rd Party Vendor -- Licence and Disclaimer + + +

-1. TO BE FIXED

+ + +
D R A F T
+ +

+This is DRAFT-V0.02. +

+ + + +
+ + +

0. Preliminaries

+ + +

0.1 Background

+ +

+Being that, +

+ + + +

+And that, +

+ + + +

+And that, in offering the USE of certificates to the end-user, +

+ + + +

+And that, +

+ + + +

+We both, CA and Vendor, agree that, +

+ + + + +

0.2 Parties

+ +With the above understanding, the following Licence and Disclaimer is offered +by CA to Vendor. + +

0.3 Terms

+ +

+Terms used in this agreement are as defined in the + +CAcert Community Agreement. +

+ + +

1. Agreement and Licence

+ +

1.1 Agreement

+ +

+You and CAcert both agree to the terms and conditions in this agreement. +The relationship between the CA and the Vendor is based on this agreement. +Your agreement is given by your distribution of the root within your +distribution of your root list. +

+ +

1.2 Other Agreements

+ +

+The relationship between the Vendor and the end-user is based on Vendor's own agreement +("end-user licence agreement" or EULA). +Generally, the Vendor offers the EULA to the end-user +in the act of distributing the software and roots. +

+ +

+The relationship between the CA and the end-user is based on CA's +Non-Related Persons -- Disclaimer and Licence +("NRP-DaL"). +This Licence follows the style of popular open source licences, +in that it is offered to an unknown audience, without a necessary +expectation for explicit agreement by the end-user, +because of the methods and restrictions of delivery. +

+ +

1.3 Licence to Distribute

+ +

+CA offers this licence to permit Vendor to distribute CA's roots +within Vendor's root list to Vendor's end-users. +

+ +

1.4 Agreement in Spirit

+

+Vendor agrees to make EULA compatible and aligned with the CA's NRP-DaL. +Specifically, the EULA must: +

+ + + +

+all with respect to the root list +(including root keys, certificates, +and related cryptographic and security software). +

+ +

1.5 Agreement in Practice

+ +

+Where agreement is explicitly sought from the end-user +they will be offered and agree to: +

+ + + +

+Vendors are encouraged to ship the NRP-DaL with their software, +and make available means for the end-user to further +examine the NRP-DaL. +
Note, document this elsewhere in FAQ. +

+ +

1.6 Fair and Non-Discriminatory

+ +

+Vendor agrees to make available CA's root key +in a fair and non-discriminatory way to Vendor's end-users. +
Note, document this elsewhere in FAQ. +

+ +

2. Disclaimer

+ +

2.1 All Liability

+ +

+Vendor's relationship with end-users creates risks, liabilities +and obligations due to the end-user's permitted USE of the certificates, +and potentially through other activities such as inappropriate +and unpermitted RELIANCE. +

+ +

+We in general DISCLAIM ALL LIABILITY to each other and to the end-user. +

+ + +

2.2 Monetary Limits on Liability

+ +

+Notwithstanding the general disclaimer on liability above, +we agree that, to the extent that CAcert is reasonably +represented to the Vendor's end-user by the software +as being the Certificate Authority, at the events and +circumstances of question, +liability of CAcert is strictly limited to be 1000 euros. +This is the same limit of liability that applies to each +member of the CAcert Community. +

+ +

+To the extent that the CA is not reasonably represented +to the end-user, we agree that any liability is limited +to the lowest of agreed liabilities of all CAs for all +roots shipped by the Vendor, and 1000 euros. +

+ +

3. Legal Matters

+ +

3.1 Law

+ +

+The Choice of Law is that of NSW, Australia. +

+ +

3.2 Dispute Resolution

+ +

+We agree that all disputes arising out +of or in connection to this agreement +and the root key of the CA +shall be referred to and finally resolved +by Arbitration under the +Dispute Resolution Policy of the CA +(DRP => COD7). +The ruling of the Arbitrator is binding and +final on CA and Vendor alike. +

+ +

+We further agree, as a single exception to DRP, +that the single Arbitrator may be chosen from outside +the CAcert Community. +

+ +

3.3 CAcert Community Agreement

+ +

+The CA also offers a CAcert Community Agreement (CCA). +The CCA replaces the NRP-DaL and this present agreement +for those parties that accept it. +

+ +

+If a Community member is also an end-user, then the provisions +of the CCA will replace all elements of the CA's NRP-DaL, +and will dominate this present agreement. +

+ +

+Acceptance alone of this present agreement by the Vendor +does not imply that Vendor is a Community User/Member. +

+ +
+ +

+The following parts are not part of the above licence, +but may shed light. +

+ +

Z. FAQ

+ +

Z.1 Notes on Liability

+ +

+Liability agreement between CA and Vendor +suggests that the end-user be presented with the name of the CA. +This is useful for identifying the particular characteristics +of the CA, and accepts that all CAs are different. +Each CA has its ways of checking, its relevent laws, and its +particular view as to the interests of the end-user. +

+ +

+The Vendor should present the name of the CA so as to inform +the end-user of what can be known. +In the event that the Vendor does not present the CA, +the CA is taking on all the risk and liability that the +CA is equivalent to others, which can only be rationally +measured as the lowest-common-denominator, that is, +the lowest of the liabilities that is accepted across all +CAs that are shipped by the CA. +This would generally be zero. +

+ +

+If the CA has been presented to the end-user, the end-user +is able to discriminate. +In this case, it is reasonable for the CA to offer to share +the liability, and to accept some limit +to that liability. +

+ +

+Always remembering that this is strictly within the +relationship with the Vendor. +As there are millions and one day, billions of users, and as +the software and the certificates are free, the liability +to the end-user must be disclaimed totally. +In other words, set to zero. +

+ +

Z.2 Reasonably Shown

+ +

+To reasonably show the name of the CA is undefined, +as security user interfaces currently are not representative +of reasonable descriptions, and the area is an open research +topic (sometimes known as "usable security"). +

+ +

+A reasonable man test is known in law, and selects someone +who would be the reasonable person who would use the software. +This might hypothetically examine whether a majority of +random users would have "got it" when presented with the +same information, however this is not quite how it is tested +in law; instead, it is more of a gut-feeling. +

diff --git a/Agreements/CAcertCommunityAgreement.html b/Agreements/CAcertCommunityAgreement.html new file mode 100644 index 0000000..4725355 --- /dev/null +++ b/Agreements/CAcertCommunityAgreement.html @@ -0,0 +1,512 @@ + + + +CAcert Community Agreement + + + + + +

0. Introduction

+ +

+This agreement is between +you, being a registered member ("Member") +within CAcert's community at large ("Community") +and CAcert Incorporated ("CAcert"), +being an operator of services to the Community. +

+ +

0.1 Terms

+
  1. + "CAcert" + means CAcert Inc., + a non-profit Association of Members incorporated in + New South Wales, Australia. + Note that Association Members are distinct from + the Members defined here. +
  2. + "Member" + means you, a registered participant within CAcert's Community, + with an account on the website and the + facility to request certificates. + Members may be individuals ("natural persons") + or organisations ("legal persons"). +
  3. + "Organisation" + is defined under the Organisation Assurance programme, + and generally includes corporations and other entities + that become Members and become Assured. +
  4. + "Community" + means all of the Members + that are registered by this agreement + and other parties by other agreements, + all being under CAcert's Arbitration. +
  5. + "Non-Related Person" ("NRP"), + being someone who is not a + Member, is not part of the Community, + and has not registered their agreement. + Such people are offered the NRP-DaL + another agreement allowing the USE of certificates. +
  6. + "Non-Related Persons - Disclaimer and Licence" ("NRP-DaL"), + another agreement that is offered to persons outside the + Community. +
  7. + "Arbitration" + is the Community's forum for + resolving disputes, or jurisdiction. +
  8. + "Dispute Resolution Policy" ("DRP" => COD7) + is the policy and + rules for resolving disputes. +
  9. + "USE" + means the act by your software + to conduct its tasks, incorporating + the certificates according to software procedures. +
  10. + "RELY" + means your human act in taking on a + risk and liability on the basis of the claim(s) + bound within a certificate. +
  11. + "OFFER" + means the your act + of making available your certificate to another person. + Generally, you install and configure your software + to act as your agent and facilite this and other tasks. + OFFER does not imply suggestion of reliance. +
  12. + "Issue" + means creation of a certificate by CAcert. + To create a certificate, + CAcert affixes a digital signature from the root + onto a public key and other information. + This act would generally bind a statement or claim, + such as your name, to your key. +
  13. + "Root" + means CAcert's top level key, + used for signing certificates for Members. + In this document, the term includes any subroots. +
  14. + "CAcert Official Document" ("COD" => COD3) + in a standard format for describing the details of + operation and governance essential to a certificate authority. + Changes are managed and controlled. + CODs define more technical terms. + See 4.2 for listing of relevant CODs. +
  15. + "Certification Practice Statement" ("CPS" => COD6) + is the document that controls details + about operational matters within CAcert. +
+ + +

1. Agreement and Licence

+ +

1.1 Agreement

+ +

+You and CAcert both agree to the terms and conditions +in this agreement. +Your agreement is given by any of +

+ + + +

+Your agreement +is effective from the date of the first event above +that makes this agreement known to you. +This Agreement +replaces and supercedes prior agreements, +including the NRP-DaL. +

+ + +

1.2 Licence

+ +

+As part of the Community, CAcert offers you these rights: +

+ +
  1. + You may USE any certificates issued by CAcert. +
  2. + You may RELY on any certificate issued by CAcert, + as explained and limited by CPS (COD6). +
  3. + You may OFFER certificates issued to you by CAcert + to Members for their RELIANCE. +
  4. + You may OFFER certificates issued to you by CAcert + to NRPs for their USE, within the general principles + of the Community. +
  5. + This Licence is free of cost, + non-exclusive, and non-transferrable. +
+ +

1.3 Your Contributions

+ + +

+You agree to a non-exclusive non-restrictive non-revokable +transfer of Licence to CAcert for your contributions. +That is, if you post an idea or comment on a CAcert forum, +or email it to other Members, +your work can be used freely by the Community for +CAcert purposes, including placing under CAcert's licences +for wider publication. +

+ +

+You retain authorship rights, and the rights to also transfer +non-exclusive rights to other parties. +That is, you can still use your +ideas and contributions outside the Community. +

+ +

+Note that the following exceptions override this clause: +

+ +
  1. + Contributions to controlled documents are subject to + Policy on Policy ("PoP" => COD1) +
  2. + Source code is subject to an open source licence regime. +
+ +

1.4 Privacy

+ + +

+You give rights to CAcert to store, verify and process +and publish your data in accordance with policies in force. +These rights include shipping the data to foreign countries +for system administration, support and processing purposes. +Such shipping will only be done among +CAcert Community administrators and Assurers. +

+ +

+Privacy is further covered in the Privacy Policy ("PP" => COD5). +

+ +

2. Your Risks, Liabilities and Obligations

+ +

+As a Member, you have risks, liabilities +and obligations within this agreement. +

+ +

2.1 Risks

+ +
  1. + A certificate may prove unreliable. +
  2. + Your account, keys or other security tools may be + lost or otherwise compromised. +
  3. + You may find yourself subject to Arbitration + (DRP => COD7). +
+ +

2.2 Liabilities

+ +
  1. + You are liable for any penalties + as awarded against you by the Arbitrator. +
  2. + Remedies are as defined in the DRP (COD7). + An Arbitrator's ruling may + include monetary amounts, awarded against you. +
  3. + Your liability is limited to + a total maximum of + 1000 Euros. +
  4. + "Foreign Courts" may assert jurisdiction. + These include your local courts, and are outside our Arbitration. + Foreign Courts will generally refer to the Arbitration + Act of their country, which will generally refer + civil cases to Arbitration. + The Arbitration Act will not apply to criminal cases. +
+ +

2.3 Obligations

+ +

+ You are obliged +

+ +
  1. + to provide accurate information + as part of Assurance. + You give permission for verification of the information + using CAcert-approved methods. +
  2. + to make no false representations. +
  3. + to submit all your disputes to Arbitration + (DRP => COD7). +
+ +

2.4 Principles

+ +

+As a Member of CAcert, you are a member of +the Community. + You are further obliged to + work within the spirit of the Principles + of the Community. + These are described in + Principles of the Community. +

+ +

2.5 Security

+

+CAcert exists to help you to secure yourself. +You are primarily responsible for your own security. +Your security obligations include +

+ +
  1. + to secure yourself and your computing platform (e.g., PC), +
  2. + to keep your email account in good working order, +
  3. + to secure your CAcert account + (e.g., credentials such as username, password), +
  4. + to secure your private keys, +
  5. + to review certificates for accuracy, + and +
  6. + when in doubt, notify CAcert, +
  7. + when in doubt, take other reasonable actions, such as + revoking certificates, + changing account credentials, + and/or generating new keys. +
+ +

+Where, above, 'secure' means to protect to a reasonable +degree, in proportion with your risks and the risks of +others. +

+ +

3. Law and Jurisdiction

+ +

3.1 Governing Law

+ +

+This agreement is governed under the law of +New South Wales, Australia, +being the home of the CAcert Inc. Association. +

+ +

3.2 Arbitration as Forum of Dispute Resolution

+ +

+You agree, with CAcert and all of the Community, +that all disputes arising out +of or in connection to our use of CAcert services +shall be referred to and finally resolved +by Arbitration under the rules within the +Dispute Resolution Policy of CAcert +(DRP => COD7). +The rules select a single Arbitrator chosen by CAcert +from among senior Members in the Community. +The ruling of the Arbitrator is binding and +final on Members and CAcert alike. +

+ +

+In general, the jurisdiction for resolution of disputes +is within CAcert's own forum of Arbitration, +as defined and controlled by its own rules (DRP => COD7). +

+ +

+We use Arbitration for many purposes beyond the strict +nature of disputes, such as governance and oversight. +A systems administrator may +need authorisation to conduct a non-routine action, +and Arbitration may provide that authorisation. +Thus, you may find yourself party to Arbitration +that is simply support actions, and you may file disputes in +order to initiate support actions. +

+ +

3.3 Termination

+

+You may terminate this agreement by resigning +from CAcert. You may do this at any time by +writing to CAcert's online support forum and +filing dispute to resign. +All services will be terminated, and your +certificates will be revoked. +However, some information will continue to +be held for certificate processing purposes. +

+ +

+The provisions on Arbitration survive any termination +by you by leaving CAcert. +That is, even if you resign from CAcert, +you are still bound by the DRP (COD7), +and the Arbitrator may reinstate any provision of this +agreement or bind you to a ruling. +

+ +

+Only the Arbitrator may terminate this agreement with you. +

+ +

3.4 Changes of Agreement

+ +

+CAcert may from time to time vary the terms of this Agreement. +Changes will be done according to the documented CAcert policy +for changing policies, and is subject to scrutiny and feedback +by the Community. +Changes will be notified to you by email to your primary address. +

+ +

+If you do not agree to the changes, you may terminate as above. +Continued use of the service shall be deemed to be agreement +by you. +

+ +

3.5 Communication

+ +

+Notifications to CAcert are to be sent by +email to the address +support at CAcert.org. +You should attach a digital signature, +but need not do so in the event of security +or similar urgency. +

+ +

+Notifications to you are sent +by CAcert to the primary email address +registered with your account. +You are responsible for keeping your email +account in good working order and able +to receive emails from CAcert. +

+ +

+Arbitration is generally conducted by email. +

+ +

4. Miscellaneous

+ +

4.1 Other Parties Within the Community

+ +

+As well as you and other Members in the Community, +CAcert forms agreements with third party +vendors and others. +Thus, such parties will also be in the Community. +Such agreements are also controlled by the same +policy process as this agreement, and they should +mirror and reinforce these terms. +

+ + +

4.2 References and Other Binding Documents

+ +

+This agreement is CAcert Official Document 9 (COD9) +and is a controlled document. +

+ +

+You are also bound by +

+ +
  1. + + Certification Practice Statement (CPS => COD6). +
  2. + + Dispute Resolution Policy (DRP => COD7). +
  3. + + Privacy Policy (PP => COD5). +
  4. + + Principles of the Community. +
+ +

+Where documents are referred to as => COD x, +they are controlled documents +under the control of Policy on Policies (COD1). +

+ +

+This agreement and controlled documents above are primary, +and may not be replaced or waived except +by formal policy channels and by Arbitration. +

+ +

4.3 Informative References

+ +

+The governing documents are in English. +Documents may be translated for convenience. +Because we cannot control the legal effect of translations, +the English documents are the ruling ones. +

+ +

+You are encouraged to be familiar with the +Assurer Handbook, +which provides a more readable introduction for much of +the information needed. +The Handbook is not however an agreement, and is overruled +by this agreement and others listed above. +

+ +

4.4 Not Covered in this Agreement

+ +

+Intellectual Property. +This Licence does not transfer any intellectual +property rights ("IPR") to you. CAcert asserts and +maintains its IPR over its roots, issued certificates, +brands, logos and other assets. +Note that the certificates issued to you +are CAcert's intellectual property +and you do not have rights other than those stated. +

+ + + + diff --git a/Agreements/NRPDisclaimerAndLicence.html b/Agreements/NRPDisclaimerAndLicence.html new file mode 100644 index 0000000..4d410fb --- /dev/null +++ b/Agreements/NRPDisclaimerAndLicence.html @@ -0,0 +1,136 @@ + + + + CAcert - Non-Related Persons - Disclaimer and Licence + + + + + + + + + + + + + + + + + + + + + + +
NRP-DaL (Advisory)
POLICY m20070918.1 + $Date$ + +
COD4
+ +

+ + + + + +
+ +

Non-Related Persons

+

(Disclaimer and Licence)

+ + +

Definitions

+ +

+This is a Disclaimer and Licence from + CAcert Inc , +the "issuer", +to you, the "user," +being a general user of the Internet. +

+ +

Disclaimer

+ +

+The issuer has no other agreement with you, +and has no control nor knowledge +as to how you intend to use the products of the issuer. +You alone take on all of the risk and all of the +liability of your usage. +The issuer makes no guarantee, warranty nor promise to you. +

+ +

+Therefore, to the fullest extent possible in law, +ISSUER DISCLAIMS ALL LIABILITY TO YOU +on behalf of itself and its related parties. +

+ +

Licence

+ +

+This licence offers you a non-exclusive, non-transferable +'PERMISSION TO USE' certificates issued by issuer. +

+ +
  • + You may 'USE' the certificates as facilitated + by your software. For example, + you may construct connections, read emails, + load code or otherwise, as facilitated by your + software. +
  • + You may NOT RELY on any statements or claims + made by the certificates or implied in any way. +
  • + If your software is licensed under a separate + third party agreement, it may be permitted + to make statements or claims based on the certificates. + You may NOT RELY on these statements or claims. +
  • + You may NOT distribute certificates or root keys + under this licence, nor make representation + about them. +
+ +
+ +

Alternatives

+ +

+If you find the terms of the above +Non-Related Persons +Disclaimer and Licence +difficult or inadequate for your use, you may wish to +

+ + + +

+These alternatives are outside the above +Non-Related Persons Disclaimer and Licence +and do not incorporate. +

+ + + diff --git a/DisputeResolutionPolicy.html b/DisputeResolutionPolicy.html new file mode 100644 index 0000000..a84645f --- /dev/null +++ b/DisputeResolutionPolicy.html @@ -0,0 +1,639 @@ + + + + +Dispute Resulution Policy + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DRP Teus Hagen
POLICY m20070919.3 + $Date$ + +
COD7
Dispute Resolution Policy
+ + +

0. Introduction

+ +

+This is the Dispute Resolution Policy for CAcert. +Disputes arising out of +operations by CAcert and interactions between +users may be addressed through this policy. +This document also presents the rules for +resolution of disputes. +

+ +

0.1 Nature of Disputes

+ +

+Disputes include: +

+ + + +

1. Filing

+ +

1.1 Filing Party

+

+Anyone may file a dispute. +In filing, they become Claimants. +

+ +

1.2 Channel for Filing

+ +

+Disputes are filed by being sent to the normal +support channel of CAcert, +and a fee may be payable. +

+ +

+Such fees as are imposed on filing will be specified +on the dispute resolution page of the website. +

+ +

1.3 Case Manager

+

+The Case Manager (CM) takes control of the filing. +

+ +
  1. + CM makes an initial determination as + to whether this filing is a dispute + for resolution, or it is a request + for routine support. +
  2. + CM logs the case and establishes such + documentation and communications support as is customary. +
  3. + If any party acts immediately on the filing + (such as an urgent security action), + the CM names these parties to the case. +
  4. + CM selects the Arbitrator. +
+ +

+The personnel within the CAcert support team +are Case Managers, by default, or as directed +by the Dispute Resolution Officer. +

+ +

1.4 Contents

+

+The filing must specify: +

+ + + +

+If the filing is inadequate for lack of information +or for format, the Case Manager +may refile with the additional information, +attaching the original messages. +

+ +

1.5 The Arbitrator

+ +

+The Case Manager selects the Arbitrator according +to the mechanism managed by the Dispute Resolution Officer +and approved from time to time. +This mechanism is to maintain a list of Arbitrators available for +dispute resolution. +Each selected Arbitrator has the right to decline the dispute, +and should decline a dispute with which there exists a conflict +of interest. +The reason for declining should be stated. +If no Arbitrator accepts the dispute, the case is +closed with status "declined." +

+ +

+Arbitrators are experienced Assurers of CAcert. +They should be independent and impartial, including +of CAcert itself where it becomes a party. +

+ +

2. The Arbitration

+ + +

2.1 Authority

+ +

+The Board of CAcert and the Users vest in Arbitrators +full authority to hear disputes and deliver rulings +which are binding on CAcert and the Users. +

+ + +

2.2 Preliminaries

+ +

+The Arbitrator conducts some preliminaries: +

+ + + + +

2.3 Jurisdiction

+ +

+Jurisidiction - the right or power to hear and rule on +disputes - is initially established by clauses in the +User agreements for all CAcert Users. +The agreement must establish: +

+ + + +

+An external court may have ("assert") jurisdiction to decide on +issues such as trademark, privacy, contract and fraud, +and may do so with legal remedies. +These are areas where jurisdiction may need +to be considered carefully: +

+ + + +

+The Arbitrator must consider jurisdiction and rule on a +case by case basis whether jurisdiction is asserted, +either wholly or partially, or declines to hear the case. +In the event of asserting +jurisdiction, and a NRP later decides to pursue rights in +another forum, the Arbitrator should seek the agreement +of the NRP to file the ruling as part of the new case. +

+ +

2.4 Basis in Law

+ +

+Each country generally has an Arbitration Act +that elevates Arbitration as a strong dispute +resolution forum. +The Act generally defers to Arbitration +if the parties have so agreed. +That is, as Users of CAcert, you agree to resolve +all disputes before CAcert's forum. +This is sometimes called private law +or alternative dispute resolution. +

+ +

+As a matter of public policy, courts will generally +refer any case back to Arbitration. +Users should understand that they will have +strictly limited rights to ask the courts to +seek to have a case heard or to override a Ruling. +

+ + +

2.5 External Courts

+ +

+ When an external court claims and asserts its jurisdiction, + and issues a court order, subpoena or other service to CAcert, + the CM files the order as a dispute, with the external court + as Claimant. + The CM and other support staff are granted no authority to + act on the basis of any court order, and ordinarily + must await the order of the Arbitrator + (which might simply be a repeat of the external court order). +

+ +

+ The Arbitrator establishes the bona fides of the + court, and rules. + The Arbitrator may rule to reject the order, + for jurisdiction or other reasons. + By way of example, if all Parties are registered Users, + then jurisdiction more normally falls within the forum. + If the Arbitrator rules to reject, + he should do so only after consulting with CAcert counsel. + The Arbitrator's jurisidiction is ordinarily that of + dealing with the order, and + not that which the external court has claimed to. +

+ + +

2.6 Process

+ +

+The Arbitrator follows the procedure: +

+ + +
  1. + Establish the facts. + The Arbitrator collects the evidence from the parties. + The Arbitrator may order CAcert or Users under + jurisdiction to provide support or information. + The Arbitrator may use email, phone or face-to-face + meetings as proceedings. +
  2. + Apply the Rules of Dispute Resolution, + the policies of CAcert and the governing law. + The Arbitrator may request that the parties + submit their views. + The Arbitrator also works to the mission of CAcert, + the benefit of all Users, and the community as a whole. + The Arbitrator may any assistance. +
  3. + Makes a considered Ruling. +
+ +

3. The Ruling

+ +

3.1 The Contents

+ +

+The Arbitrator records: +

+ +
  1. + The Identification of the Parties, +
  2. + The Facts, +
  3. + The logic of the rules and law, +
  4. + The directions and actions to be taken by each party + (the ruling). +
  5. + The date and place that the ruling is rendered. +
+ + +

3.2 Process

+

+Once the Ruling is delivered, the case is closed. +The Case Manager is responsible for recording the +Ruling, publishing it, and advising users. +

+ +

+Proceedings are ordinarily private. +The Ruling is ordinarily published, +within the bounds of the Privacy Policy. +The Ruling is written in English. +

+ +

+Only under exceptional circumstances can the +Arbitrator declare the Ruling private under seal. +Such a declaration must be reviewed in its entirety +by the Board, +and the Board must confirm or deny that declaration. +If it confirms, the existance of any Rulings under seal +must be published to the Users in a timely manner +(within days). +

+ +

3.3 Binding and Final

+ +

+The Ruling is binding and final on CAcert and all Users. +Ordinarily, all Users agree to be bound by this dispute +resolution policy. Users must declare in the Preliminaries +any default in agreement or binding. +

+ +

+If a person who is not a User is a party to the dispute, +then the Ruling is not binding and final on that person, +but the Ruling must be presented in filing any dispute +in another forum such as the person's local courts. +

+ +

3.4 Re-opening the Case or Appeal

+ +

+In the case of clear injustices, egregious behaviour or +unconscionable Rulings, parties may seek to re-open the +case by filing a dispute. The new Arbitrator +reviews the new dispute, +re-examines and reviews the entire case, then rules on +whether the case may be re-opened or not. +

+ +

+If the new Arbitrator rules the case be re-opened, +then it is referred to the Board of CAcert Inc. +The Board hears the case and delivers a final +and binding Ruling. +

+ +

3.5 Liability

+ +

+All liability of the Arbitrator for any act in +connection with deciding a dispute is excluded +by all parties, provided such act does not constitute +an intentional breach of duty. +All liability of the Arbitrators, CAcert, its officers and its +employees (including Case Manager) +for any other act or omission in connection with +arbitration proceedings is excluded, provided such acts do not +constitute an intentional or grossly negligent breach of duty. +

+ +

+The above provisions may only be overridden by +appeal process (by means of a new dispute causing +referral to the Board). +

+ +

3.6 Remedies

+ +

+The Arbitrator generally instructs using internal remedies, +that is ones that are within the general domain of CAcert, +but there are some external remedies at his disposal. +He may rule and instruct any of the parties on these issues. +

+ + + +

+The Arbitrator is not limited within the general domain +of CAcert, and may instruct novel remedies as seen fit. +Novel remedies outside the domain may be routinely +confirmed by the Board by way of appeals process, +in order to establish precedent. +

+ +

4. Appendix

+ + +

4.1 The Advantages of this Forum

+

+The advantage of this process for Users is: +

+ + + +

4.2 The Disadvantages of this Forum

+ +

+Some disadvantages exist. +

+ + + +

4.3 Process and Flow

+ +

+To the extent reasonable, the Arbitrator conducts +the arbitration as with any legal proceedings. +This means that the process and style should follow +legal tradition. +

+ +

+However, the Arbitrator is unlikely to be trained in +law. Hence, common sense must be applied, and the +Arbitrator has wide latitude to rule on any particular +motion, pleading, submission. The Arbitrator's ruling +is final within the arbitration. +

+ +

+Note also that many elements of legal proceedings are +deliberately left out of the rules. +

+ + + diff --git a/OrganisationAssurancePolicy/OrganisationAssurancePolicy.html b/OrganisationAssurancePolicy/OrganisationAssurancePolicy.html new file mode 100644 index 0000000..30c7086 --- /dev/null +++ b/OrganisationAssurancePolicy/OrganisationAssurancePolicy.html @@ -0,0 +1,379 @@ + + + +Organisation Assurance Policy + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OAP Jens
POLICY m20070918.x + $Date$ + +
COD11
Organisation Assurance Policy
+ + + +

0. Preliminaries

+ +

+This policy describes how Organisation Assurers ("OAs") +conduct Assurances on Organisations. +It fits within the overall web-of-trust +or Assurance process of Cacert. +

+ +

+This policy is not a Controlled document, for purposes of +Configuration Control Specification ("CCS"). +

+ +

1. Purpose

+ +

+Organisations with assured status can issue certificates +directly with their own domains within. +

+ +

+The purpose and statement of the certificate remains +the same as with ordinary users (natural persons) +and as described in the CPS. +

+ + + + +

2. Roles and Structure

+ +

2.1 Assurance Officer

+ +

+The Assurance Officer ("AO") +manages this policy and reports to the board. +

+ +

+The AO manages all OAs and is responsible for process, +the CAcert Organisation Assurance Programme form ("COAP"), +OA training and testing, manuals, quality control. +In these responsibilities, other Officers will assist. +

+ +

2.2 Organisation Assurers

+ +

+

+ +
  1. + An OA must be an experienced Assurer +
      +
    1. Have 150 assurance points.
      2. +
    2. Be fully trained and tested on all general Assurance processes.
      3. +
    + +
  2. + Must be trained as Organisation Assurer. +
      +
    1. Global knowledge: This policy.
      2. +
    2. Global knowledge: A OA manual covers how to do the process.
      3. +
    3. Local knowledge: legal forms of organisations within jurisdiction.
      4. +
    4. Basic governance.
      5. +
    5. Training may be done a variety of ways, + such as on-the-job, etc.
      6. +
    + +
  3. + Must be tested. +
      +
    1. Global test: Covers this policy and the process.
      2. +
    2. Local knowledge: Subsidiary Policy to specify.
      3. +
    3. Tests to be created, approved, run, verified + by CAcert only (not outsourced).
      4. +
    4. Tests are conducted manually, not online/automatic.
      5. +
    5. Documentation to be retained.
      6. +
    6. Tests may include on-the-job components.
      7. +
    + +
  4. + Must be approved. +
      +
    1. Two supervising OAs must sign-off on new OA, + as trained, tested and passed. +
      2. +
    2. AO must sign-off on a new OA, + as supervised, trained and tested. +
      3. +
    +
+ + + +

2.3 Organisation Administrator

+ +

+The Administrator within each Organisation ("O-Admin") +is the one who handles the assurance requests +and the issuing of certificates. +

+ +
  1. + O-Admin must be Assurer +
      +
    1. Have 100 assurance points.
      2. +
    2. Fully trained and tested as Assurer.
      3. +
    + +
  2. + Organisation is required to appoint O-Admin, + and appoint ones as required. +
      +
    1. On COAP Request Form.
      2. +
    + +
  3. + O-Admin must work with an assigned OA. +
      +
    1. Have contact details.
      2. +
    +
+ + +

3. Policies

+ +

3.1 Policy

+ +

+There is one policy being this present document, +and several subsidiary policies. +

+ +
    +
  1. This policy authorises the creation of subsidiary policies.
    2. +
  2. This policy is international.
    3. +
  3. Subsidiary policies are implementations of the policy.
    4. +
  4. Organisations are assured under an appropriate subsidiary policy.
    5. +
+ +

3.2 Subsidiary Policies

+ +

+The nature of the Subsidiary Policies ("SubPols"): +

+ +
  1. + SubPols are purposed to check the organisation + under the rules of the jurisdiction that creates the + organisation. This does not evidence an intention + by CAcert to + enter into the local jurisdiction, nor an intention + to impose the rules of that jurisdiction over any other + organisation. + CAcert assurances are conducted under the jurisdiction + of CAcert. +
  2. + For OAs, + SubPol specifies the tests of local knowledge + including the local organisational forms. +
  3. + For assurances, + SubPol specifies the local documentation forms + which are acceptable under this SubPol to meet the + standard. +
  4. + SubPols are subjected to the normal + policy approval process. +
+ +

3.3 Freedom to Assemble

+ +

+Subsidiary Policies are open, accessible and free to enter. +

+ +
  1. + SubPols compete but are compatible. +
  2. + No SubPol is a franchise. +
  3. + Many will be on State or National lines, + reflecting the legal + tradition of organisations created + ("incorporated") by states. +
  4. + 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). +
  5. + There could also be SubPols for special + organisations, one person organisations, + UN agencies, churches, etc. +
  6. + 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. +
+ + +

4. Process

+ +

4.1 Standard of Organisation Assurance

+

+The essential standard of Organisation Assurance is: +

+ +
  1. + the organisation exists +
  2. + the organisation name is correct and consistent: +
      +
    1. in official documents specified in SubPol.
      2. +
    2. on COAP form.
      3. +
    3. in CAcert database.
      4. +
    4. form or type of legal entity is consistent
      5. +
    +
  3. + signing rights: + requestor can sign on behalf of the organisation. +
  4. + the organisation has agreed to the terms of the + Registered User Agreement, + and is therefore subject to Arbitration. +
+ +

+ Acceptable documents to meet above standard + are stated in the SubPol. +

+ +

4.2 COAP

+

+The COAP form documents the checks and the resultant +assurance results to meet the standard. +Additional information to be provided on form: +

+ +
  1. + CAcert account of O-Admin (email address?) +
  2. + location: +
      +
    1. country (MUST).
      2. +
    2. city (MUST).
      3. +
    3. additional contact information (as required by SubPol).
      4. +
    +
  3. + administrator account names (1 or more) +
  4. + domain name(s) +
  5. + Agreement with registered user agreement. + Statement and initials box for organsation + and also for OA. +
  6. + Date of completion of Assurance. + Records should be maintained for 7 years from + this date. +
+ +

+The COAP should be in English. Where translations +are provided, they should be matched to the English, +and indication provided that the English is the +ruling language (due to Arbitration requirements). +

+ +

4.3 Jurisdiction

+ +

+Organisation Assurances are carried out by +CAcert Inc under its Arbitration jurisdiction. +Actions carried out by OAs are under this regime. +

+ +
  1. + The organisation has agreed to the terms of the + Registered User Agreement, +
  2. + The organisation, the Organisation Assurers, CAcert and + other related parties are bound into CAcert's jurisdiction + and dispute resolution. +
  3. + The OA is responsible for ensuring that the + organisation reads, understands, intends and + agrees to the registered user agreement. + This OA responsibility should be recorded on COAP + (statement and initials box). +
+ +

5. Exceptions

+ + +
  1. + Conflicts of Interest. + 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. +
  2. + Trusted Third Parties. + TTPs are not generally approved to be part of + organisation assurance, + but may be approved by subsidiary policies according + to local needs. +
  3. + Exceptional Organisations. + (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. +
  4. + DBA. + Alternative names for organisations + (DBA, "doing business as") + can be added as long as they are proven independently. + E.g., registration as DBA or holding of registered trade mark. + This means that the anglo law tradition of unregistered DBAs + is not accepted without further proof. +
+ diff --git a/PolicyOnFoundations.html b/PolicyOnFoundations.html new file mode 100644 index 0000000..17b8485 --- /dev/null +++ b/PolicyOnFoundations.html @@ -0,0 +1,222 @@ + + + + W I P - Foundations Policy - W I P + + +

-1. To Fix

+ + + +
+ +
W I P . . W I P . . W I P . . W I P . . W I P
+ +

Foundations Policy

+ +

0. Preamble

+ +

+Foundations and Associations are now a strong part of CAcert's community. +In part this is because the Dutch have set up a great Foundation, Oophaga, +and a German Foundation named Secure-U is in the process of being +set up for the support in Germany (CeBIT, etc). +As time goes on, we'll get more and more questions on how to do this process. +

+ +

+Let's start a policy on Foundations. Here is a WIP policy, +to get people thinking: +

+ +

Terms

+ +

+In this policy, we refer equally +to Associations, Foundations, Vereins (German), Stichtings (Dutch), +and other legal forms found around the world. +For simplicity only the term Foundation is used in this document. +

+ +

1. Principles

+ +

+ Foundations are a good mechanism to + provide local support to CAcert activities. + As a policy, the CAcert community encourages + well-governed Foundations to be created and + to take up local responsibilities. +

+ +
    +
  1. Foundations may accept and manage local donations, etc.
    2. +
  2. Foundations may organise events.
    3. +
  3. Foundations may provide budget for organised activities.
    4. +
+ +

Limits on the Foundation.

+ +
    +
  1. The Foundation should be non-profit, non-commercial, non-competitive. + This needs to be measured against what is possible in local laws.
    2. +
  2. The Foundation must use a Mission and/or Purpose that is + written into their Charter that limits their purpose and responsibility.
    3. +
  3. The Membership Register must be open to scrutiny + to the community.
    4. +
  4. The Financial Report must be open to scrutiny + to the community.
    5. +
+ +

Mission of the Foundation.

+ +

+The Mission / Purpose should be controlled: +

+ +
    +
  1. Should be announced and comments accepted.
    2. +
  2. should support the CAcert community.
    3. +
  3. can only refer to CAcert if CAcert Inc agrees.
    4. +
  4. should be approved by policy group.
    5. +
  5. should not be changeable. + If changeable, a community process must be adopted.
    6. +
+ +

+Comments: +

+ +

+... The "limitation of their purpose" has to be fortified. If we accept for example a german "Verein" with a very small membership base, these limitations can be easily changed by a member decission and therfore the way for a missuse of the money is prepared. So this limitation should be "fortified" and controlled carefully. I like (5), but can we - by legal terms - limit the change to a community process outside that foundation? If it is only inside, we need a broad member base ... +

+ +

+disagreement with your idea that the local foundations should be bound on the mission instead of being bound to CAcert. F.e. if the mission is "free certificates" then the local foundations could decide to spend the money to a free PGP project instead of CAcert for example. While it is fine for foundations to support many projects, if we create our own foundations we should make sure that they support CAcert. +

+ +

+Creating a foundation with the goal of supporting projects who issue free certificates is completly different then creating a foundation with the goal to support the CAcert project. +

+ +

+CAcert's mission itself is not defined. Is it "free certs" ? Is it "any free certs" or is it special "free certs?" We need to define free certs. +

+ +

+ + ISOC suggests: +"2. Purpose of Chapters + +Chapters of the Internet Society are expected to serve the interests of a segment of the global Internet community in a manner consistent with the mission and principles of the Internet Society. Through a presence local to its community of interest, a Chapter focuses on issues and developments important to its community. A Chapter recognizes, honours, and uses the culture, customs, and language of its community. Every Chapter shall have an explicit statement of purpose. +

+ + +

Legal Independence

+ +

+ The Foundation should be legally independent from others, including CAcert Inc. +

+ +
    +
  1. The Foundation must not use "CAcert" in the name.
    2. +
  2. The Foundation and its members must not represent themselves + as being CAcert or CAcert Inc or even being "part of CAcert Inc".
    3. +
  3. + The Foundation may represent itself as "part of the CAcert community."
    4. +
+ +

+Comment: Representing is difficult ... too much hierarchy. +There is a mutual thing with CAcert and others. E.g. +a set of foundations/associations with a common goal, +each with it's sub +area to take care of, each supporting the other. +

+ +

+Right know we talk about foundations especially created for the support of CAcert. Or is it for free certs? Which is it? +

+ +

+For example: There are several approaches to "issuing free certificates" (the "mission" for this example). I like some of them but not all. I like CAcerts approach. So I would donate money towards CAcert (CAcert's approach) but not to the overall mission "free certificates". If me move from a well-known name attached to a particular mission ("CAcert") to an overall "mission definition" we will lose our shape to the outside. This might confuse public. +

+ +

+Or another example: CAcert is accepted as a "trusted CA" in more and more areas ("els..." "Sta...." for virtual post office...). If we move to an "mission attachment" outsiders might think about loose, uncontrollable structures while the believe in a fortified CAcert (which WE know it is not!). +

+ +

+ + ISOC suggests: +"7. Liabilities The Internet Society shall not be liable for any act or omission or incurred liability of any kind of any Chapter." Also see "5. Public Positions and Statements." +

+ +

Liason

+ +

+ The Foundation must maintain lines of communication + open with CAcert and the community. +

+ +
    +
  1. Although independent, the community has the right to provide advice.
    2. +
  2. A liason officer must be named to the CAcert community.
    3. +
+ +

Finances and Books

+ +

+ The Foundation must govern its own books. +

+ +
    +
  1. As we are a security community we expect money matters + to be treated as seriously as we treat our systems.
    2. +
  2. The money should be spent locally.
    3. +
  3. Transfers between Foundations, regions and CAcert Inc + must be carefully controlled and documented. + The process must be open, transparent and auditable.
    4. +
  4. Public reports on finances must be open.
    5. +
  5. Foundation should accept a community financial auditor.
    6. +
+ +

+Comment: +So we should define which level of bookkeeping we set as a minimum standard. We don't need to rise it up to the german standard for example, but we should define a minimum. +

+ +

Suggestions

+ +

+ +Another idea: the "CAcert" foundations should be an Association member +of CAcert Inc. In this way one is less dependent of individuals in the +Association. With this I do not say that personal membership of the +association should be impossible. Having a subgroup of association +members who are a supervisory council and policy group with certain +responsibilities and power the CAcert association gets more body and +corrective entities. The foundations have still their own independence. +Is that something to bind the foundations, as well to get CAcert more +stable? + +

+ +

+ +Maybe we could think of CAcert Inc. as a "parent foundation" (don't know if it's the right word. The child entities (the local foundations) are members of it. Having this in place would mean that the child entities (representing the users) have a certain amount of control because they do the AGM and vote in the board. By having this it would be even more protected. That's because control would need to be exercised over many daughter foundations before control of the main foundation was gained. + +

+ + +
W I P . . W I P . . W I P . . W I P . . W I P
+ + + diff --git a/PrivacyPolicy.php b/PrivacyPolicy.php new file mode 100644 index 0000000..65249d7 --- /dev/null +++ b/PrivacyPolicy.php @@ -0,0 +1,3 @@ + diff --git a/PrivacyPolicy.txt b/PrivacyPolicy.txt new file mode 100644 index 0000000..95236d4 --- /dev/null +++ b/PrivacyPolicy.txt @@ -0,0 +1,85 @@ +

+ +

+ +

+ +

1.

+

+ +

+ +

2.

+

+ +

+

+ +

+ +

3.

+

+ +

+ +

4.

+

+ +

+

+ +

+ +

5.

+

+ +

+ +

6.

+

+ +

+ +

7.

+

+ +

+ + + +

8.

+

+ +

+ +

9.

+

+ + +

+ +

10.

+

+ +http://www.privacy.gov.au/ for further details.")?> + +

+ + +

+

+CAcert Inc.
+P.O. Box 81
+Banksia NSW 2216
+Australia +

+ + + +