Résumé

  • La RFC 5379 ne définissait pas un niveau global de nettoyage : elle associait chaque priv-value à des en-têtes SIP et paramètres SDP déterminés, avec des actions distinctes.
  • Un champ non visé pouvait néanmoins devoir être retiré ou traduit pour une autre cause, par exemple une signature devenue invalide ou une correspondance de Call-ID créée auparavant.
  • La preuve complète doit distinguer la demande, le périmètre autorisé, la règle indépendante, l’action exécutée, la continuité sémantique et l’exposition réellement observée.

Le sens politique d’une case vide

Une équipe de sécurité reçoit un tableau. Les lignes portent des noms d’en-têtes ; les colonnes portent user, header, session, id et history. Certaines cellules disent supprimer, ne pas ajouter ou anonymiser. D’autres restent vides. L’ingénieur pressé peut lire le vide comme « à décider localement ». L’ingénieur prudent le lit comme « cette valeur ne donne pas cette compétence ».

C’est la distinction centrale de la RFC 5379. Le document fut publié en février 2010 dans l’Independent Stream, avec le statut Informational. Il ne créait pas un nouveau mécanisme normatif. Il cherchait à rendre praticables des règles issues des RFC 3323, 3325 et 4244, dont les interprétations divergentes avaient déjà produit des problèmes d’interopérabilité.

Son tableau était donc moins un catalogue de transformations qu’une carte d’autorité. La présence d’un en-tête Privacy prouvait qu’un traitement avait été demandé. Elle ne prouvait ni que chaque champ du message relevait de cette demande, ni que le traitement avait réussi, ni même que l’appel demeurait utilisable.

Les valeurs ne formaient pas une échelle

user, header et session ne signifiaient pas faible, moyen et fort. Ils désignaient des surfaces différentes. user concernait des informations insérées par l’utilisateur ; header, des informations de signalisation ajoutées par le réseau ; session, des données de description de session. id ciblait P-Asserted-Identity dans le modèle de domaine de confiance de la RFC 3325. history portait sur History-Info. none et critical réglaient encore d’autres décisions.

La matrice détaillait ensuite les actes. Un Call-Info pouvait être supprimé ou ne pas être ajouté selon la valeur. Contact pouvait être anonymisé pour un périmètre mais pas pour tous. History-Info répondait à plusieurs valeurs. P-Asserted-Identity avait son propre rapport à id et header. La direction du message comptait également : requête, réponse, ou les deux.

Pour le SDP, la RFC identifiait les lignes c, m, o, i, u, e et p sous Privacy:session. Ce choix limité empêche une erreur de langage : la « session » n’est pas tout ce qui participe à l’appel. Le terme sélectionne un ensemble décrit, pas une permission illimitée sur le paquet.

Un moteur correct doit donc interpréter une demande comme un tuple : valeur, type de message, champ, opération, condition et source normative. Réduire ce tuple à un booléen privacy=true supprime précisément l’information nécessaire pour agir sans casser le protocole.

Les non-cibles pouvaient sembler plus sensibles que les cibles

La RFC 5379 nommait explicitement Identity/Identity-Info, Path, Replaces, Route, Service-Route et Target-Dialog comme non-cibles des valeurs énumérées. Le service ne devait pas les anonymiser ou les modifier simplement parce qu’un priv-value apparaissait.

La formulation est importante : « sur le fondement de cette valeur ». Elle ne dit pas que ces champs sont dénués de sensibilité. Path peut révéler un domaine visité. Route expose des relais. Identity-Info peut pointer vers le certificat d’un signataire. Replaces et Target-Dialog contiennent des identifiants qui relient des dialogues.

Mais la sensibilité ne suffit pas à créer la compétence. Path permet d’atteindre un agent enregistré dans un domaine visité. Le masquer sans substitut fonctionnel peut rendre l’utilisateur injoignable. Route impose un passage par des proxys déterminés ; l’anonymiser au hasard détruit la route qu’il encode. Replaces permet à un nouveau dialogue d’en remplacer un autre ; casser son identifiant transforme une intention valide en échec silencieux.

Le contrôle de confidentialité ne doit donc pas demander seulement ce qui pourrait révéler quelque chose. Il doit demander quel acteur a demandé quel traitement, quelle spécification lui donne portée sur ce champ et quelle propriété du protocole doit rester vraie après la transformation.

Une non-cible pouvait changer pour une cause indépendante

L’autre excès consiste à transformer la liste des non-cibles en interdiction absolue. La RFC 5379 montre pourquoi cette lecture échoue.

Dans son exemple historique fondé sur la RFC 4474, Identity protégeait par signature From, To, Call-ID, CSeq, Date, Contact et le corps. Si un service modifiait légitimement un de ces éléments pour fournir la confidentialité, la signature cessait d’attester le message transmis. Identity n’était pas la cible directe du jeton, mais conserver une preuve devenue fausse aurait été pire. Sa suppression répondait à l’invalidation de l’intégrité, non à un pouvoir global du jeton.

La RFC 4474 a depuis été remplacée par la RFC 8224. L’exemple reste utile comme modèle de gouvernance : lorsqu’une transformation invalide une preuve dérivée, le système doit retirer ou régénérer la preuve et consigner le lien causal. Il ne doit pas réécrire l’histoire en disant que la demande initiale ciblait ce qu’elle ne ciblait pas.

La traçabilité devrait donc produire deux lignes : le jeton a autorisé la modification du champ protégé ; cette modification a invalidé l’objet d’intégrité, retiré sous une règle distincte. Sans cette séparation, l’auditeur ne peut plus déterminer si le service a respecté une dépendance ou dépassé son mandat.

Le Call-ID transformait un acte local en dette future

Modifier Call-ID ne finit pas avec le message sortant. Le service crée une correspondance entre l’ancien identifiant et le nouveau. D’autres messages pourront transporter cet identifiant dans In-Reply-To, Replaces, un paramètre replaces ou Target-Dialog. Le service doit conserver la relation, rester sur le chemin pertinent et traduire dans le bon sens.

Or le message ultérieur peut ne porter aucun en-tête Privacy. Il peut venir d’un autre participant. La traduction demeure nécessaire, mais son autorité n’est plus une nouvelle demande de confidentialité. Elle provient de l’obligation de cohérence créée par la première transformation.

Les scénarios de transfert de la RFC 5379 montrent la panne. Un INVITE arrive avec C1, puis ressort avec C2. Un REFER ou un nouvel INVITE tente de remplacer le dialogue en citant C1 ou C2. Si le même service ne voit pas l’opération, ou s’il ne sait pas restaurer la valeur attendue, l’établissement du dialogue échoue. Tous les messages peuvent être bien formés ; la sémantique, elle, est perdue.

Cette dette doit être possédée. Le composant qui transforme Call-ID doit préciser la durée de la table, les chemins couverts, les messages corrélés, la récupération après redémarrage et le comportement lorsque la correspondance manque. Il ne peut déclarer son travail achevé au seul vu du paquet qu’il vient d’émettre.

La politique locale devait signer ses propres actes

La RFC admettait que l’implémentation et la politique réseau influencent la manière d’obscurcir les données. Elle reconnaissait aussi que certaines informations sensibles, pourtant hors cible, pouvaient nécessiter un traitement. Cette souplesse ne rendait pas le jeton responsable de toutes les décisions locales.

Un opérateur peut masquer sa topologie. Un domaine de confiance peut retirer P-Asserted-Identity à sa frontière. Un service peut supprimer une signature invalide. Un moteur de corrélation peut restaurer Route après avoir transformé Record-Route. Chacun de ces actes possède une origine différente.

Une seule mention « confidentialité appliquée » efface l’origine, le but et la possibilité de contester. La politique locale doit donc se nommer. Elle doit indiquer son propriétaire, sa version, son champ, son motif et la modification réalisée. La réparation de corrélation doit référencer la transformation antérieure. La demande de l’utilisateur doit rester la preuve de ce qu’il a demandé, sans absorber les choix de l’institution.

Cette discipline suit une règle plus générale : un enregistrement décrit une réalité limitée. L’agrandir par vocabulaire ne lui donne pas d’autorité supplémentaire. Le jeton est une instruction bornée ; le journal du service est une trace d’exécution ; le résultat du dialogue et l’exposition mesurée appartiennent à d’autres couches.

L’appel réussi ne prouvait pas la confidentialité

Un appel peut aboutir tout en divulguant l’information que l’utilisateur voulait cacher. Il peut aussi protéger l’identité vis-à-vis du destinataire tout en la révélant au service intermédiaire. Les adresses de média, les journaux, les certificats, les champs oubliés et les systèmes de taxation créent des observateurs distincts.

Une affirmation de résultat doit donc nommer l’information, l’observateur, la période et le canal. Dire « l’identité a été cachée » sans dire à qui revient à transformer un souhait en verdict. De même, la disparition d’un en-tête ne prouve pas que la donnée n’est plus corrélable ailleurs.

Le test utile suit le chemin. Il capture les messages avant et après chaque service, exécute l’enregistrement, l’établissement initial, les réponses, le transfert, le rappel et la terminaison. Il vérifie à la fois l’absence de divulgation vers l’observateur choisi et la conservation des fonctions attendues.

La conformité au tableau soutient ce test ; elle ne le remplace pas. La RFC 5379 organisait des comportements d’implémentation. Elle n’émettait pas un reçu universel de confidentialité.

Le statut du document faisait partie du résultat

Le texte était Informational et issu de l’Independent Stream. Il disait explicitement que son langage normatif provenait des RFC existantes et qu’il n’ajoutait pas de comportement normatif. Cette modestie documentaire est une information opérationnelle.

Une équipe peut utiliser la RFC 5379 pour comprendre les interactions et réduire les divergences. Elle doit néanmoins retrouver la spécification qui fonde chaque obligation. Elle doit aussi noter que la RFC 4244 a été remplacée par la RFC 7044 et la RFC 4474 par la RFC 8224. L’exemple historique éclaire un mécanisme ; il ne dispense pas de vérifier l’état actuel.

Le registre IANA fournit encore une couche séparée. Il établit les noms et références enregistrés. Il ne prouve pas qu’un produit prend en charge une valeur, qu’il la traite correctement, qu’il maintient l’état nécessaire ou qu’il obtient le résultat promis.

Le registre de preuve minimal

Pour chaque message, un service auditable devrait conserver :

  • l’émetteur, la direction et la demande reçue ;
  • chaque valeur Privacy et sa spécification applicable ;
  • le champ sélectionné et la cellule de matrice correspondante ;
  • toute règle locale ou obligation de protocole distincte ;
  • l’état avant et après la suppression ou transformation ;
  • les preuves d’intégrité invalidées ou régénérées ;
  • les correspondances d’identifiants et leur durée ;
  • les messages ultérieurs ayant consommé ces correspondances ;
  • le résultat du routage, du dialogue, du transfert et du média ;
  • le test d’exposition pour chaque observateur pertinent.

Cette chaîne empêche une case vide de devenir une délégation implicite. Elle empêche aussi le succès syntaxique de masquer un échec fonctionnel. La confidentialité cesse d’être une étiquette et devient un enchaînement contrôlable.