Du respect de la loi

C'est un point sur lequel je tiens à insister, je l'ai évoqué cent fois avec les gens qui venaient suivre les débats à l'Assemblée Nationale: FDN appliquera la loi, toute la loi, mais rien que la loi. Et, en dehors de la loi, il n'y a que la signature d'une convention, validée par le Bureau de l'association, et qui ne soit pas dénoncée par l'Assemblée Générale, qui puisse nous engager. En particulier, FDN n'étant pour le moment membre d'aucun organe représentatif, d'aucune fédération[1], ne peut être engagée que par sa propre signature.

La loi, plus exactement un décret d'application pris en vertu de la loi, et (selon nous) en dehors des formes légalement requises, indique que l'interconnexion entre la HADOPI et les FAIs se fait selon les règles d'une convention signée, ou à défaut, d'un arrêté publié par les ministres concernés. Ça ne dit pas que les FAIs doivent s'empresser d'aller quémander une convention. Ça dit que si la HADOPI veut aller plus vite que la prise d'un arrêté interministériel, il est de bon ton d'aller discuter avec les FAIs.

Pour s'en convaincre: en l'absence de convention, la mission de FDN, qui est depuis 1992 de permettre à ses adhérents d'accéder à Internet, est parfaitement remplie. À l'opposé, celle de la HADOPI ne l'est pas, ou est pour le moins retardée.

Donc, évoquer dans une interview à la presse (et pas dans le contexte moitié-potache moitié-pamphlétaire d'un blog) que nous pourrions n'être pas scrupuleusement attentifs au respect de la loi, c'est à deux doigts de la diffamation.

Un président d'association qui s'exprime sur un blog peut se permettre certaines moqueries, tant qu'elles restent dans les bornes. Par contre, il me semble qu'un secrétaire général d'une Haute Autorité Indépendante est tenu à un tout petit peu plus de rigueur intellectuelle quand il s'exprime dans la presse...

De la bonne volonté

Toutefois, dans un esprit d'apaisement, et par habitude du logiciel libre et des contenus générés par les utilisateurs, nous allons proposer ici ce que pourraient être les termes d'une convention entre FDN et la HADOPI[2] sur l'interconnexion nécessaire pour l'identification des adresses IP.

  1. L'interconnexion se ferait en HTTPS[3], sur le port 443, vers une adresse IP sur les serveurs de l'association réservée à cet usage, et chiffrée par un certificat émis par notre autorité de certification[4]
  2. L'accès à l'interface automatique serait bien entendu uniquement via un échange de login et de mots de passe, permettant un première forme d'authentification[5].
  3. Les requêtes se devraient d'être transmises par la HADOPI depuis une (ou des) adresse IP explicitement indiquées comme y étant autorisées[6]. La HADOPI s'engageant à avoir une configuration similaire de son côté, n'autorisant les requêtes que depuis les IPs spécifiées par FDN.
  4. Les requêtes auraient la forme de fichiers XML simples[7]. Basiquement une DTD qui prévoit un élément englobant, typiquement requetes, contenant une liste d'éléments simples, typiquement requete, au contenu vide, ayant chacune trois attributs (identifiant unique de requête[8], adresse IP concernée, date concernée, au format ISO). La balise englobante devra bien entendu porter plus d'attributs (identifiant du FAI concerné, identifiant de l'émetteur de la requête, numéro de série du fichier, nombre de requêtes contenues dans le fichier, etc).
  5. Les requêtes seraient à déposer par un upload HTTP standard (donc, en POST, avec du form-multipart). Les réponses étant disponibles en GET, le plus simplement du monde, dans les minutes ou heures qui suivent.
  6. Les fichiers de requêtes seraient chiffrés avec une clef publique fournie par FDN, et signés avec une clef privée propre à la HADOPI, indiquant donc que le fichier vient bien de la bonne source, et est bien à destination du bon FAI[9].
  7. Les fichiers de réponses seraient eux aussi en XML simple, avec cependant un peu plus d'attributs pour l'élément interne (adresse postale, nom, prénom, adresse mail quand elle est connue, etc), contenant les coordonnées associées à l'abonnement Internet correspondant à cet enregistrement horodaté[10].
  8. Les fichiers de réponses seraient chiffrés avec la clef publique de la HADOPI (complémentaire de celle ayant servi à signer les requêtes) et signés par la clef privée de FDN[11].

Bien entendu, une facture, portant les références des requêtes, serait communiquée à la HADOPI, immédiatement après que les requêtes auraient été traitées, appliquant les barêmes en vigueur. Les factures une fois réglées, les fichiers de requêtes signés-chiffrés seraient alors détruits[12].

Du logiciel libre

Cet embryon de spécification est, bien entendu, libre de droits. Si la HADOPI le souhaite, FDN se fera un devoir de transformer cet embryon (cependant déjà clair) en un projet de cahier des charges. Il serait alors, lui aussi, sous une licence permettant sa libre réutilisation (probablement CC-by).

Enfin, si une telle interconnexion venait à être réalisée, la partie FAI (implémentée par FDN[13], elle serait publiée elle aussi sous une licence permettant une libre ré-utilisation (probablement GPL[14]).

Une telle approche permettrait d'ailleurs d'avoir des propositions techniques valables pour l'ensemble de FAIs, basées sur une spécification simple, connue, reconnue comme sécurisée, et aisément implémentable dans n'importe quel langage moderne.

Notes

[1] Ça, ça devrait changer, lors de la création de la fédération d'opérateurs associatifs, mais je serai surpris qu'elle suive une direction différente. Le monde associatif est trop complexe et foisonnant pour être mis en coupe réglée.

[2] C'est un des points sur lesquels je me perd, et je n'ai pas le courrage d'aller vérifier exactement dans le texte. Je ne sais plus si c'est la HADOPI qui est interconnectée avec les FAIs et en charge de transmettre les dossiers à la CPD, ou si c'est la CPD qui réalise ce traitement dans le cadre de son instruction du dossier. Je suppose ici que c'est la HADOPI, le raisonnement serait à transposer directement en cas d'erreur de ma part,

[3] Forcément, il circulera sur cette interface des données sensibles, qui ne doivent donc pas transiter en clair. Le chiffrement des fichiers ne chiffre que les fichiers eux-mêmes, et pas toute la négociation protocolaire HTTP. Le SSL est donc de rigueur.

[4] Pourquoi notre propre autorité de certification? Pour être absolument certain que le certificat ne puisse être révoqué que par nous, qu'il ne dépende que de nous, et donc qu'il n'engage que nous.

[5] Bien entendu, ce n'est pas de la haute sécurité, mais ça évite simplement de recevoir des fichiers farfelus. Et n'exonère pas de chiffrer et signer les données échangées

[6] Comme il a été dit en commentaire du billet précédent, certainement pas dans le but d'identifier l'émetteur, mais seulement dans le but d'écarter des usurpations d'identité grossières, et par soucis de protéger la machine de FDN d'un certain nombre d'attaques possibles.

[7] Les données échangées sont très simples, donc rien n'exige de mettre en branle des usines à gaz comme XMLRPC ou SOAP. Du XML tout ce qu'il y a de plus bête est bien plus léger à traiter, typiquement manipulable en XPath, ou pour les puristes à grands renfort d'expressions régulières.

[8] Au libre choix de la HADOPI, typiquement un numéro de dossier ou quelque chose qui ressemble.

[9] Sur des systèmes automatisés, surtout pendant les phases initiales, ça s'est déjà vu, des fichiers qui se mélangent. Et il serait innacceptable qu'un fichier à destination de FDN puisse être lu par un autre FAI, ou que FDN puisse lire un fichier à destination d'un autre FAI.

[10] C'est une nuance importante dans le fonctionnement de FDN, il a les adhérents, d'une part, qui sont les gens qui ont le droit de vote en Assemblée Générale, et il y a d'autre part les abonnés qui sont titulaires d'un login permettant de se connecter sur nos systèmes. Il est fréquent qu'un adhérent ait plusieurs abonnements (pour ses parents, ses enfants, etc).

[11] Pour les spécialistes en sécurité, rien que de très banal, signature et chiffrement par clefs asymétriques, bref du GPG de base.

[12] Il est évident que l'association se doit de les conserver pour justifier, autant que de besoin, de sa bonne foi dans l'émission de la facture, et pour pouvoir corriger en cas d'erreur.

[13] Et dont les frais de développement seraient à la charge de la HADOPI, en vertu des jurisprudences applicables, puisque ces développements ne sont pas nécessaire à la satisfacton de l'objet statutaire de l'association mais seraient réalisés dans le cadre d'une contrainte légale.

[14] Le développement étant financé par le contribuable, au final, il nous semble absolument évident que le code résultant ne peut pas ne pas être sous une licence libre.