TrustedBird, un client de messagerie de confiance
Laurent Cailleux
Ministère de la défense, Direction Générale de l'Armement, CELAR
La roche marguerite, BP 57419, 35174 Bruz CEDEX
Résumé
La messagerie est devenue le moyen de communication le plus utilisé dans les entreprises. Cependant, sa déclinaison professionnelle impose la mise en œuvre de services et de mécanismes exigés par ce type d’utilisation. Citons, par exemple, le marquage du type d’échange (privé, professionnel, officiel …) imposé parfois dans le cadre du droit à la correspondance privée, les services étendus de sécurité, les besoins d’archivage, de distribution, de suivi ou de renseignement du niveau de sensibilité des messages. Fort de ce constat et compte-tenu du besoin exprimé par le ministère de la défense, la direction générale de l'armement (DGA), en partenariat avec la direction générale des systèmes d'information et de communication (DGSIC), a initié le projet TrustedBird. Outre l’objectif de répondre à ces besoins, TrustedBird a aussi l’ambition d’apporter des services de sécurité (reçu signé, entêtes sécurisés...) et d’offrir de nouveaux services (corrélation temporelle des avis, XIMF...) au sein d'un client de messagerie ; Ceci avec une volonté affirmée de respect des standards, assurant ainsi un fonctionnement avec la majeure partie des serveurs de messagerie. Après une étude des logiciels de messagerie candidats au développement d'extensions et disposant d'une forte communauté, le choix s’est orienté vers le client de messagerie Mozilla Thunderbird. Le client répondant aux exigences des messageries de confiance et l’ensemble des travaux y afférant sont mis à disposition sur le site officiel de TrustedBird sous les licences libres MPL, GPL et LGPL.
Mots clefs
Logiciels libres, TrustedBird, Client de messagerie, Messagerie sécurisée, Messagerie professionnelle, Messagerie de confiance, Standards de l'IETF, S/MIME
Le succès de la messagerie électronique n'est plus à démontrer. Ce succès a participé, ces dernières années, au formidable développement du réseau Internet et il est difficile, aujourd'hui, de se passer de cet outil. Les possibilités offertes par ce service sont la raison principale de ce succès. Nous pouvons échanger de l'information avec quiconque possède un système standard. Ces échanges, sous forme de messages électroniques simples ou bien complexes (avec des pièces jointes), sont réalisés avec une grande rapidité d'acheminement et sans la contrainte géographique des destinataires. La capacité d'envoi d'un message à des destinataires multiples est également un atout important par rapport aux limitations du courrier postal, imposant pour sa part un message par destinataire. Toutes ces fonctionnalités ont contribué à une large adoption de la messagerie par les particuliers. Cette dépendance est encore plus marquée dans l'environnement professionnel. La messagerie électronique a pris la place des autres systèmes comme le fax ou le courrier postal. Ce succès masque toutefois d'importantes lacunes. La messagerie électronique a été adoptée sans réelle conscience des risques, des inconvénients et souvent dans la méconnaissance des lois.
L'utilisation de la messagerie dans un environnement professionnel impose la mise en œuvre des services suivants : la disponibilité, la prise en compte de l'importance et de l'urgence des messages, le service de notification, le marquage du niveau de sensibilité des messages et du type de correspondance (privée ou professionnelle), la traçabilité, la garantie d'intégrité des messages, l'horodatage sécurisé et l'archivage des échanges. Rares sont les entreprises disposant d'un système de messagerie intégrant tous ces services. Parallèlement, le cadre juridique a évolué ces dernières années et le législateur a apporté des précisions entourant les échanges électroniques et plus particulièrement les échanges basés sur les systèmes de messagerie. La loi pour la confiance dans l'économie numérique1 (LCEN), qui transpose une directive européenne sur le commerce électronique, précise le statut du courrier électronique. La publication de cette loi a occasionné de fortes polémiques qui portaient sur le respect du secret des correspondances à caractère privé2. La LCEN intégrait dans sa version initiale tout type de correspondances. Le conseil constitutionnel a supprimé la notion de correspondances privées et laisse l'autorité juridictionnelle compétente se prononcer sur ces aspects (par le biais de la jurisprudence). Nous voyons à travers cette courte présentation que le statut des courriers électroniques est certes défini, mais que les échanges à caractères privés dans un environnement professionnel restent quant à eux, entourés d'un certain flou. Il convient donc d'apporter aux entreprises des moyens (de marquage du type de correspondance) permettant de répondre à ce type de problématique. La mise en œuvre des services abordés dans ce paragraphe contribue à la réalisation d'un système de messagerie professionnelle.
Le succès croissant de la messagerie électronique a également été accompagné d'une forte évolution des menaces et des vulnérabilités. Les entreprises, plus ou moins conscientes de ces risques, ont déployé des solutions de sécurité afin de protéger les composants de l'architecture de messagerie et de sécuriser les flux entre ces composants (clients, serveurs...). Bien qu'importants, ces principes de sécurisation ne sont pas suffisants. Il est également nécessaire d'appliquer des mécanismes de sécurisation sur les messages afin, par exemple, de garantir l'intégrité des données, d'authentifier le rédacteur d'un message ou d'empêcher une personne non autorisée de prendre connaissance de celui-ci. La mise en œuvre de ces services au sein d'une infrastructure permet de disposer d'une messagerie sécurisée. La plupart de ces services peut être apportée par la signature électronique. À ce sujet, la loi3 relative à la signature électronique et son décret d'application4 définissent le statut juridique d'un courriel et de la signature électronique. L'écrit sur support électronique a dorénavant la même force probante que l'écrit sur support papier, dès lors que l’émetteur peut être identifié et que l’écrit est « établi et conservé dans des conditions de nature à en garantir l’intégrité »5.
Fort de ces constats et compte tenu de la forte augmentation de la dématérialisation des informations, les entreprises doivent disposer d'une messagerie à la fois professionnelle et sécurisée. Cette utilisation conjointe concourt à la réalisation d'un système offrant des échanges numériques de confiance. Les entreprises disposeront alors d'un système de messagerie de confiance (dont le périmètre est décrit dans la figure 1).
Figure 1 - Périmètre d'un système de messagerie de confiance
Une infrastructure de messagerie de confiance doit intégrer des composants capables d'interagir entre eux en respectant les exigences associées à ce type de système. TrustedBird6 ambitionne d'être un client de messagerie de confiance et l'objet de ce document est de présenter les travaux réalisés et les services apportés pour atteindre cette cible.
La Direction Générale de l'Armement (DGA) a initié en 2006, un programme d'études amont (PEA) dont les objectifs étaient doubles : le développement d'un client de messagerie adapté à un contexte militaire (et civil) et la réalisation de ces travaux dans un contexte communautaire. La Direction générale des systèmes d'information et de communication (DGSIC) s'est jointe à la DGA pour mener à bien le pilotage du projet, la partie réalisation des développements incombant aux sociétés British Telecom et EADS.
Une étape de consolidation des besoins a tout d'abord été nécessaire. Elle a permis de faire ressortir les similitudes entre les contextes militaire et civil, et d'en déduire des exigences communes. Dans un second temps, une étude a permis de corréler les exigences liées à un système de messagerie de confiance avec les standards existants. Le choix du client a été réalisé à partir de l'analyse des différents clients de messageries existants et des licences associées. Dans ce but, un état de l'art a été effectué et le choix s'est porté sur le client Mozilla Thunderbird7 (issu de la communauté Mozilla Foundation). Parmi les critères ayant pesé dans cette décision, nous pouvons citer la portabilité sur des systèmes d'exploitation comme Windows et Linux ainsi que la taille de la communauté. Pour les aspects licences, le choix s'est arrêté sur trois types de licences, à savoir MPL8 (Mozilla Public License), GPL9 (GNU General Public License) et LGPL10 (Lesser GNU General Public License), dans l'optique d'une reprise des développements par Mozilla Messaging et ainsi éviter le maintien d'une version parallèle (fork).
Il a été décidé de suivre les principes de développements de la Mozilla Foundation. Les développements ont été réalisés sous deux formes : modules externes (plugin) et modules internes (patch). Les fonctionnalités développées sous forme de modules externes n'entrainent pas de modifications du logiciel Thunderbird, contrairement aux fonctionnalités développées sous forme de modules internes qui imposent, quant à elles, une phase de compilation.
L'autre objectif était de réaliser les travaux dans un contexte communautaire, en se basant sur les principes des logiciels libres et open source, et d'évaluer la possibilité de fédérer une communauté autour de problématiques civiles et militaires. Il faut noter que ce projet est précurseur dans ce domaine car il n'existait pas (à l'époque) d'initiative du ministère de la défense en ce sens.
Afin de répondre aux objectifs visés et de fournir un composant susceptible de répondre aux exigences d'un système de messagerie de confiance, un ensemble de services a été défini. Cela a permis de décrire les fonctionnalités liées aux exigences légales et celles associées aux aspects métiers.
Parmi les services génériques, nous retrouvons principalement le service de suivi des messages basé sur les mécanismes des notifications. Sa mise en œuvre a impliqué la réalisation de plusieurs modules. Tout d'abord, le support des avis de remises, standardisés au sein de l'IETF11 sous l'acronyme DSN12 [1], a été développé. Il permet à un émetteur de demander une notification lors de la remise (ou de la non remise) du message dans la boîte aux lettres du destinataire. Cet avis est généré par le serveur du destinataire. Il faut noter que les modifications apportées par ce module interne seront intégrées dans les futures versions de Thunderbird, grâce au principe de reversement du code. Ensuite, le support des accusés de suppression a été intégré au sein d'un module externe nommé « MDN-Extended ». Il est basé sur les mécanismes d'accusé de lecture (MDN13 [2]). Ce module permet au destinataire d'un message comportant une demande d'accusé, de renvoyer un accusé lorsque le message est supprimé.
Nous disposons donc à présent de deux mécanismes offrant un service de suivi de messages. Toutefois, il est également nécessaire de corréler ces différentes notifications avec les messages initialement émis. Pour cela, le module externe « Notification viewer » a été développé. Il permet d'associer les avis et accusés reçus avec le message envoyé. Grâce à ce module, il est maintenant possible, dans le cadre d'une architecture maitrisée, de disposer d'un service de suivi permettant d'identifier et d'afficher l'état des différentes notifications.
L'interaction entre les clients de messagerie et le service d'annuaire, conforme au standard LDAP14, offre des perspectives intéressantes. Afin d'étendre les échanges avec ce service, plusieurs modules externes ont été développés.
Le module « Multi-LDAP » permet une recherche simultanée et une auto-complétion des adresses de messagerie des destinataires, à partir de plusieurs annuaires LDAP. Par défaut, Thunderbird 2.x ne permet d'utiliser qu'un seul annuaire à la fois.
Le module « Check Recipients » propose des mécanismes de vérification de l'existence des adresses des destinataires avant l'envoi d'un message, à partir des carnets d'adresses locaux et des annuaires LDAP. Ce composant peut être utilisé conjointement avec le module « Multi-LDAP » afin d'effectuer des recherches simultanées sur plusieurs annuaires. Il est également possible d'obtenir les formats de messages supportés par les destinataires. Ce service est fourni par le module « Send-Format-LDAP ». Le module « Card Viewer Extended », quant à lui, permet d'afficher le certificat X.50915 d'un contact.
Le module « CRL over LDAP » autorise l'importation de listes de certificats révoqués (ou certificate revocation lists) depuis des annuaires LDAP. Il ajoute le support d'URL LDAP dans la fenêtre d'import du gestionnaire de certificats révoqués et programme des mises à jour automatiques de ces CRL. Enfin, un module permettant d'étendre la fiche utilisateur, en ajoutant la photo ou tout autre type de données disponibles dans un annuaire LDAP, sera bientôt disponible.
Il est nécessaire, dans les systèmes de messagerie de confiance, de disposer de règles de routage et d'acheminement prioritaires. Pour cela, plusieurs modules ont été développés. TrustedBird a la capacité de négocier l'envoi de messages prioritaires avec un serveur supportant le draft SMTP PRIORITY16 [3]. Cette extension permet de définir un niveau de priorité pour le message. Les 5 niveaux définis sont dans l'ordre croissant de priorité NONE, ROUTINE, PRIORITY, IMMEDIATE et FLASH. Ce service ne trouve son intérêt que dans le cas d'architectures composées de serveurs supportant cette extension. Si un serveur ne met pas en œuvre ce mécanisme, le traitement de la priorité est impossible. Pour remédier à ce problème, il est possible d'utiliser des champs d'entête présents dans un message IMF17 [4]. Un traitement prioritaire de bout en bout est dorénavant possible car les champs d'entête d'un message sont transportés par chaque serveur sans subir de modification.
Le projet TrustedBird fournit un composant pour Postfix18, offrant ce mécanisme de traitement prioritaire des messages. Pour cela, le serveur utilise certains champs d'entête présents dans le message pour l'aiguiller vers l'instance Postfix associée au niveau de priorité. Le niveau de priorité est ensuite transporté jusqu'à la couche IP, en modifiant la classe de service DiffServ19. Il est possible de déployer ce composant dans une architecture de qualité de service (QoS).
Le standard Sieve20 [5] définit un langage de filtrage de message. Ce filtrage est réalisé sur le serveur (lors de la remise des messages dans les boîtes aux lettres) contrairement aux mécanismes de filtrage natifs que nous pouvons trouver dans la plupart des clients de messagerie. Le module externe « Out-of-Office » permet, à partir du client TrustedBird, de configurer certaines règles qui sont ensuite transférées sur le serveur (intégrant le standard Sieve). L'utilisateur a, par exemple, la possibilité d'activer la redirection de ses messages vers le destinataire de son choix, de conserver les messages dans sa boîte aux lettres s’ils sont redirigés ou encore d'activer l'envoi de notification d'absence à la réception d'un message.
Une messagerie de confiance impose des services de sécurité étendus. Aujourd'hui, plusieurs protocoles permettent de sécuriser les échanges de messages électroniques. Il est possible d'utiliser le protocole TLS21 [6] pour garantir l'authentification ainsi que la confidentialité des échanges. Dans le cadre d'une messagerie sécurisée, ce service n'est cependant pas suffisant. Lors d'une transaction, le protocole TLS est mis en œuvre entre le client à l'initiative de la transaction et le serveur. Dès la transaction terminée et le message reçu par le serveur, le message n'est plus sécurisé et rien ne garantit que le serveur suivant supporte à nouveau le protocole TLS. Dans une architecture comportant plusieurs serveurs de messagerie, il y a un risque de rupture de sécurité entre l'émetteur du message et le destinataire final. Pour faire face à ce risque, il existe plusieurs protocoles dont S/MIME22 [7] qui rencontre un certain succès auprès des entreprises et qui est imposé par le référentiel général d'interopérabilité23. Actuellement, Thunderbird met en œuvre ce protocole à travers les librairies cryptographiques NSS24 (Network Security Services). Ces librairies proposent des fonctions de signature et de chiffrement des messages. Cela n'est toutefois pas suffisant, plusieurs extensions de services de sécurité ont donc été développées dans le cadre du projet TrustedBird. Nous expliquons ici pourquoi.
La signature électronique est une technologie apportant un niveau de confiance dans les échanges électroniques. Elle est équivalente à une signature manuscrite (sous certaines conditions) avec la particularité de permettre un attachement d'autres données électroniques. La signature électronique se base sur une transformation cryptographique des données permettant au destinataire de vérifier l'identité de l'émetteur du message (authentification), de prouver l'émission du message (non répudiation) et d'avoir l'assurance que l'information n'a pas été altérée (intégrité). Il existe différents standards de signature électronique. Les mécanismes de signature mis en œuvre dans les systèmes de messagerie de confiance et traités dans ce document sont définis dans le RFC CMS25 [8]. Ce standard décrit la structure de la signature électronique, pièce jointe du message, sous la forme d'un objet SignedData, présenté dans la figure 2.
Figure 2 - Description de la struture de l'objet SignedData
Il est également nécessaire de présenter les concepts d'attributs signés. Lors de la création de la signature, un processus de génération de condensé est appliqué sur les données à signer. Il est possible d'ajouter des données à sécuriser lors de l'exécution de ce processus. Pour cela, le standard CMS propose une structure interne nommée SignedAttributes (cf. colonne 2 de la figure 2) qui permet l'encapsulation de données additionnelles. Si une structure SignedAttributes est présente, le processus de calcul de condensé est appliqué à la fois sur le contenu, mais également sur cette structure. Ensuite, le condensé obtenu est utilisé par les processus de génération et de vérification de signature. La troisième colonne de la figure 2 comporte les principaux attributs signés utilisés par TrustedBird. L'étiquette de sécurité (SecurityLabel), le reçu signé (ReceiptRequest) et les entêtes sécurisés (SecureHeaders) sont détaillés ci-après.
La description détaillée en ASN.126 (et une représentation graphique) présentée dans la figure 3 permet de comprendre les possibilités offertes par ce concept. Une structure d'attributs signés doit comporter un identifiant (appelé OID) qui garantit son unicité. Reste ensuite à définir le type de données à encapsuler dans l'objet AttributeValue.
Figure 3 - Description ASN.1 et représentation graphique des attributs signés
Les extensions de sécurité développées dans le cadre du projet TrustedBird et présentées dans les chapitres suivants, sont en partie basées sur cette technologie. Elles sont intégrés dans les codes sources des librairies NSS.
L'objectif de cette extension est d'intégrer dans les attributs signés, une étiquette de sécurité contenant le niveau de sensibilité du message. Grâce à cette étiquette, l'utilisateur est informé que le message comporte des informations protégées (restreintes, confidentielles, secrètes), et que celui-ci doit être manipulé avec précaution. Le mécanisme appliqué est basé sur le SecurityLabel décrit dans le RFC ESS27 [9] (extension du protocole S/MIME). L'étiquette est intégrée dans la signature et plus précisément dans une structure interne liée aux attributs signés (cf. Figure 2). Il est possible d'ajouter une (ou plusieurs) catégorie(s) de sécurité afin de définir une étiquette avec une granularité plus fine. Nous pouvons par exemple envisager un message comportant une étiquette « Confidentiel » associée à deux catégories de sécurité « Laboratoire X » et « Laboratoire Y ». Cet exemple ainsi que la syntaxe ASN.1 du SecurityLabel sont décrits dans la Figure 4. Pour mettre en œuvre ce type de mécanismes, les protagonistes de l'échange doivent utiliser la même politique de signature (préalablement définie).
Figure 4 - Description ASN.1 et exemple d'étiquette de sécurité
La deuxième extension de sécurité fournie offre un service de reçu signé. Elle est décrite dans le RFC ESS et porte le nom de SignedReceipt. Actuellement (et comme nous l'avons vu précédemment), il est possible d'obtenir des informations sur l'acheminement du message, à l'aide des mécanismes de DSN et MDN. Ces protocoles ne sont toutefois pas sécurisés et il est possible de créer un faux message de notification de remise. Pour remédier à ce problème, il existe une extension des services de sécurité du protocole S/MIME permettant d'obtenir un reçu sécurisé. Ce principe fournit à l'émetteur la preuve de remise d'un message envoyé et permet également de prouver à un tiers que le destinataire a pu vérifier la signature du message d'origine. Ce service peut être mis en œuvre uniquement si le message est signé. Lors de la réception d'un message comportant une demande de reçu signé, l'agent de réception doit vérifier la signature. Si la signature est valide, il doit renvoyer un reçu signé. La demande de reçu est indiquée en ajoutant un objet receiptRequest à la structure des attributs signés (cf. figure 2). Un logigramme simplifié ainsi que la description ASN.1 de l'objet receiptRequest sont fournis dans la figure 5. Dans la structure interne de cet objet, un identifiant de contenu signé (signedContentIdentifier) est créé. Il est utilisé pour associer le reçu signé avec le message ayant émis la demande de reçu. L'émetteur à l'origine de la demande de reçu est contenu dans le champ receiptsTo. Le champ receiptsFrom contient la liste des destinataires devant renvoyer un reçu signé. Un reçu signé est un objet signedData encapsulant un contenu Receipt.
Figure 5 - Logigramme simplifié et description ASN.1 du ReceiptRequest et Signed Receipt
L'envoi d'un message chiffré contenant une signature avec une demande de reçu signé apporte l'assurance que le destinataire a correctement déchiffré le message. Nous obtenons par ce principe un niveau d'assurance plus important.
Avant de présenter en détails cette extension, il est nécessaire de rappeler une particularité du standard S/MIME. La signature s'applique, en général, seulement sur le contenu du message et non sur sa totalité, excluant ainsi la sécurisation des champs d'entête. Il est par exemple possible de modifier le champ « Subject » ou bien de supprimer d'autres champs d'entête. La dernière version du standard propose une solution consistant en une encapsulation complète du message dans la signature mais cela entraîne d'autres problèmes (perte d'interopérabilité, pas de service de confidentialité). Fort de ce constat, nous avons réalisé des travaux afin de proposer une solution de sécurisation des champs d'entête.
Une première solution envisageable est l'utilisation du protocole TLS, mais comme nous l'avons vu en introduction de ce chapitre, il ne répond pas au besoin de sécurisation de bout en bout des champs d'entête.
Le protocole DKIM28 [10] offre des services de sécurité qui permettent la vérification de la source et du contenu du message. DKIM définit un mécanisme de signature électronique de messages en utilisant le DNS comme mécanisme de publication de clés publiques. Malgré ses nombreux atouts, il ne permet pas de répondre au besoin exprimé. Le principal problème étant que la signature électronique appliquée au message est liée à l'organisation qui gère le domaine et qui fournit la clé publique. L'identité utilisée dans DKIM est celle du nom de domaine et non celle de la personne. Il n'y a donc pas d'engagement de responsabilité d'une personne physique.
Ne disposant pas de solution répondant totalement à notre besoin, nous avons réalisé une étude dont l'objectif affiché est de garantir l'intégrité, la non-répudiation et la confidentialité des champs d'entête des messages. Cette étude a abouti aux concepts d'entêtes sécurisés (ou Secure Headers29 ). Le principe de cette technologie est d'intégrer ces champs dans la signature, et de garantir une sécurisation de la totalité du message, lors de son transfert de l'émetteur jusqu'aux destinataires finaux.
Figure 6 - Signature S/MIME sans et avec les entêtes sécurisés
Techniquement, le processus est le suivant. Lors de la génération de la signature, le client de messagerie crée une structure de champs d'entête nommés SecureHeaderFields. Celle-ci contient les champs à protéger (noms et valeurs). Cette structure est intégrée dans les attributs signés (cf. figure 2). Grâce à ce concept, la signature s'applique dorénavant à la totalité du message. La figure 6 décrit succinctement ce mécanisme.
Cette technologie a l'avantage non négligeable de ne pas engendrer de problème d'interopérabilité. En effet, les structures internes des attributs signés ne sont prises en charge que par les clients les mettant en œuvre. L'utilisation de la technologie des entêtes sécurisés ne remet donc pas en cause l'interopérabilité avec des clients de messagerie S/MIME.
Lors de la réception d'un message signé, deux solutions sont envisageables. Dans le premier cas, le client ne traite pas les entêtes sécurisés. Il reste toutefois en mesure de vérifier la signature. La présence des champs d'entête dans la signature est dans ce cas totalement transparente pour le client. Dans le second cas, le client est capable de traiter les entêtes sécurisés. La modification (ou la suppression) d'un champ d'entête du message ne remet pas en cause la validité de la signature. Cependant, un avertissement est transmis à l'utilisateur.
Une autre extension de sécurité dont l'objectif est de permettre de générer des messages sécurisés en appliquant le concept de triple enveloppe a été développée. Cette extension est décrite dans le RFC ESS [9]. Un message au format triple enveloppe est un message dont le contenu est signé. Ensuite, la signature ainsi que le contenu sont chiffrés. Enfin, le contenu chiffré est signé à son tour. Les intérêts du mécanisme de triple enveloppe sont divers. Les utilisateurs à l'origine des signatures internes et externes peuvent être différents. Il est également possible de positionner des attributs dans la signature interne différents de ceux présents dans la signature externe. Nous pouvons par exemple envisager une signature interne contenant une demande de reçu signé et une signature externe intégrant une étiquette de sécurité.
Figure 7 - Génération d'un message au format triple enveloppe
La figure 7 décrit le processus de création d'un message sécurisé basé sur le mécanisme de la triple enveloppe, avec dans notre cas une signature détachée telle que défini dans S/MIME. La signature enveloppante est également utilisable dans la génération d'une triple enveloppe.
Comme cela a été présenté en introduction, l'utilisation de la messagerie sous sa forme professionnelle impose de nouvelles exigences, notamment en ce qui concerne le format d'échange. Actuellement, le format utilisé dans les systèmes de messagerie électronique est basé sur le standard IMF. De par sa simplicité et sa facilité de mise en œuvre, ce format a rapidement été adopté et il a contribué au succès de la messagerie sur Internet. Les échanges professionnels nécessitent cependant, l'utilisation de messages étendus. L'urgence du message, le type de correspondance (privée ou professionnelle) ou le nom d'un projet sont autant d'informations qui peuvent être utiles pour les destinataires. Pour offrir ce type de service, il faut proposer une technologie capable de spécifier les formats de messages et de les échanger sans perte d'interopérabilité. Le destinataire doit pouvoir visualiser le message ainsi que les champs additionnels renseignés par l'émetteur.
La technologie XIMF30 (eXtended Internet Message Format) a donc été définie. Cette technologie réunit plusieurs concepts. Elle permet d'étendre le format de message IMF. Pour rappel, un message conforme à ce standard est composé, au minimum, d'une liste de champs d'entête et d'un corps. Ces champs d'entête sont standardisés, enregistrés auprès de l'IANA31 et un RFC32 [11] a été publié. Le standard IMF propose, pour des besoins spécifiques, de décrire des champs d'entête personnalisés.
XIMF permet la prise en charge de formats étendus. Chaque nouveau format est défini à l'aide de fichiers au format XML33. Un fichier principal contient la liste des champs (noms et valeurs associées) ainsi que leur statut (obligatoire, optionnel). Un second fichier décrit les formulaires de saisie et d'affichage des champs personnalisés. Il existe d'autres fichiers permettant de positionner les règles d'associations entre les champs ou encore d'importer des données externes. L'ensemble de ces fichiers XML constitue une collection appelée instance XIMF.
La technologie XIMF dispose d'un moteur capable de traiter les différentes instances présentes dans le client de messagerie. Ce moteur permet le chargement des formulaires de saisie (rédaction) et d'affichage (réception) des champs additionnels. Il réalise également l'intégration de ces champs dans le message. Grâce à cette technologie, il n'est pas nécessaire de développer d'applications dédiées, mais simplement de décrire les nouveaux champs dans une instance XIMF.
Figure 8 - Format IMF et XIMF
La figure 8 présente de manière simple les concepts de XIMF. Un utilisateur renseigne un formulaire lié à une instance et chargé par le moteur XIMF. Lors du processus d'envoi, le moteur génère les champs d'entête personnalisés dans le message. À la réception, le moteur récupère les champs d'entête puis les affiche dans le formulaire du destinataire.
La mise en œuvre de XIMF peut être associée à celle des entêtes sécurisés (cf. chapitre 3.2.4). Par ce principe, il est maintenant possible d'ajouter des champs d'entête dans les messages et de les sécuriser. L'utilisation de champs sécurisés trouve tout son intérêt dans le cas du type de correspondance. L'utilisateur peut positionner une valeur de correspondance (privée, professionnelle...) qui est signée et donc non-répudiable.
XIMF est fourni sous la forme de deux modules externes : le moteur ainsi qu'une instance. Il est possible d'installer d'autres modules d'instances en fonction de besoins spécifiques. Le moteur est, quant à lui, unique. XIMF peut être utilisé dans un environnement ne le mettant que partiellement en œuvre sans impacter les autres composants du système. Les clients ne disposant pas des modules XIMF traitent le message de manière standard, et les serveurs ne sont en aucun cas impactés.
XIMF permet de disposer de formats d'échange étendus, pouvant être personnalisés et garantissant l'interopérabilité entre les utilisateurs. Ce service offre aux entreprises (ou organisations) la capacité de réaliser des échanges professionnels.
Les échanges professionnels, sont actuellement très largement basés sur le service de messagerie électronique, devenu indispensable voire critique. Ses atouts sont indéniables mais ce service souffre toutefois, d'inconvénients majeurs qui sont autant d'obstacles à une mise en œuvre d'un service de messagerie professionnelle, sécurisée et respectueuse du cadre légal.
Le projet TrustedBird avait pour objectif principal la fourniture d'un client de messagerie, répondant aux exigences d'un tel environnement ; il est aujourd'hui disponible et sera utilisé dans les systèmes du ministère de la défense. TrustedBird peut être déployé dans tout type d'architecture respectant les normes et standards ouverts et se positionne comme un candidat potentiel à intégrer dans les futures infrastructures de messagerie de confiance. Le modèle de licences associé permet, quant à lui, une utilisation illimitée et sans coût supplémentaire.
La réalisation des travaux dans un contexte communautaire a permis d'évaluer l'intérêt d'une telle démarche. Grâce à la mise à disposition sur le site de TrustedBird des composants, les personnes intéressées ont pu participer au processus de développement et contribuer à l'amélioration des travaux. Des échanges ont eu lieu avec les communautés Mozilla Foundation et Mozilla Messaging afin d'orienter les travaux (en fonction des feuilles de routes respectives) et d'envisager le reversement d'une partie des développements. Enfin, de nombreux contacts ont été noués et offrent la perspective de futurs partenariats.
ASN.1 Abstract Syntax Number One
CMS Cryptographic Message Syntax
DGA Direction Générale de l'Armement
DGSIC Direction Générale des Systèmes d'Information et de Communication
DKIM DomainKey Identified Mail
DNS Domain Name System
DSCP Differentiated Services Code Point
DSN Delivery Status Notification
GPL GNU General Public licence
IETF Internet Engineering Task Force
IMF Internet Message Format
IANA Internet Assigned Numbers Authority
IP Internet Protocol
LDAP Lightweight Directory Access
LGPL Lesser GNU General Public licence
MDN Message Disposition Notification
MIME Multipurpose Mail Extensions
MPL Mozilla Public licence
OID Object IDentifier
RFC Request For Comments
URL Uniform Resource Locator
S/MIME Secure MIME
SMTP Simple Mail Transfer Protocol
QoS Quality of Service
Moore, K. « Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) », RFC 3461, January 2003
Hansen, T., Vaudreuil, G. « Message Disposition Notification », RFC 3798, May 2004
Schmeing, M., Brendecke, J., Carlberg, K. « draft-schmeing-smtp-priorities-05 », Expired February 24, 2007
Resnick, P. « Internet Message Format », RFC 5322, October 2008
Guenther, P., Showalter, T. « Sieve: An Email Filtering Language », RFC 5228, January 2008
Dierks, T., Rescorla, E. « The Transport Layer Security (TLS) Protocol Version 1.2 », RFC 5246, August 2008
Ramsdell, B. « Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification », RFC 3851, July 2004
Housley, R. « Cryptographic Message Syntax (CMS) », RFC 5652, September 2009
Hoffman, P. « Enhanced Security Services for S/MIME » RFC 2634, June 1999
Crocker, D. « DomainKeys Identified Mail (DKIM) Signatures – Update », RFC 5672, August 2009
Klyne, G., Palme, J. «Registration of Mail and MIME Header Fields », RFC 4021, March 2005
1 Loi n°2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique. Journal officiel du 22 juin 2004.
2 Loi n°91-646 du 10 juillet 1991 relative au secret des correspondances émises par la voie des communications électroniques.
3 Loi n°2000-230 du 13 mars 2000 portant adaptation du droit de la preuve aux technologies de l'information et relative à la signature électronique.
4 Décret n°2001-272 du 30 mars 2001 pris pour l'application de l'article 1316-4 du code civil et relatif à la signature électronique.
5 Article 1316-1 du Code civil.
6 http://www.trustedbird.org
7 http://www.mozilla-europe.org/fr/products/thunderbird/
8 http://www.mozilla.org/MPL/MPL-1.1.html
9 http://www.gnu.org/licenses/gpl-3.0.html
10 http://www.gnu.org/licenses/lgpl.html
11 http://www.ietf.org
12 http://www.rfc-editor.org/rfc/rfc3461.txt
13 http://www.rfc-editor.org/rfc/rfc3798.txt
14 http://www.rfc-editor.org/rfc/rfc4510.txt
15 http://www.rfc-editor.org/rfc/rfc5280.txt
16 https://datatracker.ietf.org/drafts/draft-schmeing-smtp-priorities/
17 http://www.rfc-editor.org/rfc/rfc5322.txt
18 http://www.postfix.org/
19 http://www.rfc-editor.org/rfc/rfc2474.txt
20 http://www.rfc-editor.org/rfc/rfc5228.txt
21 http://www.rfc-editor.org/rfc/rfc5246.txt
22 http://www.rfc-editor.org/rfc/rfc3851.txt
23 « cadre de recommandations référençant des normes et standards afin de favoriser l'interopérabilité au sein des systèmes d'information de l'administration », http://www.references.modernisation.gouv.fr/sites/default/files/RGI_Version1%200.pdf
24 http://www.mozilla.org/projects/security/pki/nss/
25 http://www.rfc-editor.org/rfc/rfc5652.txt
26 http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf
27 http://www.rfc-editor.org/rfc/rfc2634.txt
28 http://www.rfc-editor.org/rfc/rfc5672.txt
29 Cailleux, L. « Secure headers for S/MIME », travaux en cours
30 Cailleux, L. « XIMF – eXtended Internet Message Format », travaux en cours
31 http://www.iana.org/assignments/message-headers/perm-headers.html
32 http://www.rfc-editor.org/rfc/rfc4021.txt
33 http://www.w3.org/TR/2008/REC-xml-20081126/
Page