Policy-Discussion

[Benny Baumann <benbe AT cacert.org>]

Hi ianG,

text near end of mail.

Am 28.05.2014 05:03, schrieb Ian G:
> On 26/05/2014 19:03 pm, 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.
> OK.  I would suggest the removal of the clause keep the numbering the
> same and just replace the text with "(removed)".
>
> I think it is an important point, if only because I've seen what can
> happen.  So if we can find suitable text, I think it worth adding in,
> sometime in the future.
>
>> 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).
> I don't see the problem with having the Arbitrator find some decision in
> this case.  It was what was intended.  It works in most cases.
>
> Obviously, we hit the rocks when it came to the death case.  And the
> Arbitrator failed at the time(s) to find answers.  And, as we've
> discussed it at length, it is not as if there are easy answers.
>
> However, this does not mean we can simply wave into existence a
> solution.  We need ideas here.  So far I'm not seeing them. What I am
> seeing is stabs in the dark like "death triggers a termination of CCA"
> which leaves open the question of RLO.
>
>
>> 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.
> I would be one I would guess, I haven't seen any good argument to change
> that.  (I have seen costs -- the work load on the Arbitrators is a high
> cost.)
>
>
>> 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.
> Well, it wouldn't make a lot of sense to change the CCA to point to a
> document that doesn't exist.
>
> But I also don't see the argument here.  If there is a desire to write a
> policy to handle some situation X, then do so.  Present it.  Then, in
> the discussion and eventual vote, there will be a change to both CCA as
> well as acceptance for the new policy.
>
>> 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.
> "out of their context" then begs the question -- what is their context?
>
>
>> 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".
>>
> Speaking for myself, I would not want an addition that did not solve a
> problem.  As stated above c.f., "context", it doesn't solve a problem
> that I can see.  We already have text that says the keys & account have
> to be secured.  Which implies or dominates the term "context" as far as
> I can see.
It doesn't fully cover the case where I as an Org Admin deploy an Org
Server certificate (without explicit agreement) on my private webserver.
The addition tells you exactly that this is not allowed (because context
of Org Server Cert = the servers of that organization vs. Conext of use
= my private webserver do not match up --> forbidden). Yes, 2.54. only
covers small details and most people won't notice them in their dayly
live, but when confronted with edge cases this addition solves quite a
lot of questions by providing a easy to follow guideline.
> iang
Regards,
BenBE.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature