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

History Log

Original Dispute, Discovery (Private Part) (optional)


  1. 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 ?
  2. 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.
  3. Policies relating to this case
  4. 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


        Purpose of access



        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)
  5. 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
  6. Potential flags in the Database to check (from CAcert Software Database Structure Defined

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


        1 if published in Assurer List



        1 if allowed to request code signing certs






        1 if user is admin



        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



        1 if user is Org admin



        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.



        1 if user is tverify admin (?)



        1 if user can administer the location database



        1 if user may administrate advertisement (?)



        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.



        1 if user may not become assurer

  7. 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);
  8. 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
  9. simple query regarding part I of (C)'s request
    • select users.fname, users.lname,, 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:

Frankfurt/Main, 2011-02-22

Discovery II

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



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

B. Who can order actions of flag removals?

C. ''Question:'' 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. 2012-03-30 (SE): phone call to (A): board flag cannot be removed under admin console

Intermediate Ruling #3

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

Questions B. - F.

Future handling of Board and Tverify flags

Exec Quick Summary

  1. update recipients list of patch bug #1003 (permission review script)
  2. 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
  3. 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
  4. locadmin=1 reset is free to Board, Support (see recommendation)

Frankfurt/Main, 2012-04-29

Discovery IV

Intermediate Ruling #4

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

  1. 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...
  2. identify all organisation administrators that are not CAcert assurer that has been added by (C2)

Part IV.1 - delete ID scans on the server

Part IV.2 - Identifying special Organisation-Admins

Frankfurt/Main, 2012-05-01

Discovery V

Intermediate Ruling #5

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

Frankfurt/Main, 2012-06-23

Discovery VI

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

Intermediate Ruling #7

  1. 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?
  2. 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)
  3. 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



Similiar Cases

Arbitration cases


Ad hoc SQL query requested


Emergency access to CAcert critical systems


Emergency code change without dual control


SQL query


Addtl. ad hoc interactive sql-query


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

Arbitrations/a20110118.1 (last edited 2014-05-11 14:54:19 by MartinGummi)