Subject: Policy-Discussion
List archive
- From: Benny Baumann <benbe AT cacert.org>
- To: cacert-policy AT lists.cacert.org
- Subject: Re: CCA: open points / comments BB
- Date: Thu, 29 May 2014 03:02:22 +0200
Dear List,
Am 26.05.2014 20:03, schrieb Eva Stöwe:
> Dear list,
>
> some time has passed since my last update.
>
> Even while there was a quite heated discussion in the background, we did
> not make so much of a progress for the open points.
>
> The open points I identified last time were:
>> - 2.5 (private key disclosure),
>> - 3.3 (termination of CCA),
>> - 4.1 (CAcert Inc. contracts with other parties)
> I want to address each point separately, in reverse order.
>
> 4.1 (CAcert Inc. contracts with other parties)
> ----------------------------------------------
> While many here agree that it could be a good idea to get some hold on
> board / Inc. so that they will not enter contracts contradicting CCA,
> nobody really found a formulation that would probably work (or at least
> where others think that it would work).
>
> There were also people who pointed out, that something like this
> logically just cannot work.
>
> Also the current version
> a) does not work and
> b) is far away to do anything in the direction it is intended to work
> c) is quite hard to read at all.
>
> So I proposed to just remove 4.1. - This got the most support.
>
> To move on I will just "add" this change to the next CCA-WiP-Update, if
> nobody protests. I hope that you can live with this.
ACK. There's a yet private proposal, which will be addressed to this
list later as to avoid further complication.
> 3.3 (termination of CCA)
> ------------------------
> This is much more complicated.
>
> There are two arbitration rulings that ask us to define something for
> the event of death.
>
> Both arbitration rulings have found, that the current version is not
> working at least for this event and that it is not sufficient to just
> hand the termination to arbitration and forget about it.
>
> We have to define something here, we have to change the current CCA (or
> it may happen that an arbitrator does this for us - what nobody wants).
>
> Also there were people who pointed out that it may be complicated to get
> an arbitrator ruling "in the case that all services of CAcert are
> terminated" - since one could consider that arbitration is one of those
> services.
>
> Nonetheless there are people who do not want to change that in all cases
> the Arbitrator has to terminate the CCA.
>
> Benedikt and I proposed to move the whole problem over to a policy that
> would need to be defined. It's not my favorite solution, but it could be
> seen as a compromise. Such a policy could define different things for
> different termination reasons. Also it would have been defined by you -
> the policy group.
>
> However there are people who seem to fear that this would lead to
> something dreadful.
>
> So I ask everybody who cannot live with this, to make a proposal (or
> support a proposal) that
> a) could probably be agreed on by a lot of others
> b) does not only state that an arbitrator will rule in the case of death
> c) hopefully also sorts out something for the termination of services.
>
> This are the requirements we have to met!
>
> (I do not post the old proposals again - if you want to have them
> posted, write me a private mail and I will see for it.)
Indifferent about this.
> 2.5 (private key disclosure)
> ----------------------------
> Here we have reached a state where people quite intensely fight for the
> addition that private keys should not be shared out of their described
> (attributed) context, while others do not want to have such an addition
> at all.
>
> I have tried to find an agreement or at least a way that leads to an
> agreement in this direction "behind the scenes" but there was little
> progress.
>
> Currently I have only one idea:
> - to collect all arguments at least from that side-discussion
Interestingly one side of that discussion mostly rejected to provide
arguments for their side while the other side provided a much more
detailed view on their stand while at the same time dissecting the other
side's arguments one-by-one.
> - ask for a vote
>
> I would prefer if this would not be needed.
>
> So as I do not have a collection of said arguments at hand, I would
> appreciate anybody who could state their position to add an addition
> that says that private keys should not be shared out of their described
> context or not. If possible I will give you an idea of the shared
> arguments, "soon", to help you there.
>
> So please write "I would like such an addition" or "I do not want such
> an addition".
I would like such an addition
Regards,
BenBE.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
- Re: CCA: open points, (continued)
- Re: CCA: open points, Benedikt Heintel, 05/27/2014
- Re: CCA: open points, Benny Baumann, 05/29/2014
- Re: CCA: open points, Alex Robertson, 05/29/2014
- Re: CCA: open points, Benedikt Heintel, 05/29/2014
- Re: CCA: open points, Benny Baumann, 05/29/2014
- Re: CCA: open points, Ian G, 05/28/2014
- Re: CCA: open points, Benny Baumann, 05/29/2014
- Re: CCA: open points, Alex Robertson, 05/29/2014
- Re: CCA: open points, Eva Stöwe, 05/29/2014
- Re: CCA: open points, Alex Robertson, 05/29/2014
- Re: CCA: open points, Eva Stöwe, 05/29/2014
- Re: CCA: open points, Ian G, 05/30/2014
- Re: CCA: open points, Alex Robertson, 05/29/2014
- Re: CCA: open points, Benny Baumann, 05/29/2014
- Re: CCA: open points / comments BB, Benny Baumann, 05/29/2014
- Re: CCA: open points, Benedikt Heintel, 05/27/2014
Archive powered by MHonArc 2.6.18.