y compris ajouter une date d’expiration à une clef qui était initialement éternellement valide
Dans l'hypothèse pessimiste, classiquement utilisée en crypto, ie. l'attaquant contrôle le réseau, tu n'as aucune garantie que le changement de date d'expiration arrive aux utilisateurs de ta clef publique. Ça ne pose pas de problème si la date d'expiration est repoussée, car au pire la clef sera inutilisable, mais dans le cas où tu raccourcis la date d'expiration, il est possible que les utilisateurs ne soient jamais au courant et continuent d'utiliser la clef, qui pour toi est expirée. C'est dans cet esprit, que je considère qu'une date d'expiration plutôt courte est un plus, puisqu'on peut toujours changer d'avis en repoussant, l'inverse n'étant pas possible sous les conditions de contrôle du réseau par l'attaquant.
Après, je vois un autre point utile à avoir une date d'expiration plutôt courte (pour moi, c'est deux mois uniquement sur les sous-clefs), c'est que tu force tes correspondants à synchroniser ta clef publique, et à éventuellement voire les révocations. Je n'ai pour ma part pas confiance au processus de révocation, l'attaquant peut très bien bloquer la diffusion de cette révocation, ou un utilisateur ne jamais la recevoir de sa propre faute. Je considère donc qu'un délai de deux mois sans avoir de nouvelles de ma part (mise-à-jour de la date d'expiration) doit valoir une inutilisabilité de ma clef publique.
# À propos de l'expiration des clefs
Posté par jben . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 3.
Dans l'hypothèse pessimiste, classiquement utilisée en crypto, ie. l'attaquant contrôle le réseau, tu n'as aucune garantie que le changement de date d'expiration arrive aux utilisateurs de ta clef publique. Ça ne pose pas de problème si la date d'expiration est repoussée, car au pire la clef sera inutilisable, mais dans le cas où tu raccourcis la date d'expiration, il est possible que les utilisateurs ne soient jamais au courant et continuent d'utiliser la clef, qui pour toi est expirée. C'est dans cet esprit, que je considère qu'une date d'expiration plutôt courte est un plus, puisqu'on peut toujours changer d'avis en repoussant, l'inverse n'étant pas possible sous les conditions de contrôle du réseau par l'attaquant.
Après, je vois un autre point utile à avoir une date d'expiration plutôt courte (pour moi, c'est deux mois uniquement sur les sous-clefs), c'est que tu force tes correspondants à synchroniser ta clef publique, et à éventuellement voire les révocations. Je n'ai pour ma part pas confiance au processus de révocation, l'attaquant peut très bien bloquer la diffusion de cette révocation, ou un utilisateur ne jamais la recevoir de sa propre faute. Je considère donc qu'un délai de deux mois sans avoir de nouvelles de ma part (mise-à-jour de la date d'expiration) doit valoir une inutilisabilité de ma clef publique.