2008-01-28 00:01:03 +00:00
|
|
|
<!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>
|
|
|
|
|
|
|
|
|
|
|
2008-03-30 12:19:37 +00:00
|
|
|
<center> <b> w o r k -- i n -- p r o g r e s s</b> </center>
|
2008-01-28 00:01:03 +00:00
|
|
|
|
|
|
|
|
<p> <i>
|
2008-12-21 11:58:15 +00:00
|
|
|
This is wip-V0.03.
|
2008-01-28 00:01:03 +00:00
|
|
|
</i></p>
|
|
|
|
|
|
|
|
|
|
<ul><li><i>
|
2008-12-21 11:58:15 +00:00
|
|
|
What to do about multi-tier distributors:
|
2008-01-28 00:01:03 +00:00
|
|
|
th: firefox/thunderbird/evolution/etc distribute things
|
2008-12-21 11:58:15 +00:00
|
|
|
but also to distributors eg Fedora, Ubuntu, etc. Who on their terms
|
2008-01-28 00:01:03 +00:00
|
|
|
redistribute it. This recursion should that be explicit in this
|
|
|
|
|
disclaimer and license?
|
|
|
|
|
is this agreement with primary or end distributor or all of them?
|
|
|
|
|
Mozilla => KDE => Evolution.
|
2008-12-21 11:58:15 +00:00
|
|
|
</i></li><li><i>
|
|
|
|
|
This agreement is with vendors that choose not to be Members.
|
|
|
|
|
Is now made explicit.
|
|
|
|
|
What about vendors who choose to be Members?
|
2008-01-28 00:01:03 +00:00
|
|
|
</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
|
2008-12-21 11:58:15 +00:00
|
|
|
<br><b> OK, done.</b>
|
2008-01-28 00:01:03 +00:00
|
|
|
</i></li><li><i>
|
|
|
|
|
pg: 1.4 Agreement in Spirit
|
|
|
|
|
It doesn't clearly indicate that this is only in respect to cert stuff.
|
2008-12-21 11:58:15 +00:00
|
|
|
<br><b> extra line added "all with respect to...".</b>
|
|
|
|
|
</i></li><li><i>
|
2008-01-28 00:01:03 +00:00
|
|
|
Also, why are we policing the redistributors?
|
2008-12-21 11:58:15 +00:00
|
|
|
<br> <i>the roots and certs are CAcert responsibility.</i>
|
|
|
|
|
</i></li><li><i>
|
|
|
|
|
pg: not clear that this applies or does not apply to Member-vendors.
|
|
|
|
|
<br><b> it is in now, in one of the bullet points.</b>
|
2008-01-28 00:01:03 +00:00
|
|
|
</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>
|
|
|
|
|
|
2008-12-21 11:58:15 +00:00
|
|
|
<h4> <a name="0.2"> 0.2 </a> Background </h4>
|
2008-01-28 00:01:03 +00:00
|
|
|
|
|
|
|
|
<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>
|
2008-12-21 11:58:15 +00:00
|
|
|
for the direct benefit and RELIANCE of its Community of signed-up users
|
|
|
|
|
("Members"),
|
2008-01-28 00:01:03 +00:00
|
|
|
</li><li>
|
2008-12-21 11:58:15 +00:00
|
|
|
where possible, of some indirect benefit and USE to other general users
|
|
|
|
|
("end-users") of the Internet;
|
2008-01-28 00:01:03 +00:00
|
|
|
</li></ul>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
And that,
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul><li>
|
2008-12-21 11:58:15 +00:00
|
|
|
the end-user has a choice in software
|
|
|
|
|
(such as browsers and email clients),
|
2008-01-28 00:01:03 +00:00
|
|
|
</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>
|
2008-12-21 11:58:15 +00:00
|
|
|
the end-user may have strictly limited or opaque
|
|
|
|
|
possibilities to choose or
|
2008-01-28 00:01:03 +00:00
|
|
|
control the usage made of certificates,
|
|
|
|
|
</li><li>
|
|
|
|
|
and that it may not be economic nor reasonable for software
|
2008-12-21 11:58:15 +00:00
|
|
|
to provide for a high degree of choice and control over certificates;
|
2008-01-28 00:01:03 +00:00
|
|
|
</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"),
|
2008-12-21 11:58:15 +00:00
|
|
|
within software,
|
2008-01-28 00:01:03 +00:00
|
|
|
</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,
|
2008-12-21 11:58:15 +00:00
|
|
|
</li><li>
|
|
|
|
|
the Vendor chooses not to be a Member of CAcert,
|
2008-01-28 00:01:03 +00:00
|
|
|
</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>
|
2008-12-21 11:58:15 +00:00
|
|
|
<b><a name="d_reliance" id="d_reliance">RELIANCE</a></b>.
|
|
|
|
|
A Member's act in making a decision,
|
|
|
|
|
including taking a risk,
|
|
|
|
|
in whole or in part based on the certificate.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
<b><a name="d_use" id="d_use">USE</a></b>.
|
|
|
|
|
The event of allowing a certificate to participate
|
|
|
|
|
in a protocol, as decided and facilitated by the user's software.
|
|
|
|
|
In general, no significant input is required of the user.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Other terms used in this agreement are as defined in the
|
2008-01-28 00:01:03 +00:00
|
|
|
<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>
|
2008-12-21 11:58:15 +00:00
|
|
|
Vendor agrees to make its relationship to end-users
|
|
|
|
|
compatible and aligned with the CA's NRP-DaL.
|
|
|
|
|
Specifically, the Vendor must:
|
2008-01-28 00:01:03 +00:00
|
|
|
</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>
|
2008-12-21 11:58:15 +00:00
|
|
|
Where agreement is explicitly sought from the end-user,
|
|
|
|
|
they may be offered and agree to:
|
2008-01-28 00:01:03 +00:00
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul><li>
|
|
|
|
|
CA's NRP-DaL,
|
2008-12-21 11:58:15 +00:00
|
|
|
<s>where the NRP-DaL and EULA are not in contradiction,</s>
|
2008-01-28 00:01:03 +00:00
|
|
|
<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>
|
