Policy-Discussion

[Eva Stöwe <eva.stoewe AT cacert.org>]

Maybe you should actually READ Bennys proposal...

Am 29.05.2014 13:57, schrieb Alex Robertson:
> What about a more specific rule somewhere along the lines of [you are
> obliged] "to ensure that your Certificates are only used within the
> context in which they are issued" rather than tying it into key
> sharing.... this whole concept would fit better as an obligation in 2.3 IMO
> 
> Regards
> 
> Alex
> 
> On 29/05/2014 03:51, Benny Baumann wrote:
>> 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.
>>
> 
> 

-- 
mit freundlichen Grüßen / best regards
Eva Stöwe
CAcert Assurer
CAcert Case Manager & Arbitrator
CAcert.org - Free Certificates
E-Mail: 
eva.stoewe AT cacert.org

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