• Arbitrations
• a20100210.2

• Case Number: a20100210.2
• Status: closed
• Claimants: Mathias T
• Respondents: CAcert

• Case Manager: SebastianKueppers

• Arbitrator: UlrichSchroeter

• Date of arbitration start: 2010-02-11
• Date of ruling: 2010-02-12
• Case closed: 2010-02-12
• Complaint: Birthdate error (with assurance points)
• Relief: correction of DoB

Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: Mathias T (C), Case: a20100210.2

History Log

• 2010-02-10 (issus.c.o) case [s20100210.181]

• 2010-02-11 (UlrichSchroeter): added to wiki, request for CM / A

• 2010-02-11 (Joost S): [s20100211.73] confirms DoB to correct, accepts CCA / DRP
• 2010-02-11 (CM): I'll take care about this case
• 2010-02-11 (A): I'll take care about this case
• 2010-02-11 (A): sent init mailing to (C) cc (CM), with request for accepting CCA / DRP under this arbitration
• 2010-02-11 (C): I accept CCA / DRP under this Arbitration
• 2010-02-11 (A): request to (C) if he wants to revoke the assurance (user authorisation for support SP 8.1.)
• 2010-02-11 (Support): did interact within this cases discovery and ruling w/o further requests to the appointed CM or A

Discovery

• this error happens after a big event
• this error happens close to the event, after applying the assurance points, in identified by the (C) itself and other assurers, that doesn't transfered their assurance points
• there was no malfeasance of any type alleged or found

• there is a definition under Security Manual (Support) 8.2.1. Support Engineers to revoke an assurance, so the user can correct an error

  • revoke an assurance
    • on request of the Assurer, suggested by Alejandro, now filed as dispute. either Assurer + Support, in a short time frame
    • the dispute was not filed by an assurer to remoke his assurances
• addtl. checks: SP 1.2, 8.1

• Security Policy 8.1. Authority

  • If the Member's authority is not in doubt, the Member can give that authority. If not, the Arbitrator's authority must be sought.
    • the authority by the user is required or
    • the authoirty by the arbitrator is required
    • user authority was given as stated in the history log thru (A), not (Support)

• Security Policy 1.2. Principles

  1. dual control -- at least two individuals must control a task
     • is given by the user and one SE
  2. four eyes -- at least two individuals must participate in a task, one to execute and one to observe.
     • is given by the user and one SE
  3. redundancy -- no single individual is the only one authorized to perform a task.
     • is given by the user and one SE
  4. separation of concerns -- when a core task is split between two people from different areas
     • is given by the user and one SE
  5. Audit -- where external reviewers do checks on practices and policies
     • is there a log that logs SE admin console activities?
  6. Authority -- every action is authorised by either a policy or by the Arbitrator.

     • general authorisation may be covered by SP 8.1 and SM 8.2.1. But what means short time frame ?

• what does short time frame mean ?

  • the request from (C) received support 3 days after the big assurance event (FOSDEM)

  • the request from (C) was a result of an email received by (C) from other assurers who find a data mismatch in the account.
• lock an account doesn't prevent further assurers from transfering points to the account

* 2010-02-11 (S) Masterdata (Birthday) change in the Database after receive eMail of (C) which contains copy of card indentity from (C) the informations are correct with the statement of (Joost S), also revoked an assurance under definition Security Manual (Support) 8.2.1. (moved from the Execution section, was edited by Martin S)

Ruling

1. Case a20100210.2 Ruling

• I hereby order, that Support can act on DoB errors and naming mismatches by request from an user as authorized by SP 8.1 under the following conditions by revoking assurances, so the user account gets 0 assurance points and the user can correct the error himself.
• SE has to check the user account:
  • the request for revoking an assurance has to meet the following conditions:
    1. 1. assurance points in total less than 50 assurance points (3 x 15 points or 35+10+4 points, less than 50) not more than 49 assurance points, otherwise the user enters the level of 50 assurance points with the option to create client certificates with name in it, so an addtl. check needs to be done. this cannot be handled thru SE right now w/o further patching the system)

          => or

       2. no certs created by the user (must be verifiable by the SE thru admin console w/o hijacking the account)
    2. assurance points are added as a result from the last assurance event / big event
       1. Events within 3 d or 7 d after an event
          1. big events (GT 1 day events, including weekend days) i.e. CeBIT, Fosdem, Froscon, Linuxtag. delays in trying to transfer points is upto 1 week (7 days), so errors probably cannot be seen and so therefor identified before the 6th or 7th day.

             • short time frame => less then 7 days (including), within 7 x 24 hours after an event = 168 hours

          2. small events (1 day events) upto a 72 hours delay (from experiences with events from one year)

             • short time frame => less then 3 days (including), within 3 x 24 hours after an event = 72 hours

          => or

       2. 24 hours rule
          • the assurance has been added within 24 hours while the request was received

          • current system state as per Feb 11th 2010 doesn't display assurance-when field from the database to SE, so this may be available someday

    3. all false assurances have to be from the same event (location info of assurance) and must meet the assurance in question. No older assurances from individual or other assurance events are accepted.
    4. no assurances done by the user
    5. (if a+b+c+d doesn't apply) otherwise the case must be transfered to arbitration
    6. procedure for support:
       • if single false assurance: proceed
       • if multiple assurances: contact assurers and ask, wait 2 days for reply
         • all agree: proceed
         • NOT(all agree): send to arbitration
  • SE has no permission to change data on his own
  • SE needs a confirmation by email from (C) to revoke the assurance

If an Assurer request for removal of an assurance, because he has made a mistake, this assurance can be revoked from SE by request from the assurer within 24 hours after assurance is added to an account.

• SE has to follow these rules:
  1. send notification to Assuree that the assurance has been revoked by Assurers request by an email
  2. inform Assurer that the assurance has been revoked by an email

This ruling can be used as a precedence for future cases.

Further I rule: for keeping the audit trail intact, each support ticket following this ruling needs to be added to this ruling as a post arbitration case note by adding the date and the Support ticket number onto the list.

2. Ruling about SEs interaction w/o execution order

The pre-ruling execution by the SE Martin S. I condemn hereby severely. SO has been informed in the meanwhile to take any action that seems to deem fit as by the ABC ruling of case a20091215.1 has been given in advance.

Frankfurt/Main, Feb 12th 2010 Ulrich Schroeter

Execution

• 2010-02-12 (A): Ruling sent to (C), (CM), Support, Martin S in the role of SE, Ian in role as SO, A in case a20091215.1
• 2010-02-12 (A): Sent execution request to (Support) with request for confirmation. Also notification for using outlined ruling for future DoB and Name change requests, also to Assurers request for revoking assurances.
• 2010-02-12 (A): Sent Report req. to SO, what actions he will take over Martin S about unauthorized modifications onto the users data.
• 2010-02-12 (A): rcvd report from SO: disabled the account in OTRS using the temporary/invalid button, and turned off the SE flag in the cacert.org system (about ruling #2)
• 2010-02-12 (A): rcvd exec req. report from support: There is no assurance on this account, Assurance points is Zero
• 2010-02-12 (A): execution order req. to (C), to correct the data in his account by himself, req. to confirm data correction
• 2010-02-12 (C): It seems the correct data was set correctly
• 2010-02-12 (A): sent notification to known assurers waiting to transfer assurance points to (C)'s account
• 2010-02-12 (A): case closed.

Similiar Cases

Post Arbitration Notes

Late comment on execution steps:

• Support Execution steps have to be:
• Request (C)'s confirmation to revoke Assurance(s) by email
• Revoke Assurance(s) that is given thru (C)s confirmation
• Report back to (C) with execution order request to correct the data in his account by himself, request confirmation reply
• Wait for the confirmation reply from (C)

• If there are known assurers awaiting transfering the points to (C)'s account, notify the Assurers that correction has been made

• 2011-02-17 further procedural clarifications see ruling under a20101016.1

• CategoryArbitration

• CategoryArbCaseAccountDataDoB