Policy-Discussion

[Ian G <iang AT cacert.org>]

On 24/03/2010 08:38, Dieter Hennig wrote:
> Dear Ian,
>
> can I ask two newbie questions?

Sure, someone once said the only bad question is the one not asked :)


> There are five types of persons (or team-members)
>
>    Access Engineers,
>    Support Engineers,
>    Systems Administrators,
>    Software Assessors,
>    Application Engineers.
>
> Is somewhere to find a list, who is who? And exist a team, which is empty?


Each team leader would be responsible for that I guess.  We haven't 
formalised it to that extent, we've been concentrating on building the 
teams.  Support Team Leader keeps a list on wiki;  Access Engineers and 
Systems Administrators are listed in the old Oophaga MoU.



> What would happen, if we would have a very specific policy, but no
> people in the groups? If the Application Engineer group would have no
> members, than there is no software update, right?

If there is no Application Engineer in the team then the Critical 
Systems Administrators cannot get access.

If there are no Software Assessors, then there is no way to do changes 
to the software.  This was the headache we had in the past, we recently 
approved a second Software Assessor, and hopefully there are more on the 
way.


> And maybe a second question about the following up duties? If we change
> SP, we have to change SM too?


SM follows SP, so a chance in SP might impact SM, yes.

> As an example, please look to point 3.4.2, one (SP) quoted about five
> lists, the other one (SM) quoted only three. And with different names.
>
> SP states
>
> <<
> 1.4.2. The Security Manual (Practices) Document
>
> (1) This Policy explicitly defers detailed security practices to the
> Security Manual ("SM"), The SM says how things are done. As practices
> are things that vary from time to time, including between each event of
> practice, the SM is under the direct control of the Systems
> Administration team. It is located and version-controlled on the CAcert
> wiki.
>
> (2) Section Headings are the same in both documents. Where Sections are
> empty in one document, they are expected to be documented in the other.
> "Document further in Security Manual" can be implied from any section
> heading in the Policy.
> > >
>
> (I introduce some numbering to guide to the sentences.)
>
> Subparagraph (1) is not fulfilled, because SP is more detailed than SM
> in this point.


In that there are two "missing" lists?  Sure, that would look like an 
omission.  To go further depends on what hat we are wearing:

Policy hat:  well, as long as the policy is what we the policy group 
want, then we're fine.

Audit hat:  where's those lists then?

Board had:  (a) complicated, because we want to do a complete review of 
this area as SP has changed the relationship between Oophaga and CAcert, 
and that effects the 1st two lists.

(b) the repository list is probably a work in progress (see that blue 
stuff) and the people working on the software team rebuild will get to 
it in due course.


> Subparagraph (2) is also not fulfilled, because is not empty in SP.


Not sure I follow that one ... Heading 3.4.2 has content in both SP and SM.

> Have I oversee something?


You've certainly spotted some questions ... however note that in the 
policy group, we are mostly concerned with making sure we have a good 
policy.  It's the job of others to take that policy and implement it. 
We might give them a few hints tho ;-)



iang


> Ian G schrieb am 22.03.2010 22:13:
> > According to PoP, a policy can only be in DRAFT for a year ...
> >
> > Security Policy reaches this milestone this Saturday, following p20090327.
> >
> > https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html
> >
> > Now, there are some marked up suggestions in BLUE that have not been
> > voted upon.  These basically add an "Application Engineer" who is
> > responsible for the application.  We would need to make a bit of a
> > decision here as to which way we want to go.
> >
> > 1.  Keep SP in DRAFT for another period, and
> >      re-work those BLUE sections.
> >
> > 2.  Accept the BLUE, and go to POLICY.
> >
> > 3.  Discard the BLUE as not voted, and go to POLICY.
> >
> > 4.  Or?
> >
> >
> >
> > What do policy group people vote for?
> >
> >
> >
> > iang
> >
> > PS: Green should disappear.

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