Archive for the ‘groupes’ Category

Nouvelle version librairie php

Samedi, juin 11th, 2016

Diffusion de la nouvelle librairie en php. Elle intègre nativement la gestion des conversations. La modification de la gestion des groupes n’est pas encore faite.

Le code : 9826667246765674e690e914bfc0a524f2847651f49f8ea1e638bb4122a3b4b4

Gestion des conversations

Lundi, mai 30th, 2016

La librairie php en cours de développement intègre maintenant nativement la gestion des conversations. Les conversations permettent de suivre des messages.
L’intégration dans la librairie permet de décharger les programmes comme sylabe et klicty de la gestion de ces conversations. Il permet aussi une uniformisation de cette gestion.

La gestion des conversations est au départ copiée/collée de la gestion des groupes. Mais elle a été revu au cours du développement.
Les conversations peuvent maintenant être marquées comme :

  1. fermée (ou ouverte)
  2. protégée (ou publique)
  3. dissimulée (ou affichée)

La fonctionnalité de conversation fermée est fonctionnelle, la protection est en court de développement et la dissimulation n’est pas encore développée.

L’intégration des groupes va être revu pour fonctionner de la même façon que les conversations.

Norme nebule v1.2

Jeudi, mars 31st, 2016

La documentation technique de nebule en version 1.2 est maintenant intégrée comme une page au blog. Elle passe en même temps de documentation à norme.

La partie concernant les groupes est agrandie.

Entités de recouvrement

Dimanche, février 28th, 2016

Le mécanisme de recouvrement des objets protégés et des liens dissimulés est en train d’être doucement mis en place.

D’un point de vue théorique, cela répond à deux problèmes similaires.
En entreprise, et pas que, il est recommandé d’utiliser une ou plusieurs autorités de recouvrement lorsque l’on utilise de la cryptographie pour protéger ses données. Les décideurs le prennent souvent comme une contraite et oublient de mettre en place ce mécanisme de restauration des données chiffrées. Et ce mécanisme est différent de celui de restauration classique alors qu’il est perçu comme étant le même. Résultat, lorsqu’un employé critique vient à manquer, ses données, critiques aussi, deviennent subitement inaccessibles. La disponibilité c’est aussi de la sécurité.
Pour différentes raisons, des états plus ou moins démocratiques peuvent imposer la mise en place d’un mécanisme de déchiffrement des données de leurs concitoyens.

Mais, afin de ne pas rompre la confiance, ce mécanisme doit être loyale, c’est à dire public, transparent et vérifiable.

D’un point de vue pratique, la mise en place comprend deux parties.
Il faut commencer par recenser les entités éligibles comme autorités de recouvrement. Pour l’instant dans le code de la librairie en php, la liste de ces entités est renvoyée vide. Les applications peuvent donc commencer à prendre en compte ces entités pour l’affichage public. C’est le cas dans klicty mais pas encore dans sylabe.
Il faut ensuite, lors de la protection d’un objet ou de la dissimulation d’un lien, dupliquer la protection ou le lien pour chacune des entités de recouvrement. Cela revient simplement à faire un partage de la protection pour un objet protégé en duplicant le lien de type k de chiffrement de la clé de session.

Pour terminer, la librairie n’intégrera pas par défaut d’entité de recouvrement. Si des entités sont définies comme tel, ce sera uniquement par choix (ou obligation) de l’entité responsable du serveur.

Intégration des groupes dans la librairie php – suite

Dimanche, février 21st, 2016

Suite à l’intégration des groupes dans la librairie php, l’ensemble est fonctionnel et stable dans la librairie ainsi que dans klicty.

Intégration des groupes dans la librairie php

Lundi, février 1st, 2016

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Définition des groupes

Jeudi, janvier 14th, 2016

Dans le cadre de la recherche sur l’implémentation des groupes dans nebule, voir 1 2 3 4 5, deux nouveaux objets réservés ont été ajoutés :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme

Le groupe

Il a été décidé de rattacher explicitement le groupe aux objets, et donc aussi aux entités notamment. Mais la notion de groupe peut être vu comme plus globale.

Si on reprend par exemple l’objet réservé nebule/danger, les objets qui lui sont liés deviennent de fait un groupe des objets à éviter. Il suffit donc de lier un objet à un autre objet pour créer un groupe. Cependant cela n’est pas très pratique puisque l’on ne peut rechercher que des groupes pré-définis à l’avance et communément acceptés. Cela marche bien pour quelques groupes avec des fonctions biens précises et universellement reconnues, et pas plus.

Fondamentalement, le groupe est la définition d’un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Le groupe met en relation des objets vis-à-vis d’une référence. C’est la référence qui identifie le groupe. Dans le cas de notre objet réservé nebule/danger, c’est cet objet réservé qui est la référence du groupe. Par simplification, l’objet de référence peut être assimilé comme étant le groupe.

Tout objet peut ainsi devenir la référence d’un groupe. Cela n’est pas sans poser un gros problème pratique. Puisque tout objet peut être un groupe, comment fait-on pour s’y retrouver dans l’immensité des groupes disponibles ?
Pour simplifier le problème, nous allons considérer les liens comme étant des groupes directs ou explicites. Et nous allons considérer les relations de deux liens ou plus comme étant des groupes indirectes ou implicites. Ces groupes indirectes sont centrés sur un et un seul objet de référence. Si nous prenons par exemple comme référence l’objet réservé nebule/objet/type, nous avons un groupe indirecte qui va contenir tous les objets de même type mime.

Nous allons à partir de maintenant considérer comme groupe uniquement les groupes indirectes.

Mais cela fait encore beaucoup trop de possibilités en pratique pour que la notion de groupe n’ai un intérêt pour gérer les objets. Nous allons en plus restreindre la notion du groupe, et donc son exploitation dans nebule, à l’objet vers lequel un lien explicite est créé avec les objets. Ce lien explicite est un lien de type l avec comme objet meta l’objet réservé nebule/objet/groupe ou nebule/objet/groupe/ferme.

Groupe ouvert ou fermé

L’exploitation des objets d’un groupe nécessite de pouvoir lire et vérifier les liens qui unissent les objets au groupe. Ces liens peuvent être générés par différentes entités, le traitement social des liens déterminera pour une entité donnée quels sont les objets reconnus dans le groupe ou pas. Ce processus est avant tout un traitement pour reconnaitre ou non les objets d’un groupe ouvert.

Pour un groupe fermé, la reconnaissance des objets du groupe n’est plus déterminée par le traitement social des liens. Ne sont reconnus les objets comme appartenant au groupe fermé que ceux dont le lien est signé par l’entité qui a créé le groupe. Dans le cas d’un groupe fermé, les liens générés par une autre entité pour ajouter des objets au groupe ne sont pas pris en compte.

Si il est possible de créer un groupe ouvert avec un objet de référence donné, le même objet de référence peut aussi servir pour un groupe fermé. Dans ce cas, lors du traitement, le groupe ouvert et le groupe fermé apparaissent comme deux groupes distincts. Si plusieurs entités créent des groupes ouverts avec le même objet de référence, un seul groupe est affiché et regroupe tous les groupes ouverts. Si plusieurs entités créent des groupes fermés avec le même objet de référence, il faut exploiter et afficher tous les groupes fermés comme des groupes indépendants.

Un groupe fermé doit toujours être accompagné son l’entité créatrice lors de l’affichage.

Groupe public ou privé

La distinction entre un groupe public et un groupe privé, c’est la visibilité de celui-ci pour les entités tierces. Si tous les liens qui relient les objets au groupe sont dissimulés, alors le groupe est privé et seuls les entités qui peuvent voir ces liens ont accès au groupe.

Cependant, si une partie des liens ne sont pas dissimulés ou si ils sont rendus publics, alors le groupe devient partiellement public.
Les liens, même dissimulés, sont complètement manipulables par toute entité qui y a accès, ainsi en terme de sécurité on peut dire qu’un groupe privé est un groupe public qui s’ignore. Mais ce n’est pas forcément un problème, si une entité A crée un groupe fermé et privé, alors le fait qu’une autre entité B crée un même groupe (même référence) ouvert et public ne rend pas pour autant public le groupe de l’entité A.

Groupe actif ou passif

Un groupe est par défaut passif. Il devient actif lorsqu’il devient capable de réaliser des actions, c’est à dire de signer des liens. Le seul objet capable de signer un lien est une entité, ainsi un groupe actif est un groupe dont l’objet de référence est une entité.

Si le secret de cette entité de référence du groupe n’est connu que d’une seule autre entité (entité maitresse) alors c’est un groupe actif fermé. Si cette entité de référence du groupe a plusieurs entités maitresses alors c’est un groupe actif ouvert.

Un groupe actif ouvert peut aussi être privé si tous ses liens sont dissimulés. Il devient semi-public ou public si une des entités maitresse dévoile tout ou partie des liens du groupe. De la même façon, une entité peut ajouter d’autres entités au groupe, c’est à dire partager le secret de l’entité de référence du groupe. En terme de sécurité, un groupe actif ouvert privé est souvent un groupe actif ouvert public qui s’ignore.

De fait, toute entité piratée devient un groupe actif ouvert, même si le secret de l’entité n’est pas rendu public.

Groupe d’entités

Un groupe d’entité est un groupe dans lequel on ne considère que les objets qui sont des entités. Les autres objets sont ignorés. Lorsque ce groupe n’est plus vu comme un groupe d’entités, tous les objets sont pris en compte et les entités sont gérés comme des objets. La distinction se fait donc uniquement sur le type d’objet que l’on attend du groupe au moment de l’exploiter.

Graphe de groupes

Lorsque l’on a un groupe qui est lié à un autre groupe, comme doit-on l’interpréter ?
Cela crée un graphe de groupes. Il est possible soit d’ignorer les sous-groupes dans un groupe ou au contraire de résoudre le graphe pour en exploiter tous les objets. Dans le cas de la résolution du graphe, on retombe sur les problèmes classiques de la résolution d’un graphe.

Le graphe de groupe peut aussi dans certains cas avoir un traitement convenu. Cela peut être appliqué à la gestion des options ou des droits dans une application. On va ainsi lier des groupes d’entités avec des groupes d’options et/ou des groupes de droits. Dans ce cas on ne parcours le graphe que de façon simple et non ambigüe.

Nœud

La notion de nœud est concurrente de la notion de groupe. Sauf usage nouveau et différencié, le nœud va disparaitre de nebule.

Cosignature – orientation

Mardi, juin 23rd, 2015

Dans la continuité de la réflexion sur la cosignature et suite.

Une des possibilités que doit permettre la cosignature, c’est que l’on puisse créer une signature (ou assimilé) valide alors que les différentes personnes (et leurs entités) ne sont pas réunies en même temps au même endroit pour réaliser cette signature commune.

Le système classique pour résoudre la cosignature consiste en la répartition du secret suivant le schéma de seuil de Shamir.

Cette solution de partage du secret n’est pas suffisante pour deux raisons.

Pour commencer, cela veut dire que l’on n’a toujours qu’un seul secret mais qu’il est répartit, dilué, entre plusieurs entités. Lorsque l’on veut faire une signature, il faut réunir un minimum de ces entités au même endroit pour accéder au secret qui permettra la signature. A ce moment, le secret est extrêmement vulnérable.
Il faut réaliser une sorte de cérémonie des clés pour cela.

Enfin, la génération du secret est réalisé par un seul équipement et ensuite répartit. Il faut ici aussi une cérémonie des clés avec tous les porteurs d’une partie du secret. Si il n’est pas possible de réunir tout le monde, une partie du secret doit être transmis de façon sûr vers le porteur concerné. Mais il ne peut pas dans ce cas garantir par lui-même que personne n’a copié sa partie du secret. Et surtout il ne peut garantir que personne n’a volé le secret complet lors de la cérémonie des clés.

Donc, il faut que chaque porteur génère sa partie de clé, on génère un bi-clé qu’il garde, et dont il peut garantir la confidentialité. Ensuite, il reste à réaliser le mécanisme intermédiaire qui permet, en ne connaissant que les clés publiques des porteurs, de valider une pseudo signature réalisée par chacun des porteurs. Une pseudo signature qui n’impose une présence ni spatial ni temporelle des porteurs.

Liens :
https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir
http://www.kilomaths.com/2010/07/partage-de-secret/

Cosignature – suite

Jeudi, mai 28th, 2015

Suite de l’article sur la Cosignature.

La notion de groupe est intéressante puisque pour l’instant, si le groupe a été définit dans sa ou ses formes, il n’a pas été définit dans son implémentation.

Cette implémentation peut rejoindre la notion de cosignature. En étendant la notion d’entité à autre chose que des bi-clés cryptographiques, notamment à un fichier de description du groupe et de la validité de sa signature (équivalente), on crée implicitement un groupe. Ce groupe hérite de par ses propriétés internes d’une capacité de signature et de vérification. Comme ce n’est pas un bi-clé cryptographique, il n’y a pas d’objet de clé privée. L’objet définissant le groupe n’est pas suffisant en lui-même pour signer des liens, il doit se reposer sur les ‘vraies’ entités qui composent le groupe.

Par exemple, la forme du fichier définissant un groupe de 3 entités peut être un objet contenant :

[Members]
88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea
01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4
19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
[Signe]
(88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea . 01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4)
+
(19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57 . 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea)
+
(01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4 . 19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57)
[Timestamp]
2015-05-28T22:20:13+0200

La signification du groupe, c’est que les membres sont 3 et que la signature d’un lien par deux des trois entités est valide comme étant celle du groupe ( (1 et 2) ou (2 et 3) ou (3 et 1) ).

Ce n’est qu’un exemple…

Cosignature

Samedi, mai 9th, 2015

Une réflexion depuis quelques temps porte sur la cosignature (cf Les entités et le code / Redéfinition de puppetmaster). Et elle est toujours d’actualité. Le but est de permettre d’avoir une entité unique mais dont la clé privée soit répartie en plusieurs morceaux, chaque morceau sous la responsabilité d’une personne différente. On doit avoir plusieurs entités qui peuvent communément, et non individuellement, signer pour l’entité unique.

Le problème peux être résolu en ayant un mécanisme qui valide la signature de l’entité unique par la présence d’un nombre pré-définit de signatures d’entités pré-validées. On n’a plus dans ce cas une entité mais un groupe d’entités dont la cosignature est reconnue comme signature du groupe. Dans ce cas, la notion d’entité s’étend et ne sous-entend plus seulement un objet avec une clé cryptographique mais un objet qui constitue un groupe d’entités avec des règles de fonctionnement.

Jusqu’ici, je n’ai trouvé que des solutions matériels avec un seul bi-clé cryptographique conservé dans une puce et dont l’usage est contraint par l’authentification de plusieurs personnes physiques. Ce n’est pas satisfaisant puisque toutes les personnes doivent être présentes au même endroit au même moment pour activer la clé privée. Les solutions de cosignatures que j’ai trouvé se contentent de gérer de multiples signatures d’un document mais sans gérer cette notion de communauté.

Nommage multiple et protéiforme

Vendredi, juillet 18th, 2014

Dans nebule, les objets ont forcément un identifiant. Ils ont aussi parfois un nom. Typiquement, c’est le cas lorsque l’objet a pour source un fichier nébulisé.

shot-2014-07-18_20-07-59

Le nom est un texte de caractères compréhensible par les humains. Déjà, en fonction des langues, il se peux que ce texte ne soit pas compréhensible pas tout le monde. Mais on exclut déjà par principe les caractères non imprimables, même si en réalité ça n’a pas beaucoup d’importance. Il vaut mieux que le texte n’ai pas de retour à la ligne, mais ça peut être interprété, traduit et pris en compte à l’affichage.

Pour un fichier, le nom (qui inclus le chemin) a deux rôles :

  1. le classement sommaire par sujets en fonction du chemin et parfois du nom ;
  2. la description sommaire du contenu, un peu comme un titre.

Dans nebule, le nom que l’on peut donner à un objet a le même rôle que le nom pour un fichier. Il donne un titre à l’objet. Par contre, le classement des objets intervient peu avec le nom que ceux-ci pourraient avoir. Ce serait plutôt le rôle de groupes et de nœuds, concept encore en cours d’affinement. Pour un objet, lui donner un nom c’est le lier à un autre objet qui contient le nom avec un lien de type l.

Si un fichier ne peut avoir qu’un seul nom, un objet peut en avoir plus. Il est possible de créer plusieurs liens vers différents objets à utiliser comme noms. Les propriétés de liens multiples et concurrents sont valables aussi pour le nommage.
Lors de l’affichage, comme dans l’exemple ci-dessus, il faut faire un choix. Soit on affiche tous les noms, ce qui peut rapidement devenir problématique et difficilement compréhensible par l’utilisateur. Soit on affiche qu’un seul nom, celui affiché étant celui qui a le plus grand score dans le calcul des relations sociales. C’est cette dernière solution qui est adoptée aujourd’hui.

Mais on peut faire encore mieux. Rien n’interdit un lien pour un titre de renvoyer vers une image. D’ailleurs, ce peut être tout objet sans distinction. C’est l’interprétation du titre qui ici prend son importance. Si on n’interprète que du texte alphanumérique sur une seule ligne, les autres objets seront ignorés comme titre.
Si on décide de prendre en compte aussi les images, il ne sera peut-être pas opportun d’utiliser une image de grande résolution, lourde. On peut utiliser à la place les miniatures, des images dérivées, pour l’affichage comme titre. Les miniatures d’images seront d’ailleurs très régulièrement utilisées lors de l’affichage.
Pour un film, on va peut-être utiliser soit une image fixe soit une petite séquence animée, l’une comme l’autre extraite du film.

L’affichage final peut dans certains cas prendre en compte simultanément plusieurs objets titres mais de types différents. Par exemple accepter une image et un texte, ou un morceau de film, un son et un texte…
Protéiforme ne veut pas dire en forme de protéine mais bien de formes multiples.
Tout est question d’interprétation et de stratégie d’affichage. Tout est possible, aussi.

Dans sylabe, comme dans nebule, une entité a un nom constitué d’un petit texte, un prénom et même un préfixe sur le même principe. Mais elle peut aussi depuis peu avoir une image, typiquement une photo d’identité. Le nommage multiple et protéiforme existe donc déjà.

Marqueur de groupe multidimensionnel

Mercredi, mars 12th, 2014

Les objets sont aujourd’hui identifiés par une valeur unique qui, de part ses propriétés, n’est pas pré-calculable ou prévisible. Ce comportement est indispensable pour distinguer parfaitement et de façon univoque les objets, et donc leur contenu. Il résulte de ces propriétés que toute modification d’un objet, quelle qu’elle soit et aussi infime qu’elle soit, entraîne un changement complet et quasi-aléatoire de son empreinte, et donc de l’identifiant correspondant.

Mais il peut être aussi intéressant de disposer d’une autre valeur plus prévisible. On va essayer de définir ici ce que l’on appellera un marqueur.
On peut imaginer par exemple que deux images très proches puissent avoir un marqueur de valeur identique ou proche. Pour de la musique, le marqueur peut être un dérivé atemporel du spectre de fréquences. Ce marqueur doit avoir une structure en accord avec la structure de l’objet. On doit pouvoir comparer les marqueurs de deux objets différents et déterminer rapidement si ils ont une structure proche, donc si ils sont ressemblants. La structure doit être multidimensionnelle et de profondeur variable. L’ajustement de la profondeur de comparaison des marqueurs doit permettre de retrouver les objets très proches ou au contraire vaguement ressemblants.

Une notion de groupe apparaît. On fait un regroupement à géométrie variable des objets par rapport à leur contenu.

Le côté multidimensionnel du marqueur doit refléter les caractéristiques multidimensionnelles d’un objet. Voici quelques exemples :

  1. Un texte simple contient des données qui s’expriment en deux dimensions : la position spatial et pour chaque position une valeur (caractère).
  2. Un texte enrichit contient des données qui s’expriment en trois dimensions : la position spatial et pour chaque position deux valeurs (caractère et encodage).
  3. Un son mono contient des données en deux dimensions : la position temporelle et pour chaque position une valeur (amplitude).
  4. Un son stéréo contient des données en trois dimensions : la position temporelle et pour chaque position deux valeurs (amplitude).
  5. Une image en noir et blanc contient des données en trois dimensions : la position spatial horizontale, la position spatial vertical et pour chaque couple de position spatial on a une valeur (amplitude).
  6. Une image en couleur (RVB) contient des données en cinq dimensions : la position spatial horizontale, la position spatial vertical et pour chaque couple de position spatial on a trois valeurs (amplitude).
  7. Un film en couleur muet contient des données en six dimensions : la position spatial horizontale, la position spatial vertical, la position temporelle et pour chaque couple de position spatial/temporelle on a trois valeurs (amplitude).
  8. Un film en couleur avec son stéréo contient des données en huit dimensions : la position spatial horizontale, la position spatial vertical, la position temporelle et pour chaque couple de position spatial/temporelle on a cinq valeurs (amplitude).

Ce marqueur n’est pas destiné à remplacé l’identifiant !
L’identifiant reste le seul moyen de
discerner sans ambiguïté tous les objets, y compris les plus ressemblants.

Ne reste plus qu’à formaliser précisément ce marqueur.

Appartenance et/ou propriété – suite

Samedi, novembre 2nd, 2013

Suite de Appartenance et/ou propriété.

En regardant le code de sylabe et notamment la façon dont on traduit les liens, on voit une énorme instruction switch pour trier les liens de type l. Ce tri est fait par rapport à l’objet méta. Les liens sans objet méta (càd égale à 0) apparaissent donc comme des exceptions qu’il faut gérer dans un autre sous switch.

D’un autre côté, les liens de type f sont triés plus naturellement par l’objet source. Cela n’a donc pas d’importance si l’objet méta est nul.

Donc, c’est un lien de type f qui sera maintenant à utiliser pour désigner un nœud. Cela devient un groupe à part entière.

Tous les liens de type l avec un objet méta nul sont marqués comme périmés. Il n’y a plus de moyen de désigner explicitement un objet comme ‘objet‘, ‘entité‘ ou ‘objet de suivi spécifique‘. Et il n’y a pas vraiment besoin.
Il est ajouté dans la documentation nebule v1.1 que les liens de type l ne devraient avoir ni un objet méta nul ni un objet destination nul.

Appartenance et/ou propriété

Samedi, novembre 2nd, 2013

Il se pose un dilemme aujourd’hui dans la définition de ce qu’est un nœud. Non sur la nature de celui-ci mais plutôt sur la façon dont le nœud est désigné comme tel.

Le même genre de problème se pose aussi pour une entité mais de façon un peu plus simple.
Une entité est capable de signer, c’est donc avant tout une clé cryptographique asymétrique (RSA uniquement aujourd’hui dans nebule). C’est aussi plus spécifiquement la clé publique, celle que l’on diffuse, donc celle par laquelle on est connu et reconnu. Au delà de ses propriétés mathématiques internes, elle est reconnu par la forme de son contenu et plus généralement par son type mime : ‘application/x-pem-file‘. Malheureusement, le fichier PEM, qu’il contienne la clé publique ou la privée ou les deux, a toujours le même type mime. Il est impossible de distinguer l’une ou l’autre naturellement par le type mime, il faut regarder le contenu pour pouvoir prendre une décision sur la nature de la clé.
Cela paraît compliqué comme ça, mais le problème est finalement facile à résoudre. Pour savoir si c’est une entité, il suffit de regarder si l’objet a le bon type mime puis de lire la première ligne du fichier (moins de 30 caractères). On peut vouloir ajouter un lien pour dire explicitement que cet objet est une entité. Mais quel doit être ce lien? Un lien de type l pour attribuer un attribut à l’objet? Ou un lien de type f pour dire que l’objet fait parti (dérivé) du groupe des entités?

Il y a le même problème avec le nœud. Celui-ci n’a pas de type mime à proprement parler, ce peut être du texte comme une image. Il peut être tentant d’ajouter un lien pour définir explicitement un objet comme étant un nœud. Dans ce cas, la recherche des nœuds est facilité puisqu’il suffit de regarder les liens vers l’objet ‘nebule/objet/noeud‘. On en revient cependant aux mêmes questions. Quel doit être ce lien? Un lien de type l pour attribuer un attribut à l’objet? Ou un lien de type f pour dire que l’objet fait parti (dérivé) du groupe des entités?
Il s’ajoute un autre problème. Nous n’avons pas besoin en théorie de ce lien pour caractériser un nœud. Il suffit que le nœud ai au moins un liens de type f pour lequel il est à la fois l’objet source et l’objet méta. Mais pour retrouver les nœuds, cela oblige à parcourir tous les objets. Bref, ce n’est pas réalisable en pratique pour un usage commun. Nous devons donc ajouter un lien qui explicite la nature de nœud de l’objet.

Les deux type de liens sont équivalents pour résoudre ce problème. Le type l est plus simple. Le type f permet quand à lui de voir la notion de nœud comme un groupe. Est-ce qu’il y a un intérêt à gérer les nœuds dans un groupe?
L’usage seul nous permettra de déterminer quel est le meilleur type de lien…

Nœud et groupe

Jeudi, juillet 25th, 2013

Dans l’utilisation qu’il en est faite dans nebule, quelles sont les différences entre les concepts de nœud et de groupe ?

Les deux sont séparés dans le code de sylabe, mais est-ce bien raisonnable ?

Le groupe

Mardi, août 21st, 2012

Suite au post du 7 août.

Le groupe est une notion assez générale qui désigne un certain nombre d’objets reliés entre eux par un seul objet. Ces objets pouvant être des entités.

Il y a deux façons de l’implémenter, en fonction de ce que l’on veut en faire :
– le groupe uni-polaire
– le groupe multipolaire

(suite…)

Le groupe ?

Mardi, août 7th, 2012

Qu’est ce qu’un groupe?
On le comprend habituellement comme un groupe de personnes.

Quel est la définition du groupe?
Qui/quoi attache des personnes à un groupe?
Comme est interprété un groupe attaché à un autre groupe?
Quelle est la solidité du groupe? Sa résilience?

Comment le traduit cryptographiquement?
Comment l’intégrer à nebule?
Est-il restreint à des entités ou peut-il intégrer des objets autres?

(voir suite sur le post du 20 août)

Etre relié ou ne pas être

Vendredi, septembre 9th, 2011

Dans la dernière revue MISC(1), en marge du dernier article, on trouve un petit descriptif rapide des modèles DAC, RBAC et OrBAC.

L’évolution de ces modèles tend vers la création d’un langage à part entière que l’on peut traduire vers nos langages humains, et vice-versa.

Et ce langage n’est autre qu’une forme de lien entre deux objets.

(suite…)

Fichiers et chemins

Dimanche, juillet 10th, 2011

Sous nebule, les objets sont référencés par leur empreinte. Ça ressemble quelque part au référencement des fichiers par des inodes sur les systèmes de fichiers UNIX. (suite…)