Arbitrations/a20111001.1

Case Number: a20111001.1
Status: running
Claimants: Marcus M on behalf of Paul J
Respondents: CAcert
Initial Case Manager: BernhardFröhlich
Case Manager: SebastianKueppers
Arbitrator: UlrichSchroeter
Date of arbitration start: 2011-11-25
Date of ruling: 201Y-MM-DD
Case closed: 201Y-MM-DD
Complaint: Dispute misssing points after applying bug fix 827
Relief: revoke assurance precedent case, scripted mailing

Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: Marcus M (C1), Paul J (C2), Case: a20111001.1

History Log

2011-10-01 (issue.c.o) case s20111001.57
2011-10-02 (iCM): added to wiki, request for CM / A
2011-11-25 (A): I'll take care about this case as (A) and appoint SebastianKueppers as (CM) in this case.
2011-11-25 (A): Initmailing to (C1) sent, with req for email address of (C2). (C1) acceptance to CCA and DRP has been approved under a20101201.1
2011-11-26 (C1): sends email of (C2)
2011-11-26 (A): init mailing with request for CCA/DRP acceptance to (C2)
2011-11-26 (C2): accepts CCA/DRP under this arbitration
2011-11-26 (A): response to (C2) questions
2011-11-27 (A): sending request to (C1) as SE, (C2) to list affected records for member (C2); sending request to (Support) to list affected records for member (C2)
2011-11-27 (C1): sent response to last request
2011-11-27 (C2): sent response to last request
2011-11-27 (Support): [s20111127.5] sent response to last request
2011-11-27 (A): answering some open questions, explaining the revoke-assurance process, and some questions regarding Thawte points removal and gaining more assurance points to (C2)
2011-11-27 (C2): question from (C2)
2011-11-27 (A): question from (C2) answered
2011-11-28 (A): request to (Support) to prepare a request to the identified assurer (A1), send him the email and awaiting the response. Mailing goes to (C1), (C2), (Support)
2011-11-28 (C1): sends a proposal for the mail to (Assurer)
2011-11-28 (A): talk with (C1) by phone, discussing email text proposal
2011-11-28 (Support): [s20111128.6822]mail to assurer (A1)
2011-11-29 (A): interview of Software-Assessor and Software-Developer regarding checkboxes bug #894
2011-11-29 (A1): assurers response to request by (Support) with ticket id [s20111128.6822], forward by (Support) to (A)
2011-11-29 (A): first step 4 proposal of the Part I procedure sent to (C1), (C2)
2011-11-29 (A): first step 4 proposal of the Part I procedure sent to arbitration and se mailing list for further discussion
2011-11-29 (C2): if assurer is a ex-thawte notary and lost points, how the assurer can re-transfer the assurance points?
2011-11-29 (A): answer to (C2) note, to (C1), (C2), arbitration and se mailing list
2011-11-29 (SA): bug#894 to be modified to allow entering assurance w/o AP flag set
2011-11-30 (A): Intermediate ruling #1, sent to (C1), (C2), se mailing list
2011-12-01 (A): exec order for intermediate ruling #1 sent to (Support), (C1)
2011-12-01 (Support): [s20111201.4] revoke/re-apply assurance mail to (A1)
2011-12-01 (A): comments on support handbook updates to (C1), (C2)
2011-12-03 (Support): forward of (A1) exec report
2011-12-03 (C1): quick info by phone to (A): 0 cases does match discovered potential exceptions
2011-12-05 (A): Intermediate ruling #2, sent to (C1), (C2), SE mailing list
2011-12-05 (A): exec order following intermediate ruling #2, sent to (Support), (C1)

Original Dispute, Discovery (Private Part)

Link to Arbitration case a20111001.1 (Private Part)

EOT Private Part

Discovery

The Facts

Thawte server has been shut down Nov 16, 2009 (CAcert blog post Oct 2009)
Thawte points transfers cannot longer verfied and therefor conflicts with AP, so therefor this program has been terminated by board motion m20090928.1, to revoke Tverify transfered points until Nov 16, 2010
The revocation deadline passed now over 1 year
Software-Assessment has prepared a fix, to
1. revoke ex Thawte transfered assurance points
2. change the points counting schema from a fixed counting at time of transfering assurance points into the online system to a schema, that dynamicly counts awarded and received assurance points and experience points. The limit of 100 assurance points and 50 experience points is calculated at the time its requested.
in detail: Tverify
- The Tverify programme is Terminated as of 16th November (2009)
- All points that are allocated under the Tverify system are to expire no later than 20101116. This is retrospective.

Considerations

... over revoke assurance / reapply assurance process

By changing the points counting, an assuree, who received in total 250 assurance points (limited to 100) by eg 25 assurances, now looses the points in the old points counting schema by removal of his first record of Thawte points transfer, which counts 150 pts. All later added assurances were rounded down to 0 points.
The new points counting therefor uses the column awarded points to sum all awarded points and later limiting the total count of points down to 100.
By historical reasons, the column awarded doesn't exist before effective date 2006-08-30.
At the time this column was added, all existing records were filled with 0 points awarded, so every Face-2-Face assurance that was entered before 2006-08-30 into the system, has only the counted value of points in the notary record. If the user had 100 assurance points at this time, the given points was rounded down to 0.
So therefor we see today 0 records in my points views.
The system cannot recover the given points by the assurers, as this value had not been recorded before 2006-08-30.
The only chance to get this info back is to ask the assurer, how many points he did gave in the Face-2-Face assurance back in 2006 and before. At least he has it on his CAP form.
The potentialy records with problems persists before 2006-08-30.
Assurers obligation is to keep his CAP form for 7 years and to destroy it afterwards.
So currently we have a small time period of potential problem records that can be recovered thru a "revoke assurance" - reapply assurance procedure
- 2011-11-25
  
  today
  
  2006-08-30
  
  column awarded was added
  
  2004-11-25 and older
  
  CAPS destroyed
So today we talk about records in the period from 2004-11-25 until 2006-08-30 that have a potential chance of recovery
1. if the record is affected (has 0 points in the awarded table)
2. if the assurer can be contacted
3. if the assurer has the CAP at hand and can reapply the assurance
4. if the assurees old email address he used in the assurance process is still valid and his primary email address in his account or if the assuree can switch to this email address
Some questions that needs an answer:
1. can an assurance be re-applyed if the old primary email address is no longer valid?
2. is Support Engineer allowed to disclose the current email address of the assuree to the assurer? and can the assurer use this new primary email address for reapplying the assurance?
3. what is the disadvantage if the assurance cannot be reapplied?
4. How does this effect AP?
AP has been created 2008-05-30, so long time after the effective time period of problem records.
CCA didn't exist by this time
Today assurances to transfer into the online system requires acceptance of CCA and the statement by the assurer that the assurance followed AP. This in effect is false by the time the assurance were given
records from 2004-11-25 until 2006-08-30 potentialy have no _value_ in assurance points but counts on given assurances (-> experience points, 2 pts each assurance until 50 pts reached)
- revoke of a 0 pts assurance record affects WoT in a way, that assurance points received doesn't count
  - so there is no difference if this record exist or not. It counts either 0 pts
- revoke of a 0 pts assurance record affects count of experience points for an assurer
- so if there is a chance to repair this 0 pts record with the link given in the notary table between the assuree and the assurer, recovery of this 0 pts record is possible to reflect the effective given assruance points
- the link given by the notary table record between the assuree and the assurer states, that the assurer met the assuree F2F in the past and the assuree gave the assurer some of his data: Name, Email, DoB
- The assurer still has these infos on his CAP form (or at least still is required to have by the given obligations of an assurer)
- From the point of privacy, the disclosure of Name and Email from Assurer to Assuree or from Assuree to Assurer is a followup of privacy regulation that is handled under the CCA by the "privacy clause"
  - ```
  I hereby confirm that the information stated above is both true and correct, and request the CAcert Assurer (identified below) to verify me according to CAcert Assurance Policy.
```
- especialy "and request the CAcert Assurer (identified below) to verify me according to CAcert Assurance Policy."
- This clause still exist before the new CAP forms with CCA acceptance (after mid of 2009) have been pushed out
- There still exist a bug #894 (Haeckchen bug) "problems with check-boxes on website forms (Assure someone) -> a20091118.3"
  - a fix is currently under testing, but the patch has not been transfered to the production system
to solve the non-AP-conformance assurance w/o CCA acceptance there are 2 potential solutions or workarounds:
1. the existing bug is helpful to enter the assurances to reapply w/o the checkboxes
2. to add some info into the locations field as addtl. note if required
Questions that araises:
- what does a notary table record mean or pose?
  1. the assuree did met the assurer
  2. the assurer has some confidence into the identity of the assuree
  3. the level of confidence is given by the count of assurance points in relation to the assurers experience
- The assuree gave the assurer the permission to use the data for the assurance process
  - if a re-appliance is required, the permission to use the data again for the re- assurance process can be assumed. The data will not be disclosed in other ways as the user did gave his permission to the assurance process (this also relates to a scripted (anonymous mailing))

what is the disadvantage if the assurance cannot be reapplied?

if a 0 points assurance cannot be recovered into its original state (count of assurance points added into the notary record) the assuree may probably doesn't have enough assurance points to enter the next higher level

0 - 49 pts	unassured member, member can only issue certs valid for 6 months, with "WoT user" in name field
50 - 99 pts	member can issue certs valid for 2 years, with his name in name field
100 pts	if CATS test passed, the member has assurer state

if the points count falling below 100 pts, the assurer state goes to hold, the assurer on hold needs addtl. assurances to get back assurers state
if the points count falling below 50 pts, the member can no longer issue certs valid longer then 6 months and the name in name field becomes invalid (this openes the next question: what happens with certs if the points count is falling below 50 pts?)
so its better to keep the points count intact
if there still exist records with 0 points that can repair the points level count if once reapplied, this should become the proposed solution to keep the WoT intact
- the assurers aren't that affected (the experience points will count as long the record still exist)
- the assuree is mostly effected by missing assurance points
- so from assurees PoV, if it is possible to get such records repaired, it should be repaired
- if there still exist no 0 points records, the assuree is in problem either way. He still needs further assurances. This cannot be handled thru this arbitration. This arbitration can only handle the repair process of individual f2f assurances with missing points upto 35 pts
- if the missing points exceeds 35 pts (eg by the old Super-Assurance program with 150 pts), only 35 pts can be reawarded. This is better then 0 points.
- assurance method cannot be switched from eg Thawte to F2F or Thawte to TTP
- the assurance method that was used in the "defective" record needs to be re-applied unchanged

Can also other assurance methods been affected by the 0 points problem?
- eg TTP?
- Super-Assurances were added as F2F records
some considerations about the "revoke the assurance" process
- if the request comes from the assuree, the permission to handle the users record is given by the request
- if the request comes from the assurer, the assuree did not gave yet the permission to SE to handle the request
- the process is an async process, that means:
  - the assuree needs to be contacted by the SE
  - the assurer needs to be contacted by the SE
  - if one of the involved parties doesn't respond, the repair process runs in an undef state
  - if the request comes from the assurer, and the assuree doesn't respond, this is less a problem, as the assurer needs to act to re-applying the assurance.
  - if the request comes from the assuree, and the assurer doesn't respond, this is a higher problem, as the assurer needs to act to re-applying the assurance
  - if the assuree doesn't respond, the record can be repaired in absence of the assurees response, if ordered by the arbitrator
  - if the assurer doesn't respond, the arbitrator cannot do anything as he do not know the points level awarded by the assurer
  - the problem case is either way the assurers side. if the assurer doesn't respond, nothing can be repaired
  - the conclusion here is:
    - on request by the assuree, the record should not be revoked until the assurer responds
    - if the assurer starts the request, the missing response from assuree can be replaced by an arbitrators ruling
  - a support engineer has the link to both involved parties, to the assurer and the assuree
  - a support engineer can coordinate the async process once notified by one of the involved parties by request
Which infos are essential in the communication process?
- the notary record lists following parameters:
  - Date
    
    Who
    
    E-Mail
    
    Points
    
    Location
    
    Method
    
    Revoke
- the who field displays the users name and email the email address of the user
- if the request goes to the assurer, all fields (date, who, email, points, location, method) are valuable fields to find the CAP form by the assurer
- the "My points" listing also displays the Id, the admin console view probably too
- In reapply the assurance, the old Id should be recorded (-> documentation) to the new record and onto the CAP, as this gives the evidence over the reappliance process
- a second indicator is the support ticket id
- summary:
  - in communication infos that should be given to the assuree / assurer
    - Id
      
      Date
      
      Who
      
      E-Mail
      
      Points
      
      Location
      
      Method
      
      Revoke
    - this is the full display line in view points table
  - recommendation: on reapplying the assurance, the old Notary Id and the support ticket number should be added as addtl. info into the locations field in the online system and on the CAP form a note should be added, that the assurance has been reapplied with date, ticket-id, old/new Notary Ids for documentation purposes
    - ```
    If in a later arbitration process or under audit review this record will be checked, the assurer can be contacted thru primary email address. The info given by the support ticket id, the relation into the re-applying assurance process of the assurance is given thru the support ticket system and by the note on the CAP form.
    An arbitrator can request the infos from the Assurer or from Support.
    Problem solved.
```

How does re-applying assurances affects AP?

At the time the affected assurances were entered into the online system, the CCA and AP wasn't written yet.
- Acceptance of CCA was not an issue by this time.
- Following AP was not an issue by this time. This does not mean, that the assurance given was less acurate. The main difference in assurances before mid 2009 were the missing CCA acceptance check by the assurer over the assuree. A second difference is, that now the assurance process follows a standard, which but doesn't mean, that the assurances before didn't followed a process. The process of Id checking was transfered from assurer to assurer. With the written AP now the assurance process can be audited.
- As long there exist no Legacy Points Policy (an anticipated policy to clarify the status of old pre-AP points, read also Policy Tasks) its still an open question if old assurance points should fade out, or if assurance points exceeding the limit of 50 assurance points given by AP should be cut. As long there still exist no policy, assurance points that are still verifyable are still valid (Thawte transfered points are no longer verifyable). A limitation is given by the online system, that prevents assurance points > 35 pts on re-applying (AP rule)
- So a ruling has to cover following topics:
  1. that assurance points exceeding 35 points cannot be entered into the online system
  2. that assurance method cannot be switched in reapplying an assurance
  3. give a ruling / definition how the relation to CCA / AP in the reapplyance should be treated

CCA and side effects

bug #894 lists a bug, that still exist in the system
- the checkboxes on activating that the Assurer agrees to the CCA doesn't work
- there are no records when a user has agreed to the CCA
The bug #894 is close before a fix and is under testing
The running Thawte points removal project is the current big project
The CCA rollout is one of the next big projects that will be started soon as the Thawte points removal project has finished
In the CCA rollout project that is one of the audit related tasks in the Software-Assessment team work queue, all users will be contacted and the CCA acceptance will be requested and recorded
Currently the CCA acceptance can be verified in the Assurance process with the users signature on the CAP form.
To confirm the members agreement to the CCA, an arbitrator can request a CARS statement from the Assurer, that the member has signed his CAP form with the CCA agreement clause on it.
Currently there still exist 2 methods in identifying potential user records that have agreed to the CCA indirectly
- The user account has been created after June 2009, the time, where the checkboxes were added to the "join" form
- The notary record assurance-when date is set in or after June 2009
  - the notary table includes 2 date fields
    1. the field the assurer adds the assurance date
      - this is a free form text field. So anything can be written here. This means this can also be a non-date text
    2. assurance-when field with datatype date
      - the assurance when field will be added to the record automaticly at the time, the assurance is added to the online system automaticly. This field cannot be edited by the user, nor seen by the user
  - in a re-assurance the assurance-when field will be field with the current date, and the free form date field has to contain the original assurance date. As this field is free form, we have no gurantee, that the entered value represents the original assurance date, except its controled by the other related party (the assuree) or by a Support Engineer. But the latter needs to be ordered by an arbitrator. So its probably helpful to give a ruling here, wether SE is allowed to check the record after its got re-applied
- all other records has probably no references to a CCA agreement.
- In the period between 2007 and mid 2009 there is a 50:50 percents chance to have the CCA agreement on the CAP form, as the first time new CAP form usage is pushed around February / March 2009, which is documented by a20090303.1 and a20090306.1. The period that is of interest in this arbitration is far before this date (before 2006-09-01).
- The assurance date field the assurer can enter is therefor of special interest, as this is the field that can be entered by the assurer, that reflects the original assurance date
- Of special interest maybe this field also for the Legacy Points Policy project, at the time, the original assurance date needs to be validated, but this is another story, not to solve within this arbitration

... over automated mailing script

From CAcert's PoV, the best solution to fix the historical gap is an active notification to the affected assurees and assurers
- this means: an automated mailing that selects affected records and sends a notification to the assurees and assurers, so they can react, and can start with requests to support
- an automated mailing prevents disclosure of user data to any party (from the experiences of the events mailing scripts, oa mailing scripts and newsletter mailings)
- its in the assurees and assurers choice to react to the notification
From CAcert's PoV the best solution is not to only notify affected assurees, also the assurers
- so either way, assurees and assurers can react
- if an active assurer has several 0 points records, its better to get only notified once, instead of each single issue, so the assurer can start a mass revocation request, to reapply assurances in a bulk
as more involved parties are notified, as faster the gap can be closed, as sooner the 2nd phase in the Thawte patch deployment can be started - the active switch to the new points counting schema

Procedural steps on requests

(preparation of a first ruling proposal)
Ruling has to cover 2 areas:
1. individual members request to revoke an assurance
2. scripted mailing to inform affected users and to encourage assurees and assurers to send requests to support to repair affected notary records

Part I

its NOD that assuree or assurer can send a request to support for revocation of a specified assurance record (notary table record)
Assuree or Assurer gives SE the permission to handle this request. This follows in principle SP (4 eyes principle)
- What is different is the circumstance, that the request to revoke an assurance is about an record, that has been entered about 5 years and more in the past into the online system. Security manual has a 24 hours rule, that the involved parties may send a request to revoke the assurance w/o forwarding to arbitration. This rule has been advanced with the precedent case a20100210.2 (Revoke assurance 24 hours / 3 days / 7 days after an event) and a20101016.1 (Remove assurance, 24 hours rule) so an arbitrator has to review this case.
- We're talking about the general "Thawte remove points / change points counting" project that opens a technical problem with a set of notary table records before 2006-09-01. This date has been identified in arbitrations a20091118.1, a20100822.1 and a20101114.1 as the date where notary table has been upgraded with column awarded, where assurance records before this identified dates doesn't contain the count of awarded points by the assurers.
- Affected records which have 0 points and 0 awarded points prior this date will be "marked" yellow/italic under bug #827 under the members "My points (new calculation)" details and under bug #882 under the System admin console view "Show Assurances the user got (New calculation)" and "Show Assurances the user gave (New calculation)"
The first step in this procedure has to be:
1. identify affected notary table records by notary id or assuree/assurer name/email
2. if the assuree or assurer did not gave enough detailed infos about the affected record(s), SE should be allowed to request this info from the assuree or assurer
  - ```
  Affected records requirements:
   - record is marked yellow/italic
   - assurance date is before 2006-09-01
   - assurance method is of type: face-2-face
     no other assurance method types to cover yet: eg 'empty', 'Unknown', 'TTP'
```
The "active" part in this procedure is the assurer. So if the request comes from the assurer, the request can be executed asap. If the request comes from the assuree and the assurer doesn't respond to any requests, a revocation of the affected record results in a missing link that will probably never been fixed. In an audit process or another arbitration case, this record is missing and therefor WoT is broken as long the assurer doesn't re-apply the assurance. So therefor ...
Step 3 has to be (if the request comes from the assuree)
- 3. send a request to assurer:
  1. to identify the affected records
  2. confirm, that the CAP forms are at hand by the assurer
  3. awaiting response by the assurer
    - step 3 can be skipped, if the request comes from the assurer
```
If contacting the assurer fails, (C2) brought in an interesting recommendation:
that the assuree may help to contact the assurer by other ways:
 - by phone
 - by another email
 - face-2-face
```
Step 4:
- 4. awaiting response from assurer, if response from assurer is received, revoke the affected assurance
  1. revoke the assurance
  2. send info to assuree/assurer that assurance is revoked and instructions for re-applying the assurance
    1. instruct assurer to re-apply the assurance with the original assurance date
    2. instruct assurer to re-check all user data: Name, DoB, Email - on any mismatch stop the assurance and report back to (Support)
    3. instruct assurer to enter no more assurance points then given in old assurance (10 pts cannot become 35 pts). If an old Super-Assurance with 150 pts needs to be handled, reenter the max possible points: this is currently 35 pts (caused by system restriction)
    4. instruct assurer to enter addtl. infos into the locations field
      1. "RE:" at the beginning of the field (to signal the re-assurance)
      2. the old locations text string
      3. append comma seperated
        [ticket id]
        old notary id
        eg. so the old string "Paris" becomes "RE: Paris, [s20111128.6822], 123456
    5. instruct assurer how to handle the CCA acceptance, conformance to AP that didn't exist at time of the old assurance (checkboxes handling)
      1. as long the bug #894 isn't fixed, leave the checkbox for
        "I have read and understood the Assurance Policy and the Assurance Handbook and am making this Assurance subject to and in compliance with the policy and handbook."
        unchecked !
      2. starting from time, the bug #894 has been fixed under the production system
        variant 1:
        bug #894 allows entering an assurance made before AP was in effect to be entered w/o the checkbox for "AP compliant assurance" set
        Requirement:
        all re-entered assurances flaged with "RE:" at the beginning and assurance date before 2009-01-05 (this is the date AP comes in effect with POLICY and Policy has been pushed to the Community) (see Assurance Policy History)
        variant 2:
        leaving the checkbox for this section empty asks for a cause
        enter: "repair of pre AP assurance"
    6. instruct assurer to document the running issue of re-applying the assurance onto the CAP form with his own words, including date, ticket id, old notary id, new notary id, arbitration number a20111001.1
  3. special cases:
    1. email address is not the email address used in old assurance
      1. email address can be switched by the assuree
      2. email address is no longer available (out of service)
2011-11-29 (SA): bug#894 to be modified to allow entering assurance w/o AP flag set
- within Software-Assessment project team meeting 2011-11-29 the issue regarding AP checkbox in re-applying an assurance has been discussed
- the patch bug #894 has been modified to allow to enter assurances w/o the checkbox "AP compliant assurance" set

Intermediate Ruling #1

Intermediate ruling #1 covers Part I of this arbitration, that is the individual request by an assuree or assurer to revoke an assurance. Step 4 of above considerations and preperations of procedural steps needs a formal ruling.
A Support Engineer is allowed to process Step 4 in the procedural steps of an "Revoke my Assurance" (to be re-applyed) request by an assuree or assurer and the preperations made in step 1. - 3. in the following way and that met following conditions:
1. old Assurance date is before 2006-09-01
2. assurance method is Face-2-Face and locations field doesn't signal that this record is a TTP workaround record x³)
3. reduced assurance points count
  1. record is flagged yellow/italic (easy identification) -or-
  2. there is a discrepancy between awarded points and counting points, all below or equal to 35 Assurance points x¹) (eg 2nd assurance counts 10 instead of 35 pts, at least one such record per user account is possible, see New Points Calculation - Example 3)
Step 4:
- 4. awaiting response from assurer, if response from assurer is received, revoke the affected assurance
  1. revoke the assurance
  2. send info to assuree/assurer that assurance is revoked and instructions for re-applying the assurance
    1. send info of old assurance record (again)
      - Notary ID, Date, When, Assuree email, Assuree name, Points, Location, Assurance Method
    2. instruct assurer to re-apply the assurance with the Assurees current primary email address sent within the request x²)
    3. instruct assurer to re-apply the assurance with the original assurance date
    4. instruct assurer to re-check all user data: Name, DoB, Email - on any mismatch stop the assurance and report back to (Support)
    5. instruct assurer to enter no more assurance points then given in old assurance and that is verifyable by the CAP form (10 pts cannot become 35 pts). If an old Super-Assurance with 150 pts needs to be handled, reenter the max possible points: this is currently 35 pts (caused by system restriction)
    6. instruct assurer to enter addtl. infos into the locations field
      1. "RE:" at the beginning of the field (to signal the re-assurance)
      2. the old locations text string
      3. append comma seperated
        [ticket id]
        old notary id
        eg. so the old string "Paris" becomes "RE: Paris, [s20111128.6822], 123456
    7. instruct assurer how to handle the CCA acceptance, conformance to AP that didn't exist at time of the old assurance (checkboxes handling)
      - leave the checkbox for
        "I have read and understood the Assurance Policy and the Assurance Handbook and am making this Assurance subject to and in compliance with the policy and handbook."
      - unchecked if
        the assurance date is before 2009-01-05 -and-
        assurance was made under the "old" pre-AP CAcert rules -and-
        re-entered assurances flaged with "RE:" at the beginning of the locations field (see Step 4 b.6.1)
      - If a reason needs to be entered why the checkbox was unselected, enter: "repair of pre AP assurance"
    8. instruct assurer to document the running issue of re-applying the assurance onto the CAP form with his own words, including
      1. date
      2. ticket id
      3. old notary id
      4. new notary id
      5. arbitration number a20111001.1
      6. primary email address used in re-apply the assurance
        if there is a mismatch between original primary email address and current primary email address mark the exception as a20111001.1 ruling and new primary email address received by Support
Special cases ruling: x²)
- email address is not the email address used in old assurance
  1. email address can be switched by the assuree
  2. email address is no longer available (out of service)
- To simplyfy the Support and communications overhead, until the exact issue is identified if a users email address is now the users secondary email address or email is out of service, the reliance between Assuree and Assurer is still given by the existing record in the database. The current primary email address is the address the user responds, the reliance path keeps still intact, if support sends the Assurer current primary email address of the Assuree to be used for re-applying the assurance into the online system.
- So therefor I hereby order:
  - Support-Engineer is allowed to send the Assurees current primary email address to the Assurer within the request for re-applying the assurance
  - Support-Engineer is allowed to instruct the Assurer, to use the given primary email address to re-enter the revoked assurance into the online system
  - Assurer is allowed to use the primary email address sent by a Support-Engineer from support@cacert.org in the order request for re-applying the revoked assurance also in the case:
    1. the primary email address is not the primary email address that is used in the original assurance -or-
    2. the email address from original assurance is now a secondary email address.
      - by following further instructions sent with the support request as described under step 4 b.2 to 4 b.8

x³) Face-2-Face records in current means:

a real face-2-face meeting with the assurer did happen

So Support-Engineer has to check the record, before proceeding with this procedure, if assurance method is "F2F" and not empty or other value, that in case of "F2F" the location field doesn't contain the remark "TTP" or "TPP" (caused by a typo). These records are known to be TTP assurance records and aren't F2F method assurances, despite the fact they are flagged so (this is a known bug within the current webdb base, see bug #855 and ref. a20091118.1)

method	location	remarks	allowed to continue?
Face-2-Face meeting	TTP	this is a TTP assurance, entered as workaround for bug #855	{r} FALSE
Face-2-Face meeting	TPP	this is a TTP assurance, entered as workaround for bug #855	{r} FALSE
Face-2-Face meeting	empty	face-2-face assurance, but can be TTP assurance too, see 2nd table below	SET ON HOLD x⁴)
Face-2-Face meeting	any other value	face-2-face assurance	{g} TRUE

x⁴) request further infos from assurer about assurance method to be F2F, if in doubt, transfer to Arbitration

Deliberations

The primary email address problem may araise more often as longer the old assurance is years ago.
We currently have "incomplete" assurance records in the database that needs to be filled with the missing informations (gets repaired).
The database content cannot be repaired by Critical admins, or Software-Assessors or Application Engineers, as long the missing info can only be given by an assurer, who has entered the original record into the database. No automatic processing works here, as the required info is not available by the CAcert systems, only by the Assurer given by his Assurance Statement. The assurance record as such is identifyable by the Notary table Id, the Assurees name, the location and the date when the assurance was entered.
The missing info is required to correct the WoT or at least to decrease the damage that is a result of the Thawte points removal process, that is still announced, but not yet activated.

Based on the "Thawte points removal" decision, that is based on the board motions back in September 2009 and is based on the Audit criterias (DRC-C) and Assurance Policy that requires (6) Subsidiary Policies for special assurance programs or referes back to the the Assurance Policy 1. Purpose of Assurance, Assurance statement, that needs to be verifyable (see CCA 2.3(1)) this running arbitration has to balance the possible solutions or workarounds against existing policys and decisions.

Until today there still exist no Tverify assurance subpolicy to AP and its very unlikely, that the Thawte servers will be restarted one day, which is a minimum requirement for Thawte transfered points to become verifyable

Community Updates - Sept 2009

All Assurance Special Programs are frozen

2009-09-14 As of Board motions m20090912.1 and finaly m20090914.2 these programs ceased immediately.

         m20090912.1
Assurance under Assurance Policy only

Resolved, that this committee, officers and all Assurers are charged to
ensure that all assurance follows Assurance Policy, made binding DRAFT
p20080712.1 and POLICY p20090105.2.

Further resolved, to cease all assurance activity outside Assurance
Policy.  Old programmes not as yet translated into the new Assurance Policy
regime of subsidiary policies include:
 - super-assurance
 - TVerify
 - assurances by and of Juniors
 - TTP
These are to cease immediately, and be only restarted when the appropriate
subsidiary policy under AP is passed into DRAFT by policy group.

This committee notes with concern that any assurance conducted outside AP
(after its passing into binding DRAFT) is subject to reversal and worse by
the Arbitrator.

2009-09-28 Tverify is now operating under the authority of board motion m20090928.1 (Run Tverify as-is until End Of Life 20091116) and under Assurance Policy. This latter means no issues of points over 50, and the earlier includes some restrictions.

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.

Assurance Policy, 1. Purpose of Assurance

1.1.The Assurance Statement

The Assurance Statement makes the following claims about a person:

   1. The person is a bona fide Member. In other words, the person is a member of the CAcert Community as defined by the CAcert Community Agreement (CCA);
   2. The Member has a (login) account with CAcert's on-line registration and service system;
   3. The Member can be determined from any CAcert certificate issued by the Account;
   4. The Member is bound into CAcert's Arbitration as defined by the CAcert Community Agreement;
   5. Some personal details of the Member are known to CAcert: the individual Name(s), primary and other listed individual email address(es), secondary distinguishing feature (e.g. DoB).

The confidence level of the Assurance Statement is expressed by the Assurance Points.

Assurance Policy, 6. Subsidiary Policies

6. Subsidiary Policies
6.1. Standard
Each Subsidiary Policy must augment and improve the general standards in this Assurance Policy. It is the responsibility of each Subsidiary Policy to describe how it maintains and improves the specific and overall goals. It must describe exceptions and potential areas of risk.

CCA 2.3

  2.3  Obligations  (as Assurer)
You are obliged
   1. to provide accurate information as part of Assurance. You give permission for verification of the information using CAcert-approved methods.

The decisions regarding "Thawte points removals" are NOD. The decisions follows policies in effect and the CAcert's audit criterias
1. AP
2. CCA
Re-assurance with another primary email address:
- AP defines: 4.5. CAcert Assurance Programme (CAP) form
  - ```
  The CAcert Assurance Programme (CAP) form requests the following details of each Member or Prospective Member:
   * Primary email address, as recorded in the on-line account;
```
- The primary email address that has been used in its initialy assurance has been verified by the time, the assurance was given. Its recorded in CAcert's notary table of the critical system. The primary email address may fade out. CCA only defines as the members obligation, to keep his primary email address in good working order. This doesn't prevents a member to switch the primary email address later. Once an email address is out of service, the email probably has been removed as its no longer active. The assurer can link to the account thru the notary table id to the user. Support can evaluate the current primary email address of the user. And in a dispute filing, the Arbitrator has to contact the user by his current primary email address. The reliance path is unchanged, still intact.
- So the only exception will be, that the assurer now is to be instructed, to enter the current active primary email address of the assuree instead of the one that is written to the CAP form.
- So as long the documentation of the process will be done seriously, adding addtl. informations to the online record, adding documentation to the CAP form, as long this process is verifyable by another arbitrator or auditor, there is no doubt, in transfering the current primary email address of the assuree to the assurer, so that he can re-apply the assurance with the current valid primary email address.

x³) related

in the old days, also in year 2009 TTP assurances were entered into the system with assurance method "F2F" or "empty". Info from a20091118.1

"2010-10-06 7 variants of TTP entered into the system has been identified". Records interesting for current running case: records 2, 3, 4, 5, 6

TTP variant	..	awarded	points	method	location	remarks
1	..	0	0..150	Trusted Third Parties	<empty>	webdb code before 2007
2	..	0	0..150	<empty>	<empty>	bug# 855
3	..	0..150	0..150	Face to Face Meeting	TTP	webdb code between 2007 and Oct 2009
4	..	0..150	0..150	Face to Face Meeting	TPP	TTP typo, webdb code between 2007 and Oct 2009
5	..	0..150	0..150	<empty>	<empty>	bug# 855
6	..	0..150	0..35	Face to Face Meeting	TTP	webdb code starting Oct 2009
7	..	0..35	0..35	<empty>	free text or empty	bug# 855, current webdb code, results from catest1

"2010-11-11 (R): sends a list of undef assurance methods in database and their real relation by CAP forms"

Awarded	Points	Location	Method	confirmed to
0	150	<empty>	<empty>	TTP
150	150	some text	<empty>	F2F
35	0	some text	<empty>	F2F
0	60	<empty>	F2F	TTP
0	90, 150	<empty>	Unknown	TTP

Frankfurt/Main, 2011-11-30

Considerations II

Part 1

Riscs - blocking issues

Support detects data inconsistency in the users account (eg name with suffix that is prevented by PracticeOnNames

Assurer reports data inconsistency in assurees account (wrong DoB).
This relates to the Step 4 b.4 exception handling of intermediate ruling #1

The blocking issues prevents progress in the assurance records repair process. all above issues has to refer to arbitration (if not yet ruled with a precedent)
So its possible, that in the "revoke my assurance/re-apply assurance" process, another issue araises and has to be transfered to arbitration. This blocks the repair process.
Assuming, that the new filed dispute awaits pickup by an arbitrator, its not unlikely of a one year timespan until the new case will be picked up by an arbitrator. Its also not unlikely, that in the meanwhile the "Thawte points removal" project will finish by setting the removal of points active and the user may loose points despite the fact that are enough points available by yet unrepaired records.
Such a scenrio should be prevented by
1. proceed with the repair process -and-
2. start a new dispute filing
But this means, that the assurer has to re-apply an assurance with a data inconsistency
Can this be allowed? -or- How does a solution have to look like?
- eg. first file a dispute, proceed with the repair and document started dispute filing with arbitration #
Assumptions:
1. DoB mismatch
2. Name mismatch (not handled by precedent yet)

To assure someone with a wrong DoB or Name mismatch, general rule is to stop assurance.

here we now have a conflicting situation, a user record with more or less wrong data, a falsery old assurance, an assurance that is prevented by rules, and the sword of Damocles of revoked assurance points.
- in a common arbitration case with Name or DoB mismatch the assurance record still exist, the user record with the data inconsistency exist and the arbitrator discovers the facts. Until the ruling the mismatching data persists in the users record
- same with the disputed users data in the revoke assurance/re-apply assurance record. by starting the process the assurance record still exist. By the started dispute filing the users data awaits a ruling to get repaired. Until another arbitrators ruling the data mismatch can still persist
Is the type of mismatch essential? (-> DoB or Name mismatch?) -or- do they have to be treated differently? (-> hard error? soft error?)
1. A name error may affects CPS (certs with name in it)
2. A DoB error doesn't affects CPS (DoB will never be added to a cert)

Until an error has been confirmed thru arbitration ruling, the potential error keeps staying in the users account under common dispute filing. There is no difference if this is a hard error or soft error and there exist no precedent ruling or other unique ruling that a user account has to be locked caused by this issue in the past

CPS 3.1 Naming defines for client certs:

3.1.1. Types of names

Client Certificates. The Subscriber Naming consists of: 

 * CN= The common name takes its value from one of:
    * For individual Members, a Name of the Subscriber, as Assured under AP.

The definition "as Assured under AP" will probably disqualify all older assurances

Currently CAcert is running under the "relaxed" variant, that allows all old transfered assurances to be listed and counted, despite the fact, assurances were made and AP doesn't exist by the time. This issue has been taken into account by the audit plan

Future, ongoing

Task	Who	Status	Blocking	Since	Comment
Review of WoT Exceptions - OA, SuperA, TVerify, ...	authors	only blocking themselves	DRC-C	Some of these are being wound-down so may be scrapped by time Audit gets to them

and Priorities for Policy Group -> Legacy Points Policy -- an anticipated policy to clarify the status of old pre-AP points.
So here we have a flow between practice and defined policies that needs a fix one day. This means, this topic is still left open from Policy Group and community, so current state is current practice that needs a fix in the near future either way. The easy fix: write the "Legacy Points Policy" - a subpolicy under AP, so the clause "as Assured under AP" becomes true. So in common: b.1 is inline with current state
The "checkbox fix" in re-applying assurances conforms to the assurers statement in repairing an existant old assurance record. The identified potential name problem relates to the state in common arbitration cases, where potential name problems keeps staying until an arbitraton is ruled and the name gets corrected.
So here again the question, what has the higher priority? The fix of old assurance records, before the users are cut off a specific level, before the "Thawte points removal" project finishes? or the clause "as assured under AP"? that is in conflict with old assurance points either way?
Server certs aren't affected by CPS

Intermediate Ruling #2

This ruling is a followup to the Intermediate ruling #1 dated 2011-11-30 regarding individual cases "Revoke Assurance/Re-apply Assurance" following the "Thawte points removal" project

Part 1

In step 4 execution of "revoke assurance/re-apply assurance" process by a Support-Engineer who stays in contact with one or more Assurees and one or more Assurers (depends on who initiated the request and how many records are affected by the identified 0 points or decreased points bug) its likely that additional problems with user account data may block continuation of the running process - the repair of old assurance records as identified in the Riscs section under Considerations II to this case.

So here we have to seperate two cases:

Support-Engineer detects a name mismatch with current AP and current practice.
Assurer detects a name- or DoB mismatch in the Assurees online account.

Both issues blocks the running process as a potential name- or DoB mismatch cannot be passed in Re-appliance of an old assurance.

To work around the Assurance re-appliance, Support-Engineer (for case 1) or Assurer (for case 2) is allowed to pickup the issue as a new issue.

Support-Engineer (in case 1) or Assurer (in case 2) should start an intermediate new dispute filing that contains the following infos as addtl. infos:

revoke assurance/re-apply assurance case ticket number (ticket id of order received by Support (case 2)) under which the data inconsistency has been identified
The name + email of the involved parties
1. case 2: (C) Assurer (R) Assuree
2. case 1: (C) Support (R) Assuree or Assurer x¹)

x¹) if the data mismatch relates to the assurer, Support-Engineer is allowed to send a notification to the Assurer, and Assurer starts the new dispute filing by his own

The running Support ticket should be set on hold temporarely.

The Support-Engineer is allowed to move the new dispute filing by documenting the new ticket id number to the running case for later reference with high priority to the disputes queue. The Support-Engineer is further allowed to contact a potential Initial Case Manager (iCM) to transfer the new dispute filing from the Disputes queue to the Arbitration list, to get a new Arbitration case number selected for further documentation references.

In the case no iCM responds within a 24 hours period, Support-Engineer is allowed to act as iCM (DRP 1.3 Case Manager) to transfer the new dispute filing from the Disputes queue into the Arbitration queue, creating a new Arbitration case # under Arbitrations list with the ticket number of the new dispute filing ticket # under Synopsis column.

Support should document the new Arbitration case number to the current running case (Support ticket) as a ticket note:

eg. Dispute filed, new Arbitration case #, involved parties, reason

The on-hold current running case should be reset by the Support-Engineer to unhold and Support-Engineer should continue with the execution orders in the running "revoke assurance/re-apply assurance" processing to the Assurer

Support-Engineer and Assurer have to enhance the documentation regarding the "revoke assurance/re-apply assurance" documentation with the information regarding the new dispute filing infos:

New Arbitration case number

into the running Support ticket (by Support-Engineer) and to the affected CAP form (by Assurer)

I hereby gave the Assurer the permission with reference to this current Arbitration case # and documentation of the new Arbitration case # where the new dispute filing has been initiated to continue with order given by a Support-Engineer to re-apply the assurance.

Reason given: the data mismatch will be handled under the new arbitration case number. An identified data mismatch can be accepted temporarely until this data mismatch will be fixed finaly through another arbitration case, but is not subject to the current case. This procedure follows each common arbitration handling, where disputed data mismatches aren't fixed before arbitrators interaction.

In cases where a precedent case exist to handle the identified data mismatch, a second Support-Engineer is allowed to pickup the case and to proceed with the precedent ruling of such a case. If such a case happens, the dispute filing can be moved to the Support-Engineer queue instead of the Dispute filing queue.

The documentation has to cover the ticket id and the precedent arbitration case # under which the data mismatch dispute is handled instead of a new Arbitration case #

In the event a new dispute filing is started, the acting Support-Engineer is explicitly allowed to pickup the new dispute filing from the Triage queue to move it to the correct OTRS queue or to instruct a Triage member to move the ticket to the appprobiate queue (case can be handled with precedent - move into SE queue, case has be handled by new arbitration - move into disputes queue) so the ticket ends in the correct queue.

The reasons to take intermediate actions is, that delays in processing the revoke-assurance/re-apply assurance process should be prevented, to keep the process flow intact and to not delay the issues longer as needed.

The fast track processing of the revoke-assurance/re-apply assurance cases that relates to the "Thawte points removal" project is running under a deadline (that is currently not set, but may be set in the near future). It can be assumed, that the deadline setting will not take into account open running arbitration cases or open Support tickets. A sequentiell processing may break the current running process (old assurance records becoming not re-applyed) and will potentialy open another problem, that data inconsistency will still continue to be in the database. So therefor the running case should be finished with all the exceptions given, and the new issue is transfered to a new dispute to be handled under another precedent # or under a new arbitration case.

Support should deploy a handbook page that covers this current special case with current state steps 1 to 4 on processing with remarks to the potential exceptions handlings and the reference to current arbitration case number.

I hereby give Support the permission to handle the current received tickets with the similiar "revoke my assurance/re-apply assurance" requests accordingly to the current case upto todays date, with reference to the current case to be the proposed precedent for this cases.

I hereby request from the handling Support-Engineer(s) a short written exec meta report summary, regarding the next couple of cases to handle until today, how the current procedural steps fits to the processing in practice. If Support-Engineer identified further blocking issues? or if a ruled step needs further clarification.

Frankfurt/Main, 2011-12-05 Ulrich Schroeter

Ruling

Execution

Similiar Cases

a20101201.1	ABC over Marcus Mängel
a20100210.2	Revoke assurance 24 hours / 3 days / 7 days after an event - Precedents Case
a20101016.1	Remove assurance (24 hours rule)
a20090303.1	Assurance made on an unproper form
a20090306.1	CAP form on the official website doesn't conform the Assurance Policy
a20100304.1	dispute for privacy purposes
a20091118.1	Assurances while TTP program frozen
a20100822.1	SQL Query
a20101114.1	Adhoc interactive SQL-query
a20090525.1	Event officer request recurrent notification to assurers near the location of the following ATEs - Precedents Case
a20110608.1	Scripted Mailing to Organisation contacts for Class3 Subroot Re-sign project - Precedents Case
a20110312.1	Weak CAcert certificates found in EFF SSL Observatory data
a20110413.1	Adhoc SQL query (Weak Pwd)
a20100309.1	periodic transfer of email addresses for general announcements (Newsletter mailing)
a20111019.1	Missing points after applying bug fix 827

2011-11-25	today
2006-08-30	column awarded was added
2004-11-25 and older	CAPS destroyed