From a30a60d192e9c9874fc37ec95855655703dd1cd8 Mon Sep 17 00:00:00 2001
From: Ian Grigg <iang@cacert.org>
Date: Tue, 11 May 2010 05:51:48 +0000
Subject: [PATCH] some semantic tweaks

git-svn-id: http://svn.cacert.org/CAcert/Policies@1897 14b1bab8-4ef6-0310-b690-991c95c89dfd
---
 SecurityPolicy.html | 55 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/SecurityPolicy.html b/SecurityPolicy.html
index a967ed1..79dfa62 100644
--- a/SecurityPolicy.html
+++ b/SecurityPolicy.html
@@ -48,6 +48,7 @@ a:hover {
 <body lang="en-GB">
 
 <ul class="change">
+<li> 20100511: Introduced "Board" term, tightened "approval" semantics, s/wiped/erased/, slight semantic tweaks. </li>
 <li> 20100502: Made 7.3 blank, "refer to SM" </li>
 <li> 20100424: tidied up 9.4 </li>
 <li> 20100422: added 9.3.2 notification requirement. </li>
@@ -95,7 +96,9 @@ These systems include:
      Source code (changes and patches) 
 </li></ol>
 <p>
-Board may add additional components into the Security Manual.
+<span class="strike">Board</span>
+<span class="change">The Committee of CAcert, Inc. (hereafter, "Board")</span>
+may add additional components into the Security Manual.
 </p>
 
 <h4 id="s1.1.1">1.1.1. Covered Personnel </h4>
@@ -304,7 +307,10 @@ are inventoried upon acquisition and tracked in their use.
 
 <p>
 New storage media (whether disk or removable) shall be
-securely wiped and reformatted before use.
+securely
+<span class="strike">wiped</span>
+<span class="change">erased</span>
+and reformatted before use.
 </p>
 
 <h4 id="s2.2.3.2">2.2.3.2 Storage </h4>
@@ -312,7 +318,10 @@ securely wiped and reformatted before use.
 <p>
 Removable media shall be securely stored at all times,
 including when not in use.
-Drives that are kept for reuse are wiped securely before storage.
+Drives that are kept for reuse are 
+<span class="strike">wiped</span>
+<span class="change">erased</span>
+ securely before storage.
 Reuse can only be within critical systems.
 </p>
 
@@ -596,8 +605,9 @@ authorisations on the below access control lists
 
 
 <p>
-All changes of personnel
-to the above lists are approved by the Board of CAcert.
+All changes of personnel to the above lists are
+<span class="change">subject to Board approval.</span>
+<span class="strike">approved by the Board of CAcert.</span>
 </p>
 
 <h4 id="s3.4.3"> 3.4.3. Authentication </h4>
@@ -886,7 +896,7 @@ Board must have a basic plan to recover.
 
 <h3 id="s6.4"> 6.4.  Key Persons List </h3>
 <p>
-Board must maintain a key persons List with all the
+Board must maintain a Key Persons List with all the
 contact information needed.
 See &sect;10.1.
 The list shall be accessible even if CAcert's
@@ -906,7 +916,9 @@ for the security and maintenance of the code.
 
 <p>
 The source code is under CCS.
-Additions to the team are approved by Board.
+Additions to the team are
+<span class="change">subject to Board approval.</span>
+<span class="strike">approved by the Board.</span>
 See &sect;3.4.2.
 </p>
 
@@ -1042,7 +1054,9 @@ See &sect;3.3.
 <p>
 The software interface gives features to Support Engineer.
 Access to the special features is under tight control.
-Additions to the team are approved by Board,
+Additions to the team are
+<span class="change">subject to Board approval,</span>
+<span class="strike">approved by the Board,</span>
 and the software features are under CCS.
 See &sect;3.4.2.
 </p>
@@ -1246,8 +1260,14 @@ All conflicts of interest should be examined.
 It is the responsibility of all individuals to
 observe and report on security issues.
 All of CAcert observes all where possible.
-It is the responsibility of each individual to resolve it satisfactorily,
-or to ensure that it is reported fully.
+It is the responsibility of each individual to resolve
+<span class="strike">it</span>
+<span class="change">issues</span>
+satisfactorily,
+or to ensure that
+<span class="strike">it is</span>
+<span class="change">they are</span>
+reported fully.
 </p>
 
 <p>
@@ -1285,14 +1305,17 @@ especially of new team members.
 <h4 id="s9.2.1"> 9.2.1.  Root Key generation</h4>
 
 <p>
-Root keys are generated only on instruction from the Board.
+Root keys are generated only on instruction from <span class="strike">the</span> Board.
 They must be generated to a fully documented and reviewed procedure.
 The procedure must include:
 </p>
 
 <ul>
    <li> Use of hardware built securely for the purpose
-        only and cleaned/wiped/destroyed immediately afterwards. </li>
+        only and cleaned/
+<span class="strike">wiped</span>
+<span class="change">erased</span>
+/destroyed immediately afterwards. </li>
    <li> Dual control over all phases, including by Board. </li>
    <li> Strong collection of primary entropy, separated from use of entropy. </li>
    <li> Test cycles of the process on the day. </li>
@@ -1327,7 +1350,7 @@ Recovery must only be conducted under Arbitrator authority.
 <h4 id="s9.3.1"> 9.3.1.  Responsibility</h4>
 
 <p>
-The Board is responsible to the Community to manage
+<span class="strike">the</span> Board is responsible to the Community to manage
 the CA at the executive level.
 </p>
 
@@ -1355,8 +1378,8 @@ and becomes your authority to act.
 Components may be outsourced.
 <span class="strike">
 Team leaders may outsource non-critical components
-on notifying the Board.
-Critical components must be approved by the Board.
+on notifying <span class="strike">the</span> Board.
+Critical components must be approved by <span class="strike">the</span> Board.
 </span>
 Any outsourcing arrangements must be documented.
 All arrangements must be:
@@ -1388,7 +1411,7 @@ All arrangements must be:
 <p>
 Contracts should be written with the above in mind.
 <span class="change">
-Outsourcing of critical components must be approved by the Board.
+Outsourcing of critical components must be approved by <span class="strike">the</span> Board.
 </span>
 </p>
 
