cacert/cacert-policies
9
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

moving these all into Policies so that they can be managed from

Browse source 
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
This commit is contained in:
Ian Grigg 2008-01-28 00:01:03 +00:00
parent 7e8bf8c56f
commit 4cf3186345
8 changed files with 2371 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

395
Agreements/3PVDisclaimerAndLicence.html Normal file
View file

@ -0,0 +1,395 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title>CAcert - 3rd Party Vendor -- Licence and Disclaimer </title></head>
<body>
<h3> -1. TO BE FIXED </h3>
<center> <b> D R A F T </b> </center>
<p> <i>
This is DRAFT-V0.02.
</i></p>
<ul><li><i>
th: firefox/thunderbird/evolution/etc distribute things
but also to distributors eg Fedora, Ubuntu, etc. Who on there term
redistribute it. This recursion should that be explicit in this
disclaimer and license?
What to do about multi-tier distributors,
is this agreement with primary or end distributor or all of them?
Mozilla => KDE => Evolution.
</i></li><li><i>
pg: I think the 3pv should define "USE" and "RELY" in a preamble
(or somewhere else at the beginning)
Perhaps even specifically declare the difference between USE and RELY
The other things are more or less clear in general,
but USE and RELY and its special meaning should be defined
</i></li><li><i>
pg: 1.4 Agreement in Spirit
It doesn't clearly indicate that this is only in respect to cert stuff.
Also, why are we policing the redistributors?
</i></li><li><i>
Practically everything else...
These are just scattered ideas and have not been exposed to criticism yet...
</i></li></ul>
<hr>
<h3> <a name="0"> 0. </a> Preliminaries </h3>
<h4> <a name="0.1"> 0.1 </a> Background </h4>
<p>
Being that,
</p>
<ul><li>
CAcert is a Certificate Authority ("the CA"),
</li><li>
the CA offers a free certificate service to its subscribers,
</li><li>
for the direct benefit and RELIANCE of its Community of signed-up users,
</li><li>
and where possible, of some indirect benefit and USE to other general users
(or end-users) of the Internet;
</li></ul>
<p>
And that,
</p>
<ul><li>
the end-user has a choice in client software (such as browsers and email clients),
</li><li>
such software offers features which are wholly or partly
based on use of certificates,
</li><li>
which may include the certificates of the CA
and/or of any other certificate authority,
</li><li>
the end-user may have strictly limited possibilities to choose or
control the usage made of certificates,
</li><li>
and that it may not be economic nor reasonable for software
to provide for a high degree of choice and control over certificates,
</li></ul>
<p>
And that, in offering the USE of certificates to the end-user,
</p>
<ul><li>
the CA has no direct relationship with the the end-user,
</li><li>
it is not economic nor reasonable to expect such a
direct relationship,
</li><li>
by way of an open, indirect offering,
the CA provides its
<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">
Non-Related Persons -- Disclaimer and Licence</a>
for the end-user ("NRP"), in which
<ul><li>
the CA disclaims liability to NRPs,
</li><li>
the CA offers a free licence to USE to all NRPs,
</li><li>
the CA specifically does not permit the NRPs to RELY,
</li></ul>
</li></ul>
<p>
And that,
</p>
<ul><li>
<b>you are a third party vendor or distributor of software for end-users</b>
("the Vendor"),
</li><li>
the Vendor offers a free distribution of root certificates ("root list"),
within client software,
</li><li>
that in choosing the Vendor's software,
the end-user would enter into an
End-User Licence Agreement ("EULA") with the Vendor,
</li><li>
the Vendor has the primary and only direct relationship with the end-user,
</li></ul>
<p>
We both, CA and Vendor, agree that,
</p>
<ul><li>
we are committed to providing a
free and USABLE way to benefit from cryptography,
</li><li>
we are committed to the security of our respective communities,
</li><li>
the design, custom and history of the public key infrastructure
("the PKI") creates risks and liabilities
for inappropriate RELIANCE by the end-user,
</li><li>
it is not economically possible nor reasonable
to provide a free, open and unconstrained service
that can be RELIED upon by end-users.
</li></ul>
<h4> <a name="0.2"> 0.2 </a> Parties </h4>
With the above understanding, the following Licence and Disclaimer is offered
by CA to Vendor.
<h4> <a name="0.3"> 0.3 </a> Terms </h4>
<p>
Terms used in this agreement are as defined in the
<a href="http://svn.cacert.org/CAcert/RegisteredUserAgreement.html">
CAcert Community Agreement</a>.
</p>
<h3> <a name="1"> 1. </a> Agreement and Licence </h3>
<h4> <a name="1.1"> 1.1 </a> Agreement </h4>
<p>
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.
</p>
<h4> <a name="1.1"> 1.2 </a> Other Agreements </h4>
<p>
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.
</p>
<p>
The relationship between the CA and the end-user is based on CA's
Non-Related Persons -- Disclaimer and Licence
("<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">NRP-DaL</a>").
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.
</p>
<h4> <a name="1.3"> 1.3 </a> Licence to Distribute </h4>
<p>
CA offers this licence to permit Vendor to distribute CA's roots
within Vendor's root list to Vendor's end-users.
</p>
<h4> <a name="1.4"> 1.4 </a> Agreement in Spirit </h4>
<p>
Vendor agrees to make EULA compatible and aligned with the CA's NRP-DaL.
Specifically, the EULA must:
</p>
<ul><li>
disclaim all liability,
</li><li>
offer free licence to USE, and
</li><li>
deny permission to RELY under this EULA;
</li></ul>
<p>
all with respect to the root list
(including root keys, certificates,
and related cryptographic and security software).
</p>
<h4> <a name="1.5"> 1.5 </a> Agreement in Practice </h4>
<p>
Where agreement is explicitly sought from the end-user
they will be offered and agree to:
</p>
<ul><li>
CA's NRP-DaL,
where the NRP-DaL and EULA are not in contradiction,
<i>OR</i>
</li><li>
only your EULA,
where the spirit of the NRP-DaL is preserved
within the EULA.
</li></ul>
<p>
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.
<br><i>Note, document this elsewhere in FAQ</i>.
</p>
<h4> <a name="1.6"> 1.6 </a> Fair and Non-Discriminatory </h4>
<p>
Vendor agrees to make available CA's root key
in a fair and non-discriminatory way to Vendor's end-users.
<br><i>Note, document this elsewhere in FAQ</i>.
</p>
<h3> <a name="2"> 2. </a> Disclaimer </h3>
<h4> <a name="2.1"> 2.1 </a> All Liability </h4>
<p>
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.
</p>
<p>
We in general DISCLAIM ALL LIABILITY to each other and to the end-user.
</p>
<h4> <a name="2.2"> 2.2 </a> Monetary Limits on Liability </h4>
<p>
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.
</p>
<p>
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.
</p>
<h3> <a name="3"> 3. </a> Legal Matters </h3>
<h4> <a name="2.3"> 3.1 </a> Law </h4>
<p>
The Choice of Law is that of NSW, Australia.
</p>
<h4> <a name="2.4"> 3.2 </a> Dispute Resolution </h4>
<p>
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.
</p>
<p>
We further agree, as a single exception to DRP,
that the single Arbitrator may be chosen from outside
the CAcert Community.
</p>
<h4> <a name="3.x"> 3.3 </a> CAcert Community Agreement </h4>
<p>
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.
</p>
<p>
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.
</p>
<p>
Acceptance alone of this present agreement by the Vendor
does not imply that Vendor is a Community User/Member.
</p>
<hr>
<p>
The following parts are not part of the above licence,
but may shed light.
</p>
<h3> <a name="faq"> Z. </a> FAQ </h3>
<h4> <a name="Z.1"> Z.1 </a> Notes on Liability </h4>
<p>
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.
</p>
<p>
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 <i>lowest-common-denominator</i>, that is,
the lowest of the liabilities that is accepted across all
CAs that are shipped by the CA.
This would generally be zero.
</p>
<p>
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.
</p>
<p>
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.
</p>
<h4> <a name="Z.2"> Z.2 </a> Reasonably Shown </h4>
<p>
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").
</p>
<p>
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.
</p>

512
Agreements/CAcertCommunityAgreement.html Normal file
View file

@ -0,0 +1,512 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title>CAcert Community Agreement</title></head>
<body>
<h3> <a name="0"> 0. </a> Introduction </h3>
<p>
This agreement is between
you, being a registered member ("Member")
within CAcert's community at large ("Community")
and CAcert Incorporated ("CAcert"),
being an operator of services to the Community.
</p>
<h4> <a name="0.1"> 0.1 </a> Terms </h4>
<ol><li>
"CAcert"
means CAcert Inc.,
a non-profit Association of Members incorporated in
New South Wales, Australia.
Note that Association Members are distinct from
the Members defined here.
</li><li>
"Member"
means you, a registered participant within CAcert's Community,
with an account on the website and the
facility to request certificates.
Members may be individuals ("natural persons")
or organisations ("legal persons").
</li><li>
"Organisation"
is defined under the Organisation Assurance programme,
and generally includes corporations and other entities
that become Members and become Assured.
</li><li>
"Community"
means all of the Members
that are registered by this agreement
and other parties by other agreements,
all being under CAcert's Arbitration.
</li><li>
"Non-Related Person" ("NRP"),
being someone who is not a
Member, is not part of the Community,
and has not registered their agreement.
Such people are offered the NRP-DaL
another agreement allowing the USE of certificates.
</li><li>
"Non-Related Persons - Disclaimer and Licence" ("NRP-DaL"),
another agreement that is offered to persons outside the
Community.
</li><li>
"Arbitration"
is the Community's forum for
resolving disputes, or jurisdiction.
</li><li>
"Dispute Resolution Policy" ("DRP" => COD7)
is the policy and
rules for resolving disputes.
</li><li>
"USE"
means the act by your software
to conduct its tasks, incorporating
the certificates according to software procedures.
</li><li>
"RELY"
means your human act in taking on a
risk and liability on the basis of the claim(s)
bound within a certificate.
</li><li>
"OFFER"
means the your act
of making available your certificate to another person.
Generally, you install and configure your software
to act as your agent and facilite this and other tasks.
OFFER does not imply suggestion of reliance.
</li><li>
"Issue"
means creation of a certificate by CAcert.
To create a certificate,
CAcert affixes a digital signature from the root
onto a public key and other information.
This act would generally bind a statement or claim,
such as your name, to your key.
</li><li>
"Root"
means CAcert's top level key,
used for signing certificates for Members.
In this document, the term includes any subroots.
</li><li>
"CAcert Official Document" ("COD" => 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.
</li><li>
"Certification Practice Statement" ("CPS" => COD6)
is the document that controls details
about operational matters within CAcert.
</li></ol>
<h3> <a name="1"> 1. </a> Agreement and Licence </h3>
<h4> <a name="1.1"> 1.1 </a> Agreement </h4>
<p>
You and CAcert both agree to the terms and conditions
in this agreement.
Your agreement is given by any of
</p>
<ul><li>
your signature on a form to request assurance of identity
("CAP" form),
</li><li>
your request on the website
to join the Community and create an account,
</li><li>
your request for Organisation Assurance,
</li><li>
your request for issuing of certificates, or
</li><li>
if you USE, RELY, or OFFER
any certificate issued to you.
</li></ul>
<p>
Your agreement
is effective from the date of the first event above
that makes this agreement known to you.
This Agreement
replaces and supercedes prior agreements,
including the NRP-DaL.
</p>
<h4> <a name="1.2"> 1.2 </a> Licence </h4>
<p>
As part of the Community, CAcert offers you these rights:
</p>
<ol><li>
You may USE any certificates issued by CAcert.
</li><li>
You may RELY on any certificate issued by CAcert,
as explained and limited by CPS (COD6).
</li><li>
You may OFFER certificates issued to you by CAcert
to Members for their RELIANCE.
</li><li>
You may OFFER certificates issued to you by CAcert
to NRPs for their USE, within the general principles
of the Community.
</li><li>
This Licence is free of cost,
non-exclusive, and non-transferrable.
</li></ol>
<h4> <a name="1.3"> 1.3 </a> Your Contributions </h4>
<p>
You agree to a non-exclusive non-restrictive non-revokable
transfer of Licence to CAcert for your contributions.
That is, if you post an idea or comment on a CAcert forum,
or email it to other Members,
your work can be used freely by the Community for
CAcert purposes, including placing under CAcert's licences
for wider publication.
</p>
<p>
You retain authorship rights, and the rights to also transfer
non-exclusive rights to other parties.
That is, you can still use your
ideas and contributions outside the Community.
</p>
<p>
Note that the following exceptions override this clause:
</p>
<ol><li>
Contributions to controlled documents are subject to
Policy on Policy ("PoP" => COD1)
</li><li>
Source code is subject to an open source licence regime.
</li></ol>
<h4> <a name="1.4"> 1.4 </a> Privacy </h4>
<p>
You give rights to CAcert to store, verify and process
and publish your data in accordance with policies in force.
These rights include shipping the data to foreign countries
for system administration, support and processing purposes.
Such shipping will only be done among
CAcert Community administrators and Assurers.
</p>
<p>
Privacy is further covered in the Privacy Policy ("PP" => COD5).
</p>
<h3> <a name="2"> 2. </a> Your Risks, Liabilities and Obligations </h3>
<p>
As a Member, you have risks, liabilities
and obligations within this agreement.
</p>
<h4> <a name="2.1"> 2.1 </a> Risks </h4>
<ol><li>
A certificate may prove unreliable.
</li><li>
Your account, keys or other security tools may be
lost or otherwise compromised.
</li><li>
You may find yourself subject to Arbitration
(DRP => COD7).
</li></ol>
<h4> <a name="2.2"> 2.2 </a> Liabilities </h4>
<ol><li>
You are liable for any penalties
as awarded against you by the Arbitrator.
</li><li>
Remedies are as defined in the DRP (COD7).
An Arbitrator's ruling may
include monetary amounts, awarded against you.
</li><li>
Your liability is limited to
a total maximum of
<b>1000 Euros</b>.
</li><li>
"Foreign Courts" may assert jurisdiction.
These include your local courts, and are outside our Arbitration.
Foreign Courts will generally refer to the Arbitration
Act of their country, which will generally refer
civil cases to Arbitration.
The Arbitration Act will not apply to criminal cases.
</li></ol>
<h4> <a name="2.3"> 2.3 </a> Obligations </h4>
<p>
You are obliged
</p>
<ol><li>
to provide accurate information
as part of Assurance.
You give permission for verification of the information
using CAcert-approved methods.
</li><li>
to make no false representations.
</li><li>
to submit all your disputes to Arbitration
(DRP => COD7).
</li></ol>
<h4> <a name="2.4"> 2.4 </a> Principles </h4>
<p>
As a Member of CAcert, you are a member of
the Community.
You are further obliged to
work within the spirit of the Principles
of the Community.
These are described in
<a href="http://svn.cacert.org/CAcert/principles.html">Principles of the Community</a>.
</p>
<h4> <a name="2.5"> 2.5 </a> Security </h4>
<p>
CAcert exists to help you to secure yourself.
You are primarily responsible for your own security.
Your security obligations include
</p>
<ol><li>
to secure yourself and your computing platform (e.g., PC),
</li><li>
to keep your email account in good working order,
</li><li>
to secure your CAcert account
(e.g., credentials such as username, password),
</li><li>
to secure your private keys,
</li><li>
to review certificates for accuracy,
and
</li><li>
when in doubt, notify CAcert,
</li><li>
when in doubt, take other reasonable actions, such as
revoking certificates,
changing account credentials,
and/or generating new keys.
</li></ol>
<p>
Where, above, 'secure' means to protect to a reasonable
degree, in proportion with your risks and the risks of
others.
</p>
<h3> <a name="3"> 3. </a> Law and Jurisdiction </h3>
<h4> <a name="3.1"> 3.1 </a> Governing Law </h4>
<p>
This agreement is governed under the law of
New South Wales, Australia,
being the home of the CAcert Inc. Association.
</p>
<h4> <a name="3.2"> 3.2 </a> Arbitration as Forum of Dispute Resolution </h4>
<p>
You agree, with CAcert and all of the Community,
that all disputes arising out
of or in connection to our use of CAcert services
shall be referred to and finally resolved
by Arbitration under the rules within the
Dispute Resolution Policy of CAcert
(DRP => COD7).
The rules select a single Arbitrator chosen by CAcert
from among senior Members in the Community.
The ruling of the Arbitrator is binding and
final on Members and CAcert alike.
</p>
<p>
In general, the jurisdiction for resolution of disputes
is within CAcert's own forum of Arbitration,
as defined and controlled by its own rules (DRP => COD7).
</p>
<p>
We use Arbitration for many purposes beyond the strict
nature of disputes, such as governance and oversight.
A systems administrator may
need authorisation to conduct a non-routine action,
and Arbitration may provide that authorisation.
Thus, you may find yourself party to Arbitration
that is simply support actions, and you may file disputes in
order to initiate support actions.
</p>
<h4> <a name="3.3"> 3.3 </a> Termination </h4>
<p>
You may terminate this agreement by resigning
from CAcert. You may do this at any time by
writing to CAcert's online support forum and
filing dispute to resign.
All services will be terminated, and your
certificates will be revoked.
However, some information will continue to
be held for certificate processing purposes.
</p>
<p>
The provisions on Arbitration survive any termination
by you by leaving CAcert.
That is, even if you resign from CAcert,
you are still bound by the DRP (COD7),
and the Arbitrator may reinstate any provision of this
agreement or bind you to a ruling.
</p>
<p>
Only the Arbitrator may terminate this agreement with you.
</p>
<h4> <a name="3.4"> 3.4 </a> Changes of Agreement </h4>
<p>
CAcert may from time to time vary the terms of this Agreement.
Changes will be done according to the documented CAcert policy
for changing policies, and is subject to scrutiny and feedback
by the Community.
Changes will be notified to you by email to your primary address.
</p>
<p>
If you do not agree to the changes, you may terminate as above.
Continued use of the service shall be deemed to be agreement
by you.
</p>
<h4> <a name="3.5"> 3.5 </a> Communication </h4>
<p>
Notifications to CAcert are to be sent by
email to the address
<b>support</b> <i>at</i> CAcert.org.
You should attach a digital signature,
but need not do so in the event of security
or similar urgency.
</p>
<p>
Notifications to you are sent
by CAcert to the primary email address
registered with your account.
You are responsible for keeping your email
account in good working order and able
to receive emails from CAcert.
</p>
<p>
Arbitration is generally conducted by email.
</p>
<h3> <a name="4"> 4. </a> Miscellaneous </h3>
<h4> <a name="4.1"> 4.1 </a> Other Parties Within the Community </h4>
<p>
As well as you and other Members in the Community,
CAcert forms agreements with third party
vendors and others.
Thus, such parties will also be in the Community.
Such agreements are also controlled by the same
policy process as this agreement, and they should
mirror and reinforce these terms.
</p>
<h4> <a name="4.2"> 4.2 </a> References and Other Binding Documents </h4>
<p>
This agreement is CAcert Official Document 9 (COD9)
and is a controlled document.
</p>
<p>
You are also bound by
</p>
<ol><li>
<a href="http://svn.cacert.org/CAcert/policy.htm">
Certification Practice Statement</a> (CPS => COD6).
</li><li>
<a href="http://svn.cacert.org/CAcert/dispute_resolution.html">
Dispute Resolution Policy</a> (DRP => COD7).
</li><li>
<a href="http://www.cacert.org/index.php?id=10">
Privacy Policy</a> (PP => COD5).
</li><li>
<a href="http://svn.cacert.org/CAcert/principles.html">
Principles of the Community</a>.
</li></ol>
<p>
Where documents are referred to as <i>=> COD x</i>,
they are controlled documents
under the control of Policy on Policies (COD1).
</p>
<p>
This agreement and controlled documents above are primary,
and may not be replaced or waived except
by formal policy channels and by Arbitration.
</p>
<h4> <a name="4.3"> 4.3 </a> Informative References </h4>
<p>
The governing documents are in English.
Documents may be translated for convenience.
Because we cannot control the legal effect of translations,
the English documents are the ruling ones.
</p>
<p>
You are encouraged to be familiar with the
Assurer Handbook,
which provides a more readable introduction for much of
the information needed.
The Handbook is not however an agreement, and is overruled
by this agreement and others listed above.
</p>
<h4> <a name="4.4"> 4.4 </a> Not Covered in this Agreement </h4>
<p>
<b>Intellectual Property.</b>
This Licence does not transfer any intellectual
property rights ("IPR") to you. CAcert asserts and
maintains its IPR over its roots, issued certificates,
brands, logos and other assets.
Note that the certificates issued to you
are CAcert's intellectual property
and you do not have rights other than those stated.
</p>
</body>
</html>

136
Agreements/NRPDisclaimerAndLicence.html Normal file
View file

@ -0,0 +1,136 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title> CAcert - Non-Related Persons - Disclaimer and Licence </title></head>
<body>
<table width="100%">
<tr>
<td> NRP-DaL </td>
<td></td>
<td width="20%"> (Advisory) </td>
</tr>
<tr>
<td> POLICY&nbsp;<a href="http://wiki.cacert.org/wiki/TopMinutes-20070917">m20070918.1</a> </td>
<td></td>
<td>
$Date$
<!--
to get this to work, we have to do this:
svn propset svn:keywords "Date" PolicyOnPolicy.html
except it does not work through the website.
-->
</td>
</tr>
<tr>
<td> <a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a> </td>
<td></td>
<td> <!-- contributors --> </td>
</tr>
</table>
<br><br> <!-- components for posting is below -->
<table border="1" bgcolor="0xEEEEEE"><tr><td>
<h1 align="center"> Non-Related Persons </h1>
<h2 align="center"> (Disclaimer and Licence) </h2>
<h2> Definitions </h2>
<p>
This is a Disclaimer and Licence from
<u> CAcert Inc </u>,
the "issuer",
to you, the "user,"
being a general user of the Internet.
</p>
<h2> Disclaimer </h2>
<p>
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.
</p>
<p>
Therefore, to the fullest extent possible in law,
<b>ISSUER DISCLAIMS ALL LIABILITY TO YOU</b>
on behalf of itself and its related parties.
</p>
<h2> Licence </h2>
<p>
This licence offers you a non-exclusive, non-transferable
'PERMISSION TO USE' certificates issued by issuer.
</p>
<ul><li>
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.
</li><li>
You may NOT RELY on any statements or claims
made by the certificates or implied in any way.
</li><li>
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.
</li><li>
You may NOT distribute certificates or root keys
under this licence, nor make representation
about them.
</li></ul>
</td></tr></table>
<h2> Alternatives </h2>
<p>
If you find the terms of the above
Non-Related Persons
Disclaimer and Licence
difficult or inadequate for your use, you may wish to
</p>
<ul><li>
As an individual,
<a href="https://www.cacert.org/index.php?id=1">
register with issuer</a>
and enter into the user agreement.
This is free.
</li><li>
As a Third Party Distributor,
enter into a separate third party agreement
with issuer.
</li><li>
Delete issuer's roots from your software.
Your software documentation should give
directions and assistance for this.
</li></ul>
<p>
These alternatives are outside the above
Non-Related Persons Disclaimer and Licence
and do not incorporate.
</p>
</body>
</html>

639
DisputeResolutionPolicy.html Normal file
View file

@ -0,0 +1,639 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Dispute Resulution Policy</title>
</head>
<body>
<table width="100%">
<tr>
<td> DRP </td>
<td> </td>
<td width="20%"> Teus Hagen </td>
</tr>
<tr>
<td> POLICY&nbsp;<a href="http://wiki.cacert.org/wiki/TopMinutes-20070917">m20070919.3</a> </td>
<td> </td>
<td>
$Date$
<!--
to get this to work, we have to do this:
svn propset svn:keywords "Date" PolicyOnPolicy.html
except it does not work through the website.
-->
</td>
</tr>
<tr>
<td> COD7 </td>
<td> </td>
<td> <!-- contributors --> </td>
</tr>
<tr> <!-- title only -->
<td> </td>
<td > <b>Dispute&nbsp;Resolution&nbsp;Policy</b> </td>
<td> </td>
</tr>
</table>
<h2> <a name="0"> 0. </a> Introduction</h2>
<p>
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.
</p>
<h3> <a name="0.1"> 0.1 </a> Nature of Disputes </h3>
<p>
Disputes include:
</p>
<ul><li>
Requests for non-routine support actions.
CAcert support team has no authority to
act outside the normal support facilities made
available to Users;
</li><li>
Classical disputes where a User or another
assert claims and demand remedies;
</li><li>
Requests by external organisations, including
legal processes from foreign courts;
</li><li>
Events initiated for training purposes.
</li></ul>
<h2> <a name="1"> 1. </a> Filing</h2>
<h3> <a name="1.1"> 1.1 </a> Filing Party</h3>
<p>
Anyone may file a dispute.
In filing, they become <i>Claimants</i>.
</p>
<h3> <a name="1.2">1.2 </a> Channel for Filing</h3>
<p>
Disputes are filed by being sent to the normal
support channel of CAcert,
and a fee may be payable.
</p>
<p>
Such fees as are imposed on filing will be specified
on the dispute resolution page of the website.
</p>
<h3> <a name="1.3">1.3 </a> Case Manager</h3>
<p>
The Case Manager (CM) takes control of the filing.
</p>
<ol><li>
CM makes an initial determination as
to whether this filing is a dispute
for resolution, or it is a request
for routine support.
</li><li>
CM logs the case and establishes such
documentation and communications support as is customary.
</li><li>
If any party acts immediately on the filing
(such as an urgent security action),
the CM names these parties to the case.
</li><li>
CM selects the Arbitrator.
</li></ol>
<p>
The personnel within the CAcert support team
are Case Managers, by default, or as directed
by the Dispute Resolution Officer.
</p>
<h3> <a name="1.4">1.4 </a> Contents</h3>
<p>
The filing must specify:
</p>
<ul><li>
The filing party(s), being the <i>Claimant(s)</i>.
</li><li>
The party(s) to whom the complaint is addressed to,
being the <i>Respondent(s)</i>.
This will be CAcert in the
case of requests for support actions.
It may be a User (possibly unidentified) in the
case where one User has given rise to a complaint against another.
</li><li>
The <i>Complaint</i>.
For example, a trademark has been infringed,
privacy has been breached,
or a user has defrauded using a certificate.
</li><li>
The action(s) requested by the filing party
(technically, called the <i>relief</i>).
For example, to delete an account,
to revoke a certificate, or to stop a
trademark infringement.
</li></ul>
<p>
If the filing is inadequate for lack of information
or for format, the Case Manager
may refile with the additional information,
attaching the original messages.
</p>
<h3> <a name="1.5">1.5 </a> The Arbitrator</h3>
<p>
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."
</p>
<p>
Arbitrators are experienced Assurers of CAcert.
They should be independent and impartial, including
of CAcert itself where it becomes a party.
</p>
<h2> <a name="2"> 2. </a> The Arbitration</h2>
<h3> <a name="2.1">2.1 </a> Authority</h3>
<p>
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.
</p>
<h3> <a name="2.2">2.2 </a> Preliminaries</h3>
<p>
The Arbitrator conducts some preliminaries:
</p>
<ul><li>
The Arbitrator reviews the available documentation
and affirms the rules of dispute resolution.
Jurisdiction is established, see below.
</li><li>
The Arbitrator affirms the governing law (NSW, Australia).
The Arbitrator may select local law and local
procedures where Claimants and all Respondents
agree, are under such jurisdiction, and it is deemed
more appropriate.
However, this is strictly limited to those parties,
and especially, CAcert and other parties
remains under the governing law.
</li><li>
The Arbitrator reviews the Respondents and Claimants
with a view to dismissal or joining of additional parties.
E.g., support personel may be joined if emergency action was
taken.
</li><li>
Any parties that are not Users and are not bound
by the CPS are given the opportunity to enter into
CAcert and be bound by the CPS and these rules of arbitration.
If these Non-Related Persons (NRPs) remain outside,
their rights and remedies under CAcert's policies
and forum are strictly limited to that specified in the
Non-Related Persons -- Disclaimer and Licence.
NRPs may proceed with Arbitration subject to preliminary orders
of the Arbitrator.
</li><li>
Participating Users may not resign until the completion of the case.
</li><li>
The Arbitrator confirms that all parties accept
the forum of dispute resolution.
This is especially important where a User might be
in a country with no Arbitration Act in law, or
where there is reason to believe that a party might
go to an external court.
</li><li>
The Arbitrator confirms that parties are representing
themselves. Parties are entitled to be legally
represented, but are not encouraged to do so,
bearing in mind the volunteer nature of the
organisation and the size of the dispute.
If they do so they must declare such, including any
changes.
</li><li>
The Arbitrator may appoint experienced Assurers
to assist and represent parties, especially for NRPs.
The Case Manager must not to provide such assistance.
</li><li>
The Arbitrator is bound to maintain the balance
of legal fairness.
</li><li>
The Arbitrator may make any preliminary orders,
including protection orders and orders referring
to emergency actions already taken.
</li><li>
The Arbitrator may request any written pleadings,
counterclaim, and/or statements of defence.
</li></ul>
<h3> <a name="2.3">2.3 </a> Jurisdiction </h3>
<p>
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:
</p>
<ul><li>
That all Parties agree to binding Arbitration
in CAcert's forum of dispute resolution;
</li><li>
for all disputes relating to activities within
CAcert, issued certificates, roles and actions, etc;
</li><li>
as defined by these rules, including the selection
of a single Arbitrator;
</li><li>
under the Law of NSW, Australia; and
</li><li>
the Parties keep email accounts in good working order.
</li></ul>
<p>
An external court may have ("assert") jurisdiction to decide on
issues such as trademark, privacy, contract and fraud,
and may do so with legal remedies.
These are areas where jurisdiction may need
to be considered carefully:
</p>
<ul><li>
Where NRPs, being not members of CAcert and not
bound by agreement, are parties to the dispute.
E.g., intellectual property disputes may involve
NRPs and their trademarks;
</li><li>
criminal actions or actions likely to result in criminal
proceedings,
e.g., fraud;
</li><li>
Contracts between Users that were formed without
a clause to seek arbitration in the forum;
</li><li>
Areas where laws fall outside the Arbitration Act,
such as privacy;
</li><li>
Legal process (subpoenas, etc) delivered by
an external court of "competent jurisdiction."
</li></ul>
<p>
The Arbitrator must consider jurisdiction and rule on a
case by case basis whether jurisdiction is asserted,
either wholly or partially, or declines to hear the case.
In the event of asserting
jurisdiction, and a NRP later decides to pursue rights in
another forum, the Arbitrator should seek the agreement
of the NRP to file the ruling as part of the new case.
</p>
<h3> <a name="2.4">2.4 </a> Basis in Law </h3>
<p>
Each country generally has an Arbitration Act
that elevates Arbitration as a strong dispute
resolution forum.
The Act generally defers to Arbitration
if the parties have so agreed.
That is, as Users of CAcert, you agree to resolve
all disputes before CAcert's forum.
This is sometimes called <i>private law</i>
or <i>alternative dispute resolution</i>.
</p>
<p>
As a matter of public policy, courts will generally
refer any case back to Arbitration.
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.
</p>
<h3> <a name="2.5">2.5 </a> External Courts </h3>
<p>
When an external court claims and asserts its jurisdiction,
and issues a court order, subpoena or other service to CAcert,
the CM files the order as a dispute, with the external court
as <i>Claimant</i>.
The CM and other support staff are granted no authority to
act on the basis of any court order, and ordinarily
must await the order of the Arbitrator
(which might simply be a repeat of the external court order).
</p>
<p>
The Arbitrator establishes the bona fides of the
court, and rules.
The Arbitrator may rule to reject the order,
for jurisdiction or other reasons.
By way of example, if all Parties are 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.
</p>
<h3> <a name="2.6">2.6 </a> Process</h3>
<p>
The Arbitrator follows the procedure:
</p>
<ol><li>
Establish the facts.
The Arbitrator collects the evidence from the parties.
The Arbitrator may order CAcert or Users under
jurisdiction to provide support or information.
The Arbitrator may use email, phone or face-to-face
meetings as proceedings.
</li><li>
Apply the Rules of Dispute Resolution,
the policies of CAcert and the governing law.
The Arbitrator may request that the parties
submit their views.
The Arbitrator also works to the mission of CAcert,
the benefit of all Users, and the community as a whole.
The Arbitrator may any assistance.
</li><li>
Makes a considered Ruling.
</li></ol>
<h2> <a name="3"> 3. </a> The Ruling</h2>
<h3> <a name="3.1">3.1 </a> The Contents </h3>
<p>
The Arbitrator records:
</p>
<ol><li>
The Identification of the Parties,
</li><li>
The Facts,
</li><li>
The logic of the rules and law,
</li><li>
The directions and actions to be taken by each party
(the ruling).
</li><li>
The date and place that the ruling is rendered.
</li></ol>
<h3> <a name="3.2">3.2 </a> Process </h3>
<p>
Once the Ruling is delivered, the case is closed.
The Case Manager is responsible for recording the
Ruling, publishing it, and advising users.
</p>
<p>
Proceedings are ordinarily private.
The Ruling is ordinarily published,
within the bounds of the Privacy Policy.
The Ruling is written in English.
</p>
<p>
Only under exceptional circumstances can the
Arbitrator declare the Ruling private <i>under seal</i>.
Such a declaration must be reviewed in its entirety
by the Board,
and the Board must confirm or deny that declaration.
If it confirms, the existance of any Rulings under seal
must be published to the Users in a timely manner
(within days).
</p>
<h3> <a name="3.3">3.3 </a> Binding and Final </h3>
<p>
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.
</p>
<p>
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.
</p>
<h3> <a name="3.4">3.4 </a> Re-opening the Case or Appeal </h3>
<p>
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.
</p>
<p>
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.
</p>
<h3> <a name="3.5">3.5 </a> Liability </h3>
<p>
All liability of the Arbitrator for any act in
connection with deciding a dispute is excluded
by all parties, provided such act does not constitute
an intentional breach of duty.
All liability of the Arbitrators, CAcert, its officers and its
employees (including Case Manager)
for any other act or omission in connection with
arbitration proceedings is excluded, provided such acts do not
constitute an intentional or grossly negligent breach of duty.
</p>
<p>
The above provisions may only be overridden by
appeal process (by means of a new dispute causing
referral to the Board).
</p>
<h3> <a name="3.6">3.6 </a> Remedies </h3>
<p>
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.
</p>
<ul><li>
"community service" typically including
<ul><li>
attend and assure people at trade shows / open source gatherings,
</li><li>
writing documentation
</li><li>
serve in role - support, dispute arbitration
</li></ul>
or others as decided.
</li><li>
Fined by loss of assurance points, which may result
in losing Assurer or Assured status.
</li><li>
Retraining in role.
</li><li>
Revoking of any certificates.
</li><li>
Monetary fine up to the liability cap established for
each party as described in the Registered User Agreement.
</li><li>
Exclusion from community.
</li><li>
Reporting to applicable authorities.
</li><li>
Changes to policies and procedures.
</li></ul>
<p>
The Arbitrator is not limited within the general domain
of CAcert, and may instruct novel remedies as seen fit.
Novel remedies outside the domain may be routinely
confirmed by the Board by way of appeals process,
in order to establish precedent.
</p>
<h2> <a name="4"> 4. </a> Appendix</h2>
<h3> <a name="4.1">4.1 </a> The Advantages of this Forum </h3>
<p>
The advantage of this process for Users is:
</p>
<ul><li>
CAcert and Users operate across many jurisdictions.
Arbitration allows us to select a single set of
rules across all jurisdictions.
</li><li>
Arbitration allows CAcert to appropriately separate
out the routine support actions from difficult dispute
actions. Support personnel have no authority to
act, the appropriately selected Arbitrator has all
authority to act.
Good governance is thus maintained.
</li><li>
This forum allows CAcert Users to look after themselves
in a community, without exposing each other to potentially
disastrous results in strange courts from foreign lands.
</li><li>
By volunteering to resolve things "in-house" the costs
are reduced.
</li><li>
Even simple support issues such as password changing
can be improved by treating as a dispute. A clear
chain of request, analysis, ruling and action can be established.
</li><li>
CAcert Assurers can develop the understanding and the rules
for sorting out own problems far better than courts or
other external agencies.
</li></ul>
<h3> <a name="4.2">4.2 </a> The Disadvantages of this Forum </h3>
<p>
Some disadvantages exist.
</p>
<ul><li>
Users may have their rights trampled over.
In such a case, the community should strive to
re-open the case and refer it to the board.
</li><li>
Users may feel overwhelmed by the formality
of the process.
It is kept formal so as to establish good and proper
authority to act; otherwise, support and other
people in power may act without thought and with
damaging consequences.
</li><li>
A country may not have an Arbitration Act.
In that case, the parties should enter into
spirit of the forum.
If they choose to break that spirit,
they should also depart the community.
</li></ul>
<h3> <a name="4.3">4.3 </a> Process and Flow </h3>
<p>
To the extent reasonable, the Arbitrator conducts
the arbitration as with any legal proceedings.
This means that the process and style should follow
legal tradition.
</p>
<p>
However, the Arbitrator is unlikely to be trained in
law. Hence, common sense must be applied, and the
Arbitrator has wide latitude to rule on any particular
motion, pleading, submission. The Arbitrator's ruling
is final within the arbitration.
</p>
<p>
Note also that many elements of legal proceedings are
deliberately left out of the rules.
</p>
</body>
</html>

379
OrganisationAssurancePolicy/OrganisationAssurancePolicy.html Normal file
View file

@ -0,0 +1,379 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title>Organisation Assurance Policy</title></head>
<body>
<table width="100%">
<tr>
<td> OAP </td>
<td> </td>
<td width="20%"> Jens </td>
</tr>
<tr>
<td> POLICY&nbsp;<a href="http://wiki.cacert.org/wiki/TopMinutes-20070917">m20070918.x</a> </td>
<td> </td>
<td>
$Date$
<!--
to get this to work, we have to do this:
svn propset svn:keywords "Date" file.html
except it does not work through the website.
-->
</td>
</tr>
<tr>
<td> COD11 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td > <b>Organisation&nbsp;Assurance&nbsp;Policy</b> </td>
<td> </td>
</tr>
</table>
<h2> <a name="0"> 0. </a> Preliminaries </h2>
<p>
This policy describes how Organisation Assurers ("OAs")
conduct Assurances on Organisations.
It fits within the overall web-of-trust
or Assurance process of Cacert.
</p>
<p>
This policy is not a Controlled document, for purposes of
Configuration Control Specification ("CCS").
</p>
<h2> <a name="1"> 1. </a> Purpose </h2>
<p>
Organisations with assured status can issue certificates
directly with their own domains within.
</p>
<p>
The purpose and statement of the certificate remains
the same as with ordinary users (natural persons)
and as described in the CPS.
</p>
<ul><li>
The organisation named within is identified.
</li><li>
The organisation has been verified according
to this policy.
</li><li>
The organisation is within the jurisdiction
and can be taken to Arbitration.
</li></ul>
<h2> <a name="2"> 2. </a> Roles and Structure </h2>
<h3> <a name="2.1"> 2.1 </a> Assurance Officer </h3>
<p>
The Assurance Officer ("AO")
manages this policy and reports to the board.
</p>
<p>
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.
</p>
<h3> <a name="2.2"> 2.2 </a> Organisation Assurers </h3>
<p>
</p>
<ol type="a"> <li>
An OA must be an experienced Assurer
<ol type="i">
<li>Have 150 assurance points.</li>
<li>Be fully trained and tested on all general Assurance processes.</li>
</ol>
</li><li>
Must be trained as Organisation Assurer.
<ol type="i">
<li> Global knowledge: This policy. </li>
<li> Global knowledge: A OA manual covers how to do the process.</li>
<li> Local knowledge: legal forms of organisations within jurisdiction.</li>
<li> Basic governance. </li>
<li> Training may be done a variety of ways,
such as on-the-job, etc. </li>
</ol>
</li><li>
Must be tested.
<ol type="i">
<li> Global test: Covers this policy and the process. </li>
<li> Local knowledge: Subsidiary Policy to specify.</li>
<li> Tests to be created, approved, run, verified
by CAcert only (not outsourced). </li>
<li> Tests are conducted manually, not online/automatic. </li>
<li> Documentation to be retained. </li>
<li> Tests may include on-the-job components. </li>
</ol>
</li><li>
Must be approved.
<ol type="i">
<li> Two supervising OAs must sign-off on new OA,
as trained, tested and passed.
</li>
<li> AO must sign-off on a new OA,
as supervised, trained and tested.
</li>
</ol>
</ol>
<h3> <a name="2.3"> 2.3 </a> Organisation Administrator </h3>
<p>
The Administrator within each Organisation ("O-Admin")
is the one who handles the assurance requests
and the issuing of certificates.
</p>
<ol type="a"> <li>
O-Admin must be Assurer
<ol type="i">
<li>Have 100 assurance points.</li>
<li>Fully trained and tested as Assurer.</li>
</ol>
</li><li>
Organisation is required to appoint O-Admin,
and appoint ones as required.
<ol type="i">
<li> On COAP Request Form.</li>
</ol>
</li><li>
O-Admin must work with an assigned OA.
<ol type="i">
<li> Have contact details.</li>
</ol>
</ol>
<h2> <a name="3"> 3. </a> Policies </h2>
<h3> <a name="3.1"> 3.1 </a> Policy </h3>
<p>
There is one policy being this present document,
and several subsidiary policies.
</p>
<ol type="a">
<li> This policy authorises the creation of subsidiary policies. </li>
<li> This policy is international. </li>
<li> Subsidiary policies are implementations of the policy. </li>
<li> Organisations are assured under an appropriate subsidiary policy. </li>
</ol>
<h3> <a name="3.2"> 3.2 </a> Subsidiary Policies </h3>
<p>
The nature of the Subsidiary Policies ("SubPols"):
</p>
<ol type="a"><li>
SubPols are purposed to check the organisation
under the rules of the jurisdiction that creates the
organisation. This does not evidence an intention
by CAcert to
enter into the local jurisdiction, nor an intention
to impose the rules of that jurisdiction over any other
organisation.
CAcert assurances are conducted under the jurisdiction
of CAcert.
</li><li>
For OAs,
SubPol specifies the <i>tests of local knowledge</i>
including the local organisational forms.
</li><li>
For assurances,
SubPol specifies the <i>local documentation forms</i>
which are acceptable under this SubPol to meet the
standard.
</li><li>
SubPols are subjected to the normal
policy approval process.
</li></ol>
<h3> <a name=""> </a> 3.3 Freedom to Assemble </h3>
<p>
Subsidiary Policies are open, accessible and free to enter.
</p>
<ol type="a"><li>
SubPols compete but are compatible.
</li><li>
No SubPol is a franchise.
</li><li>
Many will be on State or National lines,
reflecting the legal
tradition of organisations created
("incorporated") by states.
</li><li>
However, there is no need for strict national lines;
it is possible to have 2 SubPols in one country, or one
covering several countries with the same language
(e.g., Austria with Germany, England with Wales but not Scotland).
</li><li>
There could also be SubPols for special
organisations, one person organisations,
UN agencies, churches, etc.
</li><li>
Where it is appropriate to use the SubPol
in another situation (another country?), it
can be so approved.
(e.g., Austrian SubPol might be approved for Germany.)
The SubPol must record this approval.
</li></ol>
<h2> <a name="4"> 4. </a> Process </h2>
<h3> <a name="4.1"> 4.1 </a> Standard of Organisation Assurance </h3>
<p>
The essential standard of Organisation Assurance is:
</p>
<ol type="a"><li>
the organisation exists
</li><li>
the organisation name is correct and consistent:
<ol type="i">
<li>in official documents specified in SubPol.</li>
<li>on COAP form.</li>
<li>in CAcert database.</li>
<li>form or type of legal entity is consistent</li>
</ol>
</li><li>
signing rights:
requestor can sign on behalf of the organisation.
</li><li>
the organisation has agreed to the terms of the
Registered User Agreement,
and is therefore subject to Arbitration.
</li></ol>
<p>
Acceptable documents to meet above standard
are stated in the SubPol.
</p>
<h3> <a name="4.2"> 4.2 </a> COAP </h3>
<p>
The COAP form documents the checks and the resultant
assurance results to meet the standard.
Additional information to be provided on form:
</p>
<ol type="a"><li>
CAcert account of O-Admin (email address?)
</li><li>
location:
<ol type="i">
<li>country (MUST).</li>
<li>city (MUST).</li>
<li>additional contact information (as required by SubPol).</li>
</ol>
</li><li>
administrator account names (1 or more)
</li><li>
domain name(s)
</li><li>
Agreement with registered user agreement.
Statement and initials box for organsation
and also for OA.
</li><li>
Date of completion of Assurance.
Records should be maintained for 7 years from
this date.
</li></ol>
<p>
The COAP should be in English. Where translations
are provided, they should be matched to the English,
and indication provided that the English is the
ruling language (due to Arbitration requirements).
</p>
<h3> <a name="4.3"> 4.3 </a> Jurisdiction </h3>
<p>
Organisation Assurances are carried out by
CAcert Inc under its Arbitration jurisdiction.
Actions carried out by OAs are under this regime.
</p>
<ol type="a"><li>
The organisation has agreed to the terms of the
Registered User Agreement,
</li><li>
The organisation, the Organisation Assurers, CAcert and
other related parties are bound into CAcert's jurisdiction
and dispute resolution.
</li><li>
The OA is responsible for ensuring that the
organisation reads, understands, intends and
agrees to the registered user agreement.
This OA responsibility should be recorded on COAP
(statement and initials box).
</li></ol>
<h2> <a name="5"> 5. </a> Exceptions </h2>
<ol type="a"><li>
<b> Conflicts of Interest.</b>
An OA must not assure an organisation in which
there is a close or direct relationship by, e.g.,
employment, family, financial interests.
Other conflicts of interest must be disclosed.
</li><li>
<b> Trusted Third Parties.</b>
TTPs are not generally approved to be part of
organisation assurance,
but may be approved by subsidiary policies according
to local needs.
</li><li>
<b>Exceptional Organisations.</b>
(e.g., Vatican, International Space Station, United Nations)
can be dealt with as a single-organisation
SubPol.
The OA creates the checks, documents them,
and subjects them to to normal policy approval.
</li><li>
<b>DBA.</b>
Alternative names for organisations
(DBA, "doing business as")
can be added as long as they are proven independently.
E.g., registration as DBA or holding of registered trade mark.
This means that the anglo law tradition of unregistered DBAs
is not accepted without further proof.
</li></ol>

222
PolicyOnFoundations.html Normal file
View file

@ -0,0 +1,222 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title> W I P - Foundations Policy - W I P </title></head>
<body>
<h2> -1. To Fix</h2>
<ul><li> <i>
Check out Isoc for some ideas:
<a href="http://www.isoc.org/isoc/chapters/guidelines/bylaws.shtml">
Isoc Chapter Bylaws</a> ..
<a href="http://www.isoc.org/isoc/chapters/application/primer.shtml">
Chapter Primer</a> ..
<a href="http://www.isoc.org/isoc/chapters/policy/">
Chapter Policy</a>
</i> </li></ul>
<hr>
<center> <big><b> W I P . . W I P . . W I P . . W I P . . W I P </b></big></center>
<h1>Foundations Policy</h1>
<h2> 0. Preamble</h2>
<p>
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.
</p>
<p>
Let's start a policy on Foundations. Here is a WIP policy,
to get people thinking:
</p>
<h3> Terms</h3>
<p>
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.
</p>
<h2> 1. Principles </h2>
<p>
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.
</p>
<ol>
<li> Foundations may accept and manage local donations, etc. </li>
<li> Foundations may organise events. </li>
<li> Foundations may provide budget for organised activities. </li>
</ol>
<h3> Limits on the Foundation.</h3>
<ol>
<li> The Foundation should be non-profit, non-commercial, non-competitive.
This needs to be measured against what is possible in local laws.</li>
<li> The Foundation must use a Mission and/or Purpose that is
written into their Charter that limits their purpose and responsibility. </li>
<li> The Membership Register must be open to scrutiny
to the community. </li>
<li> The Financial Report must be open to scrutiny
to the community. </li>
</ol>
<h3> Mission of the Foundation.</h3>
<p>
The Mission / Purpose should be controlled:
</p>
<ol>
<li> Should be announced and comments accepted. </li>
<li> should support the CAcert community. </li>
<li> can only refer to CAcert if CAcert Inc agrees. </li>
<li> should be approved by policy group. </li>
<li> should not be changeable.
If changeable, a community process must be adopted.</li>
</ol>
<p><i>
Comments:
</i></p>
<p><i>
... 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 ...
</i><p>
<p><i>
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.
</i></p>
<p><i>
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.
</i></p>
<p><i>
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.
</i></p>
<p><i>
<a href="http://www.isoc.org/isoc/chapters/policy/">
ISOC</a> 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.
</i></p>
<h2> Legal Independence </h2>
<p>
The Foundation should be legally independent from others, including CAcert Inc.
</p>
<ol>
<li> The Foundation must not use "CAcert" in the name. </li>
<li> The Foundation and its members must not represent themselves
as being CAcert or CAcert Inc or even being "part of CAcert Inc".</li>
<li>
The Foundation may represent itself as "part of the CAcert community." </li>
</ol>
<p> <i>
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.
</i></p>
<p><i>
Right know we talk about foundations especially created for the support of CAcert. Or is it for free certs? Which is it?
</i></p>
<p><i>
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.
</i></p>
<p><i>
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!).
</i></p>
<p><i>
<a href="http://www.isoc.org/isoc/chapters/policy/">
ISOC</a> 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."
</i> </p>
<h2> Liason </h2>
<p>
The Foundation must maintain lines of communication
open with CAcert and the community.
</p>
<ol>
<li> Although independent, the community has the right to provide advice. </li>
<li> A liason officer must be named to the CAcert community. </li>
</ol>
<h2> Finances and Books </h2>
<p>
The Foundation must govern its own books.
</p>
<ol>
<li> As we are a security community we expect money matters
to be treated as seriously as we treat our systems. </li>
<li> The money should be spent locally. </li>
<li> Transfers between Foundations, regions and CAcert Inc
must be carefully controlled and documented.
The process must be open, transparent and auditable. </li>
<li> Public reports on finances must be open. </li>
<li> Foundation should accept a community financial auditor. </li>
</ol>
<p><i>
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.
</i></p>
<h3> Suggestions </h3>
<p>
<i>
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?
</i>
</p>
<p>
<i>
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.
</i>
</p>
<center> <big><b> W I P . . W I P . . W I P . . W I P . . W I P </b></big></center>
</body>
</html>

3
PrivacyPolicy.php Normal file
View file

@ -0,0 +1,3 @@
<?php
include_once('PrivacyPolicy.txt');
?>

85
PrivacyPolicy.txt Normal file
View file

@ -0,0 +1,85 @@
<h3><?=_("Privacy Policy")?></h3>
<p>
<?=_("This policy discloses what information we gather about you when you visit any of our Web site, and when you issue or use our certificates. It describes how we use that information and how you can control it.")?>
</p>
<h4>1. <?=_("Website information")?></h4>
<p>
<?=_("We collect two kinds of information about website users: 1) data that users volunteer by signing up to our website or when you send us an email via our contact form; and 2) aggregated tracking data we collect when users interact with our site.")?>
</p>
<h4>2. <?=_("Personal information")?></h4>
<p>
<?=_("When you post to the contact form, you must provide your name and email address. When you sign up to the website, you must provide your name, email address, date of birth and some lost pass phrase question and answers.")?>
</p>
<p>
<?=_("We only share your information with any other organisation when so instructed by a CAcert arbitrator.")?>
</p>
<h4>3. <?=_("Aggregated tracking information")?></h4>
<p>
<?=_("We analyse visitors' use of our sites by tracking information such as page views, traffic flow, search terms, and click through. We use this information to improve our sites. We also share this anonymous traffic and demographic information in aggregate form with advertisers and other business partners. We do not share any information with advertisers that can identify an individual user.")?>
</p>
<h4>4. <?=_("Cookies")?></h4>
<p>
<?=_("Some of our advertisers use a third-party ad server to display ads. These ads may contain cookies. The ad server receives these cookies, and we don't have access to them.")?>
</p>
<p>
<?=_("We don't use cookies to store personal information, we do use sessions, and if cookies are enabled, the session will be stored in a cookie, and we do not look for cookies, apart from the session id. However if cookies are disabled then no information will be stored on or looked for on your computer.")?>
</p>
<h4>5. <?=_("Notification of changes")?></h4>
<p>
<?=_("If we change our Privacy Policy, we will post those changes on www.CAcert.org. If we decide to use personally identifiable information in a manner different from that stated at the time it was collected, we will notify users via email. Users will be able to opt out of any new use of their personal information.")?>
</p>
<h4>6. <?=_("How to update, correct, or delete your information")?></h4>
<p>
<?=_("You are able to update, add and remove your information at any time via our web interface, log into the 'My Account' and then click on the 'My Details' section, and then click the relevant link")?>
</p>
<h4>7. <?=_("Privacy of certificates")?></h4>
<p>
<?=_("CAcert does not automatically publish the certificates through a directory
service or the website to other people than the user who requested the
certificate. In the future, the user might be able to opt-in for publication
of the certificates through a directory server by CAcert.")?>
</p>
<h4>8. <?=_("Privacy of user data")?></h4>
<p>
<?=_("CAcert Assurers can see the name, birthday and the number of points by looking up the correct email address.
No other person related data is published by CAcert.
")?>
</p>
<h4>9. <?=_("Exceptions")?></h4>
<p>
<?=_("A CAcert arbitrator may override this policy in a dispute.")?>
<?=_("To obtain access to confidential data, a dispute has to be filed.")?>
</p>
<h4>10. <?=_("Legal mandates")?></h4>
<p>
<?=_("CAcert adopts the Australian privacy regulations.")?>
<?=_("Please see <a href=\"http://www.privacy.gov.au/\">http://www.privacy.gov.au/</a> for further details.")?>
<?=_("Governmental warrants and civil supoenas will be processed through the dispute resolution system, which
ensures that valid authority is given to whoever complies with the supoena or the warrant.")?>
</p>
<p><?=_("If you need to contact us in writing, address your mail to:")?></p>
<p>
CAcert Inc.<br>
P.O. Box 81<br>
Banksia NSW 2216<br>
Australia
</p>