Résumé

  • RFC 9589 rend signing-time obligatoire dans les objets RPKI protégés par CMS et retire l’alternative binary-signing-time.
  • L’attribut permet d’aligner le mod-time d’un fichier publié par rsync et celui d’une copie matérialisée après RRDP, afin d’éviter un retransfert inutile lors d’un repli.
  • Il ne constitue ni une horloge fiable, ni une preuve de validité de certificat, ni l’inventaire courant, ni une observation de BGP.

Un même repère pour deux livraisons

RRDP et rsync ne sont pas deux autorités RPKI. Ce sont deux voies pour obtenir une représentation d’objets signés. Un relying party préfère souvent RRDP et ses snapshots ou deltas, puis peut devoir utiliser rsync lorsqu’un XML est malformé, qu’un certificat TLS expire ou qu’une connexion échoue. Le problème pratique n’est pas seulement la disponibilité : une copie DER déjà obtenue par RRDP existe peut-être localement, tandis que rsync compare une arborescence de fichiers.

Le contrôle rapide de rsync s’appuie notamment sur la taille et le temps de modification. Des valeurs différentes peuvent faire transférer à nouveau un objet déjà présent. RFC 9589 propose une convention étroite. L’émetteur met un signing-time CMS dans l’objet; l’opérateur de dépôt devrait reporter cette valeur dans le mod-time publié par rsync; le relying party devrait faire de même lorsqu’il écrit l’objet obtenu via RRDP. Après l’échec de RRDP, les deux côtés exposent ainsi le même repère de comparaison.

Le gain est réel : moins de bande passante, d’entrées-sorties et de calcul pendant un incident de transport. Mais le repère n’est pas promu en juge de la réalité. Il sert à décider si rsync doit probablement recopier un fichier; il ne décide pas si le fichier doit être accepté par RPKI.

Ce que la signature ne promet pas

La signature protège l’attribut tel qu’il est contenu dans l’objet. Elle n’oblige pas l’émetteur à avoir une horloge juste et ne prouve pas l’instant auquel la clé a signé. RFC 9589 dit expressément qu’aucune exigence ne porte sur la correction de signing-time et que cette valeur ne donne pas une information fiable sur l’heure de production de la signature.

Cette limite est une qualité d’architecture. Pour réduire les retransferts, il suffit qu’un même objet reçoive la même valeur quand il passe de RRDP au système de fichiers rsync. Il ne faut ni horodatage opposable ni centre de temps universel. Une valeur erronée mais cohérente peut encore permettre la bascule; elle ne doit jamais devenir la preuve qu’une publication est récente, qu’un incident est résolu ou qu’une autorisation demeure active.

La même prudence vaut pour le contrôle rapide de rsync. Taille et mod-time identiques sont des indices de non-transfert, pas une preuve cryptographique d’égalité des octets. Les contrôles CMS, les certificats et les règles propres à chaque objet conservent leur travail.

La chaîne qui reste à vérifier

Un objet récupéré ou conservé doit passer le profil commun de RFC 6488 et son contrôle spécifique. Le certificat EE doit être valide dans la chaîne de ressources; la révocation reste pertinente. Le manifeste courant de RFC 9286 fournit l’inventaire signé. RFC 9829 précise que la CRL utile est à la fois celle indiquée par le certificat et celle présente, avec le bon hash, dans le manifeste courant de l’émetteur.

Une ROA illustre bien la frontière. Même valide, elle formule une autorisation limitée entre ressources, préfixe et AS. Elle ne prouve pas qu’une annonce est présente, choisie par des voisins ou acheminée jusqu’à une destination. La réussite de RRDP, le repli rsync et l’heure signée n’élargissent pas cette déclaration.

Il faut donc observer la chaîne complète : URI et octets, résultat du transfert, certificats, CRL, manifeste, validation de l’objet, empreinte des données validées, puis entrée effectivement livrée à la politique de routage. Un feu vert de transport n’est pas un feu vert d’autorisation.

Tester le repli réel

Le bon exercice crée des écarts contrôlés : RRDP normal puis repli avec mêmes octets; XML RRDP invalide; TLS expiré; timeout; fichier rsync absent; taille ou mod-time modifié; certificat révoqué; objet absent du manifeste courant. Pour chaque produit et version, conserver l’URI, le chemin, le hash, signing-time, les deux mod-time, la taille, la décision de transfert, les résultats de certificat, CRL et manifeste, puis l’empreinte de sortie validée.

Comparer les sorties de plusieurs implémentations est décisif. Une bascule qui économise des octets tout en modifiant le jeu validé mérite une explication; une bascule plus coûteuse qui préserve ce jeu peut n’être qu’un problème d’efficacité. La conformité déclarée ne remplace pas ce test de code en fonctionnement.

Sources