Policy-Discussion

[Benny Baumann <benbe AT cacert.org>]

Hi Alex,

glad we use such short mails for the discussion ;-)

Am 27.05.2014 21:50, schrieb Alex Robertson:
>
> On 27/05/2014 15:36, Eva Stöwe wrote:
>> Dear Alex,
>>
>>> Including the death of a member as a trigger is sufficient to meet that
>>> demand.
>>>
>>> However then leaving it with a non-existent  policy as to what the
>>> response to that trigger should be negates that.
>>>
>>> Therefore please either define the subsidiary policy - or leave the
>>> current text alone (or put it into in a "stub" policy) - you can always
>>> come back to it later.
>
> 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.
>
>
>> 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.
>
>>>> There is also no reason for sharing of an account (assisting someone
>>>> with the access for example because of medical reasons is not
>>>> sharing!).
>>> Hmm... then perhaps what YOU mean by "sharing" is not what I
>>> mean.... so
>>> warrants clarification. If anyone else has access to the account or to
>>> the machine, the account's security  becomes questionable. This could
>>> (I'm not saying it will!) easily occur in the example above or in the
>>> case of multiple users on a single machine or even in the case of the
>>> theft of a machine.
>> No.
>>
>> a) Sharing a machine is not sharing an account.
> Agreed - with the proviso that we are talking about accounts here.
> Sharing a machine leaves things like keys at keast potentially accessible
You don't make sense.

Let's retry in simple english:
Sharing (providing unlimited access) to a maschine (computer, notebook,
tablet, $device)
is not
Sharing (providing unlimited access) to a (CAcert) account (the thing
you log into to get your certificate).
>> b) Sharing is something intentional, theft is not - at least if one
>> takes
>> some sensible precautions
> Agreed - although there may also be an element of force upon the
> account holder to share.
Sharing your private key might consist of voluntarily handing me your
private key.
If somebody is asking you to provide your private key by pointing a gun
to your head can with very high confidence be interpreted as not being
voluntarily.
>> 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.
Depending on how you provide the access you can be quite sure. Four eye
principle and yourself entering any authentication if possible. There
are other precautions, but those two already nail quite a bit of basic
protection you CAN do if you need assistance.
> In many cases one also finds that someone other than the user may set
> up the certificates (and hence the keys!) - typically a family member
> and this may include setting up the account for them.
If in the family this is consented on that $IT-cousin is managing things
for everyone and does anything IFF (IF AND ONLY IF) he has consent of
that owner there is little issues with $IT-guy assisting here. If
$IT-guy furthermore requires the actual account holder to enter
passwords for logins this is even better - as we then again have the
"assists" case of above.
> It's not quite "sharing" but it is getting very close to it in that
> the account holder may have little or nothing to do with the actual
> account.
If the holder consents into the accounts management by someone else he
takes on the responsibility for that person acting in his own will and
his will only.

If the holder did not consent into the account's creation it's a CCA
violation and the person creating the account is liable.
> However the moment a machine is shared any *keys* on it are
> potentially vulnerable (So are stored passwords!).
However the moment a car is shared any *luggage* stored in the trunk is
potentially vulnerable (So are the reserve wheels!).
> Bear in mind that many people are not technically familiar with what
> goes on "behind the scenes" and that it is relativly trivial to get
> keys out of a Windows system. 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!
No comment on Microsoft and security - I work with this all day.
>>>> It would contradict the ideas of our accounts, the definition of a
>>>> member in CCA and the idea of AP. It also contradicts our privacy and
>>>> security ideas of not sharing personal information (in the case of
>>>> assurances) and to keep precautions that someone else can impersonate
>>>> oneself.
>>> This comes back to 2.5 as it stands - "reasonable precautions"
>>> should be
>>> taken by an account holder.
>
>>>> 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 - 
That's the intention.
> there's at least one arbitration about abuse of multiple accounts
> including "cross assuring" -
Cross-Assuring is a different story, as it's the opposite side of
sharing - and we IIRC have a clear line on multiple accounts for one
"identity".
> it's wrong, it's against the rules but I am not aware of any active
> checks being made to prevent it happening.
Your are welcome to suggest them.
> Another possible abuse is that of "ballot box stuffing" on eg PolGrp
> votes  - if someone has multiple accounts, they can potentially have
> multiple votes!
If in doubt people will check and recount the result accordingly or
initiate other steps.
> Again there is little if any checking as far as the democratic process
> is concerned (NB Benedikt!)
Be the first to suggest such checks.
>
>>>>> 2.5b Various countries - certainly including UK and US (and I
>>>>> think AU)
>>>>> have legislation in place that can enforce surrender of keys
>>>>> allegedly
>>>>> for anti-organised crime and anti-terrorism reasons in their
>>>>> legislation. Given this, *I'd prefer not to add such a clause*,
>> although
>>>>> I could "live with it under protest". If such a clause is put in
>>>>> place,
>>>>> I'd suggest that this perhaps needs to be considered, and that
>> direction
>>>>> be given to clarify what action a member of the community should take
>> it
>>>>> it did. I also think we would be on "dodgy ground" if such
>>>>> legislation
>>>>> applies to NSW-AU as we take that as our "governing law"!
>>>> Those laws are part of the reason why people not living there (and
>>>> probably also people living there) come to CAcert for certificates,
>>>> because it is one of the few CAs not based in the USA so that such
>>>> laws
>>>> are not the basis of the CA. And our RA is spread out so that it
>>>> cannot
>>>> be affected as easily by such laws.
>>> Even in Germany you are likely to be affected by this - there are
>>> various German organisations that may have this type of power (BfV and
>>> BND come to mind) and there is a considerable amount of EU legislation
>>> that's at least related as well.
>> 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!
Citeing Aldous Huxley and George Orwell when referring to the situation
in UK might seem ironic at best.
>
> Instead of doing it openly, the German authorities seem to prefer to
> sneak spyware onto the machines of people that they are interested
> in.see
> http://www.globalresearch.ca/germany-calls-for-less-democracy-police-caught-planting-spyware-on-personal-computers/27107
> as one discussion - this has been going on for years and is still
> continuing with allegations that a new improved version of
> state-sponsored malware will be out sometime this year. It's probably
> illegal, it's probably against the German consititution but it is
> (allegedly) still going on with some degree of "official blessing".
Part of my open disconsent is because of exactly THOSE unconstitutional
operations officials are performing. There's that unfortunate habbit of
the constitutional court having to remove all those weeds on a regular
basis. It's not the first time I was taking part in removing such
unconstitutional laws and rules. And I'll keep on fighting.
>>> 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,
One quite good indication is a sharp increase in dayly account
registrations which mostly aligns with the release of NSA documents.
Might be coincidence, but about double the number of accounts registered
per day then the month before ...
>> If you just want to have free certificates there are other - more
>> professional CAs that even are in the browsers.
> There are certainly other organisations out there - I am not in a
> position to judge whether they are "more professional" - there are
> certainly organisations that are regarded as "reputable"
>>> Regardless of that, it makes no difference to the individual - they are
>>> still subject to the laws of their land, whether you like that or not.
>>> The CA doesn't hold the keys, the individual does. The only choice the
>>> individual will have if their keys are demanded by a competent legal
>>> authority in their country is to either comply with the law  and break
>>> CAcert's rules as proposed or to face fines or jail for breaking the
>>> law. This is the place to make that clear and possibly to provide
>>> explicit guidance.
>> This may be the case. And there even may be people who will decide
>> one way
>> or the other or destroy the keys or whatever.
>>
>> The consequences of such action from the point of view of CAcert
>> would have
>> to be decided by an arbitrator who would cosider the whole situation and
>> decide based on that.
>>
>> 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.
Some situations have been discussed in the side discussion before.
>> 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.
>>> As far as I am concerned, 2.5 works reasonably well as it stands and
>>> thus is in no real need of change!
>> As I said in the side-discussion. The fact THAT you read that above
>> sharing
>> is currently allowed is the reason why I think that it does not work.
>> Else
>> I would agree with Benedikt.
> I personally don't think account sharing is currently allowed because
> of the "reasonable precautions" clause if nothing else - but, due to
> human nature, it does happen and it will continue to happen whatever
> we may decide upon - this point was made by IanG quite strongly in the
> side-discussion.
>
> We are unlikely to find out that this has happened until/unless
> something goes wrong at which point we are "stuck with it" and
> Arbitration has to sort it out hence my preferred phrasing "You should
> not share your account but if you do you are responsible for all
> activity based on that account" as it makes it totally clear who is to
> be held accountable.
RFC 2119 ... The word you are looking for is MUST NOT ... Using SHOULD
NOT, SHALL NOT, OUGHT NOT or anything else you are allowing the sharing
if the user has a "good reason" ("my little puppy otherwise would have
died of cancer if I didn't forward my account credentials to the NSA")
and the second part of your sentence would become ineffective.

If you want to play realistic use RFC 6919 additions to those previously
defined by RFC 2119 and you probably cover it up to satisfaction.
> What about simplifying it to "You are responsible for all activity on
> your account" and just leaving it at that.
You already are - and that's not the point of the addition that is to be
added.
> The difficulty with the "must not" approach is that you cannot
> logically then make the conseqences explicitly clear at that point.
Actually ... no. "You MUST NOT kill somebody. Otherwise you MUST face at
least N years in jail."
> (Most criminal law is based on the concept that you should not do
> certain things but if you do there are likely to be consequences -
> "you should not murder your neighbour - but if you do, you may face
> the death penalty"
Back to RFC 2119: You SHOULD NOT murder your neighbour - but if you do,
you MAY face death penalty. Does not make to much sense - especially if
you use the weakest intepretations allowed by RFC 2119. Using the MUST
interpretation from above this is much more logical.
> Regards
>
> Alex
>
Regards,
BenBE.

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