Résumé

  • La RFC 3923 protégeait un objet CPIM avec S/MIME puis le transportait dans une enveloppe XMPP ; l’espace de noms de cette enveloppe ne définissait pas le sens du message.
  • La passerelle XMPP-CPIM pouvait retirer ou ajouter l’enveloppe du service, mais devait relayer l’objet protégé sans le modifier.

La modification autorisée à la passerelle

Une passerelle permet à deux services de messagerie qui n’emploient pas le même protocole d’échanger un message. Mais dès que l’un traduit le message, une question de sécurité apparaît : que peut-il modifier sans entrer lui-même dans le périmètre de confiance ? Publiée en octobre 2004 comme norme IETF, la RFC 3923 répond par une unité de confiance très limitée. Une passerelle XMPP-CPIM peut enlever l’enveloppe d’un service et mettre celle d’un autre. Elle ne peut pas altérer l’objet S/MIME signé ou chiffré qui se trouve à l’intérieur.

Cette distinction rendait la protection de bout en bout compatible, au moins à la frontière des protocoles, avec un intermédiaire connaissant les deux services. La passerelle n’est pas un terminal cryptographique : elle transporte l’objet protégé comme une charge opaque. L’architecture sépare ainsi le travail d’interopérabilité de celui qui consiste à signer, chiffrer et interpréter le contenu.

Un objet protégé dans une stanza XMPP

L’expéditeur crée d’abord un objet Message/CPIM. Celui-ci contient les en-têtes et le contenu ; la RFC exige que les deux soient couverts par la signature ou le chiffrement S/MIME. L’objet obtenu est ensuite placé dans une section CDATA XML, elle-même contenue dans un enfant <e2e/> d’une stanza XMPP de message ou de présence. Selon le cas, l’objet peut aussi être un document de présence PIDF ou un objet XML XMPP.

L’élément <e2e/> transporte ; il n’interprète pas. La RFC précise que son espace de noms n’a pas de sémantique propre : les normes CPIM, PIDF ou XMPP définissent l’objet encapsulé. L’intermédiaire n’a donc pas à comprendre le contenu protégé simplement parce qu’il sait analyser la stanza XMPP qui le transporte.

La règle de passerelle découle de cette séparation. Pour sortir du réseau XMPP, elle retire l’enveloppe XMPP, balises <e2e> comprises, afin de récupérer l’objet S/MIME multipart et de l’acheminer, en ajoutant au besoin l’enveloppe du service non-XMPP. Dans l’autre sens, elle retire l’enveloppe non-XMPP, place le même objet dans une enveloppe XMPP puis achemine la stanza. La RFC est explicite : l’objet S/MIME enveloppé doit rester immuable et la passerelle ne doit pas le modifier.

Une frontière, pas un système de sécurité complet

L’immutabilité est une instruction de protocole forte, mais elle ne prouve pas qu’une passerelle déployée la respecte. L’enveloppe ne rend pas non plus fiables tous les faits qui l’entourent. Le destinataire doit disposer de certificats et les valider ; il doit aussi décider ce qu’une signature établit sur l’identité de l’expéditeur. La RFC laisse l’inscription des certificats hors de son périmètre et demande à l’agent récepteur de fournir un mécanisme de récupération.

Sa promesse porte donc sur la préservation d’un objet protégé à travers une voie d’interopérabilité donnée, pas sur l’identité, la distribution des clés ou l’expérience utilisateur.

Le compromis opérationnel est visible : le transport opaque aide un intermédiaire à acheminer un contenu qu’il ne peut pas réécrire sans risque, mais limite sa capacité à le transformer ou à l’inspecter. Si un service exige une conversion, son point d’exécution et ses effets sur la signature deviennent décisifs. Modifier un objet couvert par la signature n’est pas une traduction neutre ; la conception renvoie cette décision aux terminaux.

Dix ans plus tard, la RFC 7165 décrivait cette approche S/MIME comme n’ayant pas connu de déploiement généralisé et citait les difficultés de gestion des clés et de traitement des objets S/MIME parmi les facteurs. Il s’agit d’un constat formulé dans un texte normatif en 2014, non d’un recensement actuel ni d’une explication unique. Il précise néanmoins la leçon historique : une frontière nette peut préserver le sens cryptographique tout en laissant difficiles le produit et la gestion des clés. La contribution durable de la RFC 3923 n’est pas d’avoir rendu les passerelles dignes de confiance.

C’est d’avoir montré que l’interopérabilité n’exigeait pas qu’elles réécrivent ce que les terminaux avaient protégé.

Sources