Subject: Policy-Discussion
List archive
- From: Daniel Black <daniel AT cacert.org>
- To: cacert-policy AT lists.cacert.org
- Subject: Re: Modification of SP
- Date: Thu, 1 Apr 2010 07:56:09 +1100
- Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none
- Organization: CAcert
On Thursday 01 April 2010 07:43:54 Mark Lipscombe wrote:
> On 4/1/2010 6:42 AM, Pieter van Emmerik wrote:
> > Hi all,
> >
> > As the board of CAcert consists of persons elected by members of CAcer
> > association I do not think they should have the requirement of a
> > background check except when they want to get access to critical systems
> > or sensitive information.
> > They form a political function and as such qualify because the have been
> > elected by association members.
> > Granting access to sensitive resources is not the same as having access
> > to those resources.
> > If board members want to have access to critical or sensitive data the
> > of course the also have to be background checked.
> > Granting access is more a administrative and/or political action.
> > If in that process no access to critical systems or sensitive data is
> > needed, a background check is unnecessary.
> > For comparison: in a company which handles secret information, the
> > people handling that secret information will need to have a government
> > issued security clearance, however the management that hires them do not
> > necessarily need to have a security clearance as the do not access
> > classified information themselves.
Same case for CAcert - arbitration does the assessment independently of the
board appointment of critical roles.
>
> Pieter's message sums up my opinion also on the proposed change.
>
> I would also add that the board has existing obligations to "do the
> right thing" that exceed any penalties that may be meted out other
> members of the community, including custodial penalties in the most
> extreme circumstances.
>
> Regards,
> Mark
agree with both sentiments here. The appointment of people isn't a security
sensitive function.
--
Daniel Black
CAcert
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
- Modification of SP, Philipp Dunkel, 03/31/2010
- Re: Modification of SP, Peter Williams, 03/31/2010
- Re: Modification of SP, Pieter van Emmerik, 03/31/2010
- Re: Modification of SP, Mark Lipscombe, 03/31/2010
- Re: Modification of SP, Daniel Black, 03/31/2010
- Re: Modification of SP (And Road-Map), Philipp Dunkel, 03/31/2010
- Re: Modification of SP (And Road-Map), Mark Lipscombe, 03/31/2010
- Re: Modification of SP (And Road-Map), Philipp Dunkel, 03/31/2010
- Re: Modification of SP, Daniel Black, 03/31/2010
- Re: Modification of SP, Mark Lipscombe, 03/31/2010
Archive powered by MHonArc 2.6.16.