Policy-Discussion

[Grégoire Sandré <gregoire.sandre AT free.fr>]

Dear all,

- 4.1 (CAcert Inc. contracts with other parties)
 drop of this is ok for me.
 
 - 3.3 (termination of CCA)
 I support the policy solution.

 - 2.5 (private key disclosure)
 I would like such an addition. This may help some arbitrations.

Grégoire 

> -----Original Message-----
> From: 
> cacert-policy-request AT lists.cacert.org
>  [mailto:cacert-policy-
> request AT lists.cacert.org]
>  On Behalf Of Martin Gummi
> Sent: Monday, May 26, 2014 8:17 PM
> To: 
> cacert-policy AT lists.cacert.org
> Subject: Re: CCA: open points / my opinions
> 
> Dear list,
> 
> 
> - 4.1 (CAcert Inc. contracts with other parties)
> drop of this is ok for me.
> 
> - 3.3 (termination of CCA)
> I support the policy solution.
> 
> - 2.5 (private key disclosure)
> I would like such an addition.
> 
> 
> --
> mit freundlichen Grüßen / best regards
> Martin Gummi
> CAcert Assurer
> CAcert Arbitrator, CAcert Case Manager
> CAcert.org - Free Certificates
> E-Mail: 
> martin.gummi AT cacert.org
> 
> On 26.05.2014 20:03, Eva Stöwe wrote:
> > 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.
> >
> > 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.)
> >
> >
> > 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
> > - 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".
> >

Attachment: smime.p7s
Description: S/MIME cryptographic signature