Policy-Discussion

[Grégoire Sandré <gregoire.sandre AT free.fr>]

Dear Eva,

I understand your points. 

The idea that I tried to write down is: if, for instance, a member connect to 
his Cacert account from a fully rotten cyber-coffee system and, thru a CaCert 
site vulnerability, transforms the site to a malware distribution point, this 
member should be accountable of what she/he did.

I do not think this kind of risks is covered, at this time, by the CCA or 
other Cacert document that I read. 

Regards.

Grégoire 



> -----Original Message-----
> From: 
> cacert-policy-request AT lists.cacert.org
>  [mailto:cacert-policy-
> request AT lists.cacert.org]
>  On Behalf Of Eva Stöwe
> Sent: Wednesday, May 14, 2014 9:50 PM
> To: 
> cacert-policy AT lists.cacert.org
> Subject: Re: collection of current proposals for CCA: 2.5
> 
> Dear Grégoire,
> 
> Am 14.05.2014 01:13, schrieb Grégoire Sandré:
> > Dear Eva,
> >
> >> "2.5  Security
> >>
> >> CAcert exists to help you to secure yourself. You are primarily
> responsible for your own security. Your >security obligations include
> >> 1. to secure yourself and your computing platform (e.g., PC),
> >> 2. to keep your email account in good working order,
> >> 3. to secure and not share your CAcert account (e.g., credentials such
> as username, password),
> >> 4. to secure your private keys,
> _ensuring_attributability_to_their_intended_context,
> >> 5. to review certificates for accuracy, and
> >> 6. when in doubt, notify CAcert,
> >> 7. when in doubt, take other reasonable actions, such as revoking
> certificates, changing account >credentials, and/or generating new keys.
> >>
> >> Where, above, 'secure' means to protect to a reasonable degree, in
> proportion with your risks and the risks >of others."
> >
> > I can only support what I understand as (4), the addition of care for
> non-repudiation and accountability in this security part. If I was able to
> do it, I would reword it as this phrase did not sound to me as clear as
> other parts of the CCA, but I did not find better.
> 
> 
> >
> > I propose to append something about requiring to take reasonable actions
> to not threat security of Cacert assets. I could have missed it, but did
> not find it in CCA. As a base I propose,
> >
> > "Your security obligations also include taking reasonable actions to not
> increase threat level on means provided by Cacert."
> 
> I do not agree to this.
> 
> First it is not CAcert or CAcerts assets that this addition should
> primary protect, at least when (external threats) are to be considered.
> 
> The other members who want to rely on secure / private communication
> channels should be protected in the first place. This can also affect
> interests of CAcert itself. But Primary the other members are the focus.
> At least from my perspective.
> 
> And as I understood Benedikt in a side-chat we had to clarify this
> points correctly, this is one point that may not be agreeable.
> 
> 
> But there is something else that I cannot agree to with your
> formulation. It's each usage of a certificate is connected with a risk.
> That is why we put so much time into fixing the R/L/O. We even define
> risks and liabilities and all.
> 
> I think, you should be allowed to use certificates where it makes a
> difference and where there may be others who do not like this and take
> actions against this, which may include actions to gain or compromise
> your keys. (Which may actually be nearly anything, nowadays.)
> 
> 
> Also we were talking about active disclosure of keys. But "taking
> [reasonable] actions to not increase threat" is not the same as "not
> taking actions to increase threat" which is the thing we were talking
> about.
> 
> 
> --
> 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