Résumé

  • La RFC 3924 a été publiée comme architecture Cisco à titre informatif, et non comme norme Internet ; la note de l’IESG invitait à la prudence quant à sa mise en œuvre et à son déploiement.
  • Le texte excluait les obligations juridiques propres à chaque pays : sa publication ne pouvait donc pas autoriser une interception.

L’avertissement placé au-dessus de l’architecture

Un numéro RFC peut ressembler à un certificat de normalisation. La RFC 3924 rappelait que l’apparence ne suffit pas. Publié en octobre 2004, le document s’intitulait Cisco Architecture for Lawful Intercept in IP Networks et portait les noms de trois auteurs de Cisco Systems. Son statut était « Informational ». Avant même le résumé, une note de l’IESG précisait qu’il ne pouvait prétendre à aucun niveau de norme Internet et recommandait la prudence concernant sa mise en œuvre et son déploiement.

Cette note allait au-delà d’une simple étiquette. Elle expliquait que le RFC Editor avait choisi de publier le document à sa discrétion et que la décision n’avait pas été fondée sur un examen de l’IETF en matière de sécurité, de contrôle de congestion ou d’interaction avec les protocoles déployés. Le texte figurait donc dans la série des RFC sans bénéficier du statut d’examen ni de la portée normative souvent associés à une norme Internet.

Cette distinction compte parce que la RFC 3924 traitait d’un sujet politiquement et juridiquement sensible. Son résumé présentait une architecture Cisco parmi d’autres, dotée d’un petit ensemble d’interfaces communes. Le même passage précisait qu’elle ne traitait pas des exigences ou obligations légales propres à un pays. L’introduction réaffirmait cette limite : il s’agissait d’une méthode, d’autres pouvaient exister, et les exigences qui motivaient le modèle ne créaient pas, à elles seules, d’obligations pour les fournisseurs de services ou de matériel.

L’IESG renvoyait à la RFC 2804, la position de l’IAB et de l’IESG publiée en 2000 sur l’écoute des communications, pour expliquer pourquoi de telles architectures relevaient de fournisseurs plutôt que de la normalisation par l’IETF. Cette référence situe la RFC 3924 dans l’histoire du processus normatif. Quatre ans auparavant, l’IETF avait consigné la question institutionnelle de savoir si les protocoles devaient être conçus pour faciliter l’interception.

La RFC 3924 n’a pas tranché ce débat en devenant une norme ; sa note a plutôt rendu la limite visible : la publication dans une série d’archives n’équivaut pas à une normalisation par la communauté.

Il ne s’agit pas d’affirmer que l’architecture a été utilisée ou ne l’a pas été, ni de juger le droit d’un pays. La RFC ne prouve aucun déploiement actuel et sa publication ne démontre pas qu’une interception particulière ait été autorisée, sûre ou conforme. Ce sont des questions distinctes pour lesquelles le document ne fournit volontairement pas de preuve.

L’importance historique de la RFC 3924 tient en partie à cette séparation. Une conception technique peut être conservée et discutée sans devenir une exigence de l’IETF. Un vocabulaire commun ne détermine pas quelle autorité publique peut demander une action, quelle procédure juridique est requise, comment une personne peut la contester, ni quelles responsabilités en découlent. L’avertissement de l’IESG n’a pas exclu le document de la série des RFC ; il a intégré ses limites au dossier.

Vue sous cet angle, la RFC 3924 est une pièce utile de l’histoire de la gouvernance d’Internet : non parce qu’elle aurait établi une règle universelle d’interception, mais parce que sa publication montre comment la série des RFC peut conserver une proposition fournisseur tout en signalant qu’elle n’est ni une norme, ni une approbation de sécurité de l’IETF, ni un énoncé de droit.

Sources