Extensions des fichiers d’authentification

Clients
1

C’est exactement pour soulever ce genre de débat, qui touche à Cas d’Utilisation complet de l’utilisateur, que j’ai soulevé ces questions.

Petites questions, donc :

  • trouves tu le nom d’extension .dewif ou .ewif intuitif (c’est à dire parlant) pour l’utilisateur moyen ? Ou bien est-ce plutôt technique ?
  • Dans PDF, on peut trouver des images, du texte, du vecteur, etc. soit différent contenu, comment sais-tu ce qu’il y a dans ton fichier, sans même l’ouvrir ? Est-ce une liste de course, un relevé de compte, un CR de réunion ? Quel autre moyen que l’extension existe t il pour signifier ce qu’il contient ?
  • Dirais tu qu’un extension adresse, généralement : un contenu ? un type de contenu ? un logiciel ou un ensemble de logiciels ?
  • Par la même logique que la tienne, ne trouves tu pas dommageable que les fichiers de révocation, par exemple, soit au format .txt ? Ne faudrait-il pas un fichier .revoc ou autre ? Ou bien ne t’es-tu jamais poser la question, parcequ’il existe un autre moyen de savoir que ton .txt contient un document de révocation ?

Ces questions me semble légitime et importante. Répondez y honnêtement, SVP.

1 Like
2

Certes dans les pdf on pet trouver différents types d’éléments, mais pour moi, ce qui caractérise les fichiers PDF et donc l’extension, c’est qu’il peut être ouvert et compris par tout logiciel qui attend justement un fichier pdf. Donc l’extension ne détermine pas le contenu mais la destination du fichier.

3

C’est l’en-tête d’un fichier qui fait foi sur le format d’un fichier. C’est avec la commande Unix file <fichier.ext> qu’on détermine le format d’un fichier :

file auie.txt 
auie.txt: UTF-8 Unicode text

On peut renommer l’extension, il sera reconnu comme PDF :

mv fichier.pdf fichier.toto

file fichier.toto
fichier.toto: PDF document, version 1.7

L’extension c’est un indice pratique pour l’utilisateur afin d’avoir une idée de ce à quoi pourrait être le format d’un fichier. Ça ne fait absolument pas foi.

1 Like
4

et pourtant les explorateurs de fichiers se basent sur l’extension pour déterminer le logiciel avec lequel ouvrir le fichier

5

Je sais pas à quel environnement tu fais référence. En tout cas, dans celui que j’utilise c’est basé sur l’en-tête :

open fichier.pdf
# ça l’ouvre

mv fichier.pdf fichier.toto
open fichier.toto
# ça l’ouvre
6

Je crois que c’est mixte, non ? Les fichiers binaires ont une entête oui, mais les fichiers textes pas forcément, donc l’OS se base sur l’extension pour ouvrir un navigateur pour un fichier .html par exemple

edit: windows a l’air de se baser que sur l’extension, en tout cas dans l’explorateur de fichier

1 Like
7

C’est toujours pratique d’avoir une extension particulière. Ça permet de connaître le format sans ouvrir le fichier, de retrouver les fichiers plus facilement avec une commande ou la recherche de l’explorateur.

Ça permet aussi à l’utilisateur de savoir à quoi il a affaire. Même si l’utilisateur d’un explorateur graphique ne sait pas ce qu’est DEWIF, il pourra voir par exemple l’icône Duniter avec une clé dessus, et fera le lien.

Exemple concret : un webserver typique traitera différemment un fichier .php, .pl, .htaccess, .html.

8

Parce que .dunikey c’est parlant ? Pour qui ? Pour toi ? Eh bien .dewif, c’est parlant pour moi. Cela exprime le format du contenu du fichier. MJPEG, MPEG, MP4, MOV, AVI, MXF c’est parlant pour toi ? Sais-tu me dire parmi les extensions vidéos citées, celles qui désignent un format de container et celle qui désigne un format d’encodage ? Difficile, hein, sans connaître le sujet ? Par expérience, je préfère savoir ce que contient le fichier. Si le fichier est un fourre tout, c’est plus compliqué et je préfère éviter. Le rôle d’une extension n’est pas d’être parlante pour MME Michu, qui s’en fout du moment que ça juste marche.

Si le pdf que je charge dans mon lecteur libre sur linux ne supporte pas les formulaires, je peste, car effectivement, quand un format fixé au départ, s’enrichit sans se versionner, on arrive à des frustrations constantes côté utilisateur. Il faut éviter cela comme la peste. Je préfère l’approche .mpeg et .mpeg2 qui permet de savoir clairement si le contenu sera lisible ou pas.

Il n’y a pas de règles, comme je te l’ai montré plus haut, ce qui entraîne confusion et frustration. C’est pour cela que, comme nous sommes libres de faire comme on le souhaite, il faut faire ce qui nous paraît le mieux. Donc je préconise une extension qui exprime précisément le contenu, quitte à avoir plusieurs extensions.

Tout à fait, il faut une extension qui exprime le format du contenu, pas le contenu (donc .revoc n’a pas de sens, puisque le contenu est avant l’extension, c’est le nom du fichier). Mais, quel est le format du contenu d’un tel fichier ? A-t-il été formalisé et spécifié quelque part ? C’est le format étendu (non raw) d’un document Duniter. Il faut donc trouver une extension qui désigne ce format.

Tu n’as pas eu de contradicteurs quand tu as créé Cesium, et ceux qui viennent après toi, qui profitent de l’expérience de Cesium pour améliorer certaines choses, tombe sous le feu de tes critiques. Et tu réclames un débat, alors qu’il n’y en a pas eu pour Cesium ? Mais maintenant les choses sont faites bien plus consensuellement qu’à ton époque. Il y a des RFC pour chaque nouvelle brique. Sur lesquelles chacun peut donner son avis et obtenir ainsi enfin un standard reproductible dans toutes les applications.

3 Likes
9

Non, par spécialement “pour moi”, dans le sens où ce n’est pas moi qui est proposé ce nom d’extension. Mais ça me parait assez parlant quand même.
Duni = Duniter - Key = clé. C’est quand même pas trop compliqué, si ?

Ce n’est pas l’enjeu (toi et moi). Nous arriveront toujours à nous débrouiller, nous. Même si on peste :slight_smile:

Ca dépend, par exemple MOV = Movie, DOC = document, etc. PDF = Portable Document Format
Certains sont plus parlant que d’autres, c’est certain.

Je n’ai pas dit que c’était facile, justement je trouve qu’on devrait simplifier la vie des gens (avant la notre).

Regardes du côté des clef SSH, par exemple, tu as juste des extensions .pub pour les clefs publiques, et les clefs secrètes n’en ont même pas. Et ce quelques que soit le type de clefs (RSA, ED25519, etc.).
J’imagine que le contenu du fichier suffit aux outils pour se débrouiller. Nous pourrions faire de même : pas d’extension, après tout, et une auto-détection par le contenu ?
C’est un peu ce que dit @moul : détection du format.

Mais du coup, quel format (dans le fichier) est plus simple pour une auto-détection ?
Il me semble qu’un format container (avec ou sans l’extension) du type de dunikey est plus simple. Et en rien difficile à maintenir.
On adresse un seul besoin : gérer des clefs. Il devrait quand même pas y avoir 10 formats possible, si ?

10

Du coup, je sui désolé d’y penser que maintenant, mais pourquoi ne pas faire un format compatible avec les clefs SSH ? Ca me semble cohérent, non ? Ces format savent très bien gérer une protection par passphrase. Peut etre existe il d’autres options.

EDIT : man ssh-keygen :

image
image1323×465 62.2 KB

Pas de -BIP32, c’est sur… mais l’aide parle de (Key Derivation Function](Protect your private SSH-key with KDF (key derivation function)) ?!

1 Like
11

Ce n’est pas moi non plus. DEWIF n’est pas un format de fichier mais une chaîne base64.

Comme @vit je suis contre un format «conteneur». Et je pense que reprendre le format ssh n’est pas une bonne idée.

Perso je propose un fichier .json qui stocke un champ "dewif" et des méta-données associées au trousseau, voir ici :

https://forum.duniter.org/t/carnets-dadresses-hd-wallets-partages-entre-clients/8219/7

12

Je suis totalement d’accord sur cet objectif, mais pas d’accord sur le «comment» atteindre cet objectif, je trouve au contraire que tes choix mènent souvent à complexifier la vie des gens :wink:

Concernant le fichier, mme michu ne le manipulera jamais directement, elle ne saura même pas qu’il existe un fichier.
Le fichier c’est une tambouille interne pour stocker des choses qui vont améliorer l’expérience utilisateur (permettre d’avoir un credential plus court à saisir, etc).

Pour l’import/export, on peut sérialiser le trousseau sous forme d’un qrcode ou d’un mnemonic, copier/coller une phrase dans la langue de l’utilisateur étant bien plus simple que de manipuler un fichier.

13

Bon je vois que tu semble tout connaître de Mme Michu, alors que Mme Michu fait juste ce qu’on lui dit pour que ça marche. Elle s’adapte, c’est sa force. Laissons cette dame tranquille. Tu dis que je ne parle que de mon point de vue, mais tu embrayes direct en faisant pareil (moi je, moi je…). C’est amusant, mais on peut peut-être revenir à des choses plus concrètes.

Ce projet, depuis le début, avance grâce à ceux qui « font » (l’âge de faire), plus que grâce à ceux qui parlent. Cela à bénéficier énormément à Cesium car tu as été plus actif que parleur. Il y a beaucoup d’initiative qui prennent d’autres voies que Cesium. Mais si vraiment il n’y a aucun danger pour le projet à les adopter, même si elles s’éloignent de Cesium, elles se feront.

Je le répète, tu as eu le droit d’expérimenter, nous avons aussi ce droit.

Tu préfères les containers générique, je préfère les extensions qui expriment l’essence du contenu.

Je préfère un format binaire à un format texte, mais à minima, comme le préconise @elois, un format texte doit être standard (yaml, json, ini, etc). Pas un home made. Cela sécurise l’extraction des infos.

1 Like
14

Oui, il me semble c’est un yml, dans dunikey (je suis sur mon téléphone, je vérifierai demain).
Du coup ça paraît proche de ce que propose Éloïs : un champ avec les données.
Je dis juste que si, dans les métadonnées, on y met Type et Version, et si on passe de json à yml, ben c’est exactement dunikey…
Je comprends pas le soucis en fait…

D’ailleurs cela ressemble aussi fortement au document que produit Duniter, non ? (Même si on n’est pas exactement du Yaml).

Ne prenez pas les choses contre vous svp. C’est juste un format à définir. On va bien y arriver, non ?

Je ne comprends absolument pas de quoi tu parles dans ce paragraphe. Ça donne l’impression que j’aurais tout décidé dans mon coin… Ce n’est pas la réalité. Tu oublies juste qu’inso était en développement actif, avant Cesium, et que j’ai repris telle quelle toute l’authentification qu’avait initié Cgeek dans Duniter (c’est bien lui l’auteur des premières versions salt/pwd et fichier de clefs).

Justement, souvent je regarde ce qui existe et je le reutilise. C’est pourquoi j’évite d’avoir de nouvelles conventions, sauf si vraiment rien n’existe.

2 Likes
15

Même chose, comprends pas de quoi tu parles. Tu refais encore l’histoire a l’envers : tu juges les maçons qui ont bâti la maison, en critiquant leur faute de goût dans la déco… C’est un peu simpliste je trouve.
Sans parler du fait que tu t’enfermes dans une généralité. Comme si j’avais un tendance naturelle à l’erreur… Je trouve ces sous entendus pas vraiment utiles aux débats.

Quand on fait le gros œuvre, on fait les fondations et on s’occupe pas des détails.
Quand les murs sont bâtis, on est fatigué (un peu quand même…) Et alors qu’on se repose voilà que les nouveaux arrivants, qui veulent habiter dans la maison, nous reprochent d’avoir oublié de peindre les murs…

2 Likes
16

Honnêtement, que je puisse proposer d’étudier la réutilisation d’un format existant à l’air si débile ? Si je résume : c’est juste avoir 2 champs de métadonnées Type et Version avant le champ de data. Et ça vous scandalise ??

Si on fait ça, peut importe l’extension, en fait : on sera capable de reconnaître le type de clef.
De même, si on met le tout en QRCode il sera facile de savoir ce qui a été scanné, sans se soucier du contexte. Ainsi si on peut scanner un clef, une TX, etc, de simple regexp suffisent pour distinguer de quoi il s’agit. L’autodetection de format, quoi…

En binaire, ça me paraît plus compliqué (mais peut-etre pas).

Bon bah sinon, on gère plusieurs formats : JSON (proposé par Elois), YAML (dunikey), binaire pur (proposé par @vit). Je m’en fou, personnellement, mais il va falloir expliquer tout cela aux gens, après…

17

hum… le format JSON proposé par @elois ne sert pas à stocker uniquement un trousseau chiffré, mais également les portefeuilles dérivés. Il ne s’agit pas que d’un fichier d’authentification (mais la discussion a peut-être dérivé depuis le début ?).

Le format d’authentification proposé par @elois est le DEWIF, qui est une string base64 et peut être incluse dans tout format de fichier texte.

Je vois un avantage au JSON par rapport au YAML : il est déjà formaté pour être envoyé dans une requête. (je dis peut-être des sottises). C’est une facilité coté dev, ça ne change rien pour l’utilisateur.

YAML et JSON ont une caractéristique par rapport au binaire, qui peut être vue comme avantage ou inconvénient : ils peuvent être modifiés à la main, dans un simple éditeur de texte. C’est à la fois une liberté pour l’utilisateur final et un risque de perte de monnaie.

Après, que l’extension soit .dunikey, .dewif, .ewif, l’utilisateur s’en fiche. Iel souhaite qu’en important un trousseau dans un client, ça juste marche. Or on parle là de trois usages différents :

  1. le fichier d’authentification lié à un trousseau dont la clef publique est… publique (appelons ça trousseau “simple”)
  2. un fichier d’authentification lié à un trousseau maître HDWallet (dont la clef publique doit rester secrète dans la plupart des cas)
  3. un format d’enregistrement des trousseaux dérivés d’un trousseau maître.

Les cas 2 et 3 peuvent être regroupés dans un même format de fichier, avec la seed stockée sous forme DEWIF, et n’être utilisable que par les clients qui implémentent les HDWallets. On aurait une extension .hdunit par exemple. JSON ou binaire me semblent adaptés pour cet usage.

Le cas 1 regroupe plusieurs modes de génération de trousseau, et tout le monde n’est pas d’accord s’il faut chiffrer ou non la seed. Pour ce cas 1, un format “conteneur” comme proposé par @kimamila me semble adapté. Il faut en revanche limiter quel type de données peuvent s’y trouver, et définir les besoins minimum pour un client Duniter. Je vois trois types de données :

  • WIF
  • EWIF
  • DEWIF

Tout client Duniter devrait être en mesure d’utiliser ces trois types pour au moins importer des trousseaux “simples”, même non chiffrés. Il devrait être en mesure d’exporter un trousseau dans au moins un de ces trois types (pour par exemple, dériver un trousseau porte-monnaie pour ma fille depuis mon trousseau maître, sur lequel je garderais le contrôle). Les devs de clients qui veulent absolument chiffrer les données d’imports pourraient choisir de n’exporter que en EWIF/DEWIF. L’extension .dunikey pour ce format me semble adaptée. Après, que ce soit un YAML ou un JSON, je vois pas trop la différence.

Le format seed et le format salt + passwd me semblent redondants avec WIF, et pourraient être abandonnés. D’autant plus que tous les clients n’ont pas accès à salt + passwd, il me semble.

Je vois un dernier cas d’import entre clients : c’est l’import d’une sous-clef publique de HDWallet, qui sera dérivée pour envoyer des transactions toujours à une même entité, mais sur des clefs publiques différentes. Ce serait une sorte de “fiche de contact”, donc encore un troisième format de fichier et une troisième extension.

PS : désolé, j’utilise “type” et “format” de façon non maîtrisée, je ne saisis pas très bien la différence : type de données, type de fichier, format de fichier, format de données d’un fichier texte…

3 Likes
18

Merci à @matograine de clarifier nos problématiques.

Il faut séparer les besoins, et travailler sur un pad peut-être avant une RFC sur ces sujets.

Tikka ciblant les producteurs (je ne veux plus utiliser le terme réducteur de commerçant…) de biens et services que je veux responsabiliser à la sécurité, je prends en import et exporte le format chiffrer EWIF uniquement pour l’interopérabilité avec Cesium (qui est très importante pour moi).

Tikka enregistre la seed dans un fichier .dewif binaire pur (pas de base64). Pourquoi ? Parce que j’avais zappé cette ligne de la RFC. Véridique ! :sweat_smile: Une erreur de ma part, mais qui finalement me convient pour l’instant. Je peux changer pour un autre format et une autre extension (surtout pour les HDwallets) si besoin ou pour l’interopérabilité avec Cesium si il y a consensus sur un autre format.

Mes préférences, en résumé, pour Tikka :

  • Fichiers sur disque toujours chiffrés.
  • Binaire si pas besoin de transport au format texte.
  • Json plutôt que Yaml si besoin de transport au format texte (pas de raison d’éditer le fichier, ce n’est pas une configuration)
  • Yaml si besoin d’imprimer, comme la révocation (document Duniter, comme dit @kimamila, ce doit déjà être du Yaml, on peut même re-formaliser ce format en véritable Yaml si ce n’est pas le cas).
  • Extension qui exprime au mieux le contenu (difficile je l’avoue avec les contenus multiples, là une extension de container s’impose).
19

Il faut aussi qu’il existe un format standard non chiffré, pour les serveurs. Parce que mon serveur redémarre très souvent et je ne peux pas rentrer le mot de passe à chaque fois.

Si ce n’est pas possible, alors les développeurs de serveurs utilisant des clés devront soit créer le leur, non interopérable, soit stocker dans la config le mot de passe du DEWIF. Pas glop.

4 Likes
20

Pas plus que pour un trousseau classique. Car sans le chaincode on ne peut rien faire avec la clé publique maître.

Hélas non car les trousseaux dérivés n’ont pas de seed, mais directement une clé privée de 64 octets.

Il faut que j’ajoute un 3ème type à la spec DEWIF pour gérer le cas des trousseaux dérivés.

Qui est tu pour décider que tout client duniter devrait ceci ou cela ? :wink:

Perso je compte gérer uniquement les HD wallet dans ğcli. Et avec @poka on ne souhaite pas gérer l’import de fichier trousesau dans ğecko. L’import de portefeuille ne sera possible que via le mnemonic où des shard (et via couple id+pass pour les portefeuilles legacy).

Pas nécessairement. L’import/export peut se faire via le mnemonic. Ainsi il n’y a pas besoin de format de fichier standard entre serveur et clients.
Dans Duniter je vais rester en pubsec tant que Duniter nécessitera un restart régulier, le but étant qu’au terme de la migration Duniter arrive à fonctionner sans restart régulier.

Je pars du principe qu’un utilisateur de duniter sais sécuriser son serveur, mais que mme michu ne sais pas sécuriser son mobile.

C’est pourquoi on a besoin de stocker le trousseau chiffré pour ğecko :slight_smile:

3 Likes