Pour les membres de Axiom-Team ou les admins, vous avez peut-être vu que je bosse sur un dossier de financement auprès de NGI0 : https://forum.duniter.org/t/financement-ngi0-commons-fund/11884.
Le but est de présenter un projet qui serve Duniter et corresponde au genre de projets que NGI finance : les standards (mail, XMPP, ActivityPub…), la sécurité sur plein d’aspects (signatures des paquets logiciels, reproductibilité des builds, PGP…), l’identité numérique et l’authentification (Keyoxide, IRMA, LDAP…) souvent sous l’axe de la vie privée.
J’essaye de me faire une idée de l’interopérabilité des systèmes crypto. L’idée étant : si on a une clé (mettons ed25519, algo assez répandu), pourquoi ne pas l’utiliser pour plus d’applications.
Exemple, j’ai une clé GPG ed25519 et je souhaite l’utiliser pour SSH, je n’ai qu’à faire :
gpg --export-ssh-key
Je sais que @Frederic_Renault et @aya vous avez déjà bossé là dessus. Où en êtes-vous par rapport aux clés Ğ1 ? Avez-vous réussi à les intégrer au format GPG ou SSH ? À signer vos mails et vous connecter à votre serveur avec votre clé Ğ1 ?
Idée générale : parfois ça peut être pertinent d’utiliser la clé Ğ1 elle-même pour certaines applications, parfois il faudrait plutôt utiliser une autre clé avec un mécanisme de délégation.
Exemples :
Un plugin thunderbird qui affiche un signe type “
” quand un message est signé par une clé appartenant à la toile de confiance Ğ1. Dans ce cas ça nécessite de pouvoir utiliser directement la clé Ğ1 pour signer ses mails, de préférence directement dans l’application, donc en utilisant le standard PGP déjà en place.
Mais ce n’est pas forcément une bonne idée d’étaler sa clé Ğ1 partout car ça augmente les risques qu’elle soit interceptée par un attaquant. Donc dans d’autre cas, il faudrait plutôt avoir un mécanisme de délégation. Par exemple, signer un message avec sa clé Ǧ1 disant “cette clé GPG m’appartient, si vous recevez un mail signé par elle, vous pouvez considérer que c’est moi”. Et évidemment ça va avec une durée de validité maximum et un document de révocation en cas de vol.
Autre cas d’application, les systèmes qui n’utilisent pas de cryptographie en interne, mais qui pourraient bénéficier d’un plugin pour réaliser une tâche spécifique impliquant des clés Ğ1.
Par exemple : j’ai une instance Nextcloud que je souhaite ouvrir à toute personne ayant une identité Ğ1, avec un certain quota par identité. Il me faut un middleware qui autorise l’ouverture d’un compte sous condition de fournir un challenge signé. Et ça peut s’appliquer à tout autre outil (serveur mail, compte fediverse…). L’intérêt pour l’adminsys est qu’il n’aura pas à valider les comptes à la main et qu’il sera protégé contre le spam d’ouverture de compte. Et si jamais une identité se comporte mal (par ex publie du contenu hors de la charte de la plateforme), il pourra blacklister l’identité et sera protégé par la wot Ğ1 contre une ré-ouverture.
[pas le temps de détailler ici, je pars avec @gerard94 à cryptoxr, mais je reviens plus tard 
