- Case Number: a20091118.5
- Status: closed
Remark: This case was split from a20091118.1.
- Claimants: Dirk Astrath (C)
- Respondents: Philipp Gühring (R)
- Case Manager: Alexander Prinsier (CM)
Arbitrator: UlrichSchroeter (A)
- Date of arbitration start: 2009-12-06
- Date of ruling: 2009-12-14
- Case closed: 2009-12-14
- Complaint summary: Code changes regarding TTP program
- Complaint (for the original dispute email, see Appendix 1):
(C) accuses (R) for making changes to the system that prevent further TTP assurances because the system now assigns an incorrect number of points.
- Relief: dispute dismissed
Before: Arbitrator UlrichSchroeter (A), Respondent: Philipp Gühring (R), Claimant: Dirk Astrath (C), Case: a20091118.5
History Log
2009-11-18 (UlrichSchroeter): added this case to wiki, request for CM and A
- 2009-12-02 (A): i'll take care about this case
- 2009-12-02 (CM): I'll take this as CM
- 2009-12-04 (A): intermediate ruling 2 to seperate Part II and Part III of a20091118.1
- 2009-12-04 (C): accepts CCA / DRP under this arbitration by dispute-filing dated 2009-11-18
- 2009-12-05 (CM): sent init mail to (R)
- 2009-12-05 (A): requests info about database structure - table: users - ttpadmin flag usage from Education Officer
- 2009-12-05 (A): rcvd infos from Education officer which database flags and which levels are needed to execute TTP assurance request
2009-12-05 (A): request to arbitrator of case a20090810.3 regarding the 150 pts level
2009-12-05 (A): rcvd info from arbitrator of case a20090810.3 that script has been executed late October 2009 to limit the points of users to 150 points.
2009-12-05 (A): request to former auditor Iang and Author Sam Johnston of Remote Assurance Policy (WIP) to answer some questions
2009-12-05 (A): questions to Lambert Hofstra, familiar with audit requirements regarding Remote Assurance Policy (WIP)
- 2009-12-05 (A): request to Crit.Sysadmins team of 3 sql queries: ttpadmin=1; board=1; ttpadmin=1 and board=1
- 2009-12-05 (A): Crit.Sysadmins team request answered
- 2009-12-06 (R): accepts CCA / DRP under this arbitration
- 2009-12-06 (R): statement: the claim is false, it is a wrong accusation
- 2009-12-07 (C): statement 2 (see below)
- 2009-12-08 (A): requesting: Do you accept (C) apology ? to (R)
- 2009-12-10 (R): Yes, I accept (C)'s apology.
- 2009-12-14 (A): Ruling
- 2009-12-14 (A): case closed.
Discovery
Seperated Arbitration case a20091118.1:
- Part III, dispute against Philipp G. who made changes to the system, which avoid correct TTP-assurances by rounding down the points to 35 instead of 50
=> new case number a20091118.5
AP 4.3. Assurance Points -> The maximum number of Assurance Points which can be allocated for an Assurance under this policy and under any act under any Subsidiary Policy (below) is 50 Assurance Points.
- Status of AP: Last change date: 2009-01-08, Status: POLICY p20090105.2
Maximum of Assurance Points one can get
- This is a Policy Discussions Overview. The initial document states:
- 2008-04-04 150 points is too high, equal to normal assurer (35 points?)?
- 2008-05-11 150 points is too high, Assurance Policy suggests a limit of 50 points on any assurance process., should TTP be 35 points, the same as any other assurer?, unclear why a TTP is considered more authoritive than our own most experienced and trained Assurers.
- 2008-07-14 (Feb 2008) Limit amount of points with TTP eg to 100 (each TTP 50) Consensus: TTP should not give Assurer power eg without Assurer Challenge. Opinions: TTP assured individual should become active as Assurer and help. # Assurance Policy suggests a limit of 50 points on any assurance process (see Assurance Policy) # should TTP be 35 points, the same as any other assurer?
2008-04-22 CACert Remote Assurance Policy (RAP) (WIP) 3.1 j+k
- 3.1 j: Suggested (iang, heard in a discussion, and following AP):
- For each TTP, RAO approves the allocation of 35 Assurance Points, making 70 points.
- 3.1 k: Suggested (iang, heard in a discussion, and following AP):
- Additionally, RAO may submit to the Board for the allocation of a further 30 Assurance Points, making 100 points available.
- 2009-12-06 Statement (R)
I was asked to remove the super-assurer status of all super-assurers. I did modify those persons accounts to limit their CAcert-Points to 150 points, to remove their super-assurer status. (Including Robert C. Account) The system always enforces (previously and now), that people that have 150 points can issue maximum 35 points. Since TTP issues more than 35 points, the person that does a TTP assurance has to have at least 200 points, to be able to issue more than 35 points. I only did changes to the database, by limiting the points of the accounts, I was asked to. I did not do any changes to the webserver. The application behaviour is still the same as it was before. Therefore the claim is false, it is a wrong accusation.
- Statement 2 (C)
Note: (C)'s reply also covers Arbitrations/a20091118.1.
> Please name me the script PG has modified > /path/script > from the CAcert sourcecode package http://www.cacert.org/src-lic.php > that results to your accusation > against respondent PG. according to the statement p. made i compiled the informations i got, checked the source and came to the following conclusion: p. did not modify the source, but he reduced the points of every 'enhanced' cacert-user to a maximum of 150 points (as it was a board-decision) ... which is correct according to the informations i got due to this arbitration case ... but i have some new questions: if RC (as an example) has ttpadmin set, but less then 200 points, how can he do a 'valid' ttp-assurance? (according to the mail: he can't ... rounded down to 35 instead of 50) if RC (to keep this example) has ttadmin set, but 200 points he can give 150 pts per assurance, which will break the policy ... (but according to the answer p. gave: RC does not have more than 150 pts) since the support-mail named in this case shows 'rounded down to 35 pts': does the user (applicant) still have 35 points? if the user has more than 35 points ... which was the way he had been assured? coming back to the point: even if it seemed that p. made code changes in the software, which did not have the expected result, i'm wrong (in this case) ... therefore: sorry to p. ... ... but the ttp-assurances in the last weeks/months are not clear to me ... ;-( i wasn't aware of the maximum number of points possible via TTP or super-assurances within the last months since i got several informations about super- and/or ttp-assurances. now i know the background ... and number of points possible ... have a nice day ...
- Board motions regarding TTP program
m20090912.1 that freezes this program and
m20090914.2 take it in effect.
- Naming of TTP program in Policies
AP doesn't name the TTP program
AssuranceHandbook2 name it in section:
- Major Variations
- Three Major Variations exist to the above
- - the TTP programme, see FAQ/AssuranceByTTP
as long all wiki pages states the TTP program is frozen, TTP program isn't active at the moment
There is no active definition, how many points can be assigned by the TTP program. There are only suggestions in the policy discussions about a TTP program / Remote Assurance Policy.
- Software code definitions aren't policy. They have to follow policies.
Ruling
I dismiss this dispute.
The claim that there software code changes were made regarding the TTP program is false, and is based on wrong accusations (C) made.
I conclude that (R) did not make any unauthorized code changes regarding this case.
For the record:
(C) apologies within his 2nd statement.
(R) accepts apology
Assertion
The whole system was designed 4 years ago, and does not reflect all today's rules that cames from policies. Mostly they are implemented in the one or another way. Motions and bugs are filed, but this doesn't indicate the implementation into the system.
The priority of the community is "when are the root certs in the browsers" which sets the board's priority of audit. It is always the #1 priority until changed by a call from the community. This is unlikely.
Following the audit, several Policies were applied and ratified. e.g. the Security Policy that includes the 4-eyes principle to update code on the system, the Assurance Policy that bans Assurance points > 50.
This is the environment the TTP Programme found itself in. It is an "oldtimer" from before the audit, and was "frozen" by the auditable Assurance Policy. But never updated.
Therefor the board started and accepted the motion(s) m20090912.1 m20090914.2 The first one that freezes this program and the 2nd one that take it in effect.
There was some activity around in the past to write a TTP policy named: Remote Assurance Policy (RAP) (WIP) but this document has not entered DRAFT status yet.
So therefor, for the arbitration process there is no policy in place.´There was also Policy discussion about this topic, The discussion about how many points can / should be given to the program varies. But as this is not yet a binding policy, so hereby i cannot rule on this if TTP assurances have to have 35 pts or 50 pts. I can only say, at this level this assurance program don't break AP as long as this program does not exceeds this limit of 50 pts that is set by AP.
If the community wants the TTP program back, they have to start a policy discussion to write a TTP policy.
On the other side, there is a common practice, to use TTP assurances with the default assurance form on the website. This wasn't expected that way. But this isn't the topic of this arbitration case and is already handled by another case.
(R) did round down everyone's points to a maximum of 150 in line with board motions m20090912.1 and m20090914.2. This influenced the TTP program indirectly, but it was not a code change. (C) acknowledges that (R) did not make any unauthorized code changes regarding this case.
Frankfurt/Main, Dec 11th, 2009
Execution
. None
Similiar Cases
Appendix
Appendix 1: Original mail from claimant
- Original dispute email (note: this case only handles the 3rd dispute from (C), please see a20091118.1 and a20091118.4 for the other sub-disputes)
on 11-11-2009 i got a message via the cacert-support-list with the following content: from: website-form@cacert.org schrieb: > > From: S* H* > > Email: s*@h* > > Subject: Rounding down of assurance points > > > > Message: > > Hi, > > > > I used the TTP method to get assured. When it was put into the > > [...] > > > > You were issued 150 points however the system has rounded this down > > to 35 and you now have 35 points in total. > > > > Best regards > > CAcert Support Team [...] however ... in detail: i want to file a dispute against several people: (1) [...] (background: robert gives 150 points for ttp-assurances while the ttp-program is frozen and the assurance policy allowes 50 points per assurance only) (2) [...] (3) against philipp g. ... since he made changes to the system, which avoid correct ttp-assurances by rounding down the points to 35 instead of 50 ------------------ [...] according the dispute against philipp this is a small bug, which causes no acts against the assurance policy ... but think about bugs, which may cause possible actions against the assurance policy. in my eyes there should be no modifications possible at the web-server without a second person checking the patch being implemented. (hint: i don't want to rule, since i'm no arbitrator ... it's just MY humble opinion as a normal cacert-user) [...] have a nice day ps: ... and yes ... i accept the CCA ...