Summary

  • Dans draft-ietf-ediint-rfc4130bis-04, AS2-From et AS2-To sont des chaînes sensibles à la casse, convenues entre partenaires ; elles ne sont ni des noms DNS, ni des identités de certificat universelles.
  • Le certificat TLS protège le canal HTTPS. Un certificat AS2 distinct signe ou chiffre le message et le MDN ; le projet interdit d'employer le même certificat pour les deux rôles.
  • La signature, le Message-ID et le MIC établissent une chaîne de réception robuste seulement après qu'une autorité locale a relié le bon nom, la bonne clé, le bon sens et la bonne relation commerciale.

Quatre colonnes que la signature ne remplit pas

Dans la table d'un opérateur B2B, une ligne devrait contenir au moins quatre éléments : nom AS2 exact, empreinte du certificat de message, sens autorisé, relation de partenariat. Une signature correcte remplit la colonne « possession de la clé ». Elle ne remplit pas seule les trois autres.

La révision 04 rend cette dissociation particulièrement lisible. Le Datatracker la présente comme un projet actif du groupe EDIINT ; l'API documentaire indique I-D Exists, et l'historique date la révision du 24 septembre 2026. L'objectif annoncé est Proposed Standard. Ce n'est pas un RFC adopté ; RFC 4130 ne serait remplacé qu'après approbation.

Le nom négocié

La section 6.3 autorise un numéro DUNS ou toute chaîne d'identification convenue. Le nom comprend de 1 à 128 caractères ASCII imprimables, respecte la casse et figure dans tout message et tout MDN. La réponse inverse la paire : son AS2-To reprend le AS2-From de la demande, et son AS2-From reprend le AS2-To initial.

Cette symétrie détecte une erreur de routage et permet la corrélation. Elle ne transforme pas une chaîne en identité juridique. Si le nom ou la relation est inconnu, le destinataire peut envoyer un MDN non signé avec unknown-trading-relationship ou unknown-trading-partner. Cette décision suppose déjà une base locale : le protocole n'offre aucun annuaire mondial qui associerait chaque nom AS2 à une clé souveraine.

Deux certificats, deux juridictions

Le certificat TLS établit la sécurité de la session HTTPS. TLS 1.3 et la sémantique HTTP de RFC 9110 décrivent le canal ; RFC 9525 apporte un contexte moderne sur l'identité de service, sans devenir pour autant une règle incorporée au projet AS2.

Le certificat AS2 protège le contenu. Les structures reposent sur S/MIME et CMS, documentés notamment par RFC 8551 et RFC 5652, avec la validation PKIX de RFC 5280. Le projet exige que le certificat AS2 ne soit pas celui de TLS. Ainsi, une compromission ou une rotation du canal n'emporte pas automatiquement la sécurité du message.

Mais une chaîne PKIX valide ne désigne pas la relation bilatérale. Elle répond à des règles d'émission et de confiance. L'administrateur AS2 répond à une autre question : cette clé est-elle approuvée aujourd'hui pour ce nom, dans ce sens, dans ce contrat ?

Recevoir une clé n'est pas lui donner pouvoir

Le texte recommande Certificate Exchange Messaging, décrit par le projet CEM. À défaut, l'échange manuel doit préserver l'intégrité et authentifier la clé avant activation. Un point d'accès Well-Known peut servir à la récupération initiale, mais le demandeur doit être authentifié et son accès autorisé.

La nuance est fondamentale. La signature de l'émetteur du certificat le rend résistant à une substitution silencieuse. Elle ne décide ni qui peut le télécharger, ni quelle ligne partenaire doit le recevoir. Pour un certificat auto-signé, le projet exige une vérification hors bande supplémentaire—par exemple la confirmation de l'empreinte sur un canal sûr—avant la production.

L'acte d'activation doit donc conserver l'origine, l'empreinte, la série, la période, l'usage signature ou chiffrement, le sens, les approbateurs, la fenêtre de recouvrement et la clé de retour. Les certificats expirés, révoqués ou non fiables doivent produire une erreur immédiate et visible. Une clé peut pourtant être valable sur tous ces critères et rester non autorisée pour le partenaire local.

Le reçu prouve exactement sa chaîne

L'émetteur garde le message, son Message-ID et son MIC. Le destinataire renvoie un MDN, éventuellement signé. L'émetteur vérifie la signature, compare l'Original-Message-ID et rapproche le MIC reçu du condensé mémorisé. RFC 8098 fournit le cadre actuel des Message Disposition Notifications.

Le projet appelle « non-repudiation of receipt » le résultat obtenu après vérification de la signature et du MIC. Cette expression n'est pas ici étendue à un verdict juridique universel. Surtout, cet article ne reprend pas l'analyse déjà publiée selon laquelle une livraison n'est pas une acceptation commerciale. Son point vient avant : la clé avec laquelle on vérifie le reçu doit déjà avoir été autorisée pour ce partenaire.

La séquence correcte est donc : connexion HTTP/TLS ; lecture des noms ; validation du certificat ; autorisation locale de la liaison ; signature ; corrélation Message-ID/MIC ; disposition MDN ; traitement EDI ; résultat commercial. Aucun étage ne doit emprunter l'autorité du suivant.

La révision 03 contient déjà les principaux contrôles de certificat. La révision 04 ne doit pas être présentée comme leur invention soudaine. Ses versions HTML et XML confirment la structure, pas l'existence d'un déploiement.

Sources et limites

Le dossier réunit le texte, le HTML et le XML de la révision 04, le Datatracker, son API et son historique, la révision 03, RFC 4130, RFC 8098, RFC 8551, RFC 8615, RFC 5652, RFC 5280, le projet CEM, RFC 9110, RFC 9525 et RFC 8446. L'analyse de gouvernance s'appuie séparément sur Lu Heng : primauté du code en fonctionnement, couches de réalité et spécification initiale minimale. Aucune mise en œuvre, panne ou décision judiciaire n'est déduite de ces sources.