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

Frédéric Lecointre frederic.lecointre at burnweb.net
Sam 23 Jan 14:56:41 CET 2016


Dans l'absolu non car Diaspora :
- utilise un identifiant utilisateur at instance
- utilise webfinger pour obtenir les informations sur l'utilisateur
- utilise xmpp pour communiquer entre chaque instance

Toutefois Diaspora échange des messages d'un certain type qui ne sont
pas compatible avec l'application (enfin à ce stade)

Le 23/01/2016 14:42, vallois.julien a écrit :
> Je dis une connerie si je cite que diaspora pourrait répondre à
> quelques problématiques cités notamment sur l'identification et le
> distribué ?
>
> Le 23 janvier 2016 à 12:46, Frédéric Lecointre
> <frederic.lecointre at burnweb.net
> <mailto:frederic.lecointre at burnweb.net>> a écrit :
>
>
>
>     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 ;-) 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
>     <mailto:Discussions at lists.partipirate.org>
>     http://lists.partipirate.org/mailman/listinfo/discussions
>
>
>
>
> -- 
> /“Le monde ne sera pas détruit par ceux qui font le mal, mais par ceux
> qui les regardent sans rien faire.”  Albert Einstein/

-- 
Frédéric Lecointre
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.partipirate.org/mailman/private/discussions/attachments/20160123/83e696f7/attachment.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/gif
Taille: 170 octets
Desc: non disponible
URL: <http://lists.partipirate.org/mailman/private/discussions/attachments/20160123/83e696f7/attachment.gif>


More information about the Discussions mailing list