D’abord, elles permettent d’utiliser des clefs différentes pour des usages différents. Typiquement, une clef pour signer et une clef pour chiffrer (et éventuellement encore une autre clef pour authentifier).
C’est important d’une part parce que tous les types de clefs ne se prêtent pas à tous les usages (une clef ElGamal ne peut être utilisée que pour chiffrer, une clef DSA ne peut être utilisée que pour signer), et d’autre part, parce que même pour les types de clefs qui peuvent servir à la fois pour signer et pour chiffrer, c’est généralement considéré comme une mauvaise idée.
L’autre grand intérêt des sous-clefs est qu’elles peuvent être remplacées à tout moment.
Remplacer une clef primaire est une opération délicate. Une telle clef a un historique, tes interlocuteurs la connaissent (certains l’ont peut-être signée) et savent que c’est la tienne. La nouvelle clef, elle, est « vierge » — elle n’a pas d’historique, et il faut recommencer un long travail d’introduction pour amener tes interlocuteurs à avoir confiance que c’est bel et bien ta clef (une méthode courante pour faciliter ce travail est de signer la nouvelle clef avec l’ancienne, et/ou de signer avec les deux clefs une déclaration de transition comme celle-ci).
Remplacer une sous-clef est au contraire totalement transparent pour tes interlocuteurs. Seule la clef primaire est importante à leurs yeux, c’est la seule clef à laquelle ils sont directement confrontés (c’est GnuPG qui s’occupe en arrière-plan de sélectionner la sous-clef appropriée une fois que l’utilisateur a sélectionné une clef primaire). Tu peux donc remplacer une sous-clef à n’importe quel moment (pour quelque raison que ce soit) sans craindre de conséquences sur la validité de ta clef aux yeux de tes interlocuteurs.
# L’utilité des sous-clefs réside dans (au moins) deux choses.
Posté par gouttegd . En réponse au message Fonctionnement des subkeys avec gpg. Évalué à 4.
D’abord, elles permettent d’utiliser des clefs différentes pour des usages différents. Typiquement, une clef pour signer et une clef pour chiffrer (et éventuellement encore une autre clef pour authentifier).
C’est important d’une part parce que tous les types de clefs ne se prêtent pas à tous les usages (une clef ElGamal ne peut être utilisée que pour chiffrer, une clef DSA ne peut être utilisée que pour signer), et d’autre part, parce que même pour les types de clefs qui peuvent servir à la fois pour signer et pour chiffrer, c’est généralement considéré comme une mauvaise idée.
L’autre grand intérêt des sous-clefs est qu’elles peuvent être remplacées à tout moment.
Remplacer une clef primaire est une opération délicate. Une telle clef a un historique, tes interlocuteurs la connaissent (certains l’ont peut-être signée) et savent que c’est la tienne. La nouvelle clef, elle, est « vierge » — elle n’a pas d’historique, et il faut recommencer un long travail d’introduction pour amener tes interlocuteurs à avoir confiance que c’est bel et bien ta clef (une méthode courante pour faciliter ce travail est de signer la nouvelle clef avec l’ancienne, et/ou de signer avec les deux clefs une déclaration de transition comme celle-ci).
Remplacer une sous-clef est au contraire totalement transparent pour tes interlocuteurs. Seule la clef primaire est importante à leurs yeux, c’est la seule clef à laquelle ils sont directement confrontés (c’est GnuPG qui s’occupe en arrière-plan de sélectionner la sous-clef appropriée une fois que l’utilisateur a sélectionné une clef primaire). Tu peux donc remplacer une sous-clef à n’importe quel moment (pour quelque raison que ce soit) sans craindre de conséquences sur la validité de ta clef aux yeux de tes interlocuteurs.