Arbitrations/a20110118.1

Case Number: a20110118.1
Status: running
Claimants: MichaelTänzer (Support t/l), Marcus M (OAO)
Respondents: CAcert
Initial Case Manager: UlrichSchroeter
iCM2: AlexRobertson
Case Manager: MartinGummi
Arbitrator: UlrichSchroeter
Date of arbitration start: 2011-01-18
Date of ruling: 201Y-MM-DD
Case closed: 201Y-MM-DD
Complaint: requests List of Admins, request list of TTPadmin's, identify all organisation administrators that are not CAcert assurer
Relief: TBD

Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: MichaelTänzer (C) Marcus M (C2), Case: a20110118.1

History Log

2011-01-18 (issue.c.o) case [s20110118.95]
2011-01-18 (iCM): added to Wiki, request for CM / A
2011-01-18 (CM): I'll take care about this case as (CM)
2011-01-18 (A): I'll take care about this case as (A)
2011-01-18 (C): accepts CCA/DRP under this arbitration in dispute filing mail.
2011-02-06 (A): discussions with (SA), (Critical Sysadmin t/l) regarding this case at Fosdem
2011-02-22 (A): Intermediate Ruling and Exec request sent to (C) + (Critical Admins)
2011-02-22 (Critical Admin): exec report sent to (C), (A), (CM)
2011-04-10 (C): asks who can view list sent by (Critical Admin) by intermediate ruling
2011-04-10 (Mario): proposal for who can view list of members for a list of flags
2011-04-10 (A): response to (C), (Mario): matches the proposal under Discovery_II
2011-04-10 (A): intermediate ruling #2, sent to (C), (board-private)
2011-04-10 (Mario): When do we get the list?
2011-04-10 (C): sends the list as requested by (Mario) to group (board)
2011-12-13 (C): report to intermediate ruling #1 and #2, fixed in role as SE t/l
2011-12-13 (C): Discovery II discussion within Software-Assessment project team meeting 2011-12-13
2012-03-26 (issue.c.o) case s20120326.67
2012-03-26 (A): added to Wiki, merged with this running case
2012-03-26 (A): CCA/DRP acceptance by (C2) is given in critical role as (SE) (see a20101201.1)
2012-03-27 (A): made some tests on testserver cacert1.it-sls.de with flag settings ttpadmin=1 and board=1, results reported under bug #855
2012-03-27 (A): request to (C2), to do the same tests and confirm or reject (A)'s findings
2012-03-27 (C2): sent first test report (in German), confirms (A)'s findings: ttpadmin=1 allows TTP-assisted-assurances, board=1 not.
2012-03-29 (Critical team): [cacert-systemlog + cacert-devel mailing list] patch bug #1003 applied to critical system. Asks for times the script should be scheduled.
2012-03-29 (C): recommendation about possible scheduling to (Critical team) and other recipients
2012-03-30 (A): reminder to arbitration participients (C), (Critical team) regarding running arbitration case a20110118.1 and reference to intermediate ruling dated 2011-02-22
2012-03-30 (Critical team): exec report and report on configuration changes regarding permissions review script
2012-03-30 (SE): phone call to (A): board flag cannot be removed under admin console
2012-03-31 (Support ML): complain by a member who received a permissions review report with Tverify flag set
2012-04-01 (A): requesting infos from Software-Assessors regarding Tverify and Board flag setting in member accounts
2012-04-03 (A): question to (OAO) if he received the permissions review script results for area OA? (flags: orgadmin, ttpadmin)
2012-04-03 (A): question to (AO) if he received the permissions review script results for the Assurance area(s)? (flags: ttpadmin, tverify, board, orgadmin?)
2012-04-03 (A): question to (Support t/l) if he received the permissions review script results for the Support area? (flags: locadmin, admin)
2012-04-03 (A): question to (C) (in role as board member) if he received the permissions review script results for the Support area? (flags: locadmin, admin)
2012-04-03 (AO): response to questions. No reports received. One board member forwarded an email.
2012-04-03 (OAO): response to questions. Rcvd Orgadmin report, didn't rcvd TTPadmin report
2012-04-03 (Support t/l): response to questions. Rcvd Admin report, didn't rcvd LocAdmin report
2012-04-03 (Board member, SE): response to questions. Rcvd * flags in board-private, rcvd Admin direct
2012-04-03 (SA): response to (SA) question(s): Flags and Special Assurance methods
2012-04-06 (SA2): response to (SA) question(s): infos about tverify admin flag
2012-04-12 (SA3): response to (SA) question(s)
2012-04-12 (issue.c.o) case s20120412.21
2012-04-29 (A): intermediate ruling #3
2012-04-29 (A): intermediate ruling #3 sent to: (C), (Board), (OAO), (AO), (Critical team), (Secretary), (Support t/l), (CM)
2012-04-29 (A): bug #1003 note added regarding intermediate ruling #3 (Exec Quick Summary #1)
2012-04-29 (A): sending notification to (Support t/l), (OAO), (AO) regarding intermediate ruling #3 (Exec Quick Summary #2)
2012-04-29 (A): question to (Critical team), (C): if we can quickly deploy a flag removal script regarding intermediate ruling #3 (Exec Quick Summary #3)
2012-04-29 (C2): [s20120412.21] new dispute filing: identify all organisation administrators that are not CAcert assurer
2012-04-29 (A): merging s20120412.21 with this case
2012-04-29 (A): question to (SA2), (C): what was the digitial Id doc scan directory store in the webdb?
2012-04-30 (SA2): forwards code lines from tverify/index.php indicating /www/photoid the directory of digitaly stored Id doc scans in webdb
2012-05-01 (A): request to (Board), (Critical team), (SA3), (Teus): exec report or infos regarding removal of digitaly stored Id doc scans in webdb from tverify program
2012-05-01 (Critical team t/l): response to digitaly Id doc scan copies on critical system - exist, critical team started Oct 2008
2012-05-01 (Iang): clarification to board motion m20080422.3, no exec report received, ask if question sent to board-private can be disclosed
2012-05-01 (Piers): new board motion placed (pending): motion m20120501.1 "Removal of copies of ID and identification number information from archives"
2012-05-01 (dirk): "if we now delete the id-documents, CAcert will not be able to track these members in case of arbitration."
2012-05-01 (A): intermediate ruling #4
2012-05-01 (A): intermediate ruling #4 with exec request sent to: (C), (C2), (Board), (Critical team), (Critical team t/l), (Secretary), (SA2), (Iang), (dirk), (CM)
2012-05-02 (Critical team): exec report to intermediate ruling #4 sent to: (C), (C2), (Board), (Critical team), (Secretary), (SA2), (Iang), (dirk), (CM)
2012-05-02 (Critical team t/l): reply to (Iang) mail
2012-06-21 (SA): sent patch request bug #1003 to (Critical team)
2012-06-21 (Critical team): patch bug #1003 installed on critical system, permission reset script ready to be executed
2012-06-23 (A): Intermediate ruling #5, sent to (Critical team), (C1), (C2), (AO), (OAO), (Board), (CM)
2012-06-23 (Critical team): exec report regarding intermediate ruling #5
2012-06-27 (C2): note and extended intermediate ruling proposal request regarding intermediate ruling #5
2012-06-27 (A): Intermediate ruling #6, sent to (C1), (C2), (AO), (OAO), (Board), (CM)
2012-10-21 (14:58) (SE): Marcus Mängel moved a ticket s20121021.322 into Disputes, this is a dupe dispute by (C2) of 2012-04-12 (issue.c.o) case s20120412.21
2012-10-21 (15:15) (iCM2): transfered c to disputes queue
2012-10-21 (15:20) (A): notification to (C), (C2), (CM), (Arbitration mailing list), that [s20121021.322] still disputed under Arbitration a20110118.1 by (C2) himself
2012-10-21 (15:40) (iCM2): sent notification to (Arbitration mailing list), (C2) as new Arbitration case a20121021.1
2012-10-21 (16:14) (iCM2): Request for clarification regarding Arbitration case a20121021.1 to (C2), (A), (ArbML)
2012-10-23 (C2): response to (iCM2) (others?) about request from (iCM2) (documentation under a20121021.1)
2012-10-23 (A): had some talk with (C2), (C), (CM) and others in Software-Assessment project team meeting 20121023 under Minutes 1.3, identifying and clarification of a20110118.1 (current case) intermediate ruling Part IV.2. referenced software bugs/patches: bug #967, bug #512
2012-10-23 (SA t/l): (who is also (C) in current case): passes the SQL query proposal under [s20121021.322], tested, to (Critical team) following intermediate ruling #4, part IV.2
2012-10-24 (iCM2): closed case a20121021.1 by request of (C2) with notification to (C2), (A), (ArbML)
2012-10-24 (Critical team): response to exec request of SQL query sent by (SA t/l) following intermediate ruling #4 part IV.2. Result sent to (C2) in role as (OAO)
2012-10-24 (C2): phone call with (A), some talks about further processing
2012-10-24 (C2): sent short email notice regarding rcvd report from (Critical team) to (CM), (A)
2012-10-25 (A): completed documentation on current case. Checked that a reference was set under a20121021.1 to current case that includes further processing and documentation about (C2)'s request, dupe dispute filed under [s20121021.322]
2013-01-17 (Critical team): exec report of bug #512 "Org admins must have 100 points" implementation -> oa-mailing
2013-02-26 (SA): ADadmin in permissions review script is missing (identified in Software-Assessment project telco 2013-02-26
2013-03-12 (A): Intermediate ruling #7, sent to (C1), (C2), (Board), (CM)
2014-05-11 (CM): asks A about progress in this case

Original Dispute, Discovery (Private Part) (optional)

Arbitration case a20110118.1 (Private Part)

Discovery

There are several questions to answer:
1. Is Support t/l allowed to request a list of SE's defined in the system ?
  1. This question seems to be simple, but needs a review
2. Is Board allowed to request such a list of SE's defined in the system ?
  1. same as question before
3. If Board and/or Support t/l is allowed to request a list of SE's defined in the system, is there a definition in policies, that this is a system task, Board and / or Support t/l has to do on a regular basis ? (-> Responsibilities)
4. Is there a system integration available, that SE can execute ? eg knowledgeable OA hidden script
5. If there isn't a software integration available, can this and should this be possible ? (-> Responsibilities?)
6. If this should become a responsibility task, where should it be documented, escalated ?
  1. query result
  2. process definition (Policy ? Procedures?)
7. What's about account clean up tasks ? (special flags are account related flags)
  1. Who is responsible ?
  2. Who executes this ?
  3. Are there leaks in the process flow ?
Ad hoc SQL queries needed to be executed by Critical Sysadmins
- SP DRAFT p20100510:
  - 3.3. Application [3] - Requests to systems administration for ad hoc queries over the database for business or similar purposes must be approved by the Arbitrator.
Policies relating to this case
- Security Policy (SP) (DRAFT p20100510) in SVN
- Security Manual (SM) in Wiki

Applicable SP parts

Additional locations on Security related procedures
- 1.4.3. The Security Procedures
  - The team leaders may from time to time explicitly defer single, cohesive components of the security practices into separate procedures documents. Each procedure should be managed in a Wiki page under their control, probably at SystemAdministration/Procedures. Each procedure must be referenced explicitly in the Security Manual.
3.3. Application (Ad hoc queries)
- Requests for ad hoc queries over the application database for business or similar purposes must be approved by the Arbitrator.
3.4. Access control
- All access to critical data and services shall be controlled and logged.

3.4.2. Special Authorisation

List Name	Who	Purpose of access	Relationship	Manager
Support Access List	Support Engineer	support features in the web application	exclusive with Access Engineers and Systems Administrators	Support team leader

All changes of personnel to the above lists are subject to Board approval.

Support Access List is defined in the Wiki:
- Support Team page is empty and relates onto the Wiki restructure project end 2009
- Support Team current and active, with Triage and Support-Engineer members

3.4.4. Removing access

Follow-up actions to termination must be documented. See §9.1.7.

 9.1.7. Termination of staff

Termination of access may be for resignation, Arbitration ruling, or decision of Board or team leader. On termination (for any reason), access and information must be secured. See §3.4.4.

The provisions on Arbitration survive any termination by persons fulfilling a critical role. That is, even after a person has left a critical role, they are still bound by the DRP (COD7), and the Arbitrator may reinstate any provision of this agreement or bind the person to a ruling.

Critical Role is e.g.: Support-Engineer (Admin Flag), but not Organisation-Assurer (O-admin flag)

2011-02-06 (A): discussions with (SA), (Critical Sysadmin t/l) regarding this case at Fosdem
- Q: Is one of the tasks for the Critical Admin to check flag settings in the database ?
  - A: No
  Q: Who should check or order check by e.g. Support of flag settings on a frequent basis ?
  - A: t/l
  Q: Can this be installed as a program? e.g. cron job, every quarter ?
  - A: yes
  Q: Who should receive the results of such reports ?
  - A: depends on security infos

Potential flags in the Database to check (from CAcert Software Database Structure Defined

Table: Users (Contains one record for each registered user.)

listme	int(1)	1 if published in Assurer List
codesign	int(1)	1 if allowed to request code signing certs
1024bit	tinyint(1)	?
admin	tinyint(1)	1 if user is admin
ttpadmin	tinyint(1)	1 if user is TTP admin, it allows to set the Assurance Method to "Trusted 3rd Parties" and leave some of those checkboxes on the Assurance page unchecked. It does not allow to issue more than the usual maximum points
orgadmin	tinyint(1)	1 if user is Org admin
board	tinyint(1)	1 if user has additional privileged of CAcert's board. In addition with ttpadmin allows to set all Assurance methods ("Face to Face Meeting", "Trusted 3rd Parties", "Thawte Points Transfer", "Administrative Increase", "CT Magazine - Germany"). Allows issuance of temporary increases if a sponsor (another user with board-flag set) is named.
tverify	tinyint(1)	1 if user is tverify admin (?)
locadmin	tinyint(1)	1 if user can administer the location database
adadmin	tinyint(1)	1 if user may administrate advertisement (?)
assurer	int(2)	1 if user is Assurer (100 Assurance Points plus Challenge). This field is caching only, if performance does not forbid try to select the underlying data instead.
assurer_blocked	tinyint(1)	1 if user may not become assurer

Potential risky settings combinations (sql query) (see a20100131.1)

# collect total users deleted
SELECT count(id) FROM users where deleted !='0000-00-00  00:00:00';

# collect total users deleted and manual SE delete procedure hasn't been executed
# or were made mistakes (not to reset flags)
SELECT count(id) FROM users where deleted !='0000-00-00  00:00:00' and email not like 'arbitration_a%' and fname not like 'a20%' and (listme=1 or admin=1 or ttpadmin=1 or orgadmin=1 or board=1 or tverify=1 or locadmin=1 or locked=0 or adadmin=1);

Ruling has to be split into 2 parts
1. the requested Ad hoc query
2. a general procedure, that allows easy checking, continuous checking on security issues regarding critical database content
simple query regarding part I of (C)'s request
- ```
select users.fname, users.lname, users.email, users.admin from users where users.admin=1;
```
- lists first and last names and email addresses of users with the admin flag set (so called Support-Engineers with access to the webadmin console)

Intermediate Ruling

Regarding part I of (C)'s dispute filing request, I hereby rule:

That Support t/l is allowed to receive a list of Support team members defined by database record settings as defined under SP 3.4.2. Special Authorisation
The list to contain: the given names, last names, primary email address, admin flag setting (forever 1) of users who has the Admin flag set to 1
This request follows the procedures defined under SP 3.3. Application (Ad hoc queries), to be authorized by an arbitrator
SP 3.4.4. Removing access relates to SP 9.1.7. Termination of staff. How to order or execute removing access if the list of active settings is unknown ? So therefor a query needs to be executed first, to collect the info before processing can start.
The script defined under Discovery H has to be used for executing the Adhoc query.
Further I rule, that Support t/l can request the execution of the script to critical sysadmins under reference to this arbitration case on a recurring basis, based on changes within the team: eg. t/l change, termination of team members, new team members and on a frequently basis not more often than quarterly (so every quarter, every half a year, or yearly is acceptable) to keep track of the defined members by database settings to prevent security issues. The trigger of team changes doesn't influence the recurring schedules.
- eg: a schedule is set to every 1st day of a quarter, and a t/l change happens in the second month, t/l can request the exec of the script. The next recurring exec on 1st of next quarter can be executed regularly.
If the exec report lists users, that are not on the active team members list, Support t/l has to file a dispute following SP 1.2. Principles, 8.1. Authority and SP 9.1.1. Roles and responsibilities
1. to document the issue
2. to get Arbitrators approval for removal of uncertain or undefined team members after discovery
Support t/l can handle immediately (emergency exec) but has to file a dispute for later review
Further I rule, Support t/l should document and add this new security procedure following SP 1.4.3. The Security Procedures so probably later final ruling may link to this new procedure

Frankfurt/Main, 2011-02-22

Discovery II

2011-02-22 results from Software-Assessment Project Team meeting 2011-02-22, Topic 'Security check procedures' - define list of groups, who can see list of flag-owners

Flag	What to show	Who should read results	Remarks
codesigning	count()	public
admin (SE's)	list	board, support, own group
ttpadmin	list	board, support, own group	current ttpadmin's to revoke ?
orgadmin	list	board, support, own group
board	list	board, support, own group
tverify	list	board, support, own group	current state to revoke ?
locadmin	list	board, support, (own group? -> later ?)
adadmin=1	list	board, support, own group	0=not set, 1=submit, 2=approve
adadmin=2	list	board, support, own group	0=not set, 1=submit, 2=approve

count() = counter within statistics
list: defines Givenname, Lastname, email, (country)

Intermediate Ruling #2

As of request by (C), result list from Intermediate Ruling #1 (C) is allowed to distribute the result list within the groups as defined under proposal Discovery_II with user names and email, and addtl. country where its appropriate (eg orgadmin, locadmin)

Frankfurt/Main, 2011-04-10

Discovery III

The "new" TTP-assisted-assurance subpolicy is now in DRAFT since p20100913. The deployment has been started in a team, that find its milestone in the 3 board motions from board meeting 2012-03-18 building the starting team of TTP-assurers. Responsible officers defined in the TTP-assisted-assurance subpolicy are *AO's. This is also documented under the "new" TTP-program documentation. So (C2) is a valid responsible person for the new dispute filing.
The last overview of TTPadmin flag settings has been discovered under Arbitration case a20091118.1 -> 2009-12-05 (A): request to Crit.Sysadmins team of 3 sql queries: ttpadmin=1; board=1; ttpadmin=1 and board=1. This revealed that probably no one has the TTPadmin flag set. The discovery under a20091118.1 also revealed that the board flag setting probably also allows a member to set assurance method "TTP" in an assurance

making 3 tests with 3 test accounts, all 100 assurance points, 50 experience points, assurer flag set. N#1 ttpadmin=1, N#2 board=1, N#3 ttpadmin=1 + board=1 set.

function	ttpadmin=1	board=1	ttpadmin=1, board=1
	user1	user2	user3
assure someone, method TTP	TTP-a-a passed	TTP-a-a not passed, passed with errors x¹	TTP-a-a passed x²

x¹) first error: all 3 checkboxes have to be checked, no TTP assurance option (ok), otherwise error/warning message, second error: assurance method displays <empty> ""
x²) one error: option box lists 4 assurance methods, also Thawte, allows -++ checkboxes selected (ok), method TTP ok

TTP-assisted-assurance can only be passed if TTPadmin flag is set. In combination TTPadmin=1 and Board=1 TTP-assisted-assurance passes. there are bugs if board flag is set only (empty assurance method in case of Assurance)

2012-03-29 (Critical team): [cacert-systemlog + cacert-devel mailing list] patch bug #1003 applied to critical system
- ```
The fix has been installed on the production system on March 29, 2012.
```
- ttpadmin flag is one of the checked flags. report goes to board-private and team members.
- if no one ttpadmin flag is set, no team member will receive this report
- at least board-private should see a list of ttpadmin flags set
- request to patch developer / critical team / board: when will be the first permission check reported? (also requested by critical admin)
  - ```
  Do you have any instructions for the time and frequency at which the
  new permissionreview script should be run?
```
2012-03-29 (C): recommendation about possible scheduling to (Critical team) and other recipients
- https://lists.cacert.org/wws/arc/cacert-devel/2012-03/msg00027.html
2012-03-30 (Critical team): exec report and report on configuration changes regarding permissions review script
- OK, I've executed a manual run, and added a quarterly run to the crontab on the production server.
2012-03-30 TTPadmin flag request does not need an Ad hoc sql query as the results are discovered by the permissions review script (patch bug #1003). The results have to be requested elsewhere (whoever received the result set).

Questions

The permissions review script initial run initiated by (Critical team) now opens some questions that needs answers:
1. have all recicipients that requires the info have received the info to act (request probably removals of permissions)?
2. how does the removal process needs to be installed? Who has permissions to order Support-Engineer to remove flags according to SP?
3. Can a universal procedure be defined? (eg by make a precedent ruling?) or is Board allowed to order removal of flags?
4. Whats about documentation? Nominations follows board motions, does have removals to undergo also Board motions? (easy solution) (eg arbitrator removals has two procedures, one within arbitration team, the 2nd procedure is a recommendation by DRO to place before board and board decides in a motion the removal of an Arbitrator)
5. one result of the initial permissions review script execution, a new dispute has been filed a20120330.1. Does all unforseen issues have to undergo an arbitration?
6. (SE) reported, that board flag cannot be removed from within the admin console

Deliberations

A. Q: have all recicipients that requires the info have received the info to act (request probably removals of permissions)?

Permissions reviewed, Responsible parties, Groups/Officers/Members who received results

      Flag      | Critical | checked | responsible area/officer       | results received
----------------+----------+---------+--------------------------------+-------------------
Org Assurer     |    -     |    +    | Assurance: OAO                 | OAO: Yes AO: No
TTP Admin       |    -     |    +    | Assurance: AO, OAO x1)         | OAO: No  AO: No
Location Admin  |    -     |    +    | Executive: Board, Support      | Board: Yes Support t/l: No
Admin (SE)      |    +     |    +    | Executive: Support t/l, Board  | Board: Yes Support t/l: Yes
Tverify Account |    -     |    +    | pre-AP: Board, post-AP: AO x2) | AO: No
Board member    |    -     |    +    | pre-AP: Board, post-AP: AO? x3)| AO: No

This is a logical view of flags and their responsibilities. This can be SP conform but also may not. SP needs reviewed separately to get an answer to this topic. Another point is, that at least 3 or 4 of the flags relates to Assurance area. In assurance area we have the Assurance Policy and some subpolicies. Are these flags covered by these existing policies? At least the tverify flag is not handled by a policy. As arbitration is the fallback instrument for all unforseen issues, this probably needs to be referenced to arbitration.
"Critical" has to follow SP, other flags are probably not covered by SP, but AP, OAP and/or subpolicies
x1) new TTP program is subject to Assurance area, main responsible officer -> AO. Deployment of new TTP program discovered that also Organisation Assurance area has responsibilities in this area (discover applicable TTPs for each country). So therefor the new TTP program has a combined responsibility by AO + OAO
x2) flag Tverify is identified as advanced/special assurance method. This flag is in the database prior to AP in effect. AP forces down all special assurance programs. Now 3 years after AP in effect, all special assurance programs are under AO's responsibility, that these programs aren't in effect until a subpolicy is written and voted into effect. AO has to report to board.
x3) flag board has:
- at least 3 different meanings prior AP
  1. make an Assurer to Super-Assurer (Special Assurance program)
  2. transfer Thawte Points requests
  3. add Experience Points (temporarely or permanent)
- at least 1 meaning post AP
  1. add Experience Points (temporarely or permanent) according to AP 4.4
- board=1 flag usage is an assurance area related process (Experience Points increase). AO's responsibility is to report to board all assurance area related activities. Doing "Experience Points increases" affects also Assurance area. One question that probably needs to be answered by AO in the report is: how many assurers received an "Experience Points increase"? The AP 4.4 definition says: "Additional Experience Points may be granted temporarily or permanently to an Assurer by CAcert Inc.'s Committee (board), on recommendation from the Assurance Officer". So first AO can report how many recommendations he has sent to Board. To set in contrast how many assurers has received an Experience Points increase, probably a board motion should be used to document this "special" issue with addtl. info if this was a temporary or permanent Experience Points increase.
- Members who should receive the board=1 flag set process is currently undefined. It can be assumed from AP, that the board receives the recommendation for an assurer from AO and board delegates one or two board members to enter the Experience Points increase. So this also means, that the flags have to be reset each time the board changes. Currently Support cannot set/unset the board flag. It needs to be ordered for an SP 3.3. Application - Ad hoc query (AdHoc sql query) to the critical team, so has to undergo arbitration.
- Board=1 flag and CAcert Inc board members have 2 separate meanings.
  1. The first is a critical system implementation of Advanced Assurance programs (Tverify, Super-Assurance).
  2. Board as CAcert Inc board members is the executive group within the CAcert Community with the duty to run the CA on behalf of the community.
- In the CAcert "old" days (prior to AP, prior to Pimasens TOP 2007) many, if not most of the management tasks were held by the CAcert Inc Committee. Prior to AP, there was no Assurance Officer definition. Prior to Security Manual there was no Support team and Support teamleader definition. All this comes into the Community with the Policy deployment. At Pimasens TOP 2007 the core policies have been approved. This also moved duties back to the Community - Officers not to be Board members, but fulfill the management tasks former Board members have done. Eg in Assurance Area. Despite the fact that board gives off some powers, despite the fact I cannot find the explicit definition where a vacant officers seat is held by board as a fallback option, the authorisation is backed up by the Management Assertion "CAcert Inc. operates Certificate Authority services for and on behalf of registered members (Members) within CAcert’s community at large (Community).". So at any time an Officers role is vacant, Board is the recipient for the duties by this area. In the case an Officers seat has been nominated and approved by Board, the duty moves to the Officer i.d. Board has the power to deduct officers who don't take care about their duties. So at the very end the Officer has to work together with the Board and the Board has to work together with the Officer. For the permissions review project this means, Officers has to receive permissions reviews reports, to take care about their duties, and can be deducted by the Board if they don't take care about their duties. This includes proposing new team members or deducting team members.
- recommendations (for Board flag)
  1. reset all current board=1 settings
  2. build an admin team that receives the board admin flag, executing the board motions according to AP defined procedure (Board admin). This can be either Support (ABC'd group) or Senior Assurers or other Assurance Area related trusted Assurers (co-auditors, OA's) or Software-Assessors (ABC'd group) or Critical team (ABC'd group), so the flags needs only be set once over a longer period of time and not every time the board changes
  3. write a documentation for the advanced assurance method (add experience points), so the assurers who apply for the board flag (special assurance) can receive an advise how to enter the "special" assurances following AP 4.4 (especialy differentiate between temporary and permanent experience points). This probably also affects bug #1007 "add 5 Experience points for ATE attendance form"
  4. add board flag setting to admin console to become admin console changeable flag (-> Software-Assessment, -> new bug#)
```
      Flag      | responsible area/officer      | results received
----------------+-------------------------------+-------------------
Org Assurer     | Assurance: OAO                | B, OAO: Yes, AO: No
TTP Admin       | Assurance: AO, OAO x1)        | B, OAO: No,  AO: No
Location Admin  | Executive: Board, Support     | B, Board: Yes, Support t/l: No
Admin (SE)      | Executive: Support t/l, Board | B, Board: Yes, Support t/l: Yes
Tverify Account | pre-AP: Board, post-AP: AO x2)| B, AO: No
Board member    | pre-AP: Board, post-AP: AO x2)| B, AO: No
```
The user flags that have been checked in the permissions review script under bug #1003 followed the recommendation of the intermediate ruling of this running arbitration case, dated 2011-04-10 (Discovery_II). So there was no wrong doing by this time the script was running the first time. The permissions review results recipients are now under review especialy because rare complains have been received.

The checked user flags can be splitted into

2 groups:
1. Assurance area related flags
2. Support area related flags
In no one case, the Assurance area(s) Officers received the reports.
Only in one case of Support area, the Support t/l received a report.
The reports received followed the model, that all members who has the flag set receives also the report, so the results can be discussed in the team and the teamleader can make a proposal to board which of the listed members should be removed.
It seems that bug #1003 script result sets needs to be advanced/modified to better reflect the new findings.
Some of the checked flags reports revealed, that there is no team behind the flag setting by default, but there are Officers who should take care about these lists. This is:
1. Location Admin
2. Tverify
3. Board
So an enhancement of the previous proposal of permission review reports distribution should be limited for those 3 flags to CAcert Inc Board and the Officers in charge.
As Support has later to execute the Officers proposals, approved by Board removals, the permissions review report can also be sent to Support (they are still bound to SP).
The remaining 3 flags can be also sent to the teams:
1. Org Assurer
2. TTP Admin
3. Admin (SE)

NEW Proposal (2012-04-03) NEW Proposal (2012-04-05)

Flag	What to show	Who should read results
/ recipient(s)		Board	SE t/l	AO	OAO	Support	own group
admin (SE's)	list	+	+			+	+
ttpadmin	list	+		+	+	+	+
orgadmin	list	+		(+)	+	+	+
board	list	+		?	?	?	?
tverify	list	+		+	(+)	+
locadmin	list	+	+			+

Recipients can be addressed in groups:
1. Board - Board private mailing list, NOT board=1 flag (!!!)
2. SE t/l - is included in "Support team", so no special distribution required
3. AO and OAO have 4 flags to check in common. One recommendation is to create a Assurance-private mailing list or distribution list for the roles of AO and OAO. The listing of (+) to the other officer in duty does not prevent the list to be received by the other officer too. So both Assurance officers probably can share one mailing list or one distribution list. Update 2012-04-04: two aliases are available: ao@c.o, oao@c.o
4. Support - Support has (probably) a closed mailing list (cacert-se) that can be addressed for the permissions review report(s) - Whats about Triage ? Triage has access to cacert-se, limit to admin=1 flag?
  (C) will check if implementation with a new email address and import into OTRS is possible (awaiting proposal/report) otherwise admin=1 (restrict to SE's only)
5. own group - has to be limited to flags: admin, ttpadmin and orgadmin
6. (?) distributions, currently WIP, needs further deliberations

Flags and related policies

      Flag               | related Policy (DRAFT or POLICY)
-------------------------+---------------------------------
Org Assurer              | Organisation Assurance Policy x1)
TTP Admin                | TTP-Assisted-Assurance-Subpolicy x2)
Location Admin           | probably Security Policy
Admin (Support-Engineer) | Security Policy
Tverify Account          | relates to AP, no subpolicy defined, x3)
Board member             | ? x4)

x1) according to discovery process under Arbitration case a20120121.1 "current" OAP is the OAP in SVN
x2) TTP-Assisted-Assurance-Subpolicy
x3) What is this Tverify flag for? Does it means Tverify Admin? is this flag automaticly set for each tverify transfered user? (so it reads under the Sysadmin console -> "Tverify account")?
x4) What is this Board member flag used for? Is this a reference to current elected board members role? or does this flag has other purposes? From investigations in next section the board flag has nothing to do with the CAcert Inc board membership. Its derived from the pre-AP old days, where no policies and procedures were defined and Board also fulfills the Assurance Officers role. Since about Pirmasens Top (by end of 2007), the role of Assurance Officer has been installed to be responsible for the whole Assurance area. This includes all special and advanced assurance programs.

B. Who can order actions of flag removals?

Security Policy related paragraphs

SP 1.2 Principles
- Authority -- every action is authorised by either a policy or by the Arbitrator.
SP 1.4.3. The Security Procedures
- The team leaders may from time to time explicitly defer single, cohesive components of the security practices into separate procedures documents. Each procedure should be managed in a wiki page under their control, probably at SystemAdministration/Procedures. Each procedure must be referenced explicitly in the Security Manual.
  - System Administration Procedures "current"
SP 2. PHYSICAL SECURITY
- not applicable

SP 3. LOGICAL SECURITY

not applicable (means network connectivity)

except

SP 3.3. Application
- Requests for ad hoc queries over the application database for business or similar purposes must be approved by the Arbitrator. (-> eg removal of board member flag, is this cannot be ordered to an (SE))

SP 3.4.2. Special Authorisation

Additional or special access is granted according to the authorisations on the below access control lists (see §1.1.1):

List Name	Who	Purpose of access	Relationship	Manager
Support Access List	Support Engineer	support features in the web application	exclusive with Access Engineers and Systems Administrators	Support team leader

All changes of personnel to the above lists are subject to Board approval.

SP 3.4.4. Removing access

Follow-up actions to termination must be documented. See §9.1.7.

SP  9.1.7. Termination of staff

Termination of access may be for resignation, Arbitration ruling, or decision of Board or team leader. On termination (for any reason), access and information must be secured. See §3.4.4.

The provisions on Arbitration survive any termination by persons fulfilling a critical role. That is, even after a person has left a critical role, they are still bound by the DRP (COD7), and the Arbitrator may reinstate any provision of this agreement or bind the person to a ruling.

SP 4. OPERATIONAL SECURITY
- not applicable
SP 5. INCIDENT RESPONSE
- is not applicable here as we have to do with a standard permissions review. Flags have been set and members with such a flag set now gets reviewed are subject to a regular change management, but no Incident Response
SP 6. DISASTER RECOVERY
- not applicable
SP 7. SOFTWARE ASSESSMENT
- despite the fact Software-Assessment has deployed the permissions review script, Software-Assessment has no authorisation to order flag removals or adds to (SE)'s
- so, not applicable
SP 8. SUPPORT
- 8.1. Authority
- The software interface gives features to Support Engineer. Access to the special features is under tight control. Additions to the team are subject to Board approval, and the software features are under CCS. See §3.4.2.
- Support Engineers do not have any inherent authority to take any action, and they have to get authority on a case-by-case basis. The authority required in each case must be guided by this policy or the Security Manual or other clearly applicable document. If the Member's authority is not in doubt, the Member can give that authority. If not, the Arbitrator's authority must be sought.
- Support Engineers are responsible to follow the policies and practices.
  - this means: Board can approve new Support team members, but every action of (SE) follows other directives. "The authority required in each case must be guided by this policy or the Security Manual or other clearly applicable document"
- SP 8.5. Arbitration
  - Support Engineers refer questions requiring authority to Arbitration ...
SP 9. ADMINISTRATIVE
- SP 9.1. Staffing
  - applicable to "critical" roles - eg Critical Sysadmins, Access Engineers, Support-Engineers, Application Engineers, Software-Assesssors.
  - SP 9.1.1. Roles and responsibilities
    - Support Engineer: human interface with users.
    - Team leaders: coordinate with teams, report to Board.
    - All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.
    - Board: authorise new individuals and accesses. Coordinate overall.
    - Arbitrator: conducts ABCs. Authorises exceptions to policy.
  - SP 9.1.2. Staffing levels
    - One individual in each team is designated team leader and reports to Board.
  - SP 9.1.3. Process of new Team Members
    - Recommendation by team leader - Arbitrated Background Check ("ABC") - Authorisation by Board
    - SP 9.1.4.4. Privacy for Critical Roles
      - CAcert trusted roles give up some privacy for the privacy of others.
  - SP 9.1.5. Authorisation
    - Individuals and access (both) must be authorised by the Board. Only the Board may approve new individuals or any access to the systems. Each individual should be proposed to the Board, with the relevant supporting information as above.
  - SP 9.1.7. Termination of staff
    - Termination of access may be for resignation, Arbitration ruling, or decision of Board or team leader. On termination (for any reason), access and information must be secured. See §3.4.4.
    - The provisions on Arbitration survive any termination by persons fulfilling a critical role. That is, even after a person has left a critical role, they are still bound by the DRP (COD7), and the Arbitrator may reinstate any provision of this agreement or bind the person to a ruling.
  - SP 9.3.1. Responsibility
    - Board is responsible to the Community to manage the CA at the executive level

All references in SP are meant to be for Critical roles. Critical roles flag definition is only "Support-Engineer". All others roles are not covered by SP, but probably by other policies (eg AP and subpolicies)
Currently I have more open questions then answers.
- Responsibilities, Authorisation, Powers of teams (Board, Arbitration) and Policies delivers an indifferent picture how to respond on the permissions review results. Then there are different levels of flags that relates to critical and non-critical roles. Adding new members to a critical team are defined in SP. Adding new members to other teams (Assurers -> AP, Organisation Assurers -> OAP) are referenced by individual other policies. Removal of team members aren't well defined except for critical roles.
- Ok, starting with adding new team members, the default procedure is similar to the one defined for critical roles:
  - a team proposes a new team member and places their request before board (critical roles have additional to undergo an ABC) and Board approves their nomination with a board motion (-> documentation).
  - The same procedure can be taken for team member removals, the team makes a recommendation who has to be removed from the team members list, places their recommendation before the commitee and the Board approves the removal by a board motion (-> documentation)
  - One side affect may be, that a team member received informations in their role as team member within a team so that "SP 9.1.7. Termination of staff" part b. applies.
  - One sidenote: flag removal does not mean CCA termination that is subject to Arbitration
  - A general ruling cannot be given as each job role given by an individual flag may have different side effects.
    - eg. roles within the assurance area relates to storage of documents -> CAP, COAP forms, maybe others
  - So therefor each flag has to undergo an individual investigation.
    - Samples:
      1. an Organisation Assurer who no longer serves as OA, but keeps to be a CAcert member, has probably collected COAP forms. By removal of the Orgadmin flag, the obligation to keep the COAP forms for 7 years doesn't disappears. The ex-OA is still bound to this obligation.
      2. a TTPadmin under the old TTP program has collected TTP CAP forms. By removing the TTPadmin flag the ex-TTPadmin is still bound to the obligations to keep the TTP CAP forms for 7 years and to respond to arbitrator requests related to these old TTP assurances
    - Probably this needs an excurse first to investigate what each flag is considered to do, and how it applies:
      - Flag: Org Assurer
        Description:
        a member who has this flag set has additional menu options in the main CAcert website, to do administrative tasks in the Organisation Assurance section. Administrative tasks in the Organisation Assurance area follows Organisation Assurance Policy (including procedures to add new OA's). One of the OA obligation is to keep the COAP form for 7 years. Removal of the OA flag without any documentation may have side effects in case the former OA starts a delete my account request. In this case an Arbitrator needs to review the roles a member had. One of the Arbitrators task is to keep track about CAP and COAP forms of the terminating member to protect the WoT. Without proper documentation this information path gets lost. A motion with the role and name of a member who resigns is sufficient.
        Team:
        Organisation Assurers
        Team leader/Officer/Responsible person:
        Organisation Assurance Officer
      - Flag: TTP Admin
        Description:
        a member who has this flag set has an addtl. option under the Assure-Someone form under the main CAcert website WoT section. There is an addtl. option box to select an assurance method "Face-2-Face" or "Trusted 3rd Party". This means, the member is allowed to enter a different assurance method record into the database. This covers main Policy Assurance Policy and probably related subpolicies. For Assurance method "Trusted 3rd Party" under the old program, there was no Policy available and therefor the old TTP program was frozen (Policy group decision: AP to DRAFT, AP to Policy, board motion that old TTP program is frozen, arbitration to publish prominent the decisions to the community). Nominations of old TTPadmin's was not covered by policies. New TTP program has been voted on policy group back in 2010. But has not set been active caused by software restrictions. Nomination of new TTPadmins did happen the first time in March 2012. The idea of the new TTP program deployment team is to recycle the old TTPadmin flag for the TTP assisted assurance part (does not cover the TOPUP process). So if there still are TTPadmin flags set active, they needs to be removed first, before the new TTP program can be set active.
        One of the TTPadmin obligation is to keep the TTPCAP forms for 7 years. In case of a former TTPadmin termination, TTPCAP forms review by an Arbitrator can be discovered by assurances given list of the user. So there is no further issue to take care in a TTPadmin flag removal of a users account in the first view. On a 2nd view the Arbitration case a20090427.2 revealed a mess in the old TTP assurances documentation. There was thoughts to prepare a Legacy Policy on how CAcert should handle old Assurance and Experience Points. As there are other database content errors with Trusted 3rd Parties assurance method, a list of old TTPadmin's should be saved to give an Arbitrator a chance for discovery purposes so that TTPadmin's from old program can be contacted by an Arbitrator if needed.
        Team:
        (old program) no team, no policy, flag used probably by old executives (commitee/board)
        (new program) new team, TTP-assisted-assurance policy, TTP-assurer proposed by team, approved by board
        Team leader/Officer/Responsible person:
        (old program) no team leader, CAcert Inc Board
        (new program) AO, OAO
      - Flag: Location Admin
        Description:
        The "Location admin" flag opens a new menu option under the main CAcert website and allows administration of the critical database included locations database. The locations database was subject of an arbitration ruling under case a20090427.2. The ruling recommendation was to replace the database or to outsource the functionality to a community driven system.
        What is the procedure to add locadmin?
        What is the decision process to add new Location Admins?
        Team:
        No policy, No team, all individuals, approval procedure? by request to Support?
        Team leader/Officer/Responsible person:
        No team leader, CAcert Inc Board, maybe Support
      - Flag: Admin (Support-Engineer)
        Description:
        The "Admin" flag relates to the Critical role "Support-Engineer" that is covered in full by SP including adding this flag to a members account (-> nomination by Board) and also the removal (-> resignation, removal procedure). The flag opens an addtl. menu option under the main CAcert website to do some administrative tasks:
        view user account settings based on orders
        modify user account settings based on orders
        Team:
        Support-Engineers team (excl. Triage)
        Team leader/Officer/Responsible person:
        Support-Engineer t/l, nominated, voted by the team
      - Flag: Tverify Admin
        Description:
        Description by SA1: I'm currently not party of the Arbitration, but since I somehow have leaked into the communication I'll take the liberty to give an opinion and some info on TVerify. IMHO the TVerify flag of all accounts may well be reset, and should not be part of further reports according to https://bugs.cacert.org/view.php?id=1003 because: TVerify Admins are not needed any more, since the Thawte Freemail program has been history for quite some time now. Issued Thawte Points won't be relevant from some time in the (near?) future. From my own experience (I was Thawte verified, though never TVerify admin), some code review and a few intelligent guesses I'd describe the TVerify process as follows: When the user requests to be TVerified a record is created in the TVerify table (I updated the table's description in https://wiki.cacert.org/Software/Database/StructureDefined), containing the CN contained in his Thawte certificate, plus optionally his URL in Thawte Freemail's Notary directory and/or a scan of one of his photo IDs Each TVerify Admin could get a list of pending TVerify requests. The TVerify Admin checks the information (goes to Thawte notary directory, verifies that the CN ) and looks at the ID scan If he's convinced about the validity of the request he accepts the request, otherwise he rejects it. Once a request gets 8 positive votes it is accepted, the requesting user gets a number of points to reach a point level according to the provided information: 150 points if ID scan and Thawte Notary Entry have been provided 90 points if only Thawte Notary Entry has been provided 50 points if neither is given (N.B.: there seems to be a bug, if only ID Scan but no Notary Entry is provided) If 4 negative votes are recorded the request is rejected, nothing happens beside marking the request is closed and the requesting user gets an informational mail. The TVerify Admins do not get any (experience-)points for a vote. N.B.: I did not find any code to delete the ID scans, so there may still be a significant number of ID scans on the server...
        Description by SA3: Yes, one more note: As far as I saw, when more TVerify Admins were needed, previously successfully TVerify-introduced people who looked trustworthy were asked whether they wanted to to join the TVerify-Admins, when they agreed, they got the Tverifyadmin flag. I agree that since the TVerify system has been deprecated, the tverify flag is obsolete and the scans could be deleted, if they are not needed for arbitration in the future.
        Team:
        no team
        Team leader/Officer/Responsible person:
      - Flag: Board member
        Description:
        
        2012-04-01 (A): made some tests with ... A: testsystem current (with 6.php patch, bug #1023) B: testsystem old (w/o 6.php patch, bug #1023), same as live system current 100 AP, CATS, 0 EP, board=1 A: F2F only, 10 pts max B: F2F + temp increase (# of days)/sponsoring member, 10 pts max 100 AP, CATS, 50 EP, board=1 A: F2F only, 35 pts max B: F2F + temp increase (# of days)/sponsoring member, 35 pts max 100 AP, CATS, 50 EP, board=1, tverify=1 same as above 100 AP, CATS, 50 EP, board=1, ttpadmin=1 addtl. option box: assurance methods avail: 1. Face-2-Face 2. Trusted 3rd Parties 3. Thawte Points Transfer 4. Administrative Increase 5. CT Magazine Germany + temp increase (# of days)/sponsoring member, 35 pts max 100 AP, CATS, 50 EP, board=1, tverify=1, ttpadmin=1 addtl. option box: assurance methods avail: 1. Face-2-Face 2. Trusted 3rd Parties 3. Thawte Points Transfer 4. Administrative Increase 5. CT Magazine Germany + temp increase (# of days)/sponsoring member, 35 pts max
        From the investigations on testservers, there is no other purpose then to add addtl. Assurance methods to an user account who has the board=1 flag set. So therefor this flag is falling under the Assurance area. As no one then a critical admin can set or remove the board flag, the automatic setting of this flag for all new committee members is prevented by design. As all additional assurance methods are frozen since AP is in effect, the usage of the board=1 flag has no longer any purpose by default.
        The difference between Adminstrative increase and Temporary increase is probably only the timespawn: Administrative increase is valid forever, Temporary increase only for a number of days count. Both assurance methods are also known as "Super-Assurance".
        Read also Statement by PG 2010-05-04
        Statement by another Software-Assessor
        Topic: Flag 'Board' related advanced special assurance methods. Here: Administrative Increase, Temporary Increase > b. what does the member who has the board flag enabled > has to activate / increase ? Assurance Points? Experience Points? > other Flags? > Which type of points are affected? AP? EP? There is no distinction of AP or EP in the system except from the new points list page. If a user has 150 point this always means 100 APs and 50 EPs but you can't explicitly give EPs to someone, once they're above the 100 points they're automatically handled as EPs if below APs. > c. How does the process continues? > are the issued points will be removed after the > "temporary" time ? or are they'll be kept still active? Yes the points will be removed in the removedead.php script run. But the expiration handling is kind of complex and as far as I can tell it may contain bugs. If ther user has more than or equal to 150 non-temporary points, the temporary increases points are set to 0. If the user has less than 150 non-temporary points the points are also set to 0 but an Administrative Increase (non-temporary) is inserted that fills up to the 150 points.
        So with the flags Board and TTPadmin set, the "Top Assurer" could make "Administrative Increase, Temporary Increase, Thawte Transfer, Trusted 3rd Parties" assurances. Under special conditions Temporary Increases moved automaticly to Administrative Increases.
        With AP in effect all these special assurance methods are no longer valid.
        Is this correct?
        Not completely!
        AP defines under 4.4. Experience Points
        "Additional Experience Points may be granted temporarily or permanently to an Assurer by CAcert Inc.'s Committee (board), on recommendation from the Assurance Officer."
        So this affects the Administrative Increase and Temporary Increase function in the Webdb code and the Board role too.
        Despite the fact, that all special assurance programs were stopped, this issue doesn't affects administrative or temporary increases of experience points!
        What is the difference between Super-Assurers who giving assurees 150 pts? and an administrative/temporary increase in Experience points?
        Well, the Super-Assurance is one F2F assurance, where the Super-Assurer makes one Assurance and awards upto 150 points (100 Assurance Points + 50 Experience Points to an Assuree).
        One Assurance only is prevented by AP, that requires at least 3 experienced assurers assurance so an assuree can reach the 100 Assurance Points barrier. So therefor the Super-Assurance program is stopped because this program is not in compliance with AP.
        In contrast: One Assuree with 100 Assurance Points and CATS passed starts with 0 Experience Points. Assurance Policy defines under section 4.4 that Board is authorized by recommendation from AO to award upto 50 Experience points to an Assuree (!). Implementation details aren't defined in AP. This is an Software issue. (read also deliberations and recommendations under section Team)
        Team:
        There is no known team (all individuals from pre-AP times, where Thawte points transfers and Super-Assurers are valid advanced Assurance methods.
        Board flag meaning has changed with AP in effect. Before AP no AO who is responsible for the Assurance area was defined. So this role was handled by CAcert Inc Board in role as executive. System implementation named the special assurance programs handling "board". This naming nowadays confuses with the todays CAcert Boards duties. Todays correct naming for this flag can be "specialassurances" or alike (Special-Assurances-Admin like TTPadmin).
        But this isn't the only function. Also Experience Points Increase (today upto 50 Points according to AP) is possible. Maybe current system implementation doesn't allow to enter Experience Points increases, but per AP 4.4 definition, this should be possible (see also bug #1007 Experience Points increase for ATE attendence).
        How is this "special program" to name? Advanced Assurance method "Experience Points Increase" ?
        The process is that by recommendation of AO, CAcert Inc's Committee has to approve the recommendation for an Assurer, to add addtl. Experience Points to his account. So once a motion (?) has passed, "someone" who has the board=1 flag set has to add the addtl. Experience Points to an assurers account. This "someone" can anybody nominated (like an Org-Assurer or TTP-Assurer), or this job can be ordered to Support. Current implementation is, that the member with board=1 flag set can/has to do this job. As its not that easy to replace or add the board flag to a members account (an AdHoc sql query needs to be ordered to the critical team)
        my recommendations here are:
        define and document the "Experience Points increase" process
        nomination and approval of an "Experience Points increase" admin (one or more) by the CAcert Inc Board (the role can be delegated like officers or other special assurer roles)
        add board flag edits to Support admin console (same process as adding/removing TTP-Assurers) (-> Software, Software-Assessment)
        update current board=1 modification implementation in software, so that only an "Experience Points increase" is possible according to AP 4.4 (no Assurance Points increase!) (remove Super-Assurance functionality) (Software, Software-Assessment)
        Alternate: kill the board flag, add a new flag for AP 4.4 requirement
        separate the ttpadmin / board flag special combination (system implementation change request) (Software, Software-Assessment)
        the group of "Experience Points increase" admin's should form a team
        to reset the current state of board=1 definitions and start from scratch with the new program
        So in the very end, yes one day we probably have an "Experience Points increase" admin team
        Team leader/Officer/Responsible person:
        There is no designated team leader prior AP. After AP in effect this flag management relates to AO
        Prior AP the board flag responsibility was CAcert Inc Board.
        Post AP times the process responsibility is AP defined to be a combined responsibilty by AO and CAcert Board.
        Responsibility of setting (or removing) the board=1 flag is subject to a process that needs to be defined (see above) (automaticly if committee members changes? delegation? nomination/approval process?). From current PoV it has to be an automatic process, never used within the last 3 years.
        From the TTP-assisted-assurance subpolicy deployment, the overall thought was to delegate as much from Board to the Community (-> officer delegations) (Post 2009 openess) so the next logical step is to delegate this responsibility to the assurance area as this is an assurance related issue (nomination by the team/teamleader or AO, approval by the Board)
  - Whats about notification to each flag removed member? (-> recommendation?)
    - ```
    On any removal process, the affected member needs to be informed about the removal of the flag and further needs to be informed, that the removal of the flag doesn't relates to a removal for his obligation, that is subject to a specific role.
    
    On termination (for any reason), access and information must be secured. See SP §3.4.4.
    * The provisions on Arbitration survive any termination by persons fulfilling a critical role. That is, even after a person has left a critical role, they are still bound by the DRP (COD7), and the Arbitrator may reinstate any provision of this agreement or bind the person to a ruling. (SP 9.1.7)
```

C. ''Question:'' Can a universal procedure be defined? (eg by make a precedent ruling?) or is Board allowed to order removal of flags?

From the deliberation under A. the flags and related responsibilities varies:

      Flag               | Critical | checked | responsible area/officer      | results received
-------------------------+----------+---------+-------------------------------+-------------------
Org Assurer              |    -     |    +    | Assurance: OAO                |
TTP Admin                |    -     |    +    | Assurance: AO, OAO x1)        |
Location Admin           |    -     |    +    | Executive: Board, Support     |
Admin (Support-Engineer) |    +     |    +    | Executive: Support t/l, Board |
Tverify Account          |    -     |    +    | pre-AP: Board, post-AP: AO x2)|
Board member             |    -     |    +    | pre-AP: Board, post-AP: AO x2)|

Back in the pre-Policies days of CAcert the main responsibility was CAcert Inc's Board. With Policies in effect, Board's role moved to a management role with delegations to teams and their respective team members. In case a team leaders role is vacant, the t/l role moves back to board. eg current Software-Assessment team has team members, but t/l role is not filled so t/l is referenced back to board.
Other teams w/o a t/l: Access-Engineers, Policy Officer, Privacy Officer and others. Read Teams. But no one of the officers listed here has a flag setting in the database users record
In the case where a team and/or teamleader / officer is available, its assumed that Board had transfered the management process to the teams, to check on team members, let the teams propose new team members, let the teams also propose team member removals and Board approves or rejects the nominations. In cases an Officers role is vacant, Board acts as the fallback by nominate one of the board members to take care about the role or to take care in a whole.
CAcert Inc and the Boards main task is to run the CA according to CAcert Inc Management Assertion. This covers the "critical" systems according to table 1 under Systems overview that falls under SP + SM. (non-critical) Infrastructure, Auxiliary and Misc systems doesn't fall under SP + SM.
- What is with Nominations and approval of (non-critical) Infrastructure team members?
- Procedures defined? Policies in effect?

D. Whats about documentation? Nominations follows board motions, does have removals to undergo also Board motions?

Removal of active team members in practice follows the nomination/approval procedure. The team/teamleader nominates candidates. Board approves the new members/removals.
- Samples:
Search function in board motions list is not avail, but with some time or search in the wiki related board motions can be identified. One recommendation is to add the motion number and the link to the motion to team member lists when a team member has been approved by board (eg Arbitrators list, Officers list, Org Assurers list).

E. one result of the initial permissions review script execution, a new dispute has been filed a20120330.1. Does all unforseen issues have to undergo an arbitration?

was a20120330.1
Also a complain has been received in public support mailing list: complain by a member who received a permissions review report with Tverify flag set
- Arbitration is the fallback option for all unforseen issues. Like the sample case that cannot be handled easily by the teams (sample relates to Support area), their team leaders nor by Board, cases should be moved to Arbitration if unclear

F. 2012-03-30 (SE): phone call to (A): board flag cannot be removed under admin console

One issue covered up, that one of the flags under permissions reviews cannot be reset by a Support-Engineer under Webdb's admin console.

permissions review script source

Permission review over following flags:
  25 $flags = array(
  26         'admin' => 'Support Engineer',
  27         'orgadmin' => 'Organisation Assurer',
  28         'board' => 'Board Member',
  29         'ttpadmin' => 'Trusted Third Party Admin',
  30         'tverify' => 'Tverify Admin',
  31         'locadmin' => 'Location Admin'
  32         );

   A. Flags that are discovered and reported under the permissions review script
   B. Flags that can be reset by a Support-Engineer by receiving an order to do so

      Flag               |  A  |  B
-------------------------+-----+-----
Code signing             |     |  +
Org Assurer              |  +  |  +
TTP Admin                |  +  |  +
Location Admin           |  +  |  +
Admin (Support-Engineer) |  +  |  +
Ad Admin                 |     |  +
Tverify Account          |  +  |  +
Board member             |  +  |  -

Summary: removal of Board flag needs an Ad hoc SQL query to critical team authorized by an Arbitator

Intermediate Ruling #3

The long deliberations doesn't makes it easy, to write down the summary in 2 lines. So therefor I walk through the questions given and give the answers to each of these questions.

Question A: have all recicipients that requires the info have received the info to act (request probably removals of permissions)?

The result of the script was inspired by the intermediate rulings #1 and #2 given. So no wrong doing by any party was given.
But the results disclosed to the recipients of the first report, that there are unexpected flag settings in the database, where all people thinks, that there shouldn't be. So here I have to take my hat off to Board who started the last initiative, to get these things discovered.
From above deliberations it has been found, that not all intended recipients received the info of the permissions review report, who should receive the info and that others, who shouldn't receive the info received the report (this includes partly reports) that becomes subject of complains or irritations.
So, the list of recipients of the permissions review script ruled under intermediate ruling #2 has to undergo some enhancements.
In principle the recipients list of the permissions review script reports shall follow the NEW Proposal dated (2012-04-05), updated (2012-04-19)
- for clarification of the intended recipients:
  - Board means:
    - the members of current active CAcert Inc committee as defined under Committee Current
    - technicly current solution is the board private mailing list but this is not limited to this distribution path as other technical solutions will be implemented (this is topic to the Software team)
    - By current findings this has not to be mixed with board=1 flag recipients ! (about board=1 flag more on later)
    - Responsible for correct addressing of current committee members are the listserver admins who manages the recipient members of the board private mailing list
    - This can change if other distribution paths will be implemented
  - AO, OAO means:
    - Assurance Officer and Organisation Assurance Officer are roles that are currently not defined with a flag in the database. Email distribution lists have been created in the meanwhile, so these two recipients can be addressed.
    - AO and OAO are the current appointed officers in the assurance area as defined under CAcert Teams
    - Responsible for correct addressing of current AO and OAO officers are the email admins who manages the email distribution lists
    - This can change if other distribution paths will be implemented
  - Support means:
    - Support-Engineers excluding Triage members. This excludes a distribution path like current available cacert-se mailing list, that is also available to triage members.
    - Support-Engineers appointed are currently listed under Support Team - Support Engineers (one sidenote here: the board motion for each respective team member acceptance should be available here for an easy documentation. That it is.)
  - Support t/l means:
    - Current Support-Engineer teamleader appointed by board as defined under CAcert Teams
  - Own group means:
    - Indented recipients are members who have the same flag set that is under review.
    - In contrast to the first proposal under Discovery_II and intermediate ruling #2, the Own group recipients shall be limited to flag settings:
      1. admin=1, list of Support-Engineers
      2. ttpadmin=1, list of TTP-assurers
      3. orgadmin=1, list of Organisation-Assurers
    - board=1, tverify=1, locadmin=1 to be removed from a group distribution of the report.
- for clarification of the intended recipients by each individual flag:
  - default recipients: Board, Support (for all flags)
    - Board is the last resort of all reports, so therefor Board applies to all individual flag settings reports
    - Support (Support-Engineers) has to respond on adding and removal requests from the responsible parties. So therefor, receiving also all permission review reports is a source for later verification of each Support action taken by SEs itself (see also a20120330.1 "Unknown CAcert user with SE permissions (was: Permissions Review)"). Support-Engineers are ABC'd and are bound to Security Policy. One topic that can prevent disclosure of the names who have a special flag set by the report can be a Privacy Policy issue. Privacy Policy defines under top 9. Exceptions "A CAcert arbitrator may override this policy in a dispute. To obtain access to confidential data, a dispute has to be filed.". So currently we're handling a dispute, so the remaining question is, if we have to do with confidential data and if Support is allowed to receive these infos (this probably also applies to Board). Security Policy (9.1.4.4. Privacy for Critical Roles) and SecurityManual (9.5. Confidentiality, Secrecy) defines: "CAcert trusted roles give up some privacy for the privacy of others.". The next question here is, what does board=1, tverify=1, orgadmin=1, ttpadmin=1, locadmin=1 have to do with a critical role? and can the disclosure of "confidential data" to an identified group (-> Support-Engieers, Board) within a permissions review report be read as "To obtain access to confidential data"? To set specific flags, at least Support-Engineers are authorized by SP and instructured by the related party following SP to do so. It can be assumed, that this info is known by the Support-Engineers, so the respective report who has the flag set in consequence of such an order (set a flag to a specific member) can be also knowledgable. Board cannot change flags by its own, as Board members have no default access to the admin console to change flags of members and Support-Engineers are bound to SP in doing any changes. So the SP definition "CAcert trusted roles give up some privacy for the privacy of others." can be extended with "other, less critical roles (as such assurance area related flags like board, orgadmin, ttpadmin and also non-assurance area related flag locadmin) give up some privacy to an identified, limited group of executive and administration group for management purposes". Assurance Policy for the assurance area has an extension to the Privacy Policy under AP 7. Privacy: "The Member's information can be accessed under these circumstances: ... CAcert support administration and CAcert systems administration when operating under the authority of Arbitrator or under CAcert policy.". This can be redefined for the running case:
```
 "The Member's information (name, email, flag setting) can be disclosed in a report to a limited group of persons under these circumstances: CAcert support administration, CAcert systems administration and executive board and identified officers responsible to the related area when operating under the authority of Arbitrator or under CAcert policy."
```
  - admin=1
    - The report shall be received by Board, Support t/l, Support, (Own group)
    - dependent on the permission script report addressing implementation Support t/l is member of the Support group so this probably doesn't need a separate addressing
    - Currently there are two proposed implementations that fulfills the requirement, that only SE's and not Triage members can read the reports. This is either
      1. admin=1 recipients implementation (my proposed variant) -or-
      2. OTRS direct addressing to SE queue
    - This can change if other distribution paths will be implemented
    - Own group: within the Support-Engineer group, all members knows each other. All team members are working in a team. So the knowledge who has the admin=1 flag set doesn't disclose more that isn't yet known by the team members. As admin=1 is the Support-Engineers group definition and Support has allready a defaults to all reports definition, the "Own group" definition is a dublicating definition that can be ignored here.
  - ttpadmin=1
    - The report shall be received by Board, AO, OAO, Support, Own group
    - The new TTP-assisted-assurance subpolicy that is currently under deployment (read TTP section in the wiki) defines AO as the responsible officer for this assurance area. Despite the fact, this definition has been set in the subpolicy, the TTP area also works together with the Organisation-Assurance area, receiving detailed informations from the Organisation-Assurers from each individual countries about applicable TTPs. Organisation-Assurers are also prefered candidates in becoming TTP-assurer. So the deployment of the new TTP-assisted-assurance program shares both Assurance areas, the Individual Assurance area with AO as the officer in duty and the Organisation-Assurance area with OAO as the officer in duty. Therefor permission review script reports shall addressed to both officers.
    - Own group: TTP-Assurers have to work in a team. By process definition, at least 3 TTP-assurers are needed to bring a TTP-user candidate upto 100 assurance points. As 2 TTP-assurers have to work together with the TOPUP-assurer all TTP-assurers have to know each other. At least this is the prefered variant. So a disclosure of all TTP-assurers that are also listed publicly under active TTP-Assurers list within the group of TTP-assurers is no secrecy that discloses more confidential data that is also known by the publicly available active TTP-Assurers list
  - orgadmin=1
    - The report shall be received by Board, AO, OAO, Support, Own group
    - Organisation-Assurers nomination follows OAP (OAP current see also a20120121.1). OAP defines under 2.1 Assurance Officer: "The AO manages all OAs and is responsible for process .... In these responsibilities, other Officers will assist." and AP under 0.3. Related Documentation: "See also Organisation Assurance Policy (OAP) ...". In practice OAO manages the Organisation Assurance area, on new OA candidates process, OAO sends the nomination request to AO and Board and Board probably checks the acceptance by AO too. As both Assurance officers have to work together with the Board on Individual, Organisation Assurance and other related assurance areas too, there is no secrecy between individual and organisation assurance areas about Organisation-Assurers (OAs are still publicly listed under Organisation Assurers List) so nothing prevents AO to receiving the report for orgadmin=1 members too.
  - board=1 and tverify=1
    - Both flags relates to Assurance area special assurance programs that were active before AP comes to effect. With AP in effect, these flags are no longer considered to be active. So therefor all flag settings (board=1, tverify=1) shall be disabled asap.
    - At least the tverify flag can be accessed through Support Sysadmin console. So this flag needs to be monitored continuously until all potential sources are removed that allows execution and processing of this special assurance program.
    - The board=1 flag can only be accessed through a sql update sequence executed by a critical sysadmin on the systems console. As long there exist code in the webdb repository that allows potential execution of code that depends on the board=1 setting, this flag shall be monitored continuously.
    - Current software code that executes the board=1 flag setting relates to the old "Super-Assurers" program, that is declared frozen, and to temporary and administrative increases. Despite the fact AP defines under 4.4 Experience points "Additional Experience Points may be granted temporarily or permanently to an Assurer by CAcert Inc.'s Committee (board), on recommendation from the Assurance Officer." this board=1 flag setting implementation doesn't fulfill the requirements given by AP 4.4 as of bugs in this special code as identified by Software-Assessors and the Software Testteam (bug #1023 tests). At least current implementation makes no difference between Assurance points and Experience points, that is prohibited by AP 4.4 Experience Points definition. So I declare this special program frozen until Software team patches this part of the code or deploys a new implementation of this special "experience points" increase program (prefered variant).
    - Reset current settings
    - Current board=1 and current tverify=1 settings shall be reset all to board=0 and tverify=0. Critical team shall execute a sql update query to reset all board=1 settings to board=0 and tverify=1 settings to tverify=0.
    - Before execution, the current state shall be saved for documentation purposes within this arbitration documentation and shall be kept for 7 years (this is the retention time for CAP forms, that a future arbitrator may request). If an issue will araise in the near future, that relates on this board=1 setting or tverify=1 setting a future arbitrator can start investigating the saved current state of board=1 and tverify=1 settings related to members.
    - All members that are affected by a flag update shall be notified by an email about the arbitration ordered flag reset. This can be either handled thru a script that also includes the flag reset procedure (similiar to the events mailing script) (-> request to Software team to deploy a script that can be executed by the critical team?) or manualy exec of the sql query, sql update query by the critical team and sending emails manualy by CM/A under this arbitration execution
      - # proposed sql query for current state reporting according to permissionsreview.php script: select `fname`, `lname`, `email` from `users` where `board` = 1; select `fname`, `lname`, `email` from `users` where `tverify` = 1; # proposed sql update query: update on cacert.users set board=0 where board=1; update on cacert.users set tverify=0 where tverify=1;
    - Future Monitoring
    - The board=1 report shall be received by Board, AO, Support until the board=1 setting will be recycled by another software implementation or removed from webdb completely
    - The tverify=1 report shall be received by Board, AO, Support until the tverify=1 setting will be recycled by another software implementation or removed from webdb completely
    - By AO in role as responsible officer for all CAcert assurance programs.
  - locadmin=1
    - The report shall be received by Board, Support t/l, Support
    - dependent on the permission script report addressing implementation Support t/l is member of the Support group so this probably doesn't need a separate addressing
    - Own group: there is no team defined nor organized. All members who have locadmin=1 setting enabled are individual members who are probably added by a Support-Engineer by request to correct or add a location information. As the location database was identified not to be critical under a20090427.2 (Ad hoc SQL query requested), the administration part isn't critical either. Its under SE's decision to give a member the locadmin=1 setting or do the location database update by its own.
      - Here I give a recommendation to the software team, to enhance the code with a locadmin=2 setting, so locadmin can be either set permanently (locadmin=2) or temporarely (locadmin=1), where a cron job script resets all temporary locadmin=1 settings from time to time to keep the list of locadmins small
      - With a recommendation given under under a20090427.2 to outsource the locations database from the critical system, this new recommendation is questionable, but may becomes attractive, if the "find an assurer" function, that relates on the locations database, the outsourcing takes any longer

Flag	What to show	Who should read results
/ recipient(s)		Board	SE t/l	AO	OAO	Support	own group
admin (SE's)	list	+	+			+	+
ttpadmin	list	+		+	+	+	+
orgadmin	list	+		+	+	+	+
board	list	+		+		+
tverify	list	+		+		+
locadmin	list	+	+			+

Last permission review script report received all above defined recipients except in cases of AO. OAO received report under role as SE. So Board or Support shall forward the report for the assurance area related flags (ttpadmin, orgadmin, board, tverify) to AO. In the meanwhile a board member forwarded a copy of the report to AO. So also here there is no action needed.

Questions B. - F.

Questions Overview / Summary
- B. how does the removal process needs to be installed? Who has permissions to order Support-Engineer to remove flags according to SP?
- C. Can a universal procedure be defined? (eg by make a precedent ruling?) or is Board allowed to order removal of flags?
- D. Whats about documentation? Nominations follows board motions, does have removals to undergo also Board motions?
- E. one result of the initial permissions review script execution, a new dispute has been filed a20120330.1. Does all unforseen issues have to undergo an arbitration?
- F. (SE) reported, that board flag cannot be removed from within the admin console
For the flags admin=1 (Support-Engineers, Security Policy), ttpadmin=1 (TTP-Assurers, TTP-assisted-assurance subpolicy) and orgadmin=1 (Organisation-Assurers, OAP) there exist procedures by Policy or the related Manual to bring in new team members with all related documentation issues.
So in consequence the resign procedure shall follow the same procedure as nomination and acceptance procedure.
In cases where an active listed team member shall be removed, following simple procedure shall be executed:
- A request for removal shall be started by the officer in duty
- passed with a board motion over each individual member
- to be documented on the related team members page (admin -> Support Team - Support Engineers, ttpadmin -> active TTP-Assurers list, orgadmin -> Organisation Assurers List).
- The action with reference to the board motion to be sent to Support
- and executed by Support.
- The members shall be notified by email to their primary email about the flag removal with reference to the passed motion.
In cases where members are listed, that aren't on the active members list (may be caused by old CAcert history, accidently set flags, or other unknown purposes):
- these cases can be handled by a Support-Engineer if an "urgent handling" is required with a following dispute filing (currently I don't see a real "urgent handling" case, but this may occur, one day). In such a case, the arbitrator probably also will check if the "urgent handling" was appropiate
- or by filing a dispute (see a20120330.1)
For documentation purposes of admin=1 settings I recommend to continue updating the Support Team - Support Engineers list with the board motions for each respective team member acceptance for quick references. For me its not easy under current motion database to find records when a specific role position has been approved by the Committee. So for others neither.
For the flag locadmin=1 there is no specific procedure defined to add a member to the localisation admins. So its upto Board or the Support engineer group to order locadmin=1 resets. My recommendation is to pass a formal motion for documentation purposes also to Support.
For the tverify=1 and board=1 flag the removal procedure has to fulfill some requirements that I've outlined above. These cannot be handled with a simple board motion. At least not since policies are in effect (SP, AP) and the board=1 flag reset cannot be executed by a Support-Engineer. Therefor this has to be passed to Arbitration, to be handled by at least 2 teams (Arbitration, Critical Team). Maybe Software-Assessor team can be requested for assistance (deployment of a flags removal script). The latter has some advantage in case the flags removal needs to be executed again as of the results of one of the future permission review reports

Future handling of Board and Tverify flags

The discovery and deliberations process revealed a complex situation with these flags.
- One is that all special assurance programs are frozen since at least by end of 2009
- On the other side AP defines a potential Experience points increase that Board can decide.
Tverify is covered by the frozen special assurance programs motion
Board flag setting relates partly to the AP 4.4 definition of temporarely or permanently increase Experience points of individual members. In software tests and also code review it has been discovered, that this code has bugs. The main problem, it doesn't differentiate between Assurance Points and Experience Points as required by AP. In my deliberations I come over to a recommendation
Recommendation for future handling of Board flag (recycle the board=1 flag for AP 4.4 special experience points increase procedure)
1. reset all current board=1 settings (this will be done within this current intermediate ruling)
2. deploy new software code to respond to AP 4.4 special experience points increase procedures (temporarely or permanent)
3. build an admin team that receives the board admin flag, executing the board motions according to AP defined procedure (Board admin). This can be either Support (ABC'd group) or Senior Assurers or other Assurance Area related trusted Assurers (co-auditors, OA's) or Software-Assessors (ABC'd group) or Critical team (ABC'd group), so the flags needs only be set once over a longer period of time and not every time the CAcert Inc committee members changes
4. write a documentation for the advanced assurance method (add experience points), so the assurers who apply for the board flag (special assurance) can receive an advise how to enter the "special" assurances following AP 4.4 (especialy differentiate between temporary and permanent experience points). This probably also affects bug #1007 "add 5 Experience points for ATE attendance form"
5. add board flag setting to admin console to become admin console changeable flag (-> Software-Assessment, -> new bug#) so nominations to this new admin team can be easily handled by a Support-Engineer by request
Recommendation for future handling of Tverify flag
- All special assurance methods with transfers of points from other sources has been frozen.
- If there ever a new tverify program will be implemented, an Assurance subpolicy is required first
- A new software deployment then is the result for a new implementation.
- So therefor current state is: reset all tverify settings and remove all tverify related code from the Webdb
- Reset of the Tverify flag settings have been ruled within this current intermediate ruling.
Future monitoring of board and tverify flag
- Future monitoring of board and tverify flag setting shall continue as its overruled by another arbitration ruling or the requirements for monitoring disappears (eg. by software code removal)
- In the case, where an action is required because report lists one or more members with flag board=1 or tverify=1 set, the principles of this ruling regarding these flags shall be followed as precedent.
  - One party of the permissions review report (either Committee or Assurance Officer) shall forward the request with reference to this arbitration to Critical team to remove the flag of the reported member(s).
  - The "current state" with a short exec report to be sent by the Critical team to the Arbitrator of this case as Post Arbitration note and stored by the Arbitrator under this Arbitration file
  - Notification to the members that did undergo a flag reset shall be send by Board or Assurance Officer if not yet implemented in a flag removal script

Exec Quick Summary

update recipients list of patch bug #1003 (permission review script)
reset of flags for admin, ttpadmin, orgadmin to follow similar to nomination procedure
1. officer makes a proposal of removal
2. board approves the proposal
3. officer sends request to support with reference to motion number
4. support executes the request
5. document the process on team members list
6. notification to the team member removed
7. in cases where non-active team members are listed, file a dispute
arbitrated reset of board=1 and tverify=1 flags
1. collect current state
2. sql update query to be executed by critical team
3. notification to members with changed flag state
locadmin=1 reset is free to Board, Support (see recommendation)

Frankfurt/Main, 2012-04-29

Discovery IV

at least 2 new infos have been arrived, that needs review

Tverify flag setting: N.B.: I did not find any code to delete the ID scans, so there may still be a significant number of ID scans on the server...

2012-04-06 (SA2): response to (SA) question(s): Info and Opinion on TVerify

I'm currently not party of the Arbitration, but since I somehow have leaked into the communication I'll take the liberty to give an opinion and some info on TVerify.

IMHO the TVerify flag of all accounts may well be reset, and should not be part of further reports according to https://bugs.cacert.org/view.php?id=1003 because:

TVerify Admins are not needed any more, since the Thawte Freemail program has been history for quite some time now. 
Issued Thawte Points won't be relevant from some time in the (near?) future. 
From my own experience (I was Thawte verified, though never TVerify admin), some code review and a few intelligent guesses I'd describe the TVerify process as follows:

When the user requests to be TVerified a record is created in the TVerify table (I updated the table's description in https://wiki.cacert.org/Software/Database/StructureDefined), containing the CN contained in his Thawte certificate, plus optionally his URL in Thawte Freemail's Notary directory and/or a scan of one of his photo IDs 
Each TVerify Admin could get a list of pending TVerify requests. 
The TVerify Admin checks the information (goes to Thawte notary directory, verifies that the CN ) and looks at the ID scan 
If he's convinced about the validity of the request he accepts the request, otherwise he rejects it. 
Once a request gets 8 positive votes it is accepted, the requesting user gets a number of points to reach a point level according to the provided information: 
150 points if ID scan and Thawte Notary Entry have been provided 
90 points if only Thawte Notary Entry has been provided 
50 points if neither is given 
(N.B.: there seems to be a bug, if only ID Scan but no Notary Entry is provided) 
If 4 negative votes are recorded the request is rejected, nothing happens beside marking the request is closed and the requesting user gets an informational mail. 
The TVerify Admins do not get any (experience-)points for a vote.

N.B.: I did not find any code to delete the ID scans, so there may still be a significant number of ID scans on the server...

MfG
Ted
;)

identify all organisation administrators that are not CAcert assurer

Part IV.1

Where are these scans stored on creation time?
This issue is no flag setting, but relates to flag settings.
Scans are part of the transfer process. So its "active" data that may give evidence to the old special assurance program "Tverify" process.
TVerified a record is created in the TVerify table (Database and Table Structure) ... and/or a scan of one of his photo IDs

When has the non-copying of Id documents rule been decided?

AH: Id Document Photocopy is Forbidden by Default

Board motion EmailBoardDecisionsUpdateFeb2008#m20080422.3 says:

 * m20080422.3 Removal of copies of ID and identification number information from archives
 * Comments: CAcert when it started in 2002 required that copies of ID's were archived for 7-10 years in the archives of CAcert or archives of CAcert Assurers. In a later instance CAcert required to take note of ID numbers and/or social security numbers of the individual. For privacy reasons both (copy of ID, personal numbers) were dropped. The CAcert Assurance Programme form states that the information should be kept 7-10 years. CAcert Inc. drops the requirements for copies of ID and personal numbers and decides to remove these information from the CAcert archives and requires the CAcert Assurers who are in position of that information to do the same. The information should be deleted with care.
 * Copies of ID are not needed for operational purposes and are not compliant with European privacy Directive (EU DPA).
  * Decision: Accepted
  * Actions: delete paper and digital copies from archive; denote the action and decision in CAcert blog; ask CAcert Assurers to follow CAcert decision. Blog on DoB and Copy IS drop done as well board order to destroy them by operators/adminsitratores has been given in May 2008.

Blog post May 23rd, 2008 "Archived copies of Identity Documents should be destroyed within CAcert."

cacert-systemlog mailing list archive starts 2009-03
cacert-sysadmin mailing list archive starts 2008-04
- no mails found regarding removal of archived copies of Id docs from Webdb
cacert-board mailing list archive starts 2008-12

cacert-board-private list archive probably upto 2008-12

EmailBoardDecisions2008-09#m20081215.2

m20081215.2 Board email archive up to date of decision m20081215.1 is kept private

    * Comment: the old email archive will have private and sensitive info.
    * Decision: accepted (25th Jan 2009)
    * Votes: 4 Ayes, 3 pending
    * Action: start new archive.

ask board and critical team for an exec report from critical team about removal of archived copies of Id docs from around Apr 2008 - May 2008

2012-05-01 (Critical team t/l): response to digitaly Id doc scan copies on critical system - exist, critical team started Oct 2008

> 1. does exist an exec report from the Critical team or Software-Engineer
>    about removal of archived copies of Id doc scans from the webdb ?
>    (probably between April 2008 and January 2010 ?!?)

There is no such report to my knowledge. Please note that the current critical
team started its operation in October 2008, well after the quoted board
decision, and only gained its formal status somewhere in 2009.

> if no exec report exist, the alternate is to check current webdb
> 
> 2. does exist a directory
>        /www/photoid/
>    on the production server?
>    if yes, does this directory contains files of digital copies of
>    Id doc scans?

It does indeed exist, and contains 447 jpg, 88 png and 16 gif files,
the oldest one dating from 2005-03-16 20:22 and the most recent one from
2009-11-17 03:06. The files are numbered 1, 2, 3, but some numbers are
missing. The highest number present is 838. I have checked the content
of one file, and indeed it contains a scanned id document.

I'd propose to destroy all documents in this directory today by running
a shred operation on the individual files, then deleting all files.
Please ACK before we proceed to do that.

Regards,
-- wytze

2012-05-01 (Iang): clarification to board motion m20080422.3, no exec report received, ask if question sent to board-private can be disclosed

>   * Copies of ID are not needed for operational purposes and are not
> compliant with European privacy Directive (EU DPA).

Privacy regulators around the world adopt the principle that unless 
there is an operational reason for storing some sensitive information, 
it shouldn't be kept.

This originally came to light in the Netherlands.  If memory serves, it 
was do with some service organisation routinely photocopying passports 
of customers.  However because they could not explain the reason, they 
got in trouble.


> 1. does exist an exec report from the Critical team or Software-Engineer
>     about removal of archived copies of Id doc scans from the webdb ?
>     (probably between April 2008 and January 2010 ?!?)

Answering from memory, I don't recall any such report sent to board.  Iang.

> if no exec report exist, the alternate is to check current webdb
>
> 2. does exist a directory
>         /www/photoid/
>     on the production server?
>     if yes, does this directory contains files of digital copies of
>     Id doc scans?
>
>
> Thanks for your assistance in advance
>
>


I'm curious -- does this need to be board-private?  One could argue that 
liabilities exist.  But we have a disclosure policy and we have 
substantial protection in our DRP.

2012-05-01 (Piers): new board motion placed (pending): motion m20120501.1 "Removal of copies of ID and identification number information from archives"

m20120501.1
Removal of copies of ID and identification number information from archives

Motion to confirm earlier board decision in 2008 (m20080422.3) to delete
paper and digital copies  of ID and identification number information from
archive.

Please see:
https://wiki.cacert.org/EmailBoardDecisionsUpdateFeb2008#m20080422.3

2012-05-01 (dirk): "if we now delete the id-documents, CAcert will not be able to track these members in case of arbitration."

according to the new motion piers placed i will vote with 'naye' at the current state.

why?

we (may) have up to around 900 members coming from tverify. not all of them agreed to the CCA, some of them had not been assured by other members ... so this tverify-assurance is their only one.

if we now delete the id-documents, CAcert will not be able to track these members in case of arbitration.

if they cannot act as an assurer anymore the 'risk' of arbitration may be lower (however ... there may have been cases before they loose the assurer-status ...)

please let us think about this ... ;-)

have a nice day ...

dirk / CAcert board member

2012-05-01 (A): verification of 8 positive or 4 negative votes

/includes/account.php line 2885 ff.

line 2898
  $rc = mysql_num_rows(mysql_query("select * from `tverify-vote` where `tverify`='$uid' and `vote`='1'"));
  if($rc >= 8) {

=> 8 positive votes are needed to get the request transfered to the notary table (automaticly) with method 'Thawte Points Transfer'

line 2937
  $rc = mysql_num_rows(mysql_query("select * from `tverify-vote` where `tverify`='$uid' and `vote`='-1'"));
  if($rc >= 4)

=> 4 negative votes, notification to the applicant was sent, that the request was denied.

votes were given by CAcert members with Tverify admin flag set
the process of "assurance" was splitted over 8 tverify "assurers" before one record has been created in the notary table with method "Thawte Points Transfer"

In case of an existing digitaly Id doc scan, the Thawte Points Transfer assurance was good for addtl. 60 points (on top of 90), splitted in 10 Assurance Points and 50 Experience Points in relation to current AP/EP regime that follows AP. Thawte program doesn't follow AP. No Subpolicy written, no subpolicy exist.

Points allocation	Points current counting	AP points counting	requirement(s) for transfer	checked by CAcert tverify-admin assurers
150	100+50	AP/EP	digitaly Id doc scan + Thawte Url + Thawte Cert	8
90	90	AP	Thawte Url + Thawte Cert	8
50	50	AP	Thawte Cert	8

Thawte Points Removal process is WIP under bug #1023 (or followup) and backed up by board motions

m20090912.1 that freezes all special assurance programs not handled by a subpolicy under AP and
m20090914.2 take it in effect.

m20090928.1 "Run Tverify as-is until End Of Life 20091116"

m20090928.1
Run Tverify as-is until End Of Life 20091116

Tverify programme is to restart, for a short period until 16th of November,
or whenever the hosting CA shuts down their web of trust and makes the
information unavailable by server control or revocation of certificates. 
This overturns motion m20090912.1 for Tverify only.

These restrictions to apply:

a. The Assurance Officer, Event Officer and Board to have visibility over
the programme.

b. The number of points allocated to a member who provides a certificate
with full Name and details is 25 as is, or up to 50 if there is alternative
evidence over the Name, email and date of birth (see below).

c. Additionally, if the voting group of Tverifiers can see evidence of
\"full Thawte Notary status\" in the Thawte system, they can
allocate another 25 points, or up to 50 if there is evidence of the date of
birth.

d. Evidence of date of birth may be provided by a scan of a high quality
photo-id document, signed by the certificate, or by the Thawte online
system.  Scans must be destroyed once examined.

e. The maximum points allocated by the sum of the above methods is 100
assurance points.  Experience points are not transferred.  Assurer\'s
judgement must be applied.  Our Tverifiers (our CAcert Assurers) are
responsible for this system.  No responsibility is placed on Thawte.

f. All points that are allocated under the Tverify system are to expire no
later than 20101116.  This is retrospective.  Implementation depending. 
Members with Tverify points should be warned, at least one month before the
cut-off.  However to give the implementation team maximum flexibility,
there is no definate requirement on warnings, and the team must go ahead if
warnings prove too difficult to deliver.

All points so allocated under the Tverify system should be marked as such
to permit early expiration.

g. Work already done on preparing the Tverify subsidiary policy may be
redirected to creating a policy to accept the certificates of other CAs as
evidence of Name and email.

h. After the system is shut down, the Tverify team is requested to advise
to board on basic statistics and observations.

1. Website information

We collect two kinds of information about website users: 1) data that users volunteer by signing up to our website or when you send us an email via our contact form; and 2) aggregated tracking data we collect when users interact with our site. 

[...]

5. Notification of changes

If we change our Privacy Policy, we will post those changes on www.CAcert.org. If we decide to use personally identifiable information in a manner different from that stated at the time it was collected, we will notify users via email. Users will be able to opt out of any new use of their personal information. 

[...]

8. Privacy of user data

CAcert Assurers can see the name, birthday and the number of points by looking up the correct email address. No other person related data is published by CAcert. 

9. Exceptions

A CAcert arbitrator may override this policy in a dispute. To obtain access to confidential data, a dispute has to be filed.

10. Legal mandates

CAcert adopts the Australian privacy regulations. Please see http://www.privacy.gov.au/ for further details. Governmental warrants and civil supoenas will be processed through the dispute resolution system, which ensures that valid authority is given to whoever complies with the supoena or the warrant.

CCA 1.4 Privacy

You give rights to CAcert to store, verify and process and publish your data in accordance with policies in force. These rights include shipping the data to foreign countries for system administration, support and processing purposes. Such shipping will only be done among CAcert Community administrators and Assurers.

Privacy is further covered in the Privacy Policy ("PP" => COD5).

Assurance Policy 7. Privacy

The Member's information can be accessed under these circumstances:

 * Under Arbitrator ruling, in a duly filed dispute (Dispute Resolution Policy => COD7);
 * An Assurer in the process of an Assurance, as permitted on the CAcert Assurance Programme (CAP) form;
 * CAcert support administration and CAcert systems administration when operating under the authority of Arbitrator or under CAcert policy.

Part IV.2
- bug #512, current state: new, bug submitted: 2008-03-07, needs work
- bug #967, current state: needs review, tested, close before transfer to production, bug submitted: 2011-08-08
  - the bugfix handles new cases, but there might be "old" Organisation-Assurers listed
  - once the patch is submitted an adhoc query makes sense to identify all "old" non-assurers added in the past

Intermediate Ruling #4

In the intermediate ruling #4 I'll handle following 2 questions that are outlined under Discovery IV.

Tverify flag setting: N.B.: I did not find any code to delete the ID scans, so there may still be a significant number of ID scans on the server...
identify all organisation administrators that are not CAcert assurer that has been added by (C2)

Part IV.1 - delete ID scans on the server

The discovery process IV revealed that, despite the fact, a board motion m20080422.3 back in April 2008 ordered the removal of digitaly stored Id doc scans on the system, the order has not been processed in full.
A second board motion m20090928.1, that also orders "Scans must be destroyed once examined." hasn't been followed too.
The current report from Critical team revealed remaining "447 jpg, 88 png and 16 gif files, the oldest one dating from 2005-03-16 20:22 and the most recent one from 2009-11-17 03:06." digitaly stored Id doc scans on the production server.
Board motions m20080422.3 and m20090928.1 still made it clear, that all digitaly stored Id doc scans have to be removed, main reason given: to be in compliance with DPA and the CAcert policies.
One might argue, that "CAcert will not be able to track these members in case of arbitration".
- Considering this issue, we're talking probably about 3 to 6 months, until the Software Patch bug #1023 to remove the "Tverify transfered points" will become active. Then "Thawte transfered points" are still CAcert history.
- No one CAcert policy backs up the storage of "digitaly stored Id doc scans".
  1. not Privacy Policy
  2. not CCA 1.4 Privacy
  3. not Assurance Policy 7. Privacy
- In the meanwhile (between removal of the old Id doc scans and the removal of the Tverify points), Arbitration can rely on the process, that 8 (Assurers) Tverify admins had to process an Tverify transfer process. In the case, an Id doc scan was available by the time, the Tverify admins have to check the DoB from the Id doc scan against the DoB as entered into the CAcert online system. So here we talk about a presumption that 8 Tverify admins have failed the DoB check. Considering the 50% error rate that has been discovered in the audit process back in 2009 regarding DoB errors, at least 4 Tverify admins had the chance to stop the process of transfer
- On weightening the likelyhood that a dispute will be filed that requires a confirmation by a Tverify admin that the Tverify admin cannot answer by himself, as he has no longer a chance to get access to the Id doc scan (this is prevented by the software "you've allready voted") of a specific user, its also unlikely, that an Arbitrator will use the "Thawte Points Transfer" method record to gather evidence over a specific user. So its more likely that an Arbitrator requests for an assurance under AP or subpolicy TTP-assisted-assurance.
So therefor I rule, that the remaining digitaly copies of Id doc scans to be removed asap from the production system, following the procedure proposed by Critical team t/l.
Critical team shall send in an exec report with reference to board motions and this arbitration case:
1. Board motion m20080422.3
2. Board motion m20090928.1
3. Arbitration case a20110118.1
  - by following the Security Policy 5.6. Report standards
A blog post shall be prepared and published once the exec report from Critical team has been received responding to Archived copies of Identity Documents should be destroyed within CAcert. 2008-05-23 and Thawte Web of Trust Shutting Down 2009-10-15 that the removal of all remaining digitaly stored Id doc scans has been executed.
Why the board motions had not been followed is not subject to current intermediate ruling and requires further investigations
The directory with digitaly stored Id doc scans shall be monitored, probably included in the permissions review script bug #1003, by the count of files residing this special directory. The report shall go to Board (Committee) (see definition under intermediate ruling #3). In the case a removal of files is required, Board shall start a request to Critical team to execute the removal of such files according to current ruling as precedent. The report to Arbitration to be added as post arbitration note to this current case file.

Part IV.2 - Identifying special Organisation-Admins

The subject "identify all organisation administrators that are not CAcert assurer" relates to a Software bug that is still WIP bug #967
- This bugs current state is: needs review, is tested, close before transfer to production
- This bugfix handles new cases, but doesn't handle "old" cases of Organisation-Assurers with state is-not-assurer listed
So therefor I rule that once the patch bug #967 is submitted and installed on production system
1. Software-Assessment team shall deploy or verify an adhoc query that identifies all "old" non-assurers Organisation-Admins with the result set:
  1. name and
  2. email of the Organisation-Admin and
  3. the name of the Organisation where the Org-Admin is asigned to
2. Critical team shall execute this adhoc query
3. Critical team shall send the report to the Organisation-Assurance-Officer.
4. Organisation-Assurance-Officer shall contact the Organisations and the Org-Admins to get in compliance with the "Is-Assurer" requirement of Org-Admins. To give the Organisations and Org-Admins appropiate time to become in compliance with OAP. In cases where other Org-Admins working for the Organisation as Org-Admin that fulfills the requirement, OAO is allowed to remove the Org-Admin that doesn't fulfill the requirement. Otherwise to file a dispute. OAO is allowed to delegate these tasks to other Organisation-Assurers.

Frankfurt/Main, 2012-05-01

Discovery V

2012-06-21 (SA): sent patch request bug #1003 to (Critical team)

2012-06-21 (Critical team): patch bug #1003 installed on critical system, permission reset script ready to be executed

The fix has been applied to the production server on June 21, 2012.
See also the attached log message that was sent to cacert-systemlog.

I have also executed "make upload" and "make all" in locale and
restarted the apache2 service.

Shouldn't there also be a request to execute the resetpermissions.php script,
or will that come from the Arbitrator?

Regards,
-- wytze

Intermediate Ruling #5

According to the intermediate ruling #3 dated from 2012-04-29

Critical team shall implement the recuring (by cron job?) execution of the permissions review script as given by the bug patch #1003 dated from 2012-06-21
Critical team shall also execute once the permissions reset script that has been added under patch bug #1003 dated 2012-06-21 to reset the board and tverify flags in the webdb users table. The exec report shall be sent to the Arbitrator of this case and to be kept under this arbitration file. Critical team is allowed to execute this special script by order of the admins / officers who monitors the board and tverify flags once it needs further permission removals. So this ruling is set as precedent for this special case if board and tverify flags are set that needs a reset.
AO and OAO shall start with a reset of the old TTPadmin flags to prepare the new TTP-assisted-assurance program.

Frankfurt/Main, 2012-06-23

Discovery VI

2012-06-23 (Critical team): exec report regarding intermediate ruling #5

The cron job was already in place for the previous version of the
script, and has remained in place. Execution is scheduled to occur
once per three month, and the next occurrence will be on July 1.
[...]
The script has been executed on June 23, 2012. The output of the run has
been attached to this e-mail. Note that I've executed the script twice,
with the second execution purely meant as an extra verification that the
first execution worked as intented -- and indeed it did.

>    The exec report shall be sent to the Arbitrator of this case and to be
> kept under this
>    arbitration file. Critical team is allowed to execute this special
> script by order of
>    the admins / officers who monitors the board and tverify flags once it
> needs further
>    permission removals. So this ruling is set as precedent for this
> special case if board
>    and tverify flags are set that needs a reset.

OK.

>  * AO and OAO shall start with the reset procedure of the old TTPadmin
> flags to prepare the new
>    TTP-assisted-assurance program.

Left for them :-)

Regards,
-- wytze

Board flags removed: 2 members affected
Tverify flags removed: 83 members affected

2012-06-27 (C2): note and extended intermediate ruling proposal request regarding intermediate ruling #5

please see the attached part and think about moving on in this 
directions to get the TTP running.
Regarding intermediate ruling #5 dated 2012-06-23
under Arbitration case a20110118.1
https://wiki.cacert.org/Arbitrations/a20110118.1
the order to start with the reset of the old TTPadmin flags to prepare
the new TTP-assisted-assurance program has probably a deadlock
as identified in our Software-Assessment project team meeting
dated 2012-06-26
https://wiki.cacert.org/Software/Assessment/20120626-S-A-MiniTOP
and the infos given under
https://wiki.cacert.org/TTP/TTPadmins  Removal Procedure
and intermediate ruling #3 dated 2012-04-29
point g. in cases where non-active team members
          are listed, file a dispute
we're still running the dispute that affects this case.

The Board motions m20090912.1 and m20090914.2 deactivated the
"Old" TTP program, but the motion did not find its way into
the system flag settings for TTPadmin flags of 4 CAcert members.
So it will be helpful to enhance the intermediate ruling #5
under Arbitration case a20110118.1 to handle the cases following
the board motions m20090912.1 and m20090914.2
https://community.cacert.org/board/motions.php?motion=m20090912.1
https://community.cacert.org/board/motions.php?motion=m20090914.2
to remove the TTPadmin flags from user accounts that aren't yet
nominated and appointed to the new TTP-assisted-assurance program
according to https://wiki.cacert.org/TTP/TTPadmins
(point 2. g.)

-- 
mit freundlichen Gruessen / best regards
Marcus Maengel

Intermediate Ruling #6

This intermediate ruling extends the intermediate ruling #5 dated 2012-06-23 on the TTPadmin flags removal procedure.

Board motions m20090912.1 and finaly m20090914.2 terminated the "old" TTP program, that was no longer in compliance to Assurance Policy that takes in effect since Policy Group decision p20090105.2. The board motions takes care about this termination of the "old" TTP program. The permissions removal of TTPadmin's had not been executed. The new TTP-assisted-assurance policy was voted to DRAFT p20100913 but hasn't been set active yet as it wasn't in compliance to the new TTP-assisted-assurance policy. In the meantime the new TTP-assisted-assurance policy processes has been deployed (nomination, removal procedures, ttpadmin procedures and much more). Also software has been updated to reflect step 1 in the TTP-assisted-assurance process. New TTP Assurers have been nominated and appointed with motions m20120325.2 so all what is missing, is the reset of the TTPadmin flag for the TTPadmins of the Old TTP program. As the old TTP program runs out of AP scope, so nomination and removal procedure of old TTPadmins didn't follows any defined procedures nor policy.

To move forward with with the new TTP-assisted-assurance program, AO + OAO shall initiate the reset of the Old TTP program related TTPadmin flags of affected members with reference to board motions m20090912.1 and m20090914.2 that did terminated the old TTP program via Support. AO + OAO shall notify the members that applies to the TTPadmin flag removal that the flags have been removed according to termination of the old TTP program and the deployment of the new TTP-assisted-assurance subpolicy with the new nomination and appointment process. The affected members later can send a request for nomination and appointment under the new processes again.

This intermediate ruling only applies once for the initial process until the new TTP-assisted-assurance program including the appointment and removal procedures has been set active

Frankfurt/Main, 2012-06-27

Discovery VI

2012-10-23 (A): had some talk with (C2), (C), (CM) and others in Software-Assessment project team meeting 20121023 under Minutes 1.3, identifying and clarification of a20110118.1 (current case) intermediate ruling Part IV.2. referenced software bugs/patches: bug #967, bug #512
- Dispute received under [s20121021.322] is yet handled and ruled by intermediate ruling a20110118.1 intermediate ruling #4, Part IV.2 from 2012-05-01, just to process
- further reference of bug #512 (less then 100 AP) falls under the definition "Is-Not-Assurer" as "Is-Assurer" has 2 requirements:
  1. reach at least 100 AP's
  2. pass the CATS test

2012-10-23 (SA t/l): (who is also (C) in current case): passes the SQL query proposal under [s20121021.322], tested, to (Critical team) following intermediate ruling #4, part IV.2

In the arbitration case a20110118.1 there is a ruling that the Software
Team shall verify an SQL query that lists all Org Admins that are not
Assurers:
https://wiki.cacert.org/Arbitrations/a20110118.1#Part_IV.2_-_Identifying_special_Organisation-Admins

We have reviewed the following query:

SELECT `users`.`email`, `users`.`fname`, `users`.`lname`,
`orginfo`.`O`, `orginfo`.`id`
FROM `users`, `orginfo`, `org`
WHERE `org`.`orgid` = `orginfo`.`id` and `org`.`memid`= `users`.`id` and
`users`.`assurer` = 0 and `org`.`deleted`=0
ORDER BY `users`.`email`, `orginfo`.`O`


The result of this query should be sent to the Organisation Assurance
Officer.

-- 
Have a nice day,
Michael Tänzer

20121-10-24 (Critical team): response to exec request of SQL query sent by (SA t/l) following intermediate ruling #4 part IV.2. Result sent to (C2) in role as (OAO)

-----Original Message-----
From: Wytze van der Raay [mailto:wytze@cacert.org] 
Sent: Wednesday, October 24, 2012 1:14 PM
To: Michael Tänzer
Cc: critical-admin@cacert.org; Ulrich Schröter CAcert; Marcus Mängel; Benny Baumann
Subject: Re: SQL Query for a20110118.1

Op 23-10-2012 22:49, Michael Tänzer schreef:
> In the arbitration case a20110118.1 there is a ruling that the Software
> Team shall verify an SQL query that lists all Org Admins that are not
> Assurers:
> https://wiki.cacert.org/Arbitrations/a20110118.1#Part_IV.2_-_Identifying_special_Organisation-Admins
> We have reviewed the following query:
> SELECT `users`.`email`, `users`.`fname`, `users`.`lname`,
> ...
> The result of this query should be sent to the Organisation Assurance
> Officer.

FYI: the query has been executed and its results have been emailed to
Marcus Mängel in his capacity as Organisation Assurance Officer.

Regards,
-- wytze

2012-10-24 (C2): phone call with (A), some talks about further processing
- note: (C2) received report from (Critical team) and was quite astonished about the large amount of people listed
- question that araised: how to proceed?
  1. I do not need the count of affected Org-Admins that aren't in compliance with the requirement Is-Assurer (100 AP, CATS passed)
  2. manual handling is probably no option by given account
  3. other options:
    1. SQL adhoc scripted notification to recipients and summary to OAO
    2. scripted mailing following existing precedent case a20110608.1 "Scripted Mailing to Organisation contacts"
2013-01-17 (Critical team): exec report of bug #512 implementation
- The script (oa-mailing) has been run on January 17, 2013
- oa-mailing sent to 186 recipients.
2013-02-26 (SA): ADadmin in permissions review script is missing (identified in Software-Assessment project telco 2013-02-26)
- Advertisement
- permission review script doesn't include ADadmin
- relates to bug #1003 and Arbitration case a20110118.1
- board motion? treasurer? adadmin?

From Discovery 2012-03-30

A. Flags that are discovered and reported under the permissions review script
B. Flags that can be reset by a Support-Engineer by receiving an order to do so

      Flag               |  A  |  B
-------------------------+-----+-----
Code signing             |     |  +
Org Assurer              |  +  |  +
TTP Admin                |  +  |  +
Location Admin           |  +  |  +
Admin (Support-Engineer) |  +  |  +
Ad Admin                 |     |  +  <==
Tverify Account          |  +  |  +
Board member             |  +  |  -

adadmin flag in database (updated)
- adadmin
  
  tinyint(1)
  
  0 = none, 1 = submit, 2 = approve

From Discovery II

2011-02-22 results from Software-Assessment Project Team meeting 2011-02-22, Topic 'Security check procedures' - define list of groups, who can see list of flag-owners

Flag	What to show	Who should read results	Remarks
codesigning	count()	public
admin (SE's)	list	board, support, own group
ttpadmin	list	board, support, own group	current ttpadmin's to revoke ?
orgadmin	list	board, support, own group
board	list	board, support, own group
tverify	list	board, support, own group	current state to revoke ?
locadmin	list	board, support, (own group? -> later ?)
adadmin=1	list	board, support, own group	0=not set, 1=submit, 2=approve
adadmin=2	list	board, support, own group	0=not set, 1=submit, 2=approve

count() = counter within statistics
list: defines Givenname, Lastname, email, (country)

Adding adadmin into permissions review script has been ruled under Intermediate Ruling #2
- As of request by (C), result list from Intermediate Ruling #1 (C) is allowed to distribute the result list within the groups as defined under proposal Discovery_II with user names and email, and addtl. country where its appropriate (eg orgadmin, locadmin)
- In the script implementation flag adadmin check had not been included. This is a subject of implementation (-> Software bug)
- in subsequent analysis this adadmin flag gets never picked up, so its also missing in the NEW Proposal (2012-04-05)
- Who should receive notifications about adadmin settings?
  - Board/Treasurer is the executive for Advertisements, so they needs to know who can add and approve Advertisements
  - Support, may be an intended recipient to check requests to add or remove a user from the adadmin list
  - Own group: members who adds Advertisements may vary. The adadmin's have not to know each other. Authority is given by Board

modified 2013-03-12

Flag	What to show	Who should read results	Remarks
adadmin=1	list	board, support	0=not set, 1=submit, 2=approve
adadmin=2	list	board, support	0=not set, 1=submit, 2=approve

from Questions A table (above)

Permissions reviewed, Responsible parties, Groups/Officers/Members who received results

      Flag      | Critical | checked | responsible area/officer       | results received
----------------+----------+---------+--------------------------------+-------------------
Org Assurer     |    -     |    +    | Assurance: OAO                 | OAO: Yes AO: No
TTP Admin       |    -     |    +    | Assurance: AO, OAO x1)         | OAO: No  AO: No
Location Admin  |    -     |    +    | Executive: Board, Support      | Board: Yes Support t/l: No
Admin (SE)      |    +     |    +    | Executive: Support t/l, Board  | Board: Yes Support t/l: Yes
Tverify Account |    -     |    +    | pre-AP: Board, post-AP: AO x2) | AO: No
Board member    |    -     |    +    | pre-AP: Board, post-AP: AO? x3)| AO: No
adadmin         |    -     |    -    | Executive: Board, Support      | Board: No, Support: No

Flag	What to show	Who should read results
/ recipient(s)		Board	SE t/l	AO	OAO	Support	own group
admin (SE's)	list	+	+			+	+
ttpadmin	list	+		+	+	+	+
orgadmin	list	+		+	+	+	+
board	list	+		+		+
tverify	list	+		+		+
locadmin	list	+	+			+
adadmin=1	list	+	+			+
adadmin=2	list	+	+			+

Intermediate Ruling #7

In the intermediate ruling #7 I'll handle following questions:
1. Shall adadmin flag check added to the permissions review script?
2. Who shall receive notifications of adadmin settings?
3. Who can add and remove adadmin's?
Questions answered:
1. Shall adadmin flag check added to the permissions review script?
  - As found under Deliberations VI, adding adadmin into permissions review script has been ruled under Intermediate Ruling #2
  - I hereby renew this ruling, as no reasons given, to not add this adadmin flag check to the permissions review script
2. Who should receive notifications about adadmin settings?
  1. reasons given:
    - Board/Treasurer is the executive for Advertisements, so they needs to know who can add and approve Advertisements
    - Support, may be an intended recipient to check requests to add or remove a user from the adadmin list
    - Own group: members who adds Advertisements may vary. The adadmin's have not to know each other. Authority is given by Board
  2. I hereby rule, that Board and Support should receive the notifications regarding adadmin
3. Who can add and remove adadmin's?
  - The reset of adadmin flags is subject to Board authority, so Board is allowed to order additions or removals of members from the adadmin list (similar to the location admin flag procedures)
Exec summary on adadmin
1. update flag check, add adadmin check and add recipients list to patch bug #1003 (permission review script) (or similar new bug#)
2. reset of flags for adadmin to follow similar to nomination procedure (ticket from Board to Support)

Frankfurt/Main, 2013-03-12

Ruling

Execution

Similiar Cases

Arbitration cases

a20090427.2	Ad hoc SQL query requested
a20090810.4	Emergency access to CAcert critical systems
a20090810.1	Emergency code change without dual control
a20100822.1	SQL query
a20101114.1	Addtl. ad hoc interactive sql-query
a20121021.1	SQL query to reveal who of the Organisation Administrators have not the CAcert Assurer status (dupe of current case)

Bug reports

bug #1003	Provide a possibility to regularly review the permissions in the system
bug #855	Fix adding TTP assurance method on testserver (was: admin console lists "empty" and "Unknown" ...)
bug #1007	add 5 Experience points for ATE attendance form
bug #512	0000512: admins must have 100 points
bug #967	0000967: Give an OA the oppertuntiy to check if a desiginated Organisation Admininistrator is a CAcert assurer