Subject: Policy-Discussion
List archive
- From: Eva Stöwe <eva.stoewe AT cacert.org>
- To: cacert-policy AT lists.cacert.org
- Subject: Re: CCA: open points / comments
- Date: Wed, 28 May 2014 20:40:45 +0200
- Organization: CAcert.org
Dear Alex,
> So what is wrong with my suggestion - it moves towards the framework you
> want and doesn't leave a gaping hole to fall into! I'm not against the
> idea of a separate policy or even a procedure about the matter, but I do
> want to know what I am agreeing to.
why?
There are 3 things the proposal does:
a) define some triggers
b) give us some time to prepare something and give it the room to work
it out
c) it could be updated without a CCA change - under the same rules as
every policy including the CCA may be changed.
Nobody has anything up their sleeves. IF someone had an idea how to
solve it at the moment that would be short enough to put it into the CCA
it would be on the table.
The involvement of anybody here would be the same. The influence on the
result would be the same.
And as long as it is not defined - as so many other things are not
defined - it's back to arbitration - so we should be fast to put
something in place.
As for termination in case of death: Nobody has had any better idea. It
would at least give an idea where R/L/O may be put (even if I would
prefer to have something more. Since we cannot expect, that after the
death of a member anybody knows both, that the person was a member and
that the person died, we cannot rely on anything that would depend on
someone informing us. Also membership is something personal so it makes
not much sense to move it around between people (without even knowing
about this or knowing anything about the person. Especially as CCA
defines a member as "a registered participant within CAcert's Community,
with an account on the website and the facility to request
certificates". Someone inheriting an account would not be registered.
Also some counties automatically terminate memberships and inheriting
would be done under local law we would never know if there even would be
a heir if we would allow for this - we even do not know the nationality
of our members.
>> It's not a "you" it's a "we". And also as long as there is no policy
>> installed there will always be arbitration. But leaving it with the
>> arbitrator just does not work. And you are one who
>> was strictly against death being a trigger - it also cannot be if it s
>> left
>> with the arbitrator, because either the death is the trigger, or the
>> decision of the arbitrator. And there is no way that a death automately
>> activates an arbitrator or an arbitration case.
> Not true - as far as I can recall I've been in favour of death as one of
> several triggers that may cause a termination process to occur. I may
> have issues about the process triggered - but that's another matter.
If it is a trigger it HAS to activate the process not "MAY" activate the
process.
>> c) Assisting someone with access does not need to involve any sharing. It
>> may be that only the assistant has actual access to the account but only
>> data of the assisted person is handled and it is only the will of the
>> assisted persen relevant (or whoever may voice the will for the assisted
>> person).
> This is where it gets less black and white. Similarly with families. I
> can choose to trust whoever to provide assistance - but I cannot
> guarantee that the trust will not be abused either accidentally or with
> malicious intent.
The assisted person can install (technical, social, judicial)
precautions sensible for the given situation. Remember there is the last
sentence of 2.5. (The wording of Bennys proposal would also allow for this.)
> In many cases one also finds that someone other than the user may set up
> the certificates (and hence the keys!)
That is something people work hard on to teach people other approaches.
When I help someone to set up some certificates or keys (friends,
family, crypto party, ...) I help them through the process, but I never
touch the sensible stuff myself - and if they for example try to tell me
a PW, they have to change it afterwards. People around me know this, and
appreciate this approach. My mother for example knows that she has
sensible information that should be kept secure even from me.
In our principles we write that we value education high.
So why do you suggest that we should answer ignorance with watering up
our ideas instead of trying to educate how to do it correct?
> It
> took me about four minutes to find out how to do this and to extract my
> keys from what Microsoft claimed was "secure storage" when I switched my
> CAcert mail onto a Thunderbird variant!
If you did it with your own account this should be easy - sharing a
computer is not the same as sharing an account on a computer.
>>>> Accounts do not cost anything, one even can have multiple ones for
>>>> different contexts or whatever.
>>> I actually have greater issues with this than with "sharing" - whatever
>>> we may decide that means. I'll leave that as a matter for another day
>>> though.
>> It is already there and nobody suggested to change it. IMHO It is
>> probably
>> one of the best parts of the CCA.
> It's both very good and very bad at the same time. Given that we are
> assuring identity, we should probably be looking at the identity being
> the "account" as it becomes easy to abuse otherwise - there's at least
> one arbitration about abuse of multiple accounts including "cross
> assuring" - it's wrong, it's against the rules but I am not aware of any
> active checks being made to prevent it happening.
Well you cannot assign an email to two accounts - and you cannot just
free an email from one account. Sure you can get another email for
another account quite fast.
Everything else probably an issue for an Auditor. But at least we should
be able to identify the person or at least a person who assured the
person. ;-)
> Another possible abuse
> is that of "ballot box stuffing" on eg PolGrp votes - if someone has
> multiple accounts, they can potentially have multiple votes! Again there
> is little if any checking as far as the democratic process is concerned
> (NB Benedikt!)
I know. That is my greatest issue with giving the policy decision to
PolG. But it was an intentional act to do so. And if I ever have a doubt
in this regard I would not hesitate file a dispute to get this checked
somehow and with urgency.
At least they would not have more than vote rightfully, as there is one
vote per member and not per member account. (PoP does not ask for a vote
at all - it asks for rough consensus.
>> No they have not. Not legaly. Neither has EU legislation.
>>
>> Nobody may force me to hand out my private keys under German or EU
>> law. Not
>> even a judge.
>>
>> (Well, at least not any private key that is not stored on a device
>> owned by
>> someone else - so I may have to hand out that device.)
> That's not how it appears to be actually happening - it appears as
> though your country prefers to steal them instead!
That is something quite different - and probably something those other
countries do as well.
But I can try to defend myself against it. Both technically and (if I
learn about it) legally. And with participating in politic processes. At
least I do not have to help them do so. And if I learn that they got
them I may announce it and may try to prevent further damage to other
people.
They may not force me to hand the keys over. They may also not force me
to hand over any diary or something like that. They may force me to hand
over my computer - but they again may not force me to hand over any
credentials stored in my head.
>>> You make sweeping assumptions here as to why people choose to come to
>>> CAcert - I suspect that the vast majority of people don't even consider
>>> them. They may be your reasons - but they are not mine!
>> No. But when I speak about reasons why people joined CAcert recently,
>> this
>> reason is a major one.
> It may or may not be - show me the research and maybe I'll believe it,
Why should I do this? With the same right I could ask you to present
research that people do not join CAcert because of this.
Sure, there are other reasons. But I'm out there at events speaking with
(potential) members. Yes, it's only on the continent, but most of our
members come from here. I've done over 180 (over 200 if you would count
the ones I did not enter because of multiple reasons) assurances since
August and I try to speak with the assurees as part of the assurance
process as it is proposed to do so in the AH.
Sure, that is only about 0,75 of the number of members who joined since
then, and we have all the "old" members as well. But how big is the
basis of your research?
>> Also NSA & Co are by way not the only "persons" whom one can share keys
>> with. There are enough other situations covered by such an addition which
>> would make it worth to have something installed.
> Perhaps you'd care to expand on this - bearing in mind that sharing
> account <> sharing keys.
I think I already wrote enough mails on this.
>> If we do not define something like this, CAcert may be reliable for
>> such a
>> break under continental law for everybody (external) who was relying
>> on the
>> certificates - which is a much greater legal issue than how to treat
>> someone in such a case. And for those external persons probably
>> continental
>> law would apply. Especially as our servers are in NL.
> Not necessarily - it would normally depend on the terms of the contract
> they have - in all cases I believe it falls back to NSW law under either
> CCA or under NRP rules.
Just because we say so?
> What about simplifying it to "You are responsible for all activity on
> your account" and just leaving it at that.
Why?
> The difficulty with the "must not" approach is that you cannot logically
> then make the conseqences explicitly clear at that point.
Sure I can: Up to 1000€ and other penalties awarded against the member
by arbitration.
As stated in 2.2 Liabilities.
--
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
- Re: CCA: open points / comments 2.5, (continued)
- Re: CCA: open points / comments 2.5, Eva Stöwe, 05/27/2014
- Re: CCA: open points / comments 2.5, Alex Robertson, 05/27/2014
- Re: CCA: open points / comments 2.5, Benedikt Heintel, 05/27/2014
- Re: CCA: open points / comments 2.5, Alex Robertson, 05/28/2014
- Re: CCA: open points / comments 2.5, Eva Stöwe, 05/28/2014
- Re: CCA: open points / comments 2.5, Ian G, 05/28/2014
- Re: CCA: open points / comments 2.5, Eva Stöwe, 05/28/2014
- Re: CCA: open points / comments 2.5, Ian G, 05/30/2014
- Re: CCA: open points / comments 2.5, Benny Baumann, 05/29/2014
- Re: CCA: open points / comments, Alex Robertson, 05/27/2014
- Re: CCA: open points / comments, Eva Stöwe, 05/28/2014
- Re: CCA: open points / comments, Alex Robertson, 05/29/2014
- Re: CCA: open points / comments, Ian G, 05/30/2014
- Re: CCA: open points / comments, Benny Baumann, 05/29/2014
- Re: CCA: open points / comments, Alex Robertson, 05/29/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
Archive powered by MHonArc 2.6.18.