Introduire un délai spécifique entre deux renouvellements d’une même certification

Aujourd’hui, le paramètre CertPeriod impose un délai minimal entre deux certifications émises par un même issuer, quel que soit le recipient.

Ce comportement ne permet pas d’exprimer une règle plus stricte sur un couple (issuer, recipient) donné :

• entre la création d’une certification et son premier renouvellement
• entre deux renouvellements successifs de cette même certification

Problème

Avec la logique actuelle, dès qu’un issuer a de nouveau le droit d’émettre une certification, il peut renouveler une certification existante vers le même recipient, même si l’on souhaite imposer une durée minimale plus longue sur ce lien précis.

Autrement dit :

• CertPeriod est un garde-fou global par issuer
• il manque un garde-fou spécifique par paire (issuer, recipient) pour les renouvellements

Objectif

Introduire un nouveau paramètre runtime dédié, distinct de CertPeriod, qui impose une durée minimale entre :

1. la création d’une certification et son premier renouvellement
2. deux renouvellements successifs d’une certification entre le même issuer et le même recipient

Comportement attendu

Nouveau paramètre

Ajouter un nouveau paramètre runtime, par exemple :

• CertRenewalPeriod

Nom exact à confirmer, mais l’intention doit être explicite :

• il s’applique au renouvellement d’une certification existante
• il est évalué au niveau du couple (issuer, recipient)

Règle métier

Pour une certification donnée entre issuer et recipient :

• après add_cert, un renew_cert ne doit pas être autorisé avant creation_block + CertRenewalPeriod
• après un renew_cert, un nouveau renew_cert ne doit pas être autorisé avant last_renewal_block + CertRenewalPeriod

Important

Ce nouveau délai :

• ne remplace pas CertPeriod
• s’ajoute à CertPeriod

Donc :

• CertPeriod continue de limiter la fréquence globale d’émission par issuer
• CertRenewalPeriod limite spécifiquement la fréquence de renouvellement d’une même certification (issuer, recipient)

Périmètre technique

Le changement implique probablement :

• l’ajout d’une nouvelle constante runtime dans la config du pallet certification
• le stockage d’une information temporelle par certification (issuer, recipient) permettant de savoir à partir de quand le renouvellement est autorisé
• l’adaptation de la logique de renew_cert
• l’initialisation correcte de cette contrainte dès add_cert

Critères d’acceptation

• Un nouveau paramètre runtime est introduit pour contrôler le délai minimal entre renouvellements d’une même certification.
• Après création d’une certification A -> B, son premier renouvellement est refusé tant que CertRenewalPeriod n’est pas écoulé.
• Après renouvellement d’une certification A -> B, un nouveau renouvellement est refusé tant que CertRenewalPeriod n’est pas écoulé.
• La restriction s’applique uniquement au couple (issuer, recipient) concerné.
• CertPeriod conserve son comportement actuel de limitation globale par issuer.
• Les tests couvrent au minimum :
  • refus d’un premier renouvellement trop tôt après création
  • refus d’un renouvellement trop tôt après un renouvellement précédent
  • succès exact à la borne
  • absence d’impact sur une autre paire (issuer, other_recipient) en dehors des règles déjà imposées par CertPeriod

Questions ouvertes

• Nom exact du paramètre : CertRenewalPeriod, SameReceiverRenewalPeriod, autre ?
• Faut-il réutiliser un stockage existant ou introduire une métadonnée dédiée par certification ?
• Faut-il prévoir une migration pour les certifications déjà présentes en storage au moment de l’introduction de la règle ?