[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