Se créer son trousseau de clés et le diffuser est un cauchemar (j'en veux pour preuve les tutos "Comment se créer une clé pgp parfaite en 723 étapes")
For the record, ces tutos, qui sont souvent le fruit de personnes qui croient certainement bien faire, sont largement déconseillés par les développeurs de GnuPG (dernier exemple en date).
La recommendation officielle pour les débutants qui veulent se créer une paire de clefs est : stick to the defaults!
Et pour les utilisateurs de GnuPG 2.1, c’est concrètement gpg --quick-gen-key mon.adresse@example.com, qui génère une paire de clefs « standard » (avec les fameux réglages par défaut) sans rien demander à l’utilisateur.
Les clés doivent être diffuses via DNS, sur le domaine de l'utilisateur, de manière a ce qu'un correspondant éventuel puisse les récupérer facilement
L’enregistrement OPENPGPKEY pour ça est en cours de standardisation à l’IETF. Il est déjà pris en charge par Bind 9.9.7 (ce qui signifie que Bind peut lire un fichier de zone contenant un tel enregistrement, mais il est aussi utilisable avec n’importe quel autre serveur DNS en passant par la syntaxe du RFC 3597) et par GnuPG depuis sa version 2.1.9.
Un logiciel qui fait du pgp doit faire le maximum pour récupérer les clés pgp des correspondants, ou qu'elles soient, et chiffrer avec.
--auto-key-locate. Peut retrouver une clef dans le DNS (dans des enregistrements CERT (RFC 4398), OPENPGPKEY (cf. point précédent), ou PKA (bidouillage non-standard spécifique à GnuPG, en passe d’être remplacé par OPENPGPKEY)), dans des serveurs LDAP, dans des serveurs de clefs. D’autres mécanismes de lookup sont encore envisageables.
Un logiciel qui fait du pgp doit partir du principe qu'une clé est bonne a partir du moment ou c'est la première qui a été vue pour le contact en question;
Modèle trust-on-first-use, Introduit à partir de GnuPG 2.1.10, sorti en décembre dernier. Ce n’est pas encore le modèle de confiance par défaut (c’est toujours la toile de confiance PGP pour l’instant), mais je pense qu’il est amené à le devenir.
réduire l'impact des métadonnées
Il y a des discussions en cours à l’IETF sur la question. Le problème est que la réduction de la fuite de métadonnées ne peut guère se faire sans modification du protocole (changement du contenu et/ou du format des paquets OpenPGP), donc ça ne peut se faire unilatéralement par GnuPG seul (contrairement à l’introduction d’un nouveau modèle de confiance, parce que le standard laisse explicitement le champ libre aux implémentations de ce côté).
Il nous faut créer des outils qui utilisent ça et fournissent l’utilisabilité qui permettront a gpg d'avoir de nouvelles utilisations un peu plus modernes et un peu plus utiles,
Tout-à-fait d’accord. GnuPG lui-même est loin d’être obsolète, et progresse constamment. Ce sont les front-ends qui pêchent encore.
[^] # Re: GPG n'est qu'une brique
Posté par gouttegd . En réponse au journal cas d'utilisation de GPG. Évalué à 10.
For the record, ces tutos, qui sont souvent le fruit de personnes qui croient certainement bien faire, sont largement déconseillés par les développeurs de GnuPG (dernier exemple en date).
La recommendation officielle pour les débutants qui veulent se créer une paire de clefs est : stick to the defaults!
Et pour les utilisateurs de GnuPG 2.1, c’est concrètement
gpg --quick-gen-key mon.adresse@example.com, qui génère une paire de clefs « standard » (avec les fameux réglages par défaut) sans rien demander à l’utilisateur.L’enregistrement OPENPGPKEY pour ça est en cours de standardisation à l’IETF. Il est déjà pris en charge par Bind 9.9.7 (ce qui signifie que Bind peut lire un fichier de zone contenant un tel enregistrement, mais il est aussi utilisable avec n’importe quel autre serveur DNS en passant par la syntaxe du RFC 3597) et par GnuPG depuis sa version 2.1.9.
--auto-key-locate. Peut retrouver une clef dans le DNS (dans des enregistrements CERT (RFC 4398), OPENPGPKEY (cf. point précédent), ou PKA (bidouillage non-standard spécifique à GnuPG, en passe d’être remplacé par OPENPGPKEY)), dans des serveurs LDAP, dans des serveurs de clefs. D’autres mécanismes de lookup sont encore envisageables.Modèle trust-on-first-use, Introduit à partir de GnuPG 2.1.10, sorti en décembre dernier. Ce n’est pas encore le modèle de confiance par défaut (c’est toujours la toile de confiance PGP pour l’instant), mais je pense qu’il est amené à le devenir.
Il y a des discussions en cours à l’IETF sur la question. Le problème est que la réduction de la fuite de métadonnées ne peut guère se faire sans modification du protocole (changement du contenu et/ou du format des paquets OpenPGP), donc ça ne peut se faire unilatéralement par GnuPG seul (contrairement à l’introduction d’un nouveau modèle de confiance, parce que le standard laisse explicitement le champ libre aux implémentations de ce côté).
Tout-à-fait d’accord. GnuPG lui-même est loin d’être obsolète, et progresse constamment. Ce sont les front-ends qui pêchent encore.