[Bug 474549] Review Request: ca-cacert.org - CAcert.org CA root certificates

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=474549

Philipp Dunkel <p.dunkel at cacert.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |p.dunkel at cacert.org

--- Comment #41 from Philipp Dunkel <p.dunkel at cacert.org> 2011-10-31 14:36:46 EDT ---
Hi,
I am a former Board Member of CAcert Inc. and was intimately involved in
drafting many CAcert Policies as well as these licenses. While i am not
authorized to speak on behalf of CAcert Inc. I believe I can help here to
further an understanding between the two communities.

There are three main problems in getting this done.

1. RedHat Legal and this thread view the issue as one of "software" or
"content" licensing. Since a certificate, especially a root certificate is
neither "just content" nor is it "just software", this is bound to fail.

2. RedHat understands limiting liability to a "vendor". However liability has
different vectors in PKI in combination with open communities that make
warranty limitations useless to a community like CAcert.

3. Reliance, warranty, use and the like have distinct meanings in the CA world.
These meanings don't necessarily mesh well with the software world

I will try to explain what the issues/thoughts at CAcert were in the hope that
this will further inter-community understanding and maybe enable this bug to be
successfully resolved.

@1: Certificates are neither content nor software:
Certificates have a single purpose. They are a piece of information that is
useful only in determining the validity of a digital signature. As such they
are, to an extent "software" as they are used to calculate a verification of a
signature supplied. In so far as they are a file containing data that is not
fundamentally executable a certificate is also "content".
However that misses the whole point of certificates and what they really are.
They are really legal statements saying: "If you can take a signature and muck
it around with this bit of digits here, then we certify that the information
contained is valid".
Now while licensing for a piece of content, such as a book, or a piece of
software, is a solved issue, the licensing of
"neither-software-nor-content-but-a-bit-of-both-but-not-really" stuff is not
something that RedHat or the OSS world in general has solved yet. However it is
something that CAcert is expert at.

Which leads me to
@2: Why limitations of liability and the like are insufficient in the CAcert
context
One of the big problems for CAcert that other CAs do not have is in fact that
CAcert is an open community. The members of our community are bound to each
other as well as CAcert Inc. via the CAcert Community Agreement (CCA). This
clearly regulated the claims any one in our community, such as providing for
arbitration, limiting cash liabilities and so forth. In this context, we as a
community are willing to make certain legal guarantees, such as statements
about the reliability of certificate information and the like.
The problem arises because in the CA/PKI world such statements are made not
only between a CA and someone using a certificate to verify some signature, but
rather it is a triangular relationship. A CAcert member makes a statement to a
user and because the CAcert Member is a member CAcert makes an auxiliary
statement to the user. Now if all a CA is worried about is its own behind, then
limiting liability is sufficient. But CAcert is a community, and we do watch
out for more than just CAcert Inc., we also watch out for our members. However
we cannot disclaim the liability of a member to a user for communications that
take place between the member and the user directly.
The only recourse is that we state "If you are not bound by the CCA you may not
rely (as defined) upon anything CAcert says with its certificates" Because this
then eliminates any reliance in statements made via CAcert certificates between
the member and the user.

So is this a "use restriction"? Absolutely. You may not use CAcert certificates
as a base for your decision making. You can use them to establish secured
connections to websites,  you can even use them for e-commerce, provided you
find some other means to verify that the certificate in question is that of
your commerce partner. But you may not take the fact that CAcert has signed a
certificate to MEAN anything, unless you are bound by separate agreement to
CAcert.

@3. The terms we use do not necessarily mesh well
Limiting liability, what does rely mean, what does use mean, what is a draft
policy, and the like are another cause for misunderstanding between the RedHat
and CAcert communities. We have a very well defined set of meanings for these
words and they re described in our policies. However while these meanings are
basically in line with the common use, they do have important nuances. Unless
someone (including a lawyer) is willing to actually read the policies in full,
it becomes very hard to understand all these nuances. This is one of the
reasons we actually train our members in this regard. So most of our members,
especially those more experienced, are very well informed on these matters.

----

Because of the specific environment CAcert operates in and the specific needs
of an open community in this space, our policies and licenses have to diverge
from the standard OSS licenses, since they are tailored to different needs. So
long as this is ignored no progress on this issue will be reachable. For anyone
interested in policy details I would direct you to:
http://svn.cacert.org/CAcert/principles.html for our community principles as
well as http://www.cacert.org/policy/ for our most relevant policies. If
someone from RedHat, especially RedHat Legal, wants to work on getting
somewhere on this, I am always available either by email or by phone (inquire
by mail for number).

Regards, Philipp

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.