Résumé

  • La RFC 8181 rend atomique une requête de publication comportant plusieurs opérations, mais sa réponse de succès prouve la transaction client-serveur, pas la vue actuelle de toutes les parties utilisatrices.
  • La RFC 9286 lie les noms et empreintes des objets d’un point de publication par un manifeste signé, tandis que RRDP distribue des instantanés et des deltas numérotés.
  • Un registre défendable sépare les états demandé, validé par le serveur, cohérent avec le manifeste, servi publiquement et observé, avec une heure et un périmètre pour chaque preuve.

La publication RPKI paraît souvent être une seule action : produire ou retirer un objet, l’envoyer au dépôt, puis attendre les validateurs. Les normes décrivent une chaîne plus précise. Une autorité de certification ou son client agit par le protocole de publication ; un serveur valide une transaction ; un manifeste décrit l’ensemble courant ; un service de distribution expose des vues ; enfin, les parties utilisatrices récupèrent et valident ces vues selon leur propre calendrier.

La RFC 8181 protège la première frontière. Les messages signés authentifient le client et le serveur. Une requête peut grouper des opérations de publication et de retrait ; son traitement est atomique. Une opération qui remplace ou retire un objet porte l’empreinte de l’objet déjà présent à l’URI. Si cet état antérieur ne correspond pas, le serveur peut refuser la modification au lieu d’écraser silencieusement une autre version.

La réponse de succès constitue donc une preuve importante et limitée. Elle établit que le serveur nommé a accepté toute la requête authentifiée. Elle n’établit ni que la notification RRDP publique a changé, ni qu’une vue rsync sert déjà les nouveaux fichiers, ni qu’un validateur particulier les a récupérés. La RFC 8181 sépare explicitement l’interface de publication client-serveur de l’interface de distribution visible par les parties utilisatrices.

La RFC 9286 définit ensuite le manifeste. Cet objet signé énumère les noms de fichiers et les empreintes des objets signés associés au point de publication d’une CA. Les signatures des objets ne suffisent pas à révéler toute substitution par une ancienne version ou toute suppression en transit ; la comparaison avec le manifeste permet de détecter certaines omissions, modifications et répétitions.

Son périmètre est strict : certificats courants émis par la CA, CRL la plus récente et autres objets signés rattachés à cette instance de CA. Lorsque plusieurs instances partagent un point, chaque manifeste ne décrit que ses propres produits. Une liste de répertoire sans identité de CA ni manifeste applicable ne prouve donc pas la cohérence recherchée.

La RFC 9286 lie aussi le manifeste à la finalisation d’un changement. Un nouveau manifeste accompagne les objets modifiés, actualise leurs empreintes et doit paraître avant nextUpdate. Cette exigence crée un jalon vérifiable ; elle ne dit toujours pas quelle vue un cache ou une partie utilisatrice détient à cet instant.

RRDP fournit la séquence de distribution. Selon la RFC 8182, une notification identifie une session et un numéro de série courant. Un instantané offre une vue complète ; chaque delta couvre une seule progression de série et contient les objets ajoutés, remplacés ou retirés. Une partie utilisatrice peut ainsi obtenir une vue ponctuelle cohérente ou avancer de manière incrémentale.

Le numéro de série n’est pas une horloge universelle. Il appartient à une session et à un serveur. Une partie utilisatrice peut interroger avant la nouvelle notification, rencontrer un cache, rejeter un delta invalide ou revenir à un instantané. Le registre doit donc conserver la session, la série, l’empreinte de la notification, le transport, l’observateur et l’heure, au lieu de noter simplement « RRDP mis à jour ».

La première entrée du registre concerne la requête : identités du client et du serveur, empreinte du message signé, URI, étiquettes d’opération, empreintes précédentes et nouvelles, heures d’envoi et de réponse. En cas d’échec atomique, elle interdit de revendiquer une réussite partielle. En cas de succès, elle conserve la réponse signée.

La deuxième entrée décrit le commit du serveur : point de publication, manifeste nouveau, heures thisUpdate et nextUpdate, empreinte de la CRL et ensemble exact des objets énumérés. Une transaction interne peut aider l’exploitant, mais ne constitue pas une observation publique.

La troisième entrée porte sur la distribution : URI de notification RRDP, session, série, empreintes du delta et de l’instantané, ou observation rsync équivalente. Les deux mécanismes peuvent être vérifiés séparément. La quatrième consigne des observations bornées de parties utilisatrices : identité et version du logiciel, heure, transport, série, résultat du manifeste, résultat de l’ensemble et verdict de validation.

Un modèle compact distingue REQUEST_AUTHENTICATED, SERVER_COMMITTED, MANIFEST_COHERENT, PUBLIC_VIEW_OBSERVED, RP_OBSERVED et EXCEPTION_OPEN. Une réponse réussie suivie d’une vue plus ancienne peut n’être qu’un ordre d’observation. En revanche, une nouvelle série accompagnée d’un manifeste incohérent reste une anomalie, même si la distribution a progressé.

Les RFC ne fixent pas un délai mondial unique de consommation par toutes les parties utilisatrices. Elles ne révèlent pas les caches privés et ne définissent pas un schéma d’audit universel pour les exploitants. Une absence chez un observateur ne prouve pas une absence mondiale ; une présence chez un autre ne prouve pas la convergence générale.

Le registre ne promet donc pas l’impossible. Il relie ce que le client a demandé, ce que le serveur a validé, ce que le manifeste a énuméré, ce que le service public a présenté et ce que des observateurs nommés ont reçu. Chaque acteur demeure autorité dans son périmètre, et aucune preuve n’est agrandie au-delà de ce qu’elle établit.

Sources