Dépréciation des clefs DSA/Elgamal 1024 bits

Posted on Oct 5, 2010

Question pas si rhétorique : si vous avez signé ma clef PGP précédente, et que je publie une nouvelle clef signée par l’ancienne, accepteriez-vous de signer ma nouvelle clef sans que l’on se rencontre à nouveau et simplement sur la base de cette signature ancienne clef → nouvelle clef ?

En fait, je n’ai pas trouvé de procédure standard pour procéder à une migration de clef quand on utilise des clefs de format OpenPGP, et je pense qu’il n’en existe pas. Chacun peut avoir sa politique personnelle de certification de clef (voir ici, là ou encore là pour des exemples) mais il n’est jamais question de permettre à un utilisateur dont on a signé la clef de changer sa clef en demandant une nouvelle signature.

Certes, le réseau de confiance (Web of Trust ou WoT) devrait répondre à la question : puisqu’Alice a signé la première clef de Bob et que la première clef de Bob a signé sa seconde, Alice devrait faire confiance à la deuxième clef de Bob. Mais cela n’est pas aussi simple : si la signature qu’Alice appose sur l’identité de Bob comporte un niveau de certification (avec quel soin Alice a-t-elle vérifié l’identité de Bob ? cf. la section correspondante des specs) et un niveau de confiance (est-ce que Bob est lui-même fiable pour certifier d’autres identités ?), leur signification est laissé volontairement floue dans les spécifications pour que cela soit directement utile. Déjà, on ne fait en général des signatures d’identité ne comportant aucune information de confiance (cf. la section correspondante de la spec, sous GnuPG il faut utiliser la commande tsign pour cela) et on n’accorde jamais un niveau de confiance suffisant à un autre utilisateur pour qu’une identité qu’il certifie soit directement acceptée par nous, fusse sa propre identité.

L’intérêt que je vois de ne pas accepter de signer automatiquement une telle nouvelle clef serait de détecter une compromission de l’ancienne clef et de vérifier « de vive voix » que Bob a vraiment créé cette nouvelle clef et demande un renouvellement de signature.

Suite à la décision par Debian de ne plus accepter à terme de clefs DSA/Elgamal 1024 bits et de préférer des clefs RSA 4096 bits, j’ai donc créé une nouvelle clef qui est signée par l’ancienne. Au vu du bavardage ci-dessus, vous pouvez considérer :

que c’est bien moi, Laurent Fousse, qui a créé cette nouvelle clef, sauf si vous considérez que ce blog a été r00té :-)
que vous préférez m’appeler pour confirmation avant de signer;
ou bien encore que vous refusez par principe de signer une clef sans voir la personne, son empreinte et sa carte d’identité, même pour une personne que vous connaissez depuis dix ans et qui n’a pas changé d’identité depuis.

Il peut sembler paradoxal que Debian continue à faire confiance à mon ancienne clef pour des tâches telles que voter et mettre à jour des paquets (la dernière impliquant un certain niveau de confiance dans le fait que je n’ai pas l’intention d’introduire un bug subtil ou un trojan dans mes paquets), mais qu’on ne me fasse pas assez confiance pour un changement de clef de routine. J’ai trouvé comme justification le besoin d’avoir à tout instant, pour les clefs des développeurs Debian prises indépendamment du reste des clefs, un ensemble fortement connecté (ce qui ne serait pas le cas si on accepte ma nouvelle clef sur la base d’une unique signature de l’ancienne, celle-ci disparaissant ensuite dans le trousseau des clefs Debian au profit de la nouvelle).

Si vous n’avez pas bien compris ce billet, on peut en discuter autour d’une bière (ou bien vous pourrez lire un excellent bouquin en cours de rédaction). Et si vous n’avez pas encore de clef PGP… franchement, vous attendez quoi ? ;-)