La rotation limite la quantité de données qu’une clé protège et la durée pendant laquelle une clé volée reste exploitable. La SP 800-57 Part 1 §5.3 donne des recommandations sur les cryptopériodes, par exemple d’un à trois ans pour une clé privée de signature. Les certificats et jetons à courte durée de vie déplacent le problème : il ne s’agit plus d’effectuer la rotation des clés, mais de renouveler automatiquement les identifiants.
Le principe est le même dans tous les écosystèmes : publiez la nouvelle clé, attendez que chaque vérificateur l’ait obtenue, commencez à signer avec elle, puis retirez l’ancienne clé une fois que tout ce qu’elle a signé a expiré. JWKS s’appuie sur kid et sur les durées de mise en cache ; DKIM utilise un nouveau sélecteur ; SSH utilise UpdateHostKeys pour faire connaître aux clients une nouvelle clé d’hôte ; TLS fait se chevaucher l’ancien et le nouveau certificat ; Sigstore et TUF effectuent la rotation des clés racines au moyen de métadonnées signées.
Échecs fréquents : retirer l’ancienne clé avant l’expiration des jetons en cache, des vérificateurs qui ne récupèrent les clés qu’une fois au démarrage, des clés sans identifiant qui obligent les vérificateurs à toutes les essayer, et des rotations d’urgence jamais testées à blanc.