CAcert Code Development list.

[Bernhard Froehlich <ted AT convey.de>]

dirk astrath schrieb:
> hiya,
>
> while implementing the patches for the storage of the CCA-agreement,
> some questions came up ...
>
> (a)     database-structure:
>
> a short discussion between ian, philipp and me showed, that a new table
> should be used to store the data ... so i did:
>
> CREATE TABLE  `cacert`.`users_agreements` (
>   `ID` int(11) NOT NULL auto_increment,
>   `users_id` int(11) NOT NULL,
>   `secondary_users_id` int(11) default NULL,
>   `document` varchar(50) default NULL,
>   `date` datetime default NULL,
>   `type` varchar(10) NOT NULL,
>   `comment` varchar(100) NOT NULL,
>   `usercomment` varchar(100) default NULL,
>   PRIMARY KEY  (`ID`)
> ) ENGINE=MyISAM AUTO_INCREMENT=8 DEFAULT CHARSET=utf8
>
> Let me explain this structure:
>
> Normally the fields are used in the following way:
> users_id        from users-table
> document        'CCA' as a fixed string up to now
> date            date of agreement (=now)
> type            'Active' as a fixed string
> comment         using 'which' action (Join, ...)
> ... other fields stay NULL ...
>   
Hi Dirk,

those DB changes look quite good to me. One thing that just jumped to my 
mind: Maybe we should provide the possibility to keep a *rejected* 
answer (at least temporarily), so maybe an additional boolean "accepted" 
column would be nice to have.
> at an assurance this behavior changes a little bit:
> users_id        from users-table
> document        'CCA' as a fixed string up to now
> date            date of agreement (=now)
> type            'Active' or 'Passive' as a fixed string
> comment         using 'which' action (Assured by/Assuring)
> secondary_users_id      The 'opposite part at an assurance
>
> ... which means: during an assurance two records are created ... one for
> the assurer (active) and one for the applicant (passive)
>   

I'm not very happy about "implicit acceptance" of the CCA by doing an 
Assurance. At least there should be two checkboxes, one for "The 
applicant did accept the CCA" and "I accept the CCA". And maybe those 
Checkboxes should only be shown if there is no "accepted" record of the 
relevant type in the agreements-table.
As described below I'd prefer the explicit acceptance of the CCA during 
the login process.

> the field 'usercomment' stays empty at the moment ... it may be used
> later when the user has to sign/... the agreement
>
> However: Most of this work is done ... if there are no request-changes,
> i'll put the patches on test1.cacert.at before weekend (hopefully ...
> ;-) ) so everything can be tested ...
>   
> Now it's your part to send the wishes for these patches ... ;-)
>
> have a nice day ...
>
> ps: as far as i heard from ian, it's really necessary for the audit to
> ask for CCA before generating certificates, signing pgp-keys etc. ...
>   
My idea would be the following:

   * At every login the users_agreements table is checked whether all
     "important" agreements (currently only the CCA) have been accepted.
   * If agreements have been rejected a message is shown, maybe there
     could be the possibility for the user to change his mind now and
     accept the agreement.
   * If there is neither an accepted not a rejected agreement record
     the user is shown the agreement and asked to "accept and continue"
     or "reject and resign from CAcert"
   * If an accepted agreement is found the login continues as usual

I prefer this idea to the idea of "implicitly accepting" by signing CAP 
forms because it leaves less loopholes for the user to say "but you did 
not tell me this"... Of course the "implicit accepting" would still be 
better than the current situation (nothing).

But maybe this is probably a topic for the policy list anyway...

Kind regards
Ted
;)

--
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature