Résumé

  • La RFC 5365 définit un service SIP de messages instantanés en mode pager : une requête MESSAGE porte une liste plate de destinataires et une charge utile, puis le service agit comme un B2BUA spécialisé et émet une nouvelle requête MESSAGE pour chaque destinataire.
  • Le service conserve normalement la valeur From, sauf lorsque la confidentialité l’interdit, mais il ne conserve pas le tag comme si le même dialogue continuait. Il recrée aussi To, Call-ID, CSeq, Max-Forwards et Via, et décide séparément si P-Asserted-Identity ou des justificatifs d’autorisation peuvent franchir la prochaine frontière de confiance.
  • Une gouvernance sérieuse distingue donc l’auteur affiché, le principal authentifié, l’autorité d’affirmation, la décision de confidentialité, l’audience cryptographique, la charge utile copiée, la transaction nouvellement créée et la livraison observée. La ressemblance à l’écran ne constitue pas une chaîne de preuve.

Le champ From promettait une continuité humaine

Dans une conversation, voir le nom de l’auteur compte. Si Alice adresse un court message à une liste improvisée, Bob s’attend à lire Alice comme expéditrice, non le nom technique du serveur qui a multiplié les envois. La RFC 5365 protège cette continuité d’usage : la valeur du champ From de la requête sortante doit correspondre à celle de la requête entrante, sous réserve des exigences de confidentialité.

Cette règle est utile précisément parce que l’architecture n’est pas transparente. Le client envoie une requête MESSAGE multipart au service de liste, accompagnée d’une liste plate au format prévu par la RFC 4826 et de l’option recipient-list-message. Le service accepte cette opération, interprète les corps, détermine les destinataires et devient client à son tour pour produire une requête distincte vers chacun.

Le texte le qualifie de B2BUA spécialisé. D’un côté, il répond comme serveur à Alice. De l’autre, il origine comme agent utilisateur une transaction vers Bob. La conservation de From relie l’expérience de lecture à l’intention de l’émettrice ; elle n’abolit pas l’intermédiaire qui a reconstruit l’acte protocolaire.

Le premier danger de gouvernance consiste à transformer cette convention d’affichage en affirmation de sécurité. « From contient Alice » n’équivaut ni à « Bob a authentifié Alice », ni à « la preuve d’Alice a été vérifiée de bout en bout », ni même à « aucune politique intermédiaire n’a choisi cette valeur ».

La confidentialité détenait un droit de priorité

La RFC ne demande pas de recopier aveuglément le champ. Elle précise que les exigences de confidentialité s’appliquent et qu’un service de confidentialité coïmplanté prend le pas sur la fonction de liste. Le visible est donc le résultat d’une décision : conserver, anonymiser ou supprimer selon le contexte et la politique.

Le tag From n’est pas transporté comme si le même dialogue SIP se prolongeait. Ce détail paraît minuscule, mais il empêche une fausse identité de transaction. La valeur qui nomme l’auteur peut être maintenue tandis que l’élément qui identifie une extrémité de dialogue est régénéré. La syntaxe elle-même dit que continuité éditoriale et continuité protocolaire ne sont pas le même objet.

Une trace exploitable doit conserver l’entrée et la décision, pas seulement la sortie. Elle lie la valeur From reçue, le principal que le service a authentifié, l’instruction Privacy, la règle appliquée, l’existence éventuelle d’un service de confidentialité et la valeur finalement émise. Sans ces éléments, un enquêteur ne sait pas si le nom visible résultait d’une autorisation, d’une exception, d’une configuration ancienne ou d’un simple copier-coller.

La hiérarchie décisionnelle doit aussi rester observable. Si la confidentialité exige de masquer une identité, l’objectif conversationnel de montrer Alice ne peut pas l’emporter. Le produit peut préférer une interface familière ; l’autorité de divulgation appartient à la politique de confidentialité.

P-Asserted-Identity racontait une autre histoire

P-Asserted-Identity n’est pas un second champ From décoratif. Dans le modèle de la RFC 3325, il porte une affirmation d’identité à l’intérieur d’un domaine de confiance. La RFC 5365 décide de sa propagation en examinant l’origine de l’affirmation, la confiance accordée à la première destination suivante et la demande de confidentialité.

Si l’affirmation entrante provient d’une source de confiance et que le premier saut sortant est lui aussi de confiance, le service doit la propager. Si le prochain saut n’est pas de confiance et que la confidentialité a été demandée, il ne doit pas l’envoyer. Le changement d’itinéraire peut donc changer la décision sans modifier ni l’auteur visible, ni la charge utile, ni le destinataire final.

Le service peut encore créer une affirmation lorsqu’il authentifie un utilisateur et sait associer cette authentification à un URI SIP ou SIPS. Il exerce alors sa propre autorité d’affirmation. Il ne transmet pas un jeton universel dont le sens serait indépendant du domaine.

Un journal qui note seulement « PAI présent » manque l’essentiel. Il faut l’origine de la confiance, la méthode d’authentification, la règle de correspondance, la valeur de confidentialité, la classification du saut sortant et la décision finale d’inclusion. Ces attributs ne doivent pas être réduits à un booléen global nommé « utilisateur vérifié ».

Le domaine d’authentification arrêtait certains justificatifs

Les champs Authorization et Proxy-Authorization montrent la même séparation sous un autre angle. Lorsqu’ils répondent au domaine du service de liste MESSAGE, celui-ci ne devrait pas les recopier dans la requête vers Bob. Le justificatif a permis d’entrer chez l’intermédiaire ; il n’autorise pas automatiquement une ressource située après lui.

Lorsque le champ concerne un autre domaine, la RFC prévoit au contraire de conserver la valeur correspondante. La décision dépend du realm, non du fait que les mots du message soient les mêmes.

Cette règle prévient deux erreurs opposées. Copier partout peut divulguer un secret ou présenter un justificatif à la mauvaise autorité. Tout supprimer peut empêcher une authentification légitime destinée à une autre frontière. Le service doit classer le domaine, non appliquer une fonction indifférenciée « nettoyer les headers ».

La preuve opérationnelle ne doit jamais enregistrer le secret brut. Elle peut conserver le type de justificatif, un identifiant non réversible, le realm déclaré, la règle de correspondance, la décision de suppression ou de copie et le contexte de confiance de la destination. On obtient ainsi une explication sans créer une nouvelle fuite dans les journaux.

Le message sortant était une nouvelle transaction

Pour chaque destinataire, le service devrait créer un nouveau To, un nouveau Call-ID et un compteur CSeq séparé. Il initialise Max-Forwards et ajoute son propre Via. La Request-URI ne désigne plus le service de liste mais le destinataire canonique concerné.

Ces transformations ne sont pas des opérations de présentation. Call-ID et CSeq participent à l’identité et à l’ordre des échanges ; Via organise le retour des réponses ; Max-Forwards fixe un nouveau budget contre les boucles. La frontière crée une action nouvelle autour d’un contenu qui peut rester égal.

Un tableau de bord qui recherche toutes les réponses sous le Call-ID d’Alice perd les transactions enfants. Un tableau de bord qui ne garde que les nouveaux Call-ID perd leur origine commune. La bonne structure relie une exécution parente à une opération intentionnelle par destinataire, puis à chaque tentative concrète.

Ce lien doit être interne et stable. Il ne doit pas réutiliser un identifiant protocolaire en lui faisant dire davantage que ce qu’il signifie. L’identifiant d’exécution explique la filiation ; le Call-ID décrit la transaction SIP observée sur un côté de la frontière.

Une enveloppe chiffrée avait une audience précise

Une requête multipart peut contenir un corps de sécurité S/MIME chiffré pour le service de liste. Bob ne possède pas nécessairement la clé correspondante. La RFC 5365 exige que le service ne copie pas vers les destinataires un corps de sécurité qui lui était adressé.

Cette exigence réfute l’idée naïve selon laquelle le serveur doit reproduire tous les octets. Il doit reconnaître l’audience cryptographique, consommer ce qui appartient à son propre traitement et construire un ensemble de corps approprié à la sortie.

Les autres corps, texte ou image par exemple, sont normalement copiés. Après retrait de la liste et des éléments de sécurité, s’il ne reste qu’un corps, l’enveloppe multipart/mixed doit disparaître. Le sens utile peut être préservé alors que les frontières MIME, les dispositions et la forme binaire de la requête changent.

La vérification pertinente travaille au niveau des composants : type de média, hash de la partie utile, transformations autorisées, corps retiré avec sa raison et corps ajouté avec sa nouvelle audience. Comparer la requête entière octet par octet rejetterait une transformation conforme ; comparer seulement le texte affiché manquerait une pièce jointe modifiée.

L’historique des destinataires était fabriqué pour le lecteur

Le service peut ajouter un corps recipient-list-history afin de permettre des fonctions telles que répondre à tous. Cet historique suit les règles de la RFC 5364 : les entrées To et Cc non anonymes peuvent être présentées, tandis que Bcc et les destinataires anonymisés demandent un traitement distinct.

Il ne s’agit pas de la liste initiale copiée intacte. C’est une vue créée pour un destinataire après application de règles de copie et d’anonymat. La RFC recommande de la chiffrer pour le récepteur. Bob et Carol peuvent donc recevoir la même charge utile conversationnelle mais des vues de participants qui n’ont ni le même contenu ni la même audience.

Cette construction possède sa propre provenance. Le système doit retenir la version de liste d’entrée, la politique RFC 5364 appliquée, les exclusions, le hash de la vue, la clé ou l’identité d’audience utilisée et l’association avec le destinataire. La bonne livraison du texte ne prouve pas la bonne confidentialité de l’historique.

La présente analyse ne remplace pas celle de la RFC 5364. Elle montre la frontière de la RFC 5365 : le B2BUA crée autour de la charge utile un nouveau corps de divulgation, sous une nouvelle responsabilité.

Un paramètre d’URI ne pouvait pas changer la nature du service

Un URI SIP peut porter des composants d’en-tête après un point d’interrogation. Le service peut honorer certains de ces composants séparément, par exemple une préférence Accept-Contact. Le composant spécial body ne doit pas fournir une charge utile alternative et peut être écarté.

Un URI peut aussi contenir un paramètre de méthode. La règle est nette : le service de liste MESSAGE produit uniquement des requêtes MESSAGE et doit ignorer un paramètre qui demanderait une autre méthode.

La liste apporte donc des indications, pas une délégation illimitée. Une entrée ne peut pas transformer discrètement un service de messages en générateur d’INVITE ou d’une autre action. Le contrat du service reste l’autorité supérieure.

La trace devrait énumérer les composants présents, ceux qui ont été acceptés, refusés ou ignorés et la règle invoquée. Autrement, l’émetteur peut croire qu’une préférence a été appliquée, tandis que le destinataire reçoit un header dont l’origine se confond avec une politique du serveur.

Le 202 attestait une prise en charge, pas une remise

Après réception, le service répond 202 Accepted. La RFC avertit expressément que ce statut ne renseigne pas sur la réussite des requêtes MESSAGE générées. Il signifie que l’instruction a été reçue et que le service va essayer.

L’accusé n’est pas faible ; son objet est limité. Il clôt une étape asynchrone avant que toutes les routes, réponses et expériences utilisateur soient connues. Le statut de livraison reste hors du périmètre défini par la RFC 5365.

Si la livraison compte, il faut d’autres observations : création de la transaction sortante, réponse SIP aval, reçu applicatif éventuel, puis preuve d’un effet côté terminal. Aucun de ces éléments n’est contenu rétroactivement dans le 202.

La RFC 5363 voisine traite plus largement de la pluralité des résultats. Ici, le point distinct est que le serveur qui préserve la charge utile est aussi celui qui reconstruit l’identité, la confidentialité, l’authentification et la transaction dont ces résultats dépendront.

Le registre normalisait des noms, non des exécutions

L’IANA enregistre l’option recipient-list-message et les dispositions de liste associées. Cette standardisation permet à deux implémentations de reconnaître une capacité et des types de corps. Elle ne prouve ni le déploiement correct du service, ni la légitimité d’une affirmation d’identité, ni la livraison d’un message particulier.

La RFC 5365 a été publiée en octobre 2008 sur la voie Standards Track. La RFC 3851 est ensuite devenue obsolète dans la lignée S/MIME, notamment avec la RFC 8551. Pour une implémentation actuelle, le choix cryptographique doit suivre les spécifications à jour ; la leçon architecturale demeure que toute protection désigne une audience et une autorité précises.

La note de Lu Heng sur la spécification initiale minimale offre ici un cadre déclaré : normaliser le plus petit contrat partagé, puis laisser les décisions futures aux acteurs qui disposent de l’information locale. L’option et les formats sont partagés ; la confiance, le realm, la confidentialité et la preuve du résultat restent locaux.

Sa note sur les couches de réalité ajoute une discipline. Un hash égal démontre une continuité symbolique de la charge utile. Il ne démontre ni une transaction identique, ni une autorité identique, ni une remise vécue. Les notes servent de lentilles d’analyse ; les RFC et le registre IANA portent les faits protocolaires.