Summary

  • La révision 04 du projet individuel sur la préparation PQC ajoute CygnetSSL, exploité dans un seul domaine administré, propriétaire et sans test d’interopérabilité indépendant.
  • Les 22 certificats ECDSA, la publication d’une CRL et un changement d’état OCSP attestent un exercice d’AC circonscrit ; ils ne valident pas les cinq exports et agrégations réseau réclamés par le texte.
  • Daniel Kade propose une matrice de preuve de fermeture des lacunes. Cette recommandation éditoriale n’est ni une exigence IETF ni un jugement sur la qualité du logiciel cité.

Le nouveau contenu est une pièce de preuve, pas un verdict

La révision 04 du 13 septembre ajoute une section consacrée à l’état des implémentations. Elle n’existait pas dans la révision 03, ce que montre la comparaison officielle.

Le cadre institutionnel reste limité. La fiche Datatracker classe le document parmi les Internet-Drafts individuels actifs. Les métadonnées indiquent I-D Exists, la révision 04 et l’absence de flux IETF. La mention « Informational » dans l’en-tête exprime un objectif ; elle ne vaut ni adoption par un groupe de travail, ni approbation de l’IESG, ni publication comme RFC.

L’entrée ajoutée décrit le pilote d’autorité de certification CygnetSSL de Sanctum SecOps. Les fonctions citées couvrent émission et révocation, vérification des chaînes et profils, génération et publication de CRL, ainsi que réponses OCSP. Le texte précise trois limites déterminantes : un seul domaine géré par un administrateur, un logiciel propriétaire sans code public et aucun essai d’interopérabilité avec une implémentation indépendante.

Le relevé du 12 septembre reste concret. Vingt-deux certificats de bout ont été émis et contrôlés selon deux profils. Tous utilisaient ECDSA sur P-384 avec ECDSA-SHA384. Une CRL au format DER a été publiée ; un certificat a d’abord reçu l’état OCSP good, puis revoked après révocation. Cela documente une chaîne d’opérations d’AC. Cela ne documente pas l’usage d’algorithmes post-quantiques. L’activation d’un fournisseur FIPS d’OpenSSL n’équivaut pas à une attestation PQC. Les références FIPS 204 et FIPS 205 définissent des signatures post-quantiques, alors que les certificats observés ici sont classiques.

Cinq lacunes, cinq objets à démontrer

La première exigence vise un export structuré des algorithmes réellement négociés dans les sessions TLS 1.3. La deuxième concerne l’inventaire par zone des algorithmes DNSSEC vus par les résolveurs. La troisième demande une distribution agrégée des familles d’algorithmes sur les infrastructures X.509/CRL et OCSP. La quatrième transpose le problème de TLS à QUIC. La cinquième cherche un état de préparation interprotocoles compatible avec les inventaires CBOM.

CygnetSSL touche au domaine de la troisième lacune, mais le relevé ne décrit pas l’export demandé. Un ensemble de 22 émissions n’est pas une distribution des certificats activement vérifiés dans toute une infrastructure OCSP/CRL. Aucun schéma, dénominateur, destinataire, intervalle d’agrégation ou essai reproductible n’est fourni. Le projet ne dit d’ailleurs pas que REQ-RG-3 est satisfaite.

Pour les quatre autres lignes, l’écart est direct : aucune trace d’export par session TLS ou QUIC, d’inventaire d’un résolveur DNSSEC, d’agrégateur global ou de test d’interopérabilité avec un CBOM. Cette comparaison n’établit pas un échec du pilote. Elle évite seulement de lui attribuer une conclusion qu’il ne revendique pas.

RFC 7942 organise précisément cette prudence

RFC 7942 permet d’inscrire du code en fonctionnement dans un Internet-Draft afin d’éclairer la discussion. Il recommande d’indiquer maturité, couverture, versions compatibles, licence, retour d’expérience, contact, date de mise à jour et, lorsqu’ils existent, rapports d’interopérabilité. Il précise aussi que la présence d’une implémentation ne constitue pas une approbation de l’IETF et que les informations fournies par les contributeurs ne deviennent pas vérifiées par leur simple publication.

Cette section est appelée à disparaître avant la RFC parce que son contenu vieillit. La révision 04 reprend correctement les limites d’approbation et de durée. Elle donne la maturité et la licence. Il manque toutefois la correspondance explicite entre la couverture annoncée et chacune des lignes REQ-RG-1 à REQ-RG-5.

La disponibilité fait partie de la preuve. L’annexe affirme que le dépôt CygnetLib contient des fichiers JSON. À l’heure de gel, cette adresse exacte répondait HTTP 404 depuis l’hôte de production. Cette observation ne prouve ni disparition historique ni intention ; le lien peut être réparé. Elle signifie simplement que la vérification publique promise n’était pas possible à cet instant.

Une matrice rendrait chaque conclusion révisable

Daniel Kade propose une matrice de preuve de fermeture. À chaque lacune correspondraient : l’exigence, le mécanisme réalisé, le nom et la version de l’implémentation, l’artefact stable, l’opérateur et l’environnement, la méthode d’essai, la population et son dénominateur, le résultat, les limites, la date, le responsable et la prochaine révision. Un reproducteur indépendant serait nommé lorsqu’il existe ; son absence ne serait pas masquée.

Cette forme respecte le code en fonctionnement. « Vingt-deux certificats ECDSA ont suivi ce parcours dans un domaine » est un constat solide et borné. « L’export REQ-RG-3 existe » exige le schéma et son résultat. « L’environnement est prêt au PQC » exige encore les lignes TLS, DNSSEC, QUIC, agrégation et CBOM.

Le Policy Mirror de Heng Lu aide à voir que l’interface entre preuve et autorité est elle-même gouvernée. La Minimum Initial Specification privilégie un noyau commun modeste qui conserve la décision locale. Why BTW Media Exists impose enfin de publier simultanément le fait nouveau et ses limites.

Sources

  1. Projet PQC, révision 04
  2. Révision 03
  3. Différence officielle 03–04
  4. Fiche Datatracker
  5. API de métadonnées
  6. RFC 7942
  7. RFC 8446
  8. RFC 4034
  9. RFC 5280
  10. RFC 6960
  11. RFC 9000
  12. NIST FIPS 204
  13. NIST FIPS 205
  14. Lien CygnetLib cité
  15. The Policy Mirror
  16. Minimum Initial Specification
  17. Why BTW Media Exists