Summary

  • RFC 10003 normalise quatre moyens de transporter CMC : HTTP, fichier, courrier électronique et TCP. Leur résultat prouve un fait de circulation, pas l'issue de l'opération PKI contenue dans le message.
  • Les états success, failed, pending ou partial appartiennent à la réponse CMC définie par RFC 10002. Un 2XX, un courriel remis ou un fichier présent ne peut pas les remplacer.
  • Daniel Kade propose un reçu transport-décision qui relie les traces minimales du canal, la réponse vérifiée, l'état de transaction, l'empreinte du certificat émis et son déploiement, sans conserver les secrets d'enrôlement.

Deux horloges dans une seule demande

L'enrôlement automatisé donne l'impression d'une action unique : une machine demande un certificat et en reçoit un. En réalité, deux horloges au moins se mettent en marche. La première mesure l'acheminement. La seconde mesure l'instruction de la demande par l'autorité d'enregistrement ou de certification.

RFC 10003 organise la première horloge. Le document, publié sur la voie Standards Track de l'IETF, définit l'emploi de HTTP, des fichiers, du courrier électronique et de TCP pour transporter les messages Certificate Management over CMS. RFC 10004 impose à toutes les entités CMC de prendre en charge HTTP ; les autres transports peuvent être mis en œuvre.

RFC 10002 règle l'autre horloge. Une réponse PKI complète peut annoncer une réussite, un échec, une demande encore en attente, un résultat partiel ou la nécessité d'une action supplémentaire. Lorsqu'une émission est différée, plusieurs allers-retours sont normaux. La fin de la requête HTTP ne clôt donc pas nécessairement la transaction de certification.

Cette séparation paraît technique. Elle est en fait une frontière de responsabilité : l'équipe qui transporte ne décide pas à la place de l'autorité qui instruit.

Le 2XX répond à une question HTTP

Pour l'interopérabilité, RFC 10003 exige l'emploi de POST et réserve les codes 2XX aux réponses HTTP réussies. Le corps doit être le codage binaire de la requête ou de la réponse PKI, avec le type de média approprié. Une requête complète utilise application/pkcs7-mime et smime-type=CMC-Request ; la réponse correspondante porte smime-type=CMC-Response.

Ces éléments produisent un reçu de transport solide : URI visée, méthode, moment, code, type de contenu, politique TLS et empreinte du corps. Mais ils ne disent pas si le certificat a été accordé. Un serveur peut parfaitement rendre un 2XX accompagné d'une réponse CMC failed, pending ou partial. C'est une réponse HTTP réussie qui transporte un résultat applicatif négatif ou incomplet.

L'erreur inverse existe aussi. Un code non-2XX peut provenir d'un proxy, d'une authentification HTTP, d'un routage défaillant ou d'un contenu refusé avant que l'autorité ne se prononce. Le qualifier de « rejet par la CA » inventerait une décision qui n'a peut-être jamais eu lieu.

Le tableau de bord devrait donc afficher deux champs, pas un seul : « échange HTTP » et « état CMC vérifié ». Ce n'est qu'après décodage, contrôle de protection et lecture du bon élément de statut que le second champ peut changer.

L'attente est un contrat de suivi

Un état pending n'est ni un échec de transport ni une réussite lente que l'on pourrait anticiper. RFC 10002 prévoit PendInfo, avec un jeton et une heure suggérée pour une nouvelle interrogation. Le demandeur doit revenir. Un état partial exige lui aussi le suivi des éléments non satisfaits.

La preuve doit préserver cette ouverture. Le reçu initial constate que la réponse a été remise et que l'opération reste pendante. Le reçu du sondage ultérieur doit reprendre le même identifiant de transaction et le même jeton protégé. Si le jeton est perdu, si l'interrogation n'a jamais lieu ou si seule une partie d'un lot est résolue, le système ne doit pas transformer le silence en réussite.

La question des rejouements renforce cette prudence. POST n'est pas idempotent ; RFC 10003 interdit donc l'emploi des données précoces 0-RTT par les implémentations CMC qui utilisent TLS 1.3 ou QUIC. Après une réponse perdue, renvoyer aveuglément la demande peut créer une deuxième livraison. Les identifiants de transaction, les nonces et les empreintes servent alors à distinguer un suivi, une répétition et une nouvelle opération autorisée.

Quatre transports, quatre illusions possibles

Avec le fichier, la règle est concrète : un seul message binaire de requête ou de réponse par fichier, avec des extensions recommandées. Pourtant, la présence de request.crq dans un répertoire ne prouve que l'écriture d'un objet. Même l'arrivée de response.crp n'atteste ni son décodage, ni sa signature, ni la décision qu'il contient.

Le courrier électronique ajoute des en-têtes MIME, des noms de fichier et des exemples encodés en base64. Un identifiant de message ou une notification de remise décrit le service de messagerie, pas l'opération CMC. RFC 10003 souligne en outre que TLS entre l'application et son premier agent de soumission ne garantit pas que les relais suivants seront authentifiés et chiffrés. REQUIRETLS peut demander cette protection de bout en bout de la chaîne SMTP, lorsqu'elle est disponible, au prix d'un risque de non-remise si un relais ne la comprend pas.

Sur TCP, les messages binaires ne reçoivent pas d'enveloppe supplémentaire. Le service pkix-cmc utilise le port 5318 et le client doit attendre la réponse entière avant d'émettre une nouvelle requête sur la même connexion. Ni l'ouverture du socket ni le nombre d'octets écrits ne remplace l'analyse de cette réponse.

Chaque canal a donc ses traces et ses angles morts. Une politique commune ne doit pas gommer ces différences ; elle doit imposer le même point d'arrivée : aucune trace de transport n'est autorisée à parler au nom de la décision PKI.

Confidentialité du canal et autorité du message

HTTPS protège un trajet contre l'écoute. Les structures CMS peuvent protéger le message lui-même. EnvelopedData ou AuthEnvelopedData peuvent apporter une confidentialité lorsque la confiance de canal n'est pas préétablie. Ces protections se complètent, mais elles ne sont pas interchangeables.

Un échange TLS correctement établi ne démontre pas que le signataire CMC avait le droit de demander les noms inscrits, ni que la RA a validé l'identité, ni que la CA a approuvé le profil. À l'inverse, un objet CMS intègre ne révèle pas tout seul quel point d'accès l'a reçu, quel relais a échoué ou quelle réponse correspond à quelle tentative.

RFC 10003 précise que les clients ne sont pas tenus de prendre en charge l'authentification HTTP ni les cookies. Un serveur ne peut donc pas bâtir son modèle sur leur présence supposée. La confiance initiale et la politique de certification restent des décisions architecturales distinctes du transport.

Le vocabulaire d'assurance devrait les nommer séparément : canal protégé, enveloppe vérifiée, autorité du demandeur confirmée, décision CMC obtenue, certificat émis, certificat activé. Le mot « sécurisé » sans complément cache trop d'acteurs.

Le reçu transport-décision

Je propose un reçu transport-décision CMC. Il s'agit d'une proposition de gouvernance de Daniel Kade, et non d'une exigence nouvelle de RFC 10003.

Le premier volet conserve le fait de transport. Pour HTTP : identité du point d'accès, méthode, heure, code, type de contenu, référence de politique TLS et empreintes bornées des objets échangés. Pour le courrier : identifiant du message soumis, destination, état de remise observé et portée éventuelle de REQUIRETLS. Pour le fichier ou TCP : canal contrôlé, sens, heure et empreinte. Aucun corps, mot de passe ou détail topologique sensible n'est nécessaire.

Le deuxième volet constate l'analyse applicative : forme simple ou complète, identifiant de transaction, parties concernées, intégrité et authenticité du message. Une réponse transportée mais indéchiffrable ou non authentifiée reste une preuve incomplète.

Le troisième inscrit le verdict CMC sans le simplifier. pending garde une référence protégée vers le jeton, l'heure de rappel et le sondage qui le résout. partial identifie ce qui demeure ouvert. Un échec conserve une cause utile et limitée, pas tout le dossier d'identité.

Le quatrième volet ne naît que si un certificat existe. Il relie son empreinte, son émetteur, son numéro de série, sa clé publique, ses noms et sa période de validité à la demande. Il ne suppose pas l'ordre des certificats renvoyés et ne transforme pas automatiquement un certificat autosigné joint en ancre de confiance.

Enfin, le déploiement est une observation distincte : installation, activation et test par une partie utilisatrice. Une émission juste peut être suivie d'une mauvaise chaîne, d'un ancien certificat encore actif ou d'une installation jamais achevée.

Gouverner par le dernier fait prouvé

Une exploitation honnête ne cherche pas un unique état « terminé ». Elle indique le dernier fait dont la preuve est disponible. « POST accepté » relève de l'équipe de plateforme. « Réponse CMC validée » relève de l'implémentation de protocole. « Certificat émis » relève de la CA. « Empreinte installée » relève du propriétaire de l'équipement. « Présenté et accepté » relève du service observé.

Les alertes les plus utiles portent sur les jointures manquantes : 2XX dont le corps ne se décode pas, réponses en échec marquées comme succès, jetons pendants abandonnés, demandes identiques sous plusieurs transactions, certificat renvoyé qui ne correspond pas à la clé ou aux noms attendus, émission sans preuve d'installation, service qui présente toujours l'ancien certificat.

La métrique juste n'est pas le taux de requêtes HTTP vertes. C'est la part des transactions dont l'organisation sait énoncer le dernier stade démontré et retrouver la preuve bornée qui le justifie.

RFC 10003 rend le transport interopérable. Sa leçon de gouvernance est de ne jamais prendre l'arrivée d'un message pour la décision qu'il sollicite.

Sources

  1. Lu Heng — Souveraineté des données : réalités techniques et pratiques
  2. Lu Heng — Pourquoi BTW Media existe
  3. Lu Heng — Primauté du code en fonctionnement
  4. RFC 10003 — Protocoles de transport CMC
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — Exigences de conformité CMC
  7. RFC 5273 — Ancienne spécification de transport CMC
  8. RFC 5967 — Type de média application/pkcs10
  9. RFC 8551 — Spécification S/MIME 4.0
  10. RFC 9110 — Sémantique HTTP
  11. RFC 9205 — Construire des protocoles avec HTTP
  12. RFC 9325 — Recommandations TLS et DTLS
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — Option SMTP REQUIRETLS
  16. RFC 3207 — SMTP sécurisé par TLS