Résumé

  • Dans RFC 9796, verified=true atteste que l’acteur ayant inséré un champ Call-Info a vérifié l’information représentée par ce champ ; le terminal doit encore avoir une relation de confiance authentifiée avec cet acteur.
  • Le paramètre integrity peut prouver l’égalité entre une ressource reçue et un condensat annoncé. Il ne prouve ni l’origine, ni l’actualité, ni l’affichage, ni la légitimité de l’appel.
  • La chaîne de preuve doit distinguer validation PASSporT, décision de politique, traduction en Call-Info, transport, récupération, rendu, attention humaine et résultat.

Imaginons non pas le début de la chaîne, mais son dernier mètre. Un téléphone reçoit une requête SIP et affiche une identité enrichie : nom, motif de l’appel, peut-être une image, avec un indicateur vert. Le téléphone n’a pas nécessairement ouvert le jeton signé qui se trouvait en amont. Il a reçu l’interprétation d’un opérateur situé sur son interface de confiance.

C’est précisément l’utilité de RFC 9796. Un fournisseur de terminaison peut vérifier des Rich Call Data protégées selon RFC 9795, puis exposer certains résultats dans Call-Info à un équipement incapable d’effectuer lui-même toute la validation. La délégation économise une duplication complexe. Elle ne supprime pas le délégataire.

La valeur verified=true ne signifie donc pas « cet appel est vrai ». Elle signifie que la partie ayant ajouté ce champ particulier a mené avec succès la vérification de l’information qu’il représente. La confiance du destinataire dépend de sa relation avec cette partie. Le qualificatif porte sur un champ, pas sur toute la carte, encore moins sur l’intention future de la personne qui parle.

Partir du terminal révèle la chaîne cachée

Pour remonter la chaîne, il faut séparer les actes. RFC 8224 place l’identité téléphonique STIR dans SIP. RFC 8225 définit le PASSporT, un jeton signé construit dans la famille de RFC 7519. RFC 9795 y protège les déclarations RCD et les condensats de ressources. RFC 9796 traite ensuite la traduction de résultats retenus vers Call-Info.

Chacune de ces étapes produit une conclusion différente : un jeton était présent ; sa signature a été validée ; une revendication correspondait ; la politique locale l’a acceptée ; un acteur a créé un champ ; le terminal a authentifié cet acteur ; une ressource a été téléchargée ; son condensat concordait ; elle a été affichée ; l’utilisateur l’a remarquée ; l’appel s’est révélé légitime. Aucune flèche ne doit être remplacée par le mot « donc » sans reçu intermédiaire.

Cette prudence ne rabaisse pas la cryptographie. Elle lui rend sa portée exacte. Une signature valide répond à une question de protection et d’autorité sur un objet signé. La décision de l’accepter reste une décision locale. La transformation qui suit crée un nouvel objet et un nouveau gardien.

La fiche n’est pas un fait atomique

RFC 3261 fournit le socle SIP et l’en-tête Call-Info. Un nom d’affichage ordinaire dans From n’est pas, par sa seule présence, une identité garantie. RFC 9796 ajoute call-reason, verified, integrity et purpose=jcard pour rendre la présentation enrichie plus explicite.

Le format jCard vient de RFC 7095 et utilise les règles JSON de RFC 8259. Le profil RCD n’autorise qu’un objet d’entité et demande la cohérence entre les noms, images, logos, From, P-Asserted-Identity et icônes qui se recouvrent. Cette exigence reconnaît une réalité simple : une fiche d’appel assemble plusieurs affirmations, qui peuvent avoir des provenances différentes.

La jCard peut être embarquée dans une URI data:, placée dans un corps MIME désigné par une URI cid: selon RFC 2392, ou récupérée auprès d’une source dont l’intégrité peut être vérifiée, par exemple en HTTPS dans un domaine validé. Le chemin choisi modifie la disponibilité, la garde et le moment de la vérification. Il ne modifie pas magiquement la portée de verified.

Une forme compacte permet même d’indiquer la vérification d’un nom avec une URI data: nulle et purpose=jcard. Ce raccourci ne transporte pas une grande carte visible. Il transporte encore le jugement d’un acteur déterminé. Si l’enregistrement opérationnel oublie cet acteur, le terminal ne conserve que le symbole.

Un condensat protège une ressource, pas son récit

Le paramètre integrity associe un algorithme et un condensat à la ressource désignée par une URI. SHA-256, SHA-384 et SHA-512 doivent être pris en charge. Une concordance démontre que les octets récupérés sont ceux qui ont été annoncés. C’est une garantie forte et limitée.

Elle ne dit pas qui contrôlait l’image au moment de sa création, si elle est récente, si le serveur répondra avant la sonnerie, si la politique du terminal autorise son affichage, ni si l’utilisateur la regardera. Elle ne rend pas vrai le motif de l’appel. L’intégrité des octets et la légitimité d’une conversation vivent dans des couches différentes.

Le paramètre call-reason le montre encore autrement. Il est facultatif, bref, susceptible d’être tronqué et son affichage n’est pas garanti. La façon dont l’appelant le choisit sort du champ de la norme. Une phrase comme « votre livraison » peut être utile sans devenir une preuve de livraison. De même, les priorités de ressources SIP décrites dans RFC 7852 portent une sémantique opérationnelle définie ; elles ne remplacent pas l’autorisation et le contrôle qui leur donnent effet.

La frontière doit résister aux réseaux intermédiaires

RFC 9796 demande qu’une seule version cohérente des RCD soit présentée dans Call-Info. Les acteurs supplémentaires du chemin ne doivent ni modifier cette version ni ajouter des champs RCD contradictoires. Sans STIR ou autre mécanisme de protection, une modification à travers des réseaux interconnectés non fiables ne peut pas être supposée détectable.

Cette règle n’est pas cosmétique. Quand un intermédiaire réécrit une image ou un nom, le résultat n’est plus exactement l’objet que le vérificateur précédent avait accepté. Un système responsable consigne l’entrée, le vérificateur, la politique, la transformation, le champ produit et le pair destinataire.

Les pièces de publication permettent de contrôler la norme elle-même : versions texte et XML, notice RFC Editor, errata, historique IETF et registre IANA des paramètres SIP. Elles ne prouvent aucune mise en œuvre précise chez un opérateur ou dans un téléphone.

La doctrine du code réellement exécuté oblige donc à demander quel composant a comparé quelle donnée. La spécification partagée minimale fixe un langage commun, sans interdire une politique locale plus exigeante. Enfin, la séparation des couches de réalité empêche qu’une icône d’interface absorbe les réalités cryptographiques, administratives et humaines qu’elle résume.

La conclusion n’est pas de se méfier de toute fiche enrichie. Elle est de conserver la délégation visible. RFC 9796 construit un pont utile vers les terminaux ; un pont digne de confiance garde la trace de ses deux rives.

Sources