[PP-discussions] Expérience systèmes distribués ?

Sam 23 Jan 17:05:10 CET 2016

Regardez https://en.wikipedia.org/wiki/Ethereum cela permet de ne pas avoir
de point centralisé. Je pense que la techno "block chain" généralisé, a un
énorme potentiel.

Le 23 janvier 2016 à 15:23, Fabbad - PP-fr <fabbad at partipirate.org> a écrit
:

> Ok et merci.
> J’approfondirais quand j’aurais la maquette à présenter et je verrais avec
> les spécialistes pour tous ces aspects sécurité, mais, a priori, c’est à
> peu près comme ça que je voyais les choses avec, de toute manière,
> nécessité d’un annuaire global pour ce que je veux faire.
>
> Je m’explique par un exemple :
> - un groupe (section, équipe de travail etc.) installe librement son
> instance,
> - il la référence auprès du central si il y est autorisé
> - celui-ci offre ensuite à l’instance un service d’authentification, par
> exemple valider à partir de son numéro d’adhérent au Parti que c’est bien
> un Pirate qui veut s’inscrire.
>
> L’idée est une gestion autonome des groupes mais avec des inscrits pouvant
> être “certifiés” par la structure centrale et qu’elle sache recompter les
> voix lors de transferts de vote.
> Par exemple : x personnes adoptent une motion dans un groupe, cette motion
> est transmise au central avec ses votes, et ceux qui ont voté en local sont
> d’emblées identifiés et ne feront pas de votes doublons si ils viennent
> modifier leur vote sur le scrutin central.
>
>
>
> *From:* Frédéric Lecointre <frederic.lecointre at burnweb.net>
> *Sent:* Saturday, January 23, 2016 12:46 PM
> *To:* Fabbad - PP-fr <fabbad at partipirate.org> ;
> discussions at lists.partipirate.org
> *Subject:* Re: [PP-discussions] Expérience systèmes distribués ?
>
>
>
> Le 23/01/2016 12:07, Fabbad - PP-fr a écrit :
>
> J’avais parlé ailleurs d’un concept de démocratie liquide et plutôt que
> d’en rester à un cahier des charges de développement, je développe moi-même.
> J’ai encore 1-2 semaines de boulot pour la présentation d’une maquette
> fonctionnelle et je tergiverse un peu sur la gestion des données sachant
> que j’ai prévu un système multi-serveur.
>
> En gros, si je prends le Parti Pirate : chaque section (ou autre groupe)
> pourrait gérer son instance de l’appli et faire passer à une instance
> centrale les propositions/décisions validées à son niveau pour une mise au
> vote au niveau national.
>
> Pour la phase de tests, je ne vais pas trop me prendre la tête avec ça, il
> faudrait déjà que ça fonctionne techniquement et socialement (=
> participation) sur une instance monoserveur, mais :
>
> *y a-t-il parmi vous quelqu’un qui a l’expérience de ces architectures et
> qui pourrait au moins m’assurer que je n’ai pas trop à m’en soucier pour
> l’instant ?*
>
> Ce que j’ai prévu :
> - seule donnée réellement centralisée : ID unique utilisateur ;
>
> Oui mais tu vas encore te simplifier la vie en utilisant un identifiant
> unique sur une instance et c'est id at instance qui te sert d'identifiant
> unique dans ton réseau tout en te permettant d'identifier l'utilisateur
> dans son instance.
>
> A la fin de cette réponse, je pose quelque chose qui permet de gérer les
> inscriptions de façon presque anonyme. l'ACR permettant alors de s'inscrire
> dans une instance. Il faudra prévoir un annuaire global, par webfinger.
>
> - échanges : par webservice XML (ID, profils utilisateurs...) et du POST
> basique pour le passage d’une proposition à voter.
> A priori, rien de problématique, mais comme je n’ai jamais eu à gérer ce
> genre de développements...
>
> Ne présume pas du format d'échange et raisonne en fonction de message à
> échanger entre deux systèmes. Le reste découlera de l'architecture, des
> contraintes, du langages, etc. Cela peu se passer avec xmpp par exemple. En
> ce moment, je m’intéresse fortement à Ice (https://zeroc.com) qui permet
> de fournir un environnement multi-système mais surtout un bus de
> messagerie. Il y en a d'autres comme rabbitMQ ou 0MQ.
>
> -----------------------
> Toutefois, le principe de clé est intéressant mais ne devrait concerner
> que l'inscription. Avec le système actuel, le secrétaire peut facilement
> briser l'anonymat en ayant accès à la fois à la base de données des
> adhérents contenant le code confidentiel d'inscription et à la fois à la
> base de données de Liquid feedback. C'est peut être cela qu'il faut
> renforcer. De plus, les identifiants doivent être créés par l'utilisateur
> final et de lui seul. Cela évite l'interception décrite plus avant.
> Prenons le cas des certificats SSL. Je veux un certificat pour mon site.
> Je produis une paire de clés, je conserve la clé privé à l'abri. Ensuite,
> je produis un CSR (Certificat signing request, requête de signature d'un
> certificat) contenant les informations que je dois fournir (l'url du site à
> minima) et la clé publique. Je transmets mon certificat à une CA
> (Certification Authority, autorité de certification) qui signe mon
> certificat. Cela implique qu'elle approuve les données du CSR et produit un
> certificat que je peux ensuite utiliser sur mon site. Dans la pratique, et
> comme un passeport, on ne fait pas confiance au certificat du site web mais
> à la CA qui l'a signée. Ainsi, si la CA n'est pas approuvée sur mon
> système, une alerte de sécurité sera affichée. Cela ne veut pas dire que le
> certificat du site n'est pas valable (techniquement il fonctione très bien,
> voir par exemple le certificat SNake Oil
> <http://en.wikipedia.org/wiki/Snake_oil> d'Apache) mais que dans ma
> configuration, je ne peux pas lui faire confiance n'ayant pas fait
> confiance au préalable à la CA. SI je décide faire confiance à la CA, le
> certificat deviendra alors lui aussi de confiance.
>
> Voici donc en "résumé" le fonctionnement des chaines de certificat x509
> pour introduire ce qui suit.
>
> Appliqué à liquid feedback, ou un autre système équivalent, voici ce qu'il
> est possible d'obtenir :
> 0 - Le Parti Pirate génère un certificat racine pour créer une CA qui
> produit deux certificats CA intermédiaire : Un pour le secrétaire, un pour
> le gestionnaire liquid feedback. Les personnes ayant accès à un certificat
> ne doivent en aucun cas accéder à l'autre.
> 1 - Un nouvel adhérent génère un paire de clé et un CSR qui est transmis
> au secrétaire à l'inscription.
> 2 - le secrétaire valide l'inscription, produit un certificat à partir de
> la CSR et le signe. Il produit en outre un code confidentiel qu'il signe
> 3 - l'adhérent reçoit son certificat qui tient lieu de carte d'adhérent
> électronique et de moyen de s'authentifier auprès des différents services
> de Parti Pirate (forum, ML, wiki, redmine, etc.) mais pas liquid feedback
> 4 - il génère une nouvelle paire de clé et produit un ACR (Account
> Creation Request, requête de création de compte) contenant le code
> confidentiel signé mais pas d'informations nominatives
> *5 - il envoie l'ACR au gestionnaire Liquid feedback qui va produire un
> deuxième certificat permettant de s'authentifier auprès du service et sur
> la confiance en la signature du code confidentiel. A ce stade, ce
> gestionnaire ne connait pas et ne doit pas connaitre l'identité de
> l'émetteur de l'ACR. Le code confidentiel est supprimé du système à la
> création de ce certificat considérant que le préalable à la création de ce
> certificat est de confirmer que le code confidentiel est bien produit par
> le secrétaire.*
> *6 - Il se connecte à liquid feedback avec ce deuxième certificat.*
>
> J'ai une variante où une partie de l'ACR est créé par le secrétaire avec
> des informations utiles pour le vote comme la section d'appartenance. Dans
> ce cas, le code confidentiel disparait plus ou moins et cette partie d'ACR
> sert de preuve pour le gestionnaire liquid feedback.
>
> Une autre variante consiste à répudier (ou les rendre obsolètes pour la
> création de nouveaux certificats mais pas pour l'authentification) les CA
> intermédiaire lorsque physiquement les personnes changent au poste de
> secrétaire et gestionnaire.
>
> C'est une usine à gaz [image: ;-)] enfin une sorte de PKI (Public Key
> Infrastructure, infrastructure à clés publiques) qui au détriment de la
> simplicité du procédé (dans la pratique c'est assez fluide) permet des
> avantages non négligeables :
> - les certificats sont produits avec une durée de validité de 365 jours,
> c'est-à-dire une durée d’adhésion. Ainsi, et automatiquement, un adhérent
> n'ayant pas renouvelé son adhésion et connu comme tel. Cela désactive sa
> participation à liquid feedback sans intervention de la part du
> gestionnaire ni du secrétaire. Actuellement, je ne suis pas sûr que les
> adhérents n'ayant pas renouvelé leur inscription n'ont plus accès à Liquid
> Feedback. Oui cela implique la production d'un nouveau certificat de
> l'étape 2 et de rejouer les étapes 3 à 5
> - les certificats sont répudiables en cas de compromission et l'effet de
> la répudiation est immédiat
>
> Ce procédé implique les considérations suivantes :
> - Le secrétaire et le gestionnaire ne partage pas de données pour qu'à
> partir du code confidentiel l'un ou l'autre ne soit en mesure de briser
> l'anonymat. Ce point est critique et demande différents niveaux de
> protection suivant le degré de certitude que l'on souhaite obtenir.
> - L'utilisateur de Liquid feedback doit utiliser la plateforme au travers
> d'un réseau de type tor afin que le gestionnaire ne puisse pas faire la
> relation avec son adresse IP. Cela est valable pour la création du deuxième
> certificat et pour l'utilisation courante de la plateforme
> - Liquid feedback ne doit concerner que la partie 4 du processus
> démocratique, ou enfin il faut trouver un autre système de vote qui ne
> serve qu'à cela.
>
> --
> Frédéric Lecointre
>
> _______________________________________________
> Discussions mailing list
> Discussions at lists.partipirate.org
> http://lists.partipirate.org/mailman/listinfo/discussions
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.partipirate.org/mailman/private/discussions/attachments/20160123/c3dacf2d/attachment.html>