Oui, enfoncer le clou, je suis d’accord. Et je vois ce que tu veux dire avec la nécessité de prendre son temps. Je vise l’efficacité et non la vitesse. Je vais travailler sur ce que tu apportes, merci.
2 « J'aime »
Ton initiative est excellente. Je ne l’ai pas encore lue (j’attends la version finale, rien que pour t’embêter 
).
Je pense qu’il faut proposer des conseils simples et concrets :
- Le certificateur envoie une June sur le compte désigné et attends de voir si on lui renvoi.
- New : donner une copie de son fichier de révocation au certificateur en qui on a le plus confiance.
Note pour moi même : ajouter aux logiciels clients un outil de vérification de signature, notamment pour le fichier de révocation…
Ah mais, si tu attends la version « finale », ce sera trop tard pour mettre ton grain de sel. 
1 « J'aime »
Du coup je ne vais pas attendre la version finale pour donner mon avis de personne qui n’a pas lu tout le fil de discussion, mais qui à déjà trouvé la licence perfectible :
- Licence pour moi, cela désigne un document contractuel dans le quel sont décrit des engagements, des obligations opposable à la personne qui la signe si elle ne la respecte pas. Informations, conseils, recommandations… n’ont pour moi pas leur place dans une licence, seulement des engagements.
- Charte pour moi, cela désigne soit des engagements façon label contrôlé, soit des idéaux vers les quels on s’engage à tendre ou vers les quels on s’accorde collectivement telle une vision partagée.
- A part ça il y a des recomandations ou guide de bonne pratique qui me semble désigner le type de document qui conseil, guide, encourage des comportement, des bonnes pratiques.
- Il y a des documents informatif visant à l’exhaustivité désigné sous le terme documentation.
- Et les documents informatifs visant la brièveté nommé L’essentiel de ou Récapitulatif, Résumé, en Bref…
Quelqu’un qui découvre monnaie libre, Ǧ1, la communauté associé… bref, notre écosystème peu vite être perdu, et selon moi, il est préférable d’avoir plusieurs documents court, qui ne remplissent qu’une seul de ses fonctions, quitte à faire référence aux autres documents pour ce qui sort du champs d’un des documents, pour facilité l’inclusion.
Du coup, pour moi la licence pourrais se résumé à un document ou l’usager s’engage à :
- avoir pris connaissance d’un récapitulatif des notions fondamentales, (qui fait référence à une doc)
- avoir pris connaissance du guide de bonne pratique, (qui fait référence à des articles explicatifs)
- respecter une charte (qui peut faire référence à une vision pour contextualiser les flous)
En outre, découper tout ça pour ne pas avoir à tout intégré d’un coup me semble utile :
- licence (ou charte) du membre
- licence (ou charte) du certificateur
- licence (ou charte) du forgeron (membre qui fait tourner un noeud)
- licence (ou charte) du développeur (contributeur à l’écosystème technique)
- licence (ou charte) du porte parole/organisateur d’évènement/prosélite/évangélisateur/communiquant
Ainsi :
- le membre s’engage à n’avoir qu’un compte membre
- Le certificateur à certifier selon certains principes
- Le forgeron à adopter une vigilance politique sur les mise à jours qu’il execute et technique sur différents aspects
- Le développeur à inclure les licenses adapté aux contexte de ce qu’il produit pour que les usagers s’y engagent
- les porte paroles à quelques principes de réserve, de rigueurs et de bienveillance pour ne pas véhiculer n’importe quoi ni faire fuir les gens.
Vaste programme !
Intéressant. Le membre pouvant certifier, ma proposition de charte est à la fois pour le certificateur et pour le futur membre qu’il s’apprête à certifier. La récursivité est dans cette phrase :
Voici pour chaque thème mes réflexions et ma proposition de modification.
-
Maîtrise du compte
Comme je le disais, il n’y a pas de mesure claire pour ce critère. Mais dans la partie Promesse de certification, j’ajoute : il vérifie que le postulant maîtrise son compte : par exemple il lui envoie quelques Ğ1 afin que le postulant les lui renvoie.
Je modifie ainsi la phrase qui suggérait déjà cette précaution : grâce au virement aller-retour décrit plus haut. -
Enfoncer le clou à propos de l’impossibilité de récupérer les identifiants
Je souligne la phrase Savoir que le système n’a pas de procédure « mot de passe perdu ».
Dans la partie Promesse de certification, j’ajoute : Avant de l’accorder,
• il vérifie que le postulant a pris ses dispositions pour conserver ses phrases de passe, et qu’il a compris qu’il ne peut ni les modifier, ni les réclamer au système. -
Plusieurs rencontres
Au risque de paraître têtue, je trouve que ce n’est pas une nécessité, parce que l’unique rencontre peut avoir lieu après des mois de discussions poussées (sur le forum, par mél ou au téléphone), notamment pour répondre à des questions techniques. Ce qui compte, c’est d’avoir la conviction que le postulant est prêt, la certitude de son identité et une raisonnable certitude de l’unicité de son compte membre.
Cependant, je reformule ainsi la phrase relative au nom et prénom : le certificateur doit disposer de suffisamment d’éléments pour pouvoir reconnaître le postulant dans un autre contexte : au moins son nom, son prénom, sa ville de résidence, si possible une photo. -
Conséquences d’une triche
Il me semble que les dangers que tu décris se rapportent tous à une personne qui aurait créé plus d’un compte membre. La prise de contrôle de plusieurs nœuds est une éventuelle étape ultérieure.
Dans la partie Unicité du compte membre, à la suite de si une personne se faisait certifier sous deux identités différentes, elle cocréerait deux DU quotidiens au lieu d’un, j’ajoute et aurait plus de facilité pour se créer des comptes membres supplémentaires, puis attaquer la stabilité du réseau et la fiabilité des opérations. Est-ce que cela couvre ce que tu voulais dire ?
Tu suggères de parler plus tôt du document de révocation. Certes, le doc est important, et c’est pourquoi je détaille son utilité. Mais il me paraît difficile d’en parler plus tôt car la charte est construite sur la chronologie des évènements. Le doc de révocation est généré après la demande d’adhésion, qui survient elle-même après toutes les précautions décrites.
En rédigeant tout cela, je m’aperçois qu’il faut dire un mot du cas où on certifie une personne qui est déjà membre. Voici une intro plus complète : Le certificateur s’engage à respecter cette charte. Avant d’accorder une certification supplémentaire à une personne qui est déjà membre, il prend les précautions énumérées sous le titre Unicité du compte membre et effectue la vérification relative au document de révocation. Avec des liens vers les paragraphes en question.
Je t’envoie par mél le document avec une mise en évidence des modifs. J’attends tes réactions et celles des autres lecteurs avant de publier la V2 ici.
1 « J'aime »
Voici la Charte du certificateur V2.pdf (534,0 Ko) .
J’ai remplacé le mot « postulant » par demandeur. J’ai supprimé la phrase qui commence par « Si le demandeur ne fait pas partie du réseau du certificateur », car elle peut donner l’impression qu’on peut certifier un inconnu lors d’un évènement autour de la monnaie libre. Je continue toutefois à penser que le nombre de rencontres n’est pas un bon indicateur de la sécurité. Faut-il « ne jamais coucher le premier soir », ou plutôt « savoir à qui on a affaire et utiliser des capotes » ? 
J’avais oublié de répondre à ceci :
Houlà, t’es sûr ? L’avenir de la relation avec ce certificateur est incertain (on peut perdre le contact après quelques temps), et le compte membre est voué à durer très longtemps.
C’est une proposition à laquelle je réfléchis encore car effectivement elle implique une grande confiance dans la personne, mais elle a aussi des avantages.
Je ne dis pas qu’il faut mettre ça dans la charte.
Pour l’instant c’est juste une proposition, qui si elle est validée par l’usage devient une bonne pratique, puis si cela améliore vraiment la sécurité au quotidien, alors on met cela dans la charte ou la licence.
Mais il faut avant réfléchir aux avantages et aux inconvénients. Si les premiers sont plus nombreux et avec une valeur (relative) plus importante pour le groupe certifié/certificateurs alors on peut considérer que ce n’est pas un risque trop important.
Quels sont les avantages :
- Le certificateur peut vérifier la signature du fichier, voir si elle correspond bien au compte.
- Le certificateur peut communiquer cette vérification aux autres certificateurs potentiels.
- Le certificateur peut fournir le fichier en cas de perte par le certifié.
Quels sont les risques :
- Le certificateur fait du chantage à la révocation. Si le certifié a plus de cinq certificateurs en contact, ce chantage à peu de chance d’aboutir. Le membre peut recréer son compte et faire savoir à la communauté le chantage qu’il a subit.
- Le certificateur n’a pas compris le but du fichier ou bien le confond avec le sien : révocation accidentelle du compte. Là encore, même si c’est pénible, on peut se sortir de la situation.
Aux lecteurs, si vous avez des idées sur des inconvénients vraiment sérieux (sécurité de la Toile de Confiance, action irréversible pour le certifié, etc) de cette idée, merci de les partager ici.
2 « J'aime »
La variante plus difficile à récupérer mais plus sûre est le secret de Shamir. Je suis prêt à implémenter un générateur de fichier de révocation découpé en plusieurs fichiers à distribuer à plusieurs personnes, et un « recolleur » de fichiers pour reformer le fichier original. En Rust ou en Python, mais pas avant 3 semaines.
Le futur certifié entre ses identifiants ainsi que le nombre (et éventuellement la hiérarchie) des co-révocateurs potentiels dans son ordinateur, et donne les fichiers par mail, clé USB, message Cesium ou QR code. L’étape de révocation ne mettant en œuvre aucun secret (le but étant de publier le secret partagé), il est même possible pour un néophyte de demander aux gens d’envoyer les morceaux à un geek qui révoquera le compte à sa place.
3 « J'aime »
Autres menaces/inconvénients :
- le certificateur se fait voler tous les certificats de révocation qui lui ont été confiés et tous se font révoquer, déstabilisant le réseau de confiance
- un certificateur ancien est en désaccord avec l’évolution de la ML et décide de lui nuire en révoquant tous ceux qu’il peut
- un groupe de certificateurs décide d’exclure un autre groupe avec lequel ils sont en désaccord. S’ils sont plus anciens dans le système, et sont dans la chaine de certification des cibles, c’est faisable. Il n’est pas nécessaire de révoquer la cible, on peut aussi révoquer le certificateur du certificateur […] de la cible.
- le nouveau certifié à l’impression qu’on lui demande de baisser son froc devant les anciens, induisant un rapport de force entre les anciens certifiés, indépendants, et les nouveaux, qu’on oblige à se mettre en position de faiblesse
C’est vraiment une drôle d’idée cette histoire de partage de certificat de révocation. Soit vous faites confiance aux gens, et ils gardent leur CR secret. Soit vous ne leur faites pas confiance, et autorisez simplement des administrateurs à révoquer des comptes. Comment promouvoir la liberté et en même temps la dépendance volontaire ?
A la limite, une solution serait que les certificateurs puissent retirer leur certification immédiatement au lieu de devoir attendre deux ans. Ça permet de révoquer en cas de perte des identifiants, à la demande de l’utilisateur, mais en même temps ça limite les risques d’attaque puisqu’ils faut que tous les certificateurs à part 4 retirent leur certification. Mais il y a peut-être des limitations techniques ?
1 « J'aime »
Effectivement, bien vu :
- Les effets de groupes peuvent être très dangereux.
- L’effet psychologique du sentiment de soumission vis à vis des anciens. C’est très bien vu ça.
- Donner son fichier de révocation à son certificateur c’est lui donner le pouvoir de révoquer sa certification avant les deux ans, ce qui n’est pas voulu par les développeurs pour des raisons de chantage individuel et de volte-face incessante qui pourrait déstabiliser la Toile de Confiance.
La solution de @tuxmain permettrait de supprimer le danger d’une nuisance individuelle, au prix d’une complexité technologique accrue pour les non informaticiens (beaucoup de petits fichiers à conserver, trier, etc) mais rendrait je pense bien plus difficile les nuisances groupées.
Cette solution semble folle au premier abord, mais a le mérite de poser la question : comment être sûr que le certifié a sauvegardé son fichier de révocation ?
+1 pour le secret de Shamir ! 
Bein moi je trouve que contribuer à l’autonomie (liberté de choix éclairé) des personnes, c’est justement de leur dire que c’est à elles de gérer leurs affaires, et que si elles ont besoin de soutien, les certificateurs qui sont d’accord peuvent stocker une copie du fichier de révocation, et même, pour les personnes qui n’arrivent vraiment pas ou ne veulent pas se servir d’un ordi, stocker leurs mots de passe. Bon, là, c’est vraiment le boulot d’un tuteur mais bon, c’est ce que j’ai fait pour ma femme et mes enfants, mais je leur rend tout ça dès qu’ils veulent s’en occuper eux-mêmes (dans de bonne conditions).
Autrement dit, comment être sûr que les gens sont responsables et prévoyants ? Y compris contre leur volonté ?
Sauf que là il est discuté d’obliger les certifiés à donner leur certificat de révocation. Il n’est pas question d’aide.
Je comprends ta réticence devant toute contrainte extérieure ou obligation. Je suis comme toi, j’essaie de les éviter au maximum.
Par contre je suis aussi développeur sur le projet et je suis particulièrement sensible à la sécurité de celui-ci. Il faut bien comprendre que de ne pas pouvoir vérifier si le fichier de révocation est bien en possession du certifié et qu’il a conscience de son importance est un problème de sécurité qui impacte globalement toute la Toile de Confiance.
On a choisi de rendre responsable de la sécurité de la Toile, non pas un groupe de quelques personnes (ce qui serait absurde avec un système décentralisé), mais les membres eux-mêmes. Ceux-sont donc les certificateurs qui ont le pouvoir de contrôler la fiabilité des certifiés en terme de sécurité. Ils doivent donc avoir les moyens d’exercer ce pouvoir qu’on leur a confié. Or il y a des lacunes dans ce système :
- Vérifier que la personne possède le compte qu’elle veut faire certifier → proposition utilisée par certains : le certificateur envoie une June et demande son renvoi.
- Vérifier que les identifiants sont « fort » → impossible. On utilise donc la communication, l’éducation à la sécurité du mot de passe avant de certifier.
- Vérifier que le fichier de révocation est bien sauvegardé en lieu sûr et ne sera pas égaré → impossible actuellement. On cherche donc une solution.
Pour l’instant, pour ces trois conditions recommandées pour certifier, rien n’est dit quand à la façon de faire en pratique.
Ainsi, on discute ici avec les membres du forum, la façon d’appliquer enfin concrètement les pouvoirs conférés à tous les membres pour certifier. Je le répète, on passera toujours par une phase de mise en pratique, et si cela s’avère un gain de sécurité à l’usage pour la Toile, légitimant le pouvoir donné aux membres d’assurer la sécurité de leur propre monnaie, alors on en fera sûrement de ses règles d’usages des obligations si le besoin s’en fait sentir pour la sécurité de toute la monnaie.
Cela sera sûrement inclus dans la Charte du certificateur, pas sûr pour la licence (laissant la place à la créativité de solutions plus pratiques et moins contraignantes).
Il y a deux choses qui m’ennuient énormément dans cette charte :
Je trouve :
Qu’elle manque d’une introduction permettant de relativiser son contenu : savoir d’où elle vient, qui peut la modifier. Et qu’elle ne remplace pas la licence.
Et que la licence n’est pas fort visible dans cette charte, il me semble nécessaire d’ajouter, entre autre que la personne qui certifie dois vérifier que le demandeur à étudié compris et accepté la licence et qu’il n’est pas suffisant d’avoir rencontré le demandeur pour le certifier.
Il semble que chez nous, en Belgique et notamment à Charlerois des gens certifient à tours de bras, sans considération pour la licence. Certaines personnes sont certifiée sans même connaîte l’existance de la la licence G1…
Cette charte m’a été proposée comme si c’était un document de qualité. L’idée d’un charte pour les certifications dans les groupe locaux est une bonne idée mais je pense que cette version n’est pas encore terminée… Qu’en pensez-vous?
Bonjour,
Je suis l’autrice de la charte, ouverte à toute suggestion, et surtout je n’ai pas d’autorité particulière pour l’écrire ou la faire évoluer. Chacun peut se l’approprier et l’améliorer.
2 « J'aime »
Peut-être est-il possible de faire un mixte avec le « Quid de la demande de certification » disponible ici => Quid_de_la_demande_de_certification.md · main · fdrubigny / Ğ1 - Quid de la demande de certification · GitLab
1 « J'aime »