J’oubliais un « léger » détail (qui peut sembler évident mais on ne sait jamais) : après avoir changé la date d’expiration d’une clef, il faut permettre à tes correspondants de prendre connaissance de la nouvelle date d’expiration, en re-publiant la clef via n’importe quel moyen a été utilisé pour la publier en premier lieu (par exemple, en la ré-envoyant vers un serveur de clefs avec --send-keys).
De manière générale, toute modification de la clef (ajout ou révocation d’une identité, ajout ou révocation d’une sous-clef, changement des algorithmes préférés, changement de la date d’expiration) est une modification locale, qui n’a pas d’effets au-delà de ta machine tant que tu ne re-publies pas explicitement ta clef. À aucun moment GnuPG ne prendra l’initiative de transmettre tes modifications au monde extérieur.
(Le changement de la phrase de passe ne nécessite évidemment pas de re-publication, puisque cela ne concerne que la clef privée.)
[^] # Re: Merci
Posté par gouttegd . En réponse au journal Bien démarrer avec GnuPG. Évalué à 6.
J’oubliais un « léger » détail (qui peut sembler évident mais on ne sait jamais) : après avoir changé la date d’expiration d’une clef, il faut permettre à tes correspondants de prendre connaissance de la nouvelle date d’expiration, en re-publiant la clef via n’importe quel moyen a été utilisé pour la publier en premier lieu (par exemple, en la ré-envoyant vers un serveur de clefs avec
--send-keys).De manière générale, toute modification de la clef (ajout ou révocation d’une identité, ajout ou révocation d’une sous-clef, changement des algorithmes préférés, changement de la date d’expiration) est une modification locale, qui n’a pas d’effets au-delà de ta machine tant que tu ne re-publies pas explicitement ta clef. À aucun moment GnuPG ne prendra l’initiative de transmettre tes modifications au monde extérieur.
(Le changement de la phrase de passe ne nécessite évidemment pas de re-publication, puisque cela ne concerne que la clef privée.)