Before: Arbitrator EvaStöwe (A), Respondent: CAcert (R), Claimant: Bruno (C), Case: a20141024.1

History Log

complete communication history of this case (partly anonymised)

Because there were a lot of activities steered up because of some decisions in this case, a complete history of the communication as documented in the private part of this case is published.

The DRP states, that the proceedings are ordiarily private. But this case seems to be of public interest.

The reasoning behind this decision is:

Because of the the Arbitrator of this case has decided to make the communication of this case (the collection within the private part) public, in a partial anonymised version.

communication of a20151024.1

Private Part

EOT Private Part

original Dispute

Discovery

Since the latest changes of the CAcert Community Agreement (CCA) the termination of accounts does not have to be handled by an Arbitrator if a process for the termination of accounts is defined by an Arbitrator in an Arbitration case.

Support is able to handle the termination of accounts when no CAP forms have to be handed over, or any other special action has to be done, comparable cases do not need to be handled by Arbitration.

Since the ruling given in a20141231.1 it is clear that delete account cases for assurer accounts do not require either the revocation of assurances or a handover of CAP forms, which both would have needed the direct authority of an Arbitrator.

Cases that are comparable to this one could be handled by Support, if an according process is defined in a precedents ruling.

This should be done in this case.

As it is sensible to have only one process for all delete account cases the process defined here should also replace any previous delete account processes definitions by Arbitration, including a20111128.3 and a20140713.1.

This is also sensible as some elements defined in a20111128.3 are not needed anymore since the latest changes of the CCA (and some previous software changes).

Process Definition

  1. The support case has to be marked as a delete-account request.
  2. The Support-Engineer checks the users account for
    • certificates that are valid
    • certificates that are not expired/revoked for 3 months
    • assurances given within last 7 years
    • assurances given over 7 years ago
  3. The Support-Engineer writes a mail to the user to explain the process and to make sure that the request to get the account delete request is genuine. The mail should contain the following elements (based on the results of Step 2) in a sensible order:
    • information when delete request was received
    • request to respond if the deletion of the account is not the wish of the user, with the information that else the account will be closed
    • optional: option to confirm delete request to fasten the process
    • deadline of about 2-3 weeks for the response
    • short explanation of the delete process
    • information that some risks, liabilities and obligations for the time of the membership, may continue even when the membership has ended
    • optional: information of alternative activities for common issues like lost passwords
    • optional: proposal to block the account
      • if this is added the wording has to be clear that it is optional and no requirement for the closure of the account
    • if valid certificates were found:
      • information that they will be revoked after the deadline has passed, if the user does not intervene
    • if certificates were found that are not expired/revoked for 3 months:
      • information that account has to be kept open until 3 months after the last certificate has expired/was revoked
      • date when this will presumably be the case
    • if any given assurances were found:
      • reminder that CAP forms have to be kept safely for 7 years after the assurance and that they have to be safely destroyed, afterwards
      • request to confirm that this has be done and/or will be done for remaining CAP forms
    • if given assurances within the last 7 years were found:
      • information that if the assurances given by the assurer are questioned (for whatever reason) they have to be revoked, if CAcert cannot reach the CAP forms
      • favoured option by CAcert that the user hands over the CAP forms to another assurer defined by an Arbitrator
      • information that the user may name such an assurer
      • information that if CAP forms have to change hands, the case will have to be handled by Arbitration
    • statement that the user may change any of the above decision until the account is deleted
  4. Wait until either the user confirms the deletion request or the deadline expires
  5. If the user was an assurer and did not confirm the point about the CAP forms
    • step 3 and 4 should be repeated 2 more times by the Support-Engineer
    • not all points from step 3 have to be repeated explicitely in the new mails, if it can be assumed that the member is informed about them [for example by a quote]
    • in the last repetition the request for confirmation should be re-worded so that getting no answer can be interpreted as a confirmation
  6. If the user is an assurer and has decided to hand over the CAP forms, the case has to be moved to Arbitration - the automatic Support activity ends in this case
  7. The Support-Engineer revokes any valid certificates
  8. If the user has agreed or requested to an account block the Support-Engineer should block the account
  9. Wait until all certificates are revoked or expired for at least 3 month
  10. Document the deletion of the account as described below as "Documentation"
  11. Close the account as described below at "Account closure"
  12. immediately inform the user about the successful account closure, stating the date of the closure of the account as the CCA termination date for the user.

General:

If a sensible way would be found so that it could be easily checked if the user who requests termination of the account is involved in an arbitration case, so that the membership should not be ended before the case is finished according, this should be checked as step 0. In the case that the Support-Engineer knows that the user is involed in such an Arbitration case the Arbitrator or (i)CM of that case should be addressed before the process of closing the account is continued, if no Arbitrator or CM could be identified or responds, the DRO should be addressed instead. The user should be informed about this. One possible way to proceed would be to allow the closure of the account without terminating the membership. Currently there is no way for Support-Engineer to know for sure that a user is not involved in an arbitration case, so this check cannot be done in a clearly defined manner.

Documentation

Document the delete account issue by adding it to the new table at the end of the Audit Section linked into the precedent case a20111128.3 with:

Account closure

The account should be closed by the Support-Engineer using the delete account option in the Support Console. This is an automatic form of the process defined in the context of a20111128.3 and described here.

(Note: If the content of the page linked here is moved, the link should be updated, accordingly!)

Note about step 5

The Support Engineer who looked over the above process was not happy with step 5, as this will allow assurer to leave without an explicite statement that they will keep the CAP forms save and destroy them after the 7 years are over.

The reasons for this solution are:

additional Notice for Support

The process defined here will be a process directly under the CAcert Community Agreement (CCA) based on the ruling in this case. No adaption of an Arbitration init mail is needed, as it was done previously, before the last CCA changes, to place it make it into a short version of an Arbitration case.

current case

With the above process the account could be handled by support. The short investigation at the beginning of the case showed no unusual things regarding the claimant or his account.

Edits to process

Ruling

original Ruling

The delete account process for assurer and non-assurer accounts should be changed as described in the process definition part of the discovery of this case file. This process replaces all delete account processes defined in previous precedents cases for delete account cases that are handled by Support, including a20111128.3 and a20140713.1.

The main reason for the new process are recent changes of the CAcert Community Agreement and the ruling given in a20141231.1.

Support should take care that all Support-Engineers are aware of the new process. It would be appreciated if the relevant process descriptions in the support area would be updated, accordingly.

If issues arise with the process within three months after the ruling, the process may be updated by the Arbitrator of this case, or the Case Manager or a Support-Engineer if they have the confirmation of the Arbitrator to do so, as long as the core elements stay the same. Substantial changes should be noted in the case log.

The account of the claimant should be closed as requested by the claimant. The new process should be used. Even as some steps were already done by Arbitration, Support should start with step 1.

Frankenthal, 2015-04-13

Follow-up Ruling

As the CAcert Community Agreement was not correctly terminated by the execution of the original ruling that I gave in this case I hereby terminate the Agreement with the claimant of the case. The termination date will be 2015-04-16, as the claimant was told it to be in a previous mail from support.

Cologne, 20150-05-03

Order given to prevent further miss-executions

Dear SEs, dear board,

I regret to have to do this, but in this case it looks like the only
sensible thing to do for the moment. As the Arbitrator of a20141024.1 I
have to ask you to do the following things.

1. Please remove the access rights from [Support Engineer who tried to execte the ruling] to
- the Support console
- the OTRS
for the time being.

This is not meant to be permanent. But I fear it is necessary to ensure
that support activity in critical areas are done correctly, especially
that the ruling of a20141024.1 is executed correctly.

Regrettably, I had to witness that [name of SE] seriously failed to execute
the  Arbitration ruling of this case. It was not the first time, that
rulings were not executed by him exactly, however at other times it was
less dramatic. Also it is clear that he did some other activities
without the required authorisation, recently, as well, like:
- looking up a members account without either the authorisation from the
member nor the authorisation from Arbitration
- posting information from the account on a public mailing list, also
without any authorisation.
While those activities are not handled in this case, they influence my
weighting of the situation.

Currently I have to fear, that it cannot be ensured that support
activity (especially those for delete account cases) is done with the
authorisation required by SP, but even worse that the CCA is terminated
correctly in those cases as defined in the CCA, if [name of SE] is handling
the according cases.

2. Please also:
Organise a re-training of [name of SE] about
- required authorisations to do something as a Support Engineer starting
with the SP
- how to handle delete account cases with special respect to the ruling
in a20141024.1
- how to handle Arbitration rulings, especially if some points are
unexpected or unclear.

3. Please document the training.

As soon as either board or the Arbitrator of this case (or a follow up
case for this point) is convinced based on the documentation, that the
retraining was successfully done, the access to the Support console and
the OTRS should be given back, as long as neither board nor the support
team lead decide differently.

I hope this will only take some days.

I have consulted the President of CAcert Inc. before writing this.

This order was given at 2015-04-19 in Solingen

Follow Up Ruling II

I hereby come to the following follow up ruling:

1. Dirk Astrath and Guillaume Romangy should be added temporarily to the Support Engineer team. Dirk should gain access to the support console. Guillaume should gain access to the Support OTRS-queues. Both of them should get any other access necessary for support work. Together they should help out within the Support team.

2. Both should take special care that the work of support is done correctly and should especially help each other in this regard. When establishing necessary channels of communication they should consider how to secure the privacy of the affected members.

3. Dirk and Guillaume are asked to make themselves familiar with the work of an support engineer. They should undergo each available training in this regard.

4. Board and any support engineer are asked to consider to initiate an ABC for Guillaume by filing an according dispute. If such a dispute is filed, Arbitration should handle it with priority as long as Guillaume works as temporary Support Engineer.

5. Any support engineer is asked to help the temporary Support Engineers to enable them to do the work, including any necessary training or information.

6. Dirk is suspended from active regular Software Assessor work. He may be active in emergency situations. (Situations where a necessary bug cannot be installed in an acceptable amount of time, without his review.)

The above points are valid until at least two regular support engineers are active on a regular basis, or if revoked by the Arbitrator of this case or a follow up case. This ruling should be reviewed by the according Arbitrator, when at least one regular support engineer is found to be active on a regular basis. Any such activity should be reported to the according Arbitrator. The according Arbitrator should also consider a review if either Dirk or Guillaume, Support or board ask for it.

Board is asked to aim to get two regular active Support Engineers working in the support area. This may include to get the temporary Support Engineers to be full flagged regular Support Engineers.

-- Wien, 2015-09-07

The above is necessary because and based on the following:

Security Policy[2] (SP) 9.1.2. first sentence gives the following requirement: "Each team should have a minimum of two members available at any time."

Currently this does not seem to be the case for support. At the board meeting of 2015-09-06 board decided to ask the Arbitrator to get a temporary replacement added to fulfil the requirements for the team staffing.

SP 9.1.3. "New team members need:

There seems to be no candidate who fulfils those requirements. Also at least two out of the current four support engineers have declared that they are not available for regular support work for the time being. Also time has shown that it takes much longer to get Werner through the requested re-training, than originally assumed by the Arbitrator, so he probably will not be able to do regular support work for an undefined amount of time. Approaches to hasten this, remain to be welcomed.

SP 9.1.1 defines the roles and responsibilities at least for the context of staffing. It includes: "Arbitrator: conducts ABCs. Authorises exceptions to policy."

As there is no way for board to ensure the minimum of active support engineers which is required by the SP by people who match the requirements of the SP, an exception to the SP requirements is required.

Dirk has an ABC that was initiated for support work. Guillaume misses an ABC but - according to board - has done support work, previously. Board had proposed to give them access as granted by the Arbitrator to solve the situation. As board is the authority who normally has the responsibility to select and install Support Engineers, the voice of board should be relevant for the selection of team members.

As Dirk has the required ABC and only Guillaume will not get access to the database, the critical access remains only available for persons with an ABC.

The sabbatical for the Software Assessor role of Dirk is indicated because of SP 9.1.2 second sentence "Individuals should not be active in more than one team at any one time, but are expected to observe the other teams." However both roles are not exclusive.

Follow up ruling III

The following ruling should a) close the issues which arose via the execution b) withdraw the arbitration authority from managing support team as much as possible and approve prior decisions from board and others in that area d) emphasise the need to staff up the support team so that one can entrust this team with processes like the delete account process 

I hereby rule:

1. Dirk, board, support-TL and the Arbitrator did a lot of steps to enable Dirk to become a full-flagged support engineer. While all requirements from the Security Policy (SP)[2] 9.1 to join that team are visible, some of them were not done exactly as required or in the requested order. But as the intention is more important than the specific process, I hereby use the authority as Arbitrator to allow exceptions from process provided by SP 9.1.1. and rule that the derivations to process are minor and Dirk was installed as Support Engineer, successfully.

1.a. Board added an additional requirement for all support team members above those from SP in motion m20140713.1 [3]: All support engineers have to pass the privacy CATS. Dirk does not fulfil this requirement so far, as the privacy CATS is not productive, at the moment. He has one month to convince the Arbitrator of this case, that he fulfils the requirements of the privacy CATS. The result has to be noted in this case file.

2. The follow up ruling II in this case did not work out as planned because of multiple interferences and complications. By this all its provisions are cancelled.

3. If Guillaume shows interest, board may grant him the access he was allowed to have via follow up ruling II, if board coordinates this with the support team, without following a specific process. However in that case board should aim to get any missing elements covered as far and soon as possible.

4. Werner has resigned from support team. There is no direct need for a training any more and the topic should be dropped. Should he ever apply for a job under SP again, he has to convince an arbitrator (in a case) that he has performed the training as it was described in follow up ruling I before he may be allowed to do that job.

5. Marcus has resigned from support team. Prior to this he had at least once refused to follow simple orders of the Arbitrator and instead decided to do no further support activities for months. Should he ever apply for a job under SP again, he has to convince an arbitrator (in a case) that he will follow orders from any arbitrator and processes in the future.

6. The SP requires to have at least two active members for each critical team like support engineers. The current failure to keep the support team staffed as required by the SP and this already had lead to grave problems which may even have lead to a situation where security relevant mails were not read, and also delete account requests were not handled as requested which also may have lead to situations where members stop to care for their accounts or certificates which may lead to issues with those certificates.

Combined with some of the issues seen in this case, this shows, that the provision of the SP to have at least two active team members in the critical teams is sensible and relevant. The availability of a team should not depend on one person only. If there is only one active team member there should be at least some oversight and possibility to step in in emergencies from at least one other person.

7. This ruling will only provide one active support engineer. Because of this board has to present a solution for said oversight as long as only one active support engineer is active.

7.a. A possible solution may be that the support-TL will take a look into the OTRS in regular intervals or when requested by Dirk. But board has the full authority to define any other solution they regard to be promising.

8. SP 9.1.3. requires an Arbitrated Background Check (ABC) for new members of the teams under SP like support engineers. A ruling given in a20140124.1 [4] forbids that ABCs are performed until the Arbitrator of that case provides a new process. However he did accept current ABCs. As those remain acceptable and there is a security need to perform ABCs the provision of the ruling of a20140124.1 have to step back if a team drops under the required amount of team members. Because of this an exception to the ruling in a20140124.1 is given so that up to 3 ABCs are allowed to be performed for candidates for the support team with the current process until a new process is provided.

8a. The same would be true for any other team in a comparable situation. Or if the support team drops below the required number of members, again.

9. Should CAcert not be successful to get to a situation where there are either two active support engineers or at least enough serious candidates for the job of support engineers within half a year after this ruling, the support team has to be closed down. While a situation with only 1 support engineer can be tolerated for some while even as it breaches the SP under the oversight of an arbitrator, there is a limit how long this is acceptable. If that situation cannot be solved in over 1,5 years with no perspective for improvement, it is likely that this limit is crossed.
 
10. If the Arbitrator of this case comes to the conclusion that there is some reason to believe that the situation is likely to improve after said half year, the Arbitrator may increase the grace time for closure accordingly on request of board. If during this time CAcert succeeds to get two active support engineers or serious candidates, support does not have to be closed down.

11. Because it is unknown how much the process defined in the original ruling was tested, the 3 months for adjustments to the process are reset by this follow ruling III and start again with this follow up ruling III.

12. Beside of the activities named in this ruling, no further actions are intended to be done in this arbitration case. It should be closed as soon as possible with the above provisions in mind.

Eva Stöwe, 2016-05-27

~~~~~

[1] https://wiki.cacert.org/Arbitrations/a20141024.1
[2] https://www.cacert.org/policy/SecurityPolicy.html
[3] https://community.cacert.org/board/motions.php?motion=m20140713.1
[4] https://wiki.cacert.org/Arbitrations/a20140124.1

Execution

a20111128.3

Delete Account cases to handle by SE - No Assurances given, no certs or certs expired - Precedents Case {i}

a20140713.1

delete assurer account

a20141231.1

no default revokation of assurances if assurer leaves CAcert

Similiar Cases

a20080702.1

User requests to delete account with Assurance Points

a20090618.3

Assurer requests to delete account

a20090328.1

Assurer wants his account deleted

a20090510.3

Assurer with alter-ego even assured himself more than once

a20100907.1

letter of resignation

a20110110.1

Please Delete my Account (Is Assurer)

a20110131.1

Account Removal Olivier F (Is Assurer)

a20111004.1

Assurer requests deletion of his account

a20130308.1

Delete Account

a20140925.3

delete assurer account Philipp S

a20140926.1

delete assurer account Nils E

a20140926.3

termination of assurer account Hannes R

a20140926.4

termination of assurer account Christoph B

a20140927.2

termination of assurer account Federico H

a20140929.1

termination of assurer account Fridtjof B

a20140930.1

deletion of assurer account Lukas H

a20141002.1

terminate assurer account Rutger S

a20141011.1

delete assurer account Johannes K

a20141020.1

terminate assurer account Klaus L

Arbitrations/a20141024.1 (last edited 2016-06-10 21:04:49 by EvaStöwe)