Résumé

  • Le RFC 5402 autorise la compression du corps MIME avant la signature ou celle de l'ensemble multipart/signed après signature, mais interdit de cumuler les deux méthodes dans un même document.
  • Pour un message signé, le MIC retourné porte sur les données effectivement signées ; sa représentation dépend donc de l'ordre des couches.
  • Une capacité annoncée, une signature valide et un MIC concordant ne prouvent ni l'extraction des pièces jointes, ni la validité métier, ni l'acceptation de la transaction.

Une compatibilité de vocabulaire, pas encore de procédure

Dans le dossier d'interopérabilité, chaque fournisseur avait coché les mêmes cases : AS2, CMS, ZLIB, accusé signé. Le désaccord n'est apparu qu'au moment d'une reprise indépendante. Le premier journal avait conservé le condensat de l'entité compressée ; le second, celui du contenu MIME avant compression. Chacun pouvait expliquer son calcul. Aucun champ n'indiquait l'étape nommée par le condensat.

Le RFC 5402 ajoute une couche de compression aux messages EDIINT utilisés par AS1, AS2 et AS3. Un échange peut déjà contenir une charge métier, une signature et du chiffrement. Insérer une transformation réversible au milieu ne change pas seulement la taille : cela change la représentation protégée et l'ordre dans lequel le destinataire doit reconstruire les preuves.

Publié en février 2010 dans l'Independent Stream avec le statut Informational, le texte comporte une note de l'IESG : ce n'est pas une spécification de l'Internet Standards Track et sa valeur de déploiement doit être appréciée avec prudence. La nuance évite déjà une confusion. Une procédure publiée n'est ni un certificat d'adoption, ni la preuve d'une configuration identique chez deux partenaires.

Deux ordres permis, deux archives nécessaires

Lorsqu'un document doit être signé, l'émetteur peut d'abord compresser le corps MIME interne, puis signer l'entité CMS CompressedData. Il peut aussi créer le multipart/signed, puis compresser l'ensemble signé. Le RFC interdit d'appliquer les deux formes au même document. Le récepteur doit savoir dépaqueter chacune d'elles.

Dans la première forme, la signature voit la représentation compressée. Dans la seconde, elle voit le contenu métier et ses en-têtes MIME avant que la compression externe ne les enveloppe. Le RFC 5402 demande que le MIC d'un message signé soit calculé sur les mêmes données que la signature. Le MIC peut donc légitimement désigner des octets compressés ou non compressés.

Dire seulement « MIC du document » détruit cette information. Pour rejouer l'échange, il faut connaître l'ordre des couches, le corps exact couvert par la signature, les règles de canonisation, l'algorithme de hachage et la forme conservée. La même facture lisible peut correspondre à plusieurs états binaires corrects ; l'identité commerciale du contenu ne remplace pas l'identité de la représentation cryptographique.

Cette distinction limite aussi la dépendance à un produit. Si la passerelle ne sait exporter que son statut interne et le XML final, changer de fournisseur oblige à croire son ancienne interprétation. Une archive avec les octets et la recette peut être vérifiée ailleurs.

ZLIB commun ne ferme pas l'interopérabilité

Le profil exige la prise en charge de ZLIB, construit sur DEFLATE. Le RFC 3274 définit le type CMS CompressedData et l'identifiant de l'algorithme. Il précise que le niveau de compression n'a pas besoin d'être transmis : des niveaux différents restent compatibles avec le même décompresseur.

Le même texte prévient pourtant d'une variation d'encodage. À cause de l'histoire d'ASN.1, le champ des paramètres de l'algorithme peut être absent ou contenir NULL. L'encodage correct l'omet, mais un récepteur peut rencontrer les deux. Deux solutions qui annoncent ZLIB peuvent ainsi diverger avant même d'atteindre le document métier si l'une rejette une forme tolérée par l'autre.

S'ajoutent l'imbrication MIME, les limites de taille, les retours d'erreur, les règles de canonisation et l'accord bilatéral. Le RFC 5402 impose une version AS2 ou AS3 égale ou supérieure à 1.1 lorsque sa compression est utilisée. Cette version décrit l'intention d'employer le profil ; elle ne prouve pas le traitement d'un message donné.

Il faut conserver quatre faits : capacité déclarée, autorisation dans l'accord partenaire, configuration active et résultat observé. Les fusionner sous « pris en charge » permet à un changement de configuration de passer pour une preuve historique.

L'encodage de transport suit la couche visible

Le RFC 5402 utilise application/pkcs7-mime avec smime-type=compressed-data. Une entité compressée binaire exposée à un transport sept bits, comme SMTP, doit recevoir un Content-Transfer-Encoding base64. Si elle est enfermée dans une enveloppe chiffrée, la couche compressée interne n'a pas besoin de base64 ; c'est l'enveloppe chiffrée visible qui en a besoin.

Ce déplacement aide à localiser une altération. Il existe le MIME source, les octets CMS compressés, éventuellement l'enveloppe chiffrée, puis la forme base64 transportée. Au retour, les étapes sont inversées. Ne conserver que le fichier final empêche de dire si une rupture vient de la conversion de transport, du déchiffrement, de la décompression ou de l'analyse MIME.

Les en-têtes et délimitations ne sont pas du décor. Pour certains cas non signés, le MIC du RFC 5402 porte sur le contenu décompressé, les en-têtes MIME et tout encodage de transfert appliqué. Le RFC 4130 ajoute les règles de canonisation AS2. Un opérateur qui recalcule un hachage sur un XML réindenté ne vérifie pas nécessairement le même ensemble d'octets.

L'accusé négatif attribue précisément l'échec

Si la décompression échoue alors qu'un accusé est demandé, le destinataire renvoie dans le MDN signé le modificateur Error: decompression-failed. Cette réponse ne vaut pas acceptation, mais elle vaut mieux qu'un silence. Après vérification de la signature, elle attribue au partenaire l'observation qu'il n'a pas pu franchir la couche de compression.

La portée doit rester exacte. Le message ne dit pas que le bon de commande a été rejeté après analyse métier : le contenu n'a peut-être jamais été reconstruit. Il ne dit pas non plus que la source de l'émetteur était fautive : la corruption peut avoir eu lieu sur une représentation intermédiaire.

Le RFC 4130 confirme la séparation. Même si le traitement du contenu échoue, une demande d'accusé signé doit encore être honorée ; la transaction elle-même peut être invalide et le champ de disposition en indique la raison. Une signature authentifie le rapport, pas le succès dont le rapport peut précisément constater l'absence.

Un MIC collectif ne rend pas chaque pièce valide

Le RFC 6362 étend EDIINT aux pièces jointes multiples dans un corps multipart/related. Pour un ensemble compressé mais non signé, le MIC couvre le corps multipart décompressé après la canonisation du transport. Si le MIC attendu diffère du MIC calculé, toutes les pièces sont considérées invalides et doivent être retransmises.

Cette atomicité de l'intégrité n'efface pas les traitements ultérieurs. Une fois l'ensemble validé et extrait, un XML peut passer son schéma, un PDF être archivé et une image être refusée par la politique locale. Le RFC laisse le stockage et le traitement des documents dépendre de l'implémentation.

Le registre doit donc relier une preuve d'enveloppe à plusieurs preuves de pièce. Copier le MIC collectif comme « validation » de chaque document exagère sa portée. Inversement, une erreur métier sur une pièce ne doit pas être réécrite en échec cryptographique de tout l'échange.

La preuve complète est une séquence

Avant l'émission, conserver l'accord partenaire, la version attendue et l'ordre de couches autorisé. Pendant la construction, préserver l'entité MIME source, la canonisation, l'identifiant de compression, sa forme de paramètres, le contenu signé et le contenu chiffré. À la réception, enregistrer le décodage de transfert, le déchiffrement, la décompression, la vérification de signature et la recette du MIC.

L'accusé ajoute sa propre signature, le certificat du partenaire, l'identifiant du message d'origine et la disposition. Ensuite seulement viennent l'extraction, la validation de format, la corrélation de transaction, le contrôle des doublons et la décision commerciale.

Les sources ne prouvent ni la part de marché actuelle de ce profil, ni le comportement d'un fournisseur, ni un incident réel. Elles suffisent à fixer la limite : deux partenaires qui prennent en charge la compression n'ont pas encore prouvé qu'ils protègent, hachent et interprètent la même représentation.