Policy-Discussion

[Alex Robertson <alex-uk AT cacert.org>]

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.

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