Bug 474549 - Review Request: ca-cacert.org - CAcert.org CA root certificates
Review Request: ca-cacert.org - CAcert.org CA root certificates
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
NotReady
:
Depends On: 466626
Blocks: FE-Legal
  Show dependency treegraph
 
Reported: 2008-12-04 07:22 EST by Matthias Saou
Modified: 2016-04-21 17:13 EDT (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-15 05:10:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Saou 2008-12-04 07:22:34 EST
Spec URL: http://thias.fedorapeople.org/review/ca-cacert.org/ca-cacert.org.spec
SRPM URL: http://thias.fedorapeople.org/review/ca-cacert.org/ca-cacert.org-2008-1.src.rpm
Description:
Class 1 and Class 3 PKI keys from CAcert.org, to trust SSL certificates signed
by either key of the CAcert Certificate Authority (CA).

Notes : Now that the main ca-bundle.crt is shipped in its own "ca-certificates" packages, I thought it might be a good idea to be able to easily trust additional well known CAs by installing optional packages. The case of CAcert.org comes up frequently, so answering "just run yum install ca-cacert.org" from now on might be useful.
If some day the CAcert.org certificates get included in the main ca-certificates packages, then it'll just be a matter of retiring this package and adding a few "Obsoletes:" to ca-certificates.
For people who only want to trust the Class 3 certificate, it is possible to only install the "ca-cacert.org-class3" sub-package.
Comment 1 Jason Tibbitts 2008-12-06 19:53:10 EST
This builds fine; rpmlint says:
  ca-cacert.org.noarch: W: no-documentation
  ca-cacert.org-class1.noarch: W: no-documentation
  ca-cacert.org-class1.noarch: W: non-conffile-in-etc 
   /etc/pki/tls/certs/ca-cacert-class1.crt
  ca-cacert.org-class3.noarch: W: no-documentation
  ca-cacert.org-class3.noarch: W: non-conffile-in-etc 
   /etc/pki/tls/certs/ca-cacert-class3.crt
None of which is troubling or all that surprising.

How did you determine that the certs are public domain?  The files themselves have no information, but the upstream web page does have a license and indicates that it governs the use of the same keys included in this package.
Comment 2 Matthias Saou 2008-12-09 06:57:48 EST
(In reply to comment #1)
> How did you determine that the certs are public domain?

By looking at the "ca-certificates" package, in which cacert.org would like to ultimately include their root certificate. But indeed, I was wrong.

I've updated the package to include a NRP-DaL.txt file where I copied the content of the website's "Disclaimer and Licence" page. I don't know if this is suitable for Fedora or not, so I've sent an email to the legal-list to ask about it.
Comment 3 Matthias Saou 2008-12-10 10:11:07 EST
Legal seems to think that the license is not appropriate for inclusion in Fedora. I'll ask on the CAcert support list now in case anyone there can give a clarification.
Comment 4 Matthias Saou 2008-12-19 06:55:07 EST
Just got a semi-official answer from Tomáš Trnka :

--

[... Matthias ...]
> IANAL, which is why I'm asking here, but it seems quite strange to not
> be able to distribute the root certificates if the goal is to some day
> have them distributed with major web browsers...  

Hello!

Yes, this is correct. The current NRPDaL doesn't permit redistribution. This 
is because CAcert is currently undergoing an audit and the NRPDaL is supposed 
to pass this audit too. Non-related parties are really not supposed to 
distribute anything, but Fedora is not a "non-related party" -  third-party 
software vendors are to be covered (and permitted cert redistribution) in the 
3PVDaL, which is currently work-in-progress. As soon as the policy group 
finishes the work and the 3PVDaL passes to DRAFT (active) status, the problem 
mentioned by you will be solved.

--

So I'm unsure what to do about this... leave this review open until things change? Close it then reopen it once it can move forward again?
Comment 5 Jason Tibbitts 2008-12-19 15:57:00 EST
How about this.  You can close it if you like, but if you'd like a reviewer to look at this ticket, just clear the whiteboard.
Comment 6 Tobias Mueller 2009-02-08 16:55:47 EST
Matthias: Do you have any official response from the cacert support mailinglist yet?

I'd love to see the cacert certs shipped with fedora...
Comment 7 Matthias Saou 2009-02-09 07:10:43 EST
(In reply to comment #6)
> Matthias: Do you have any official response from the cacert support mailinglist
> yet?

The last feedback was what I posted here, that it was "work-in-progress" to get the situation fixed. If you have any further news and/or want to get in touch again with cacert about this, please post any info here!
Comment 9 Jason Tibbitts 2009-11-20 10:28:21 EST
Could someone perhaps update the status of this ticket?  There's a ticket before FESCo relating to the CAcert certificates and it would be good to know where things stand today.

Given that as of the last comment there were still license issues, I'm going to block FE-Legal so perhaps we can get a more formal statement of what needs to change before this can be considered acceptable for Fedora.
Comment 10 Matthias Saou 2009-11-24 14:42:23 EST
I've just re-read the latest version of the document linked above, and not only do I still not know if it'll become official at any point, it also still seems like a big mess to me.

From the main website, the current "policy" still seems to be this one :
http://www.cacert.org/policy/NRPDisclaimerAndLicence.php

Which still contains the very confusion and saddening "You may NOT distribute certificates or root keys under this licence, nor make representation about them.".

So my feeling is that we're still at the exact same point as before.
Comment 11 Tom "spot" Callaway 2009-11-28 21:02:50 EST
Agreed. The above draft license gives me a headache. I really hope they find a lawyer at some point.
Comment 12 David Woodhouse 2010-01-08 14:09:51 EST
Technical review... you include these files:

%{pkidir}/tls/certs/%{name}-class1.crt
%{pkidir}/tls/certs/%{class1hash}.0

But that is broken. Nothing will ever use the first, and I'm not even sure if they'll use the second. Besides, the hash function used is a fairly weak one and it's quite likely that there will be collisions. You can't just assume that you can use %{hash}.0 as the file name.

We need a script to rebuild the /etc/pki/tls/cert.pem file from a configurable list of original certs, like Debian has (see bug #466626). And you should be using that in your %post script.

You also need to add it to the system-wide NSS database. We have that working now, and hopefully we'll deploy it in firefox/thunderbird/evolution in time for Fedora 13. Then we can just add the new cert to the central database in /etc/pki/nssdb/ and it'll actually work for everything which uses NSS. Our solution for bug #466626 will need to do that too, presumably.
Comment 13 Matthias Saou 2010-04-08 05:31:18 EDT
Thanks, David, very interesting feedback.

The %{class1hash}.0 file is just the file that openssl is looking for when it tries to check a certificate signed with this CA, which is why I put it there after seeing that there were no means to easily and cleanly manipulate the main cert.pem file.

This package also pre-dates the mass switching to NSS, and I hadn't looked at it since.

Points taken, I'm adding myself to be CC'ed in bug #466626. Thanks!
Comment 14 Sascha Thomas Spreitzer 2010-06-26 08:33:52 EDT
@Matthias; Is it OK with you to close this bug?

I want to open a seperate one and take care on a future CACert root certificates package.
I am a CACert member and I am working on a "Policy on Root Certificates Licensing" to license the Root Certificates under/via the CC-BY-ND.

This will enable the distribution of the certificates. I think it makes sense if I take maintainership of an upcoming Fedora package. :)

freedom regards,
Sascha
Comment 15 Sascha Thomas Spreitzer 2010-06-26 20:16:57 EDT
Please read this carefully and take action!

Your vote is needed within CACert!

http://spreitzer.name/set-the-cacert-root-certificates-free
Comment 16 Tom "spot" Callaway 2010-06-27 20:32:00 EDT
Just noting that CC-BY-ND is not a Free Creative Commons license.

This begs the question of whether the CACert root certificates are content or code. I could probably make a persuasive argument that they are content, thus, they would only need to be freely redistributable without restriction (and CC-BY-ND would meet that requirement), but you'd need to get FESCo to sign off on that.
Comment 17 Matthias Saou 2010-06-28 05:02:35 EDT
I'm fine with anyone else more involved to work on getting the CACert root certificates packaged and included in Fedora. So Sascha, feel free to take over.
Comment 18 Sascha Silbe 2010-06-28 07:15:41 EDT
I'm neither a Fedora developer nor an experienced Fedora user, just someone who needs to support Fedora users running the software I maintain (which includes having them access the bug tracker and other web services using a CAcert certificate from their regular browser). Since I'm already rather busy with other work, I can't do too much to make this happen, sorry. :(
Comment 19 Sascha Thomas Spreitzer 2010-06-28 07:34:22 EDT
@spot; That is an intersting point though. I for myself also consider it as content. Can you please probably raise it to FESCo, I am stuck in between an haystack of work and just one week before vacations...

@Matthias Saou; Thank you very much, this is very kind of you!
Comment 20 Tom "spot" Callaway 2010-06-28 08:48:07 EDT
(In reply to comment #19)
> @spot; That is an intersting point though. I for myself also consider it as
> content. Can you please probably raise it to FESCo, I am stuck in between an
> haystack of work and just one week before vacations...

Lets wait on the relicensing. If it happens, I will be happy to handle the code vs content issue with FESCo.
Comment 21 Sascha Thomas Spreitzer 2010-07-29 07:14:34 EDT
The relicensing is finished, please take a look on the new license and my blog post about it.

CACert RDL: https://svn.cacert.org/CAcert/Policies/Agreements/RootDistributionLicense.html
Blog post:  http://spreitzer.name/cacert-root-certificates-are-free-now

Is it possible to remove the blocker status and assign this ticket to me?
Comment 22 Tom "spot" Callaway 2010-07-29 10:32:28 EDT
My only remaining concern is that the license still seems to be in the draft space. Is there a tarball with the CACert Root Certificates that has the new license in it?

Alternately, some clear documentation from upstream stating that the new license is in effect would also be sufficient (it would need to be included as %doc).

Either way, show me a new package. :)
Comment 23 Matt McCutchen 2010-07-29 10:55:51 EDT
I'm puzzled by this part of the license:

"THIS LICENSE SPECIFICALLY DOES NOT PERMIT YOU TO RELY UPON ANY CERTIFICATES ISSUED BY CACERT INC. IF YOU WISH TO RELY ON CERTIFICATES ISSUED BY CACERT INC, YOU MUST ENTER INTO A SEPARATE AGREEMENT WITH CACERT INC."

Is this a condition of the copyright license, an extra remark, or what?  If it is a condition of the copyright license, I would expect it to make the license non-free, like a field-of-use restriction.  If it is an extra remark, it is false: no law or contract forbids me from taking a risk based on a CACert-signed certificate, although it may be a foolish thing to do since they have no liability to me.
Comment 24 Tom "spot" Callaway 2010-07-29 11:04:05 EDT
I suspect they mean "RELY" in the sense of "Depend upon existence of", or that they make no guarantee that they will make (or continue to make) certificates, and that if you need guaranteed certificates, you need to negotiate that separately.
Comment 25 Sascha Thomas Spreitzer 2010-07-29 11:07:04 EDT
The license was checked by RedHat legal department and commented as GPL
compatible.

CACert policies in status DRAFT are put into force according to CACerts Policy
on Policy "4.2 A DRAFT is a policy-in-effect for the Community and is to be
distributed and treated as such."
http://www.cacert.org/policy/PolicyOnPolicy.php

I will be brewing a tarball with the certs and the RDL + spec and srcrpm.
Comment 26 Matt McCutchen 2010-07-29 11:37:30 EDT
(In reply to comment #24)
> I suspect they mean "RELY" in the sense of "Depend upon existence of", or that
> they make no guarantee that they will make (or continue to make) certificates,
> and that if you need guaranteed certificates, you need to negotiate that
> separately.    

That is not what the definition in section 1 says:

'"RELY" means the human act in taking on a risk or liability on the basis of the claim(s) bound within a certificate issued by CAcert.'

(In reply to comment #25)
> The license was checked by RedHat legal department and commented as GPL
> compatible.

I want to hear what Red Hat Legal thought of the clause I cited.
Comment 27 Tom "spot" Callaway 2010-07-29 11:50:51 EDT
Alright. With that definition of RELY, it means they provide no risk mitigation or indemnity, which isn't abnormal.

Nevertheless, I'll ask Red Hat Legal about it.
Comment 28 Matt McCutchen 2010-07-29 14:21:29 EDT
(In reply to comment #27)
> Alright. With that definition of RELY, it means they provide no risk mitigation
> or indemnity, which isn't abnormal.

Disclaiming liability isn't abnormal.  What is abnormal is telling me I am /not permitted/ to rely, even at my own risk, unless I become a member.  That is either a false statement or a field-of-use restriction that makes the license non-free.
Comment 29 Sascha Thomas Spreitzer 2010-07-30 06:31:06 EDT
The intention of that paragraph is to keep away lawyers from suing CACert(inc.) in the case, an alien party is appearing fraud/exploitation by CACert root certificates.

IMHO it is also stated by the disclaimer, but the CACert community wished to expressively have (no) reliance also included in the license.


I inspected about three other CA's licenses, none of those where having a statement of (no) reliance.
The CACerts community answer on that was; Of course, they have the money if they run into a suecase, CACert has not.

I still have mixed thoughts about RDL, but I am also happy that we finally achieved something that allows the ditribution for alien parties.

Even if the license turns out, not to be "free", it still might be compatible and therefor a GOOD marked one, not hindering us from including it into Fedora.
Comment 30 Sascha Thomas Spreitzer 2010-07-30 06:51:16 EDT
Spec URL: http://sspreitzer.fedorapeople.org/ca-cacert/ca-cacert.spec
SRPM URL: http://sspreitzer.fedorapeople.org/ca-cacert/ca-cacert-0.1-1.fc13.src.rpm
Description:
root certificates of CACert Web-of-Trust Certification Authority

! This is my second package, but I still need a sponsor :) !
Comment 31 David Woodhouse 2010-07-30 08:18:35 EDT
The %post and %preun scripts look like they'll be fine for now for the NSS database, but I don't think /etc/pki/tls/certs/*.0 is going to be OK.

Even if our OpenSSL is looking there by default and not just at the single file in /etc/pki/tls/cert.pem (which I'm not convinced about), there is also a significant chance of filename collisions.

If I make a package for my company's internal trust chains, I might *also* have a CA with a hash of 590d426f or 99d0fa06 -- and then one of the files would need to be called 590d426f.1 or 99d0fa06.1.

This can only be handled with some kind of post-processing step like Debian's update-ca-certificates script -- as discussed in bug 466626.

Sascha, can you be tempted to port/implement that?
Comment 32 Sascha Thomas Spreitzer 2010-08-02 06:42:06 EDT
(In reply to comment #31)
> The %post and %preun scripts look like they'll be fine for now for the NSS
> database, but I don't think /etc/pki/tls/certs/*.0 is going to be OK.
> 
> Even if our OpenSSL is looking there by default and not just at the single file
> in /etc/pki/tls/cert.pem (which I'm not convinced about), there is also a
> significant chance of filename collisions.
> 
> If I make a package for my company's internal trust chains, I might *also* have
> a CA with a hash of 590d426f or 99d0fa06 -- and then one of the files would
> need to be called 590d426f.1 or 99d0fa06.1.

That is interesting, I was wondering about the dot-index, but never made my mind clear about it. Thank you for the explanation!

> This can only be handled with some kind of post-processing step like Debian's
> update-ca-certificates script -- as discussed in bug 466626.
> 
> Sascha, can you be tempted to port/implement that?    

I will take a look at it, if it is clean and easy, I am willing to brew and maintain "update-ca-certificates"
Comment 33 Sascha Thomas Spreitzer 2010-08-03 08:13:25 EDT
(In reply to comment #31)

> Sascha, can you be tempted to port/implement that?    

Created a python script to handle this, please review and comment on "update-ca-certificates" 
https://bugzilla.redhat.com/show_bug.cgi?id=620752
Comment 34 Tom "spot" Callaway 2010-08-06 09:19:11 EDT
So, unfortunately, Red Hat Legal, upon reviewing the license again, thinks that the part of the license that Matt pointed out in Comment 23 makes it non-free.

Specifically, in the license, RELY is defined as:

  the human act in taking on a risk or liability on the basis of the
  claim(s) bound within a certificate issued by CAcert

Then the license says:

  THIS LICENSE SPECIFICALLY DOES NOT PERMIT YOU TO RELY UPON ANY
  CERTIFICATES ISSUED BY CACERT INC. IF YOU WISH TO RELY ON
  CERTIFICATES ISSUED BY CACERT INC, YOU MUST ENTER INTO A SEPARATE
  AGREEMENT WITH CACERT INC.

So, if you do an insert, it means:

  THIS LICENSE SPECIFICALLY DOES NOT PERMIT YOU TO (take) the human act in taking on a risk or liability on the basis of the claim(s) bound within a certificate issued by CAcert, UPON ANY CERTIFICATES ISSUED BY CACERT INC.

Its rather confusing, but the final conclusion was that this counts as a use restriction, as opposed to a simple waiver of liability. This means the license is non-free. :(

CACert should simply dislaim any liability and let end-users/distributors worry about their own risks.
Comment 35 Sascha Thomas Spreitzer 2010-08-06 09:56:04 EDT
(In reply to comment #34)
> CACert should simply dislaim any liability and let end-users/distributors worry
> about their own risks.    

I forwarded the discussion to the CACert policy group, lets see what CACert can do about this. Please, stand by.
Comment 36 Rod Montgomery 2011-02-02 15:56:21 EST
After reviewing the CACert policy discussion archive, I offer the following summary and a suggestion to reconsider the interpretation of RDL.

CACert seeks to avoid the potential liability of an end user relying on a CACert certificate without being bound by the CCA (CACert Community Agreement), which is a precondition of membership.

Sascha Thomas Spreitzer proposed that CACert use a more widely-known license, CC-BY-ND, to distribute the root certificates. https://lists.cacert.org/wws/arc/cacert-policy/2010-06/msg00151.html This license does not specifically mention reliance. For this and other reasons, the policy discussion did not find consensus to adopt CC-BY-ND.

CACert resolved to use the Root Distribution License (RDL), as mentioned in Comment 21, and further discussion of CC-BY-ND and 3pv-DaL ceased. https://wiki.cacert.org/PolicyDecisions#p20100710

RedHat Legal interpreted the RDL to have a use restriction which blocks this bug.

Without some reconsideration, it appears that Fedora and CACert have created an impasse. May I suggest that RedHat Legal reconsider the interpretation on the grounds that:

a) the RDL language "specifically does not permit" is not the same as "prohibits." CACert disclaims express or implied warranties, and specifically withholds permission to rely (take on risk or liability).

b) all software under GPL carries the same restriction, "No warranty... the entire risk as to the quality and performance of the program is with you [the user]." It seems consistent to say, from another perspective, that relying on the quality or performance of the program is specifically not permitted by the GPL. The RDL language is a restatement of warranty disclaimer for clarity and emphasis, it is not an incremental restriction.

In either reading, the user is free to assume risk or liability absent the permission of CACert. CACert is not held liable for the use of the certificates distributed under the RDL.
Comment 37 Matt McCutchen 2011-02-02 17:53:06 EST
(In reply to comment #36)
> Without some reconsideration, it appears that Fedora and CACert have created an
> impasse. May I suggest that RedHat Legal reconsider the interpretation on the
> grounds that:

Red Hat Legal's analysis is correct.  There is nothing to reconsider.

> a) the RDL language "specifically does not permit" is not the same as
> "prohibits." CACert disclaims express or implied warranties, and specifically
> withholds permission to rely (take on risk or liability).

A priori, I don't need CAcert's permission to rely on (= take on risk or liability based on) their certificates.  There is no law, and I have agreed to no contract, that would forbid me to do this.  A simple statement that they withhold permission is meaningless; there is no permission to withhold.  It seems more likely, especially in view of the policy discussion you linked, that the intended interpretation is to make non-reliance a condition of the copyright license.  (If this is not the case, CAcert should issue an official clarification.)

> b) all software under GPL carries the same restriction, "No warranty... the
> entire risk as to the quality and performance of the program is with you [the
> user]." It seems consistent to say, from another perspective, that relying on
> the quality or performance of the program is specifically not permitted by the
> GPL.

Nope.  Companies rely (= take on risk and liability based on) the correct operation of GPL software every day.  They just can't sue the copyright holders if it breaks.

> The RDL language is a restatement of warranty disclaimer for clarity and
> emphasis, it is not an incremental restriction.

No, that is not what it says when "RELY" is expanded with the definition given (comment #34).
Comment 38 Tom "spot" Callaway 2011-02-03 11:25:29 EST
I agree with Matt here. If CAcert's position is that their intention behind the "specifically does not permit" is that it is meant to be functionally equivalent to the GPL warranty disclaimer, then I would suggest that they reword the RDL to use that warranty disclaimer and drop the additional restrictions.
Comment 39 Rod Montgomery 2011-02-03 15:40:44 EST
(In reply to comment #37)
> A priori, I don't need CAcert's permission to rely on (= take on risk or
> liability based on) their certificates.  There is no law, and I have agreed to
> no contract, that would forbid me to do this.  A simple statement that they
> withhold permission is meaningless; there is no permission to withhold.  It
> seems more likely, especially in view of the policy discussion you linked, that
> the intended interpretation is to make non-reliance a condition of the
> copyright license.  (If this is not the case, CAcert should issue an official
> clarification.)

Yes, in further reading at https://lists.cacert.org/wws/arc/cacert-policy/2010-06/msg00062.html, I found Ian Grigg's opinion that non-related persons should be banned from relying on the certificates. His comment was made in the context of the NRP-DaL (since removed in favor of the RDL), but the intention carries on in the language of the RDL.

> Companies rely (= take on risk and liability based on) the correct
> operation of GPL software every day.  They just can't sue the copyright holders
> if it breaks.

Companies choose to take those risks and liabilities of their own volition, not as a result of any assurance, warranty, or claim in the GPL. IANAL, but it seems that the first portion of the RDL Disclaimer would sever any CACert liability from "relying inappropriately." CACert's concern over possible litigation seems to be the driving concern behind the reliance language in the second portion, but I do not see why the warranty disclaimer is insufficient for CACert's concern.

I cannot speak for CACert or Fedora, but I am an interested user/participant of both organizations. Thanks for the quick and thoughtful reply.
Comment 40 Matt McCutchen 2011-02-03 15:56:06 EST
(In reply to comment #39)
> Companies choose to take those risks and liabilities of their own volition, not
> as a result of any assurance, warranty, or claim in the GPL.

Right.

> IANAL, but it
> seems that the first portion of the RDL Disclaimer would sever any CACert
> liability from "relying inappropriately." CACert's concern over possible
> litigation seems to be the driving concern behind the reliance language in the
> second portion, but I do not see why the warranty disclaimer is insufficient
> for CACert's concern.

It would make complete sense that the warranty disclaimer should be enough, but this is a question for the lawyers to puzzle out.  In the meantime, I know of a third party repository that has a "nonfree" section and would probably be happy to carry the package given that they use CAcert certificates themselves.
Comment 41 Philipp Dunkel 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
Comment 42 Iang 2011-11-01 10:15:14 EDT
What Philipp wrote, ++

just to stress the liability issue a little:  All open software seeks to discount liability to zero in its licences, and much of sold software does the same.  Look in any licence.

In CAcert, we do not do that -- as Members, we are all liable up to 1000 euros.  Philipp, me, and any of around 20k other active members.  Which means a relying party (by our definition, a Member) can get damages, serious damages.

This of course doesn't work for the whole world.  Our 20k active users can't pay those liabilities to the 2 billion Internet users.  Imagine we get sued for some bank class action fraud… Our Members won't survive, Audit won't permit it, and our Directors would be hauled to jail for such a fraud as offering free liability coverage to the whole Internet.

Hence we define reliance as being a permission available to members.  Membership is free, but you are then liable.

As you see in the CAcert RDL, we use the statement "you may not RELY" in order to make sure that you, as a non-member of CAcert, don't actually assume you can sue us if something goes wrong.  This is the case with practically all CAs,  and it is a mathematical and financial certainty, so be warned that Internet mythology is unreliable on this point.

It's just that CAcert tells you up-front, in an easy to find way.

However, what you do have as a visitor to some cert at a user level is a permission to USE.  This is really what is desired and is useful, because in the practical world of Internet and communications, we don't typically sue each other.  The wording for this is found in the CCA (for historical reasons, it's not in the RDL).
Comment 43 Iang 2011-11-01 10:19:52 EDT
One other point:  Our policies are written to be fair, honest, and up-front (and done so in open forum with open voting).  Someone would say, in your face!  Which is why RedHat Legal found it, and we hope that the Judge will find it of credibility too.

One question you may want to ask is why RedHat Legal has not found the situation for any other CAs?  Has it examined the distribution licences from other CAs?  Has it examined the RPAs from other CAs?

Let me provide a summary of what you will find:  All CAs typically do not give permission to rely, unless you enter into a Relying Party Agreement.  (Google knows...)

They just don't say the first part, but the clue is in the title:  Relying Party Agreement -- without that, you have no permission to rely.  We say it without the clue.

Further, in a typical RPA, all CAs typically set all liabilities to you to zero.  If you enter into an agreement with your local CA, chances are it will set liability to zero both explicitly and through a number of other tactics which would take a book to describe.  Ergo, if you have no agreement with a CA, then you have even less.  The exceptions to this in general are QC issuers in Europe -- which operate to government regulated limits on liability primarily for digital signing smart cards -- and CAcert.

A second thing you need to look at is the licence you agree to when shipping the root of other CAs.  They won't tell you about it necessarily, but *you do need a licence* or permission of some form.  We tell you, it's the Root Distribution Licence.

In summary, in order to say that CAcert's licence is bad (non-free is the term used above) we have to also say that all the other licences of all the other CAs are better (freer?).  Has that been done?
Comment 44 Matt McCutchen 2011-11-02 04:45:14 EDT
(In reply to comment #41)
> However
> we cannot disclaim the liability of a member to a user for communications that
> take place between the member and the user directly.

What would be an example of a suit against a member that you would want to prevent?

> 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.

And as long as you insist on doing this, the root is non-free.

> So is this a "use restriction"? Absolutely. You may not use CAcert certificates
> as a base for your decision making.

But that is precisely what availability of the root in Fedora would invite users to do.  This is the kind of legal trap that Red Hat has rightly stood firm against.

> 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.

Yep.  I don't see why Fedora should be any more willing to make an exception for CAcert than for other projects that do not meet its licensing requirements due to competing interests.

(In reply to comment #42)
> Imagine we get sued for
> some bank class action fraud…

You have disclaimed liability.  What is the problem?

> As you see in the CAcert RDL, we use the statement "you may not RELY" in order
> to make sure that you, as a non-member of CAcert, don't actually assume you can
> sue us if something goes wrong.

Non-members would be wrong to make that assumption anyway, because you have disclaimed liability.

> However, what you do have as a visitor to some cert at a user level is a
> permission to USE.  This is really what is desired and is useful, because in
> the practical world of Internet and communications, we don't typically sue each
> other.

No, you are conflating relying with suing.  In the practical world, I choose to rely (= make decisions based on certificates) all the time via the tool of my browser, even though I know I cannot sue.

(In reply to comment #43)
> All CAs typically do not give
> permission to rely, unless you enter into a Relying Party Agreement.  (Google
> knows...)

Wrong.  StartCom allows unrelated parties to rely at their own risk (http://www.startssl.com/policy.pdf, "Legal and Limitations").  VeriSign allows unrelated parties the same provided that they "validate" the certificates, whatever that means (http://www.verisign.com/repository/rpa.html).

> In summary, in order to say that CAcert's licence is bad (non-free is the term
> used above) we have to also say that all the other licences of all the other
> CAs are better (freer?).  Has that been done?

I hereby say it.  It's likely that some of the other root certificate licenses strictly speaking do not meet Fedora's requirements, but CAcert's use restriction is by far the most blatant.
Comment 45 Matt McCutchen 2011-11-02 04:50:20 EDT
(In reply to comment #44)
> (In reply to comment #43)
> > All CAs typically do not give
> > permission to rely, unless you enter into a Relying Party Agreement.  (Google
> > knows...)
> 
> Wrong.

Backspace... Your statement is true, but the point is that StartCom and VeriSign (as two examples) offer general RPAs that permit unrelated parties to rely under certain conditions, while CAcert does not.
Comment 46 Philipp Dunkel 2011-11-02 05:03:43 EDT
(In reply to comment #45)
> (In reply to comment #44)
> > (In reply to comment #43)
> > > All CAs typically do not give
> > > permission to rely, unless you enter into a Relying Party Agreement.  (Google
> > > knows...)
> > 
> > Wrong.
> 
> Backspace... Your statement is true, but the point is that StartCom and
> VeriSign (as two examples) offer general RPAs that permit unrelated parties to
> rely under certain conditions, while CAcert does not.

Well actually CAcert does the same thing. If you want to rely on a StarCom or Verisign Cert you need to enter into their separate Relying Party Agreement. If you want to rely on a CAcert Certificate you have to enter into the CCA http://www.cacert.org/policy/CAcertCommunityAgreement.php

So where is the difference?
Comment 47 Philipp Dunkel 2011-11-02 05:08:21 EDT
(In reply to comment #44)
> (In reply to comment #41)
> > 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.
> 
> And as long as you insist on doing this, the root is non-free.
Well in that case we need to stop right now. And Fedora will also remove all CA-Certificates from the distribution, because none of them are free. (The StarCom and Verisign Examples you provide below are an indication of that)

> > In summary, in order to say that CAcert's licence is bad (non-free is the term
> > used above) we have to also say that all the other licences of all the other
> > CAs are better (freer?).  Has that been done?
> 
> I hereby say it.  It's likely that some of the other root certificate licenses
> strictly speaking do not meet Fedora's requirements, but CAcert's use
> restriction is by far the most blatant.

And here we arrive at the real problem. CAcert is blatant about what we do and do not do. Other CAs are more politic about it and hide the same things in the fine print. You almost make it look like openness is not appreciated at Fedora?
Comment 48 Philipp Dunkel 2011-11-02 05:12:05 EDT
(In reply to comment #46)
> (In reply to comment #45)
> > (In reply to comment #44)
> > > (In reply to comment #43)
> > > > All CAs typically do not give
> > > > permission to rely, unless you enter into a Relying Party Agreement.  (Google
> > > > knows...)
> > > 
> > > Wrong.
> > 
> > Backspace... Your statement is true, but the point is that StartCom and
> > VeriSign (as two examples) offer general RPAs that permit unrelated parties to
> > rely under certain conditions, while CAcert does not.
> 
> Well actually CAcert does the same thing. If you want to rely on a StarCom or
> Verisign Cert you need to enter into their separate Relying Party Agreement. If
> you want to rely on a CAcert Certificate you have to enter into the CCA
> http://www.cacert.org/policy/CAcertCommunityAgreement.php
> 
> So where is the difference?

The difference is that CAcert makes it explicit that you are entering an agreement.

Verisign sais:

1. Term of Agreement. This Agreement becomes effective when you submit a query to search for a VeriSign Certificate, or rely on any VeriSign Information in the manner set forth in the preamble above. This Agreement shall be applicable for as long as you use and/or rely on such VeriSign Information. 

So just by navigating to a site with you browser that uses a cert from Verisign and having your browser do what it was designed to do you enter an agreement with them?  Talk about fine print!
Comment 49 Iang 2011-11-02 05:16:31 EDT
Matt,

did you read the RPA from Verisign?

       "IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT,
        DO NOT SUBMIT A QUERY AND DO NOT DOWNLOAD, ACCESS,
        OR RELY ON ANY VERISIGN INFORMATION."

If you agree to the RPA, you may rely on their certificates (according to their definition, not yours).  And you are a related party, bound by their RPA.

If not, then not. "DO NOT RELY!"

Exactly the same as CAcert.
Comment 50 Iang 2011-11-02 05:25:12 EDT
A couple of additional caveats:

1.  Startcom is a different kettle of fish.  It doesn't have an RPA (last I looked) and doesn't follow the normal CA contractual pattern.  Because it doesn't have a defined agreement and instead relies on its CPS, it is much harder to interpret in legal terms.  It is better to familiarise with the Verisign standard RPA approach first, and then branch out.

2.  Please also note that it is your responsibility to agree to the RPAs and understand them, as and when you use certificates.  As professionals, we are limited in what we can say about brother CAs.  Obviously, this absence of inspection can be be used against you, and has been used against you in this case, because you believed you could rely under your own definitions.

That is indeed why we are the blatant ones.
Comment 51 Iang 2011-11-02 05:43:41 EDT
Matt writes in comment #44:
> > Imagine we get sued for
> > some bank class action fraud…
> 
> You have disclaimed liability.  What is the problem?

Liabilities are not set in contract, but in court.  The judge looks at the whole case, and determines the wrong & right of it all.  This holistic view requires us also to look holistically, and do what we can to make things right.

In our view, a boilerplate disclaimer is not sufficient.  The primary reason for this is that the user-public falsely believes - and vendors and CAs continue to perpetuate by absence of clarity - that users have a universal right to rely.  As is evidenced above, this is far from reality.

So we have gone further to create a more clear arrangement, and we have added an explicit USE permission in the void for those who haven't agreed to the CCA (our RPA).  In this we are explicitly speaking both to our users and to the judge in a future case.  Clarity for both, which makes it a bit unusual.

> What would be an example of a suit against a member that you would want to
prevent?

The big ones are if a financial institution is defrauded by many users, using a manipulated cert in some sense.  E.g., a successful phishing operation pulls in maybe 100k.  If for example we had a small merchant with PeopleBank.com as a job sharing website, and his cert was stolen and used to defrauded PeoplesBank.com, a big financial institution, then we'd have an issue...

As has been seen from the DigiNotar case (finally) a cert delivered by one CA can be used to defraud another CA's customers.  So this means our CA could be used to breach Bank of America, or the Whitehouse, or whoever.  The smallest CA could be used to breach the biggest customer...
Comment 52 Tom "spot" Callaway 2011-11-02 10:33:15 EDT
If any of you CA-Cert folks are lawyers, please indicate that.
Comment 53 Matt McCutchen 2011-11-03 03:34:48 EDT
Phillip and Ian,

Please spare us the self-righteousness and the propaganda.  The topic of this bug is whether the CAcert root meets Fedora's licensing requirements.

(In reply to comment #46)
> Well actually CAcert does the same thing. If you want to rely on a StarCom or
> Verisign Cert you need to enter into their separate Relying Party Agreement. If
> you want to rely on a CAcert Certificate you have to enter into the CCA
> http://www.cacert.org/policy/CAcertCommunityAgreement.php
> 
> So where is the difference?

Sorry, I wasn't precise enough.  To rely under the CCA, one must register affirmatively with CAcert (fails the dissident test) and agree to be bound by arbitration, including potential liability up to 1000 euros; it's unclear whether a party who does not obtain any certificates from CAcert can be certain of avoiding this liability.  This is not something to which Fedora should expose its users.  OTOH, the VeriSign RPA can be entered anonymously and allows one to rely at one's own risk, provided that one "validates" the certificates, without accepting any obligations or liabilities aside from a standard indemnity.  StartCom doesn't purport to restrict reliance, and just makes clear that it is at one's own risk.

(In reply to comment #51)
> If for example we had a small merchant with PeopleBank.com as a
> job sharing website, and his cert was stolen and used to defrauded
> PeoplesBank.com, a big financial institution, then we'd have an issue...

You're saying that even if the CAcert root is distributed with "absolutely no warranty", someone may be able to use its lack of fitness for a particular purpose as the basis of a suit against a third party?  I would like to think that that is not possible, but IANAL and I would want an actual lawyer's opinion.  If this issue is real, it might affect free software more generally.
Comment 54 Iang 2011-11-03 07:28:06 EDT
Matt, comment #53

> (In reply to comment #51)
> > If for example we had a small merchant with PeopleBank.com as a
> > job sharing website, and his cert was stolen and used to defrauded
> > PeoplesBank.com, a big financial institution, then we'd have an issue...
> 
> You're saying that even if the CAcert root is distributed with "absolutely no
> warranty", someone may be able to use its lack of fitness for a particular
> purpose as the basis of a suit against a third party?

Yes, that's what I'm saying, more or less.  Obviously, there are many different methods of legal attacking any CA's contract, and it's beyond the scope of this forum to examine what they would be.  And this applies to all CAs, not just CAcert.

> I would like to think
> that that is not possible, but IANAL and I would want an actual lawyer's
> opinion.


Steve Schultze and Steve Roosa for example recently published a paper on this, but the tradition is long standing.

https://freedom-to-tinker.com/blog/sroosa/flawed-legal-architecture-certificate-authority-trust-model

Quote, for others skimming through:

    "Given the absence of notice to the end-user and assent by the end-user, it would appear that many CAs would have a difficult time holding an end-user to the terms of the relying party agreements or certification practice statements. To date, the CA Trust Model's legal architecture has apparently not been the subject of any published court decision and remains untested.

     The bottom line is that the CA Trust Model's legal architecture inures to the benefit of no one. Neither website operators, certificate authorities, nor end-users can be sure of their rights or exposure. The Model's legal structure may therefore be just as troubling as its security vulnerabilities."

End quote.  Within the legal field, it is normal for law profs to look at the general CA contracts and declare them unfit, and assert that the contracts would likely have a lot of trouble standing up in court.

> If this issue is real, it might affect free software more generally.

No, you may rest easy :)

(Free) software is not effected by this because it isn't a business that ordinarily involves claims and liabilities and claims of fitness.  CAs and certificates do, a certificate is a claim that it is fit for some purpose or other.  So, CAs have to go to a great deal more extent to refine their legal posture, and protect themselves and their stakeholders.

E.g., our legal project is 100 pages of contract & policy, and 3 years in the making.

In contrast, a pure play open source operation just copies one of the standard licences.  And it's done.  It's safe, it can even change midstream by issuing under dual licences without any problems.
Comment 55 Iang 2011-11-03 09:20:57 EDT
Comment #53, continuing in reverse order:

> (In reply to comment #46)
> > Well actually CAcert does the same thing. If you want to rely on a StarCom or
> > Verisign Cert you need to enter into their separate Relying Party Agreement. If
> > you want to rely on a CAcert Certificate you have to enter into the CCA
> > http://www.cacert.org/policy/CAcertCommunityAgreement.php
> > 
> > So where is the difference?

> Sorry, I wasn't precise enough.  To rely under the CCA, one must register
> affirmatively with CAcert (fails the dissident test) and agree to be bound by
> arbitration, including potential liability up to 1000 euros; it's unclear
> whether a party who does not obtain any certificates from CAcert can be certain
> of avoiding this liability.  This is not something to which Fedora should
> expose its users.

OK, this is where we start to differ on terms and semantics.  Your term "relying" is what we call USE from CAcert's lexicon.  This right is available (more or less, the details are a little convoluted, but it is works).  Fedora users don't need to do much or anything to benefit, it's not an "exposure" in those terms.

> OTOH, the VeriSign RPA can be entered anonymously and allows
> one to rely at one's own risk, provided that one "validates" the certificates,
> without accepting any obligations or liabilities aside from a standard
> indemnity.

Right, we differ in semantics of terms.  They offer "rely at ones own risk" to a wider public, whereas CAcert's USE of certificates is available to a wider public.  These are comparable at the legal/semantic level, and both are useful to Fedora's users.  Both deliver the essence of what CAcert calls USE.

> StartCom doesn't purport to restrict reliance, and just makes clear
> that it is at one's own risk.

Yes, they also define "reliance at your own risk," approximately.  Substitute "CAcert" and "USE" into the above sentence and it will bear comparison.
Comment 56 Matt McCutchen 2011-11-04 01:12:29 EDT
(In reply to comment #55)
> Your term
> "relying" is what we call USE from CAcert's lexicon.

No, it isn't.  By "rely", I mean to proceed with a transaction with a party on the basis of a certificate presented by the party, where I would face risk or loss if the claims in the certificate are untrue.  This includes my browser's decision to complete an SSL connection to a server, which can result in transmission of confidential information to the server or lead me to act based on information received from the server, putting me at greater risk if the server is not one authorized by the registrant of the DNS name I requested.  StartCom and VeriSign let me do this anonymously at my own risk if I validate the certificate; CAcert requires me to register and agree to potential liability of 1000 euros via its arbitration process.

"USE" as you define it is quite useless: if I am not permitted to rely on a certificate, it is no better than self-signed.  So the CAcert RDL is significantly farther from "free" with respect to use (lowercase) than the StartCom and VeriSign licenses.  And we're deluding ourselves if we think offering the CAcert root in Fedora would lead to anything but massive violation of the prohibition on reliance.
Comment 57 Iang 2011-11-04 09:56:59 EDT
Look beyond the labels for a moment, and look at the actions.

   *  you can use the certificates to complete your connections.
   *  you have to conduct your own due diligence ("validate").
   *  you cannot (expect to?) pin any bad effects on the CA.
   *  you may have heard that the CA has done a good job at the claims. Super!
   *  you may not base your decision on the claims.
   *  you may proceed with any transaction you see fit.

All of those are true for CAcert.   They are true for other CAs (more or less, for this discussion, I'll assume it, as it is a job of work to show it or otherwise.)

Now back to the labels.  That's what we call USE.  That's what other CAs call reliance.

What is it that you are missing?
Comment 58 Iang 2011-11-04 10:10:59 EDT
Matt,

> [2 CAs] let me do this anonymously at my own risk if I validate
> the certificate;

:) so, there is one of the industry's dirty little secrets:  validate.

You are not allowed to rely *unless you validate the certificate*.  What does that mean?  Well, to cut short a long debate, I'll assert it:  the requirement to validate is complete.  You must validate the other party/certificate to the extent that you do not need to rely on the certificate.  At all!

The description doesn't say it, but you will find out in court that this is what it means.  In court, if you relied on my name being Iang from a certificate, you will have to show you also checked it another way.  In short, you will have to show that reliance was ignored or ignorable.  And because you took it at your own risk, and because you did your own diligence, and you got it wrong, then the CA isn't at fault.

Now, let's look at a legal definition of Reliance (just the 1st I found):

http://legal-dictionary.thefreedictionary.com/reliance

reliance n. acting upon another's statement of alleged fact, claim, or promise. In contracts, if someone takes some steps ("changes his position" is the usual legal language) in reliance on the other's statement, claim or promise then the person upon whom the actor relied is entitled to contend there is a contract he/she can enforce. However, the reliance must be reasonable. (See: reasonable reliance)



Do you see what has happened?  The CAs have re-defined reliance to be not reliance:  at own risk, must do own validation, disclaimer of liabilities, no clause you can enforce, etc etc.  This is the Fort Knox definition of reliance:  we have a lot of gold, but in order to get it, you'll be committing harakiri.

For those CAs, reliance is an empty term.  They could call it pink bananas and it would have the same effect:  here is a list of things that *you have to do* in order to use the certificate.  Legally, they don't offer you anything in that you couldn't get other ways, and in legal assertion in the contract, you must get those things other ways.

Now, CAcert declines to do that.  We decline to stand up before the judge and say "your honour, we offer reliance, but our contract strips it of meaning!"

That's why we call the normal usage of certificates USE.

(Earlier, we discussed whether the RPAs are valid, and whether they are potentially risky contracts.  We can now see an avenue of attack:  anything to do with the use of the term "reliance" is a target for being written out by the judge, because it redefines itself out of well-understood legal tradition.  A risk... and that is yet another reason why CAcert does not join the rest of the industry.)
Comment 59 Tom "spot" Callaway 2011-11-04 10:54:07 EDT
All of you, please stop.

It seems clear from the lack of response to my query that no one from CAcert that is posting on this ticket is a lawyer.

Red Hat has lawyers who review license issues, whether they be on content, code, certificates, or greased ferrets. They've reviewed the CAcert terms and advised us that they do not meet the minimum requirements for Fedora to include them.

If there is an actual lawyer on the CAcert side who would be willing to correspond with Red Hat Legal on this issue, please feel free to either have them reach out to me, or send me their contact information and I will be sure to connect them with Red Hat Legal.

Otherwise, please, stop. It smells like Debian Legal in here. I'm sure you mean well, but you're not accomplishing anything or convincing anyone.
Comment 60 Miroslav Suchý 2013-03-15 05:10:58 EDT
Not suitable for Fedora. 

If this get at some point green flag from fedora-legal, please reopen. Closing for now.

Note You need to log in before you can comment on or make changes to this bug.