mercredi, décembre 19, 2007

L'&, où le détournement d'un caractère par l'opérateur télécoms national

Lorsque l'on feuillette de vieux ouvrages imprimés avant 1801, on y retrouve l'emploi d'un signe inhabituel, le caractère "&" en remplacement de la conjonction et, même dans la locution et caetera, dont l'abréviation s'écrivait &c.

L'alphabet ne s'arrêtait pas à la lettre Z, comme aujourd'hui. Il comportait une lettre de plus, le caractère &, que les élèves qui apprenaient à lire prononçaient à la latine, ète. Ce qui donnait en fin de récitation: ixe, igrec, zède, ète. La tradition s'était établie que l'élève, une fois parvenu à la fin de son aalphabet, saluât son exploit d'une rime plaisante: ...ixe, igrec, zède, ète... perluète (ou esperluète, ou encore pirlouète). On prit donc l'habitude de baptiser du nom d'esperluète le signe &.

Aujourd'hui, ce caractère, appelé parfois "et commercial", n'est pas à proprement parler une lettre supplémentaire de l'alphabet, mais une abréviation courante, désormais enseigne commerciale de notre opérateur télécoms national!

Libellés : ,

mardi, décembre 11, 2007

Mon brevet sur la sécurisation des échanges de courriels (texte intégral)

MESSAGE ELECTRONIQUE AVEC AVIS DE RECEPTION ET SUIVI (MARS).

La présente invention concerne le domaine des envois et des réceptions de mèls à remise sécurisée. Il est de tradition depuis 1969 d’utiliser le protocole IPv4 (« Internet Protocol » version 4) afin de transmettre d’une console informatique à une autre console un flux d’information sous forme électronique.

Un mèl consiste en un message simple codé en ASCII-256 et couplé avec un ou plusieurs éventuels fichiers attachés codés en MIME. Le serveur d’expédition des mèls est un serveur SMTP. Chaque utilisateur est identifié par une adresse mèl unique défini par un identifiant utilisateur, un nom de domaine et un suffixe: condat@chrystol.com est une adresse non équivoque qualifiant un utilisateur spécifique sur un domaine déterminé par ses huit lettres et son extension.

L'usage courant veux que toutes les opérations soient facilement identifiables à vue. Il demeure toujours un risque de non-acheminement d’un mèl. Un automate est en charge de transmettre les problèmes de délivrance d’un mèl aussi bien à cause de problèmes de délais de remise que des défauts des serveurs SMTP s’échangeant les informations.

Pour l'envoi de documents officiels ou nécessitant un traitement particulier, on utilise des produits complémentaires permettant d'assurer l’authentification des parties, le séquestre du mèl transitant, le respect des paramètres d’envoi du routeur expéditeur et le cryptage du flux de données électroniques composant le corps du mèl. Parfois, les outils progiciels mis en œuvre pour garantir l’absolu sécurité de chacune des étapes du processus de transmission impose la présence d’un technicien maîtrisant la gestion des PKI (gestionnaire de clefs), des garde-barrières ou même des moyens durs d’intentification biométriques des parties (iridologie, reconnaissance des traits du visage ou empreintes palmaires).

Le système de courrier recommandé postal classique permet de s'assurer qu’un courrier sera effectivement acheminé de la meilleure façon possible. Il permet d'obtenir une preuve de la bonne réception par le destinataire de l'enveloppe contenant les documents. Afin de s'assurer que le courrier sera remis à son destinataire réel, on utilise l’artifact d’un avis de réception. Cet avis de réception est signé par le destinataire puis est remis à l'expéditeur. Dans tous les cas, la remise de l'enveloppe et non de son contenu est certifiée par ces systèmes. Dans le cas où l'enveloppe est vidée, intentionnellement ou non, il n'est pas possible de retrouver le document tel qu'il a été envoyé sans posséder soi-même une procédure d'archivage des envois (c’est-à-dire de conservation pérenne de l’envoi avec la garantie de lisibilité dans le temps de l’envoi s’il a été soumis sous forme numérique). Une assurance est généralement proposée par le transporteur pour rembourser de façon forfaitaire les éventuelles spoliations.

Dans le cas du mèl, l’aspect dématérialisé du flux d’information numérique impose une relation forte entre le corps du texte et l’enveloppe numérique de support de l’envoi. Quelque soit le protocole utilisé pour l’envoi des données (routeur SMTP, par exemple), il est à noter que le support de l’enveloppe tout comme le contenu formel du message sont tous deux numériques. Le mode même de routage des mèls impose un transport par paquets, chacun utilisant une chemin inter-routeurs différent.

Les brevets PCT00/33203 et US5850520 présentent un système et une méthode de confirmation et de vérification de la délivrance d’une communication numérique. Le mèl ou chacune de ses pièces jointes est stocké sur une adresse URL unique transmise au destinataire par un premier mèl d’information. Après un double-clic de la souris sur ce lien hypertexte unique, le destinataire pourra télécharger le contenu du fichier original sur sa station. Le lien hypertexte pourra se faire sur une URL dont la validité peut être temporaire ou le retrait automatique des mèls non sollicités (WO00/17768).

L’originalité de cette application baptisée « boomerang » tient à ce que l’expéditeur est instantanément notifié de la remise de son envoi par un second mèl d’information. Toutes ses transactions sont stockées sur un serveur dédié à leur consultation. A noter que le document consulté peut soit être créé à la volée (seules les données de fusion avec le formulaire-type seront archivées), soit être stocké à l’identique de façon fixe (format 1/1 PAL/pixel).
Avantageusement, le serveur « SMTP boomerang » aura informé par un échange de mèls les parties de leur droits et devoirs réciproques (tel que décrit dans le brevet US5903723). Il n’est en aucun cas responsable des éventuelles altérations de forme ou de fonds (lisibilité d’un contenu crypté par un procédé propriétaire à l’une des parties) qu’il est possible d’avoir soit avec les outils de messagerie servant d’interface, soit avec ceux de visualisation. Ce procédé très verbeux impossible plus de cinq états transitoires, source inévitable d’erreurs.

Le brevet US5022080 propose une solution de notarisation d’un document électronique qui évite qu’un document puisse être modifié en dehors de sa date d’enregistrement validé en heure GMT. Aucune variante n’est indiquée quant à un mèl transitant sur un réseau local (LAN) ou étendu (WAN ou extranet d’entreprise), ou lorsque le document confonds aussi parfaitement le corps du mèl, ses inserts et son enveloppe de transport.

De plus, le seul côté retenu de l’invention décrite dans le brevet US5936149 est l’horodatage fortement précise de chacune des étapes de la vie du mèl : initialisation de l’enveloppe, complétude du champs « texte » et accroche des pièces jointes avec leur spécificités propres, demande de routage du premier routeur SMTP, notation des éventuels renvois sur indisponibilité dudit routeur, notation d’un éventuel retour en non-remise (NPAI).

Le brevet EP01/107203 permet de remédier au défaut d’authentification du destinaire d’un mèl donné. L’expéditeur encapsule son envoi dans une double-enveloppe numérique qui ne pourra être ouverte par son destinataire après téléchargement sur une URL désignée qu’après l’avoir décryptée grâce à une demi-clef à validité temporelle de trois minutes reçue sur le téléphone portable de ce dernier (numéro de poste GSM obligatoirement connu de l’originateur du mèl). Les lourdeurs de la procédure d’émission du mèl et de celle de sa réception sont telles que l’usage de cette invention n’est pas imaginable industriellement.

Enfin, notre brevet FR2801390 décrit le fonctionnement d’une plate-forme de courrier hybride acceptant des flux numériques en entrée qui seront ensuite transformés après horodatage et séquestre successifs des différentes transformations en des documents autres que numériques (lettre simple, lettre recommandée, télécopie, télégramme, SMS, messages sonores encapsulé MP3, etc.). Si le flux d’entrée de cette plate-forme peut être un mèl, il est à noter qu’il n’est pas prévu que le flux de sortie soit également un mèl (obligation de transformation imposée par la notion d’hybride).

L'invention décrite dans ce document a pour but de pallier à ces inconvénients en proposant un système peu coûteux permettant de mémoriser, et de certifier le contenant et le contenu des mèls. Elle permet également d'envoyer des messages rapidement et à toute heure en libérant l'expéditeur de l'ingrate et fastidieuse impression d’une copie archive du document transmis ou le doublement de l’envoi du mèl par une lettre recommandée papier avec demande d’avis de réception.

Ce nouveau service de messagerie à valeur ajoutée permettra de mieux gérer les échanges entre boîtes aux lettres et facilitera l'organisation de la distribution de l'information. Ce service sera mis en ligne sur Internet. Avec MARS, il s'agira d'offrir, au-delà de la messagerie de base, un service à valeur ajoutée comme le font les opérateurs postaux.

L'invention concerne un procédé d'envoi de mèl à au moins un destinataire spécifique, comportant une étape de création d'une enveloppe numérique comportant au moins un élément d'identification de l'expéditeur (son adresse électronique), le contenu du courrier (texte simple et/ou fichiers attachés) et les éléments descriptifs du contenant permettant l'acheminement du courrier au destinataire spécifique (nommé par son adresse électronique), une étape de transmission par un réseau numérique sécurisé (RSA, SSL v3 ou au delà, par exemple) de ladite enveloppe numérique à une plate-forme comportant un serveur centralisateur. La plate-forme centrale effectue dès réception du mèl un ensemble d’actions permettant de ne pas rompre la chaîne de sécurisation entamée et de garantir ainsi la non-répudiation du mèl.

Ce procédé est caractérisé en ce qu'il comporte en outre une étape de mémorisation des éléments contenus dans l'enveloppe numérique et des informations concernant le destinataire du courrier, ladite mémorisation étant systématiquement effectuée immédiatement après réception de l’enveloppe numérique du mèl, et, lorsque l'enveloppe numérique comporte une séquence d'instructions de conservation, pendant une seconde durée d'archivage au moins dix fois supérieure à période de réémission des mèls sur incidents par le MX, le procédé comportant en outre un étape accessoire de délivrance d'un certificat de vie comportant un identifiant numérique ainsi que les informations archivées relatives à un courrier spécifique, cette étape étant activée par une requête émise par l'expéditeur de ladite enveloppe numérique. Dans le cas d’un premier envoi, l’expéditeur créé alors un profil par défaut des paramètres généraux de ses futures enveloppes numériques.

Avantageusement, on mémorise en outre les informations concernant la remise du mèl au destinataire spécifique, allant de son environnement technique au type d’outils de messagerie avec avis de réception (MARS) utilisé, de la vitesse de sa liaison Internet au mode de correction d’erreurs du progiciel de cryptage utilisé.

Dans une variante préférée, les informations de remise du mèl comprennent une identification certaine du récepteur du MARS. Il est systématiquement demandé une marque-signature non répudiable juridiquement au destinataire.

A cette fin de non répudiabilité des contenus, nous déférencirons l’intégralité et l’intégrité d’un mèl :
· INTEGRALITE
Madame Michu appartient à un lot de cent clients qui doivent recevoir un mèl. L’intégralité, c’est le fait de s’assurer que le lot de cent clients sorti de la plate-forme informatique avant le routeur est bien parti dans son entièreté ;
· INTEGRITE
Madame Michu est un client qui doit recevoir un message par MARS. S’assurer que Madame Michu a bien reçu le MARS souhaité avec les éléments demandés en pièces jointes et partis sur le routeur avec la bonne adresse électronique.

En supplément, lorsque l’on souhaite traiter intégrité et intégralité, le plus complexe est de traiter les reprises en cas de détection de non-intégrité et de non-intégralité.

La mémorisation du contenu de l'enveloppe numérique utilise préférentiellement des moyens de certification de date et de contenu. On peut également créer un journal des actions effectuées depuis la réception de l'enveloppe numérique auquel on donne accès à l'expéditeur de l'enveloppe numérique.

Avantageusement, le serveur centralisateur envoie une notification de réception de l'enveloppe numérique à l'expéditeur de ladite enveloppe. Cette notification peut comprendre la liste des éléments reçus et inviter à compléter l'enveloppe numérique s'il manque des éléments nécessaires à l'envoi du MARS ou si l’enveloppe s’avérait être corrompue ou virusée.
Dans une variante, l'expéditeur utilise un moyen d'identification certaine pour l'envoi de l'enveloppe numérique.

L'invention concerne également l'interface pour la mise en œuvre du procédé d'envoi de MARS.
Pour répondre aux besoins de sécurité, il est nécessaire de modifier un grand nombre d’infrastructures, en particulier les environnements logiciels des utilisateurs. Il semble bon d’utiliser les compétences de plusieurs éditeurs de logiciels de messageries.

L’invention présentée ici repose sur une infrastructure distribuée entre les postes utilisateurs, le serveur de « collection d’évènements » et le service de suivi. Ceci nous impose donc une nécessité d’usage de protocoles ouverts.

Afin de répondre le plus efficacement possible à la demande de sécurité des entreprises, il est nécessaire de définir un protocole d’évènements d’envoi et de réception de message et d’avis de réception basé sur des standards actuellement proposés et de convaincre des constructeurs de messageries d’implémenter des interfaces sur le poste-client. Dans une première période, il est possible de choisir des développements basés sur la plate-forme Microsoft Outlook.

Dans ce chapitre, nous allons préciser notre compréhension concernant les besoins du service à fournir. Cela nous semble essentiel afin d’éviter des mauvaises interprétations potentielles.

Les services postaux qui sont associés au concept d’accusé de réception comprennent plusieurs caractéristiques dont deux principales qui sont usuellement demandées.

La première caractéristique est que l’émetteur des messages est informé de la bonne réception d’un message. Contrairement aux services postaux, l’implémentation de cette caractéristique dans une messagerie électronique ne nécessite pas de contrainte ni au destinataire ni à l’acheminement du message. Autrement dit, c’est un service à valeur ajouté au fonctionnement normal de la messagerie.

La deuxième caractéristique est la traçabilité des courriers dans le but de réaliser des statistiques de suivi. Nous utiliserons le concept d’évènement comme unité de base de notre approche. L’envoi d’un message électronique peux se résumer en une simple formule : c’est 1 + 2n—événements [n étant le nombre des destinataires].

La solution proposée doit respecter des standards internationalement reconnus et ouvertement publiés afin de garantir une plus large possibilité d’interopérabilité entre communautés différentes. Le respect des standards doit permettre une évolution de la ou des solutions.
Il est souhaitable que certains éléments de la solution, par exemple la gestion des participants d’une communauté puissent être utilisée pour d’autres contextes applicatifs (accès bases de données, services administratifs, etc.).

Il apparaît que l’agrégation de toutes les données syslog n’est pas suffisante.

De plus, il est prouvé que l’utilisateur final n’est pas intéressé par le chemin toujours différent que prend un email pour aller d’un poste informatique à un autre. Nous supposons que cette constatation peut être appliquée à notre conception de MARS. L’expéditeur ne demandera qu’exceptionnellement le résumé quotidien de l’ensemble de ses envois de MARS.

Pareillement, une demande relative à la fourniture de tous les messages perdus reste sans intérêt. Dans le cas de MARS, les traces laissées sont nombreuses et au moins égales à trois : (1) celle générée par l’expéditeur à la création du MARS ; (2) celle générée par le destinataire lors de la fabrication de l’AR ; (3) celle générée par la réception de l’AR qui termine ainsi la transaction.

Le risque de perte d’évènements ou même de faux évènements est acceptable : cela ne ferait que perturber le système de suivi sans influence sur la messagerie.

Même si le réseau tombe en panne, l’avis de réception est disponible et accroché au MARS qui l’a généré. Les traces laissées par le routage d’un MARS sont aussi bien dans le message que dans le système de suivi.

Lors d’une demande de validation d’un évènement par un membre habilité, le serveur central est en mesure de valider simplement la requête relative à un évènement avec un chiffrement fort (autorisé par la DCSSI).

Vu l’importance du marché des mèls transmis quotidiennement et vue la complexité potentielle de l’infrastructure à mettre en place, il est indispensable d’utiliser des techniques normalisées et ouvertes afin de répondre aux besoins d’évolution et d’adaptation.

Le service MARS décrit ci-après doit être nécessairement ouvert à tous les fournisseurs de technologie et de services et doit permettre une ouverture vers d’autres communautés extérieures (par exemple, d’autres administrations).

La solution s’appuie sur n’importe quelle messagerie existante qui utilise les protocoles SMTP et PoP3/IMAP, i.e. des protocoles standards de la messagerie de l’Internet. Pour le format des messageries sont utilisés les format MIME et S/MIME.

Dans le contexte S/MIME, le RFC 2634 ESS (extended security services) défini un format d’avis de réception sécurisé. Ce RFC a été créé pour supporter plusieurs besoins des administrations ou autres services publics ou militaires. Il est proposé d’utiliser cette technique pour répondre aux besoins d’avis de réception.

Nous soulignions qu’actuellement le NIST est en train de préciser un profil d’utilisation S/MIME pour les services de l’administration américaine. Ce profil s’appuie aussi ESS. Le besoin de traçabilité et d’archivage est adressé avec le protocole DVCS qui est une généralisation d’un service d’horodatage et permet également une interface standardisée vers un service d’archivage.

Le système de génération de statistiques s’appuie sur l’utilisation d’un format d’événement standardisé et publié permettant ainsi l’utilisation des produits du marché.
La solution proposée comporte un poste client et un service d’enregistrement d’évènements. Chaque entité participant à un groupe privé d’utilisateurs possède un réseau local de haute qualité en matière de disponibilité et pour chaque réseau un ou plusieurs serveur(s) d’enregistrement d’évènements (env. 50K messages /jour /serveur).

La collecte des évènements vers le serveur centralisé à des fins de statistiques et de suivi peut se faire avec anonymation possible de l’identité des utilisateurs qu’ils soient ou non membre d’un groupe d’utilisateurs privés donné. Elle ne nécessite qu’une disponibilité moyenne des machines. Elle permet de réaliser soit à la demande soit à date fixe un certain nombre de statistiques automatisées.

En matière d’architecture fonctionnelle, la solution comprends les éléments suivants :
- une interface utilisateur intégrée avec la messagerie permettant la création, réception et gestion des messages sécurisés ;
- un service d’horodatage avancé permettant de gérer des traces d’évènements (création, réception) afin de constituer la base des événements pour le suivi et la génération des statistiques ;
- un service de back-office de génération de statistiques et de suivi ;
e- n option, un service d’archivage accessible d’une façon similaire que le service d’horodatage par l’interface utilisateur. Ce service comprends une interface vers n’importe lequel service de conservation de données ;
- une infrastructure pour générer des moyens d’identification pour la communauté (clés d’authentification).

Afin de mieux comprendre la solution, nous l’illustrons avec un cycle de vie d’un message :
- L’utilisateur compose un message avec des destinataires soit de la même communauté, soit d’autres ;
- L’interface utilisateur permet de distinguer les membres de la communauté cible permettant ainsi un affichage différent de l’état d’acheminement du message. En particulier pour les membres de la communauté cible, un message est initialement marqué « Non reçu » ;
- Avant l’envoi du message, l’événement de l’envoi est horodaté par DVCS. Ainsi le service de suivi prend compte de la transaction ;
- Ensuite, le message est envoyé normalement avec la messagerie standard SMTP vers le(s) destinataire(s) ;
- A la réception du message, le(s) destinataire(s) sont informés de la demande de génération d’un accusé de réception et peuvent initier la génération de cet accusé. Cela inclus des options de refus ou d’acceptation. Il est essentiel que cette activité soit entièrement contrôlée par le destinataire ;
- Un autre événement d’horodatage est généré ;
- L’accusé de réception est ensuite envoyé à l’émetteur du message initial ;
- La réception de l’accusé modifie automatiquement l’état du message envoyé (« refusé », « accepté », etc.) ;
- Un autre événement d’horodatage est généré pour clore l’activité.

L’architecture du logiciel client comporte l’implémentation en forme plug-in pour des messageries standards. Le paramétrage utilise des certificats X.509. Chaque utilisateur est associé au service réalisé par un Trousseau individuel d’accès MARS. Si le gestionnaire du réseau le désire, il est possible d’associer une PKI (gestionnaire de clefs publiques) à l’ensemble des utilisateurs par l’entremise d’un serveur d’annuaire LDAP. En option favorite, il est également possible d’intégrer d’autres produits au choix de l’administration, y compris des produits déjà existant et/ou adaptés aux besoins de MARS.

Quant à l’infrastructure de gestion des utilisateurs, la participation des utilisateurs de MARS nécessite un moyen d'authentification auprès de service de suivi et pour l'authenticité des avis de réception. Ce moyen d'accès est appelé Trousseau d'Accès M.A.R.S (TAMARS).
Le TAMARS est fourni à chaque utilisateur, techniquement il s'agit d'une bi-clé RSA avec certificats X.509, permettant l'authentification de l'utilisateur et d'un certificat de confiance permettant l'authentification les serveurs de suivi et de l'archivage. Le TAMARS est fourni aux utilisateurs en format PKCS12, le format standard de-facto d'échange de certificats et secrets, protégé par un code confidentiel personnel.

La création de TAMARS nécessite une infrastructure avec quelques éléments qui sont normalement trouvés dans une infrastructure de gestion de clé (IGC ou ICP), notamment la génération de clés et de certificats et leur distribution.
Nous remarquons que la gestion des utilisateurs, en particulier l'enregistrement, des participants MARS existe en dehors de notre invention. Il s’agit essentiellement de l’enregistrement dans l'annuaire.

Les besoins fonctionnels pour l’infrastructure de génération de TAMARS sont donc principalement d'une nature technique et pas organisationnels. Pour la solution MARS, n'importe quelle solution de fourniture de certificats par un opérateur spécialisé peut être utilisée.

Nous remarquons également que la partie ICP et l'utilisation des techniques S/MIME semble indiquer une protection des messages S/MIME par signature ou chiffrement, cela n’est pas l’objectif de l’invention proposée. La solution reste néanmoins totalement ouverte et compatible avec une telle évolution.

Dans le contexte de l’invention, il s’agit seulement de gérer la participation à une communauté privée d’abonnés d’une façon standardisée et évolutive, donc de répondre à quelques besoins de sécurité concernant l’accès au service de traçage et de conservation des données.

Architecture service d'horodatage avancé
Il s’agit d’un service implémentant le protocole ccpd (certify claim of possession of data) accessible par HTTPS. Le logiciel client possède le certificat du service permettant ainsi l’authentification du service.

Afin de répondre aux besoins d’une grande communauté, le service peut être réalisé d’une façon distribué avec plusieurs serveurs HTTPS placés dans les endroits critiques de l’infrastructure réseau.

Le service horodatage génère une base d’événements en utilisant des techniques et des formats standardisés et publiés. Les évènements vont être exploités par le service de suivi.
Ce service est réalisé par une version adaptée d’un logiciel ayant une autorisation DCSSI, sur des machines PC/Linux+Apache, par exemple. Le service peut co-exister sur la même plate-forme que le service d'archivage. Un serveur est nécessaire par communauté privée d’utilisateurs.

Architecture service d’archivage
Il s’agit d’un service implémentant le protocole cpd (certify possession of data) accessible par HTTPS de la même façon que le service d’horodatage.
Ce service peut aussi être implémenté d’une façon distribuée en fonction du développement des charges et ceci en toute transparence vis-à-vis des clients. Ce service peut s’interfacer avec un service de conservation et distribution de données.
Ce service peut co-exister sur la même plate-forme que le service d'horodatage. Nous proposons un serveur par communauté privée d’abonnés.
Les besoins en serveurs d’archivage sont à mutualiser avec les serveurs de production de statistiques.

Si le choix de l’hébergement est à la charge de la plate-forme MARS, il est nécessaire que l’ensemble des évènements arrive dans une salle blanche. De plus, une connexion Internet proche des machines permettant un tunnel VPN pour la collecte des évènements reste nécessaire ainsi qu’une connexion Internet externe de la salle blanche vers le centre de supervision.

Si l’hébergement est externalisé, il est optimal d’utiliser des serveurs d’un tiers partie de confiance. Dans ce cas, l’administration des données sera réalisée localement tout comme l’archivage (respectant la norme NF Z42-013).

Service de suivi
Il s’agit d’un service de back-office d’analyses d’événements dans un format standardisé et publié afin de générer des statistiques et des informations concernant la facturation, etc. Cette technique permet l’utilisation de produit du marché qui sera proposé dans le contexte MARS.
Semblable aux interface homme-machine de gestion des documents séquestrés, l’interface MARS permettra de faire tous types de statistiques à des fins de facturation inter-services ou de contrôle de l’efficacité des formations.

Un simple PC peut stocker jusqu’à 50K évènements par jour. Une configuration simple répondant aux besoins d’une centaine d’utilisateurs nécessite sept (7) postes afin de garantir le travail de suivi : 2 serveurs de collecte d’évènements, 2 serveurs de production de statistiques et 2 serveurs d’archivage, ainsi qu’un poste d’administrateur local (machine en stand-by). La raison du doublement des serveurs s’explique par la nécessité d’avoir des ressources CPU toujours disponibles.
Chaque MARS génère (1 + 2n) évènements [n étant le nombre de destinataires demandés par l’expéditeur sur Internet]. Chaque évènement est un élément unique donnant un état d’un mèl sous forme non signé. Il est possible d’enregistrer dans un premier temps le chrono des évènements par serveurs SMTP dans le cas d’un groupe privé d’utilisateurs sur un LAN donné.
Le serveur de collecte des évènements est à même de faire des tris en fonction de nombreux critères par une interface conviviale donnant toutes les possibilités d’analyse (par nom de domaine, par poids des messages, par type de cryptages...).
Les formulaires les plus utiles seront définis prioritairement afin qu’il soit rapidement possible de les appeler par un administrateur et/ou de les transmettre à un service d’audit qualité.

L'invention sera mieux comprise par la description détaillée du procédé selon l'invention.
Un expéditeur cherche a créer un MARS sécurisé à partir de son terminal. S'il possède un navigateur adapté au réseau Internet, il se connecte à un serveur Web sur lequel il remplit alors un formulaire d’identification comportant quelques questions nécessaires à la création de son trousseau individuel d’accès (TIA). Son mot de passe lui est transmis pour confirmation quelques secondes après par mèl ou par tout autre moyen. Il précise alors les paramètres secondaires de sa demande de transmission : confidentiel, remise différée dans le temps...
Ces paramètres consistent en le type d'envoi désiré, en les coordonnées du (ou des) destinataire et en les options concernant l'archivage. L'adresse est une adresse unique ou un ensemble d'adresse réunies pour un envoi groupé. Il est également possible de définir un ensemble d'adresses personnalisé qui est mémorisé sur la base de données. L'expéditeur n'aura alors plus qu'à faire référence à ces adresses mémorisées, ce qui présente un gain de rapidité lorsqu'il s'agit d'effectuer des envois groupés.
Dans une variante préférée, l'expéditeur se trouve sur le réseau LAN ou extranet de son entreprise. Lorsqu'il désire procéder à l'envoi d'un MARS sécurisé, il clique sur l'icône spécifique dans la barre des outils de son traitement de texte habituel. Une fenêtre de dialogue s'ouvre alors et propose à l'expéditeur de saisir les caractéristiques de sa requête: adresse du destinataire et la valeur des paramètres de son profil utilisateur (défini par son responsable réseau à l'ouverture de son compte) qu'il souhaite modifier spécialement pour cette requête. La fermeture de la fenêtre de dialogue génère une enveloppe numérique transmise immédiatement au routeur de l'entreprise qui s'occupe de l'envoi au serveur centralisateur.
Les documents reçus par le serveur centralisateur sont mémorisés dans une base de données spécifique pendant une durée minimale définie par le prestataire de service. Cette durée est d'au moins un jour. Dans le cas où l'expéditeur l'a demandé dans les paramètres d'envoi, il est possible d'archiver les informations concernant l'envoi pendant une durée au moins dix fois supérieure à la durée minimale. Cette option d'archivage permet de conserver des traces de tous les MARS durablement. Avantageusement pour le prestataire de service, la première durée minimale est gratuite, alors que l'extension de durée est payante. Il est également possible pour l'expéditeur de définir un prix d'extension à partir duquel le serveur centralisateur calcule la durée d'archivage supplémentaire à laquelle il a droit. Eventuellement, les données concernant les adresses d'expédition et du destinataires, ainsi que l'enveloppe numérique, peuvent avoir une durée de vie limitée. Il est alors possible de réaliser des statistiques sur tous les éléments des MARS transmis.
Le serveur est en fait hébergé chez un huissier de justice au sein de son étude. L'huissier procède au séquestre de l'enveloppe numérique et à la création d'un identifiant numérique unique clef principale d'entrée du certificat de vie. Il est le gardien de la confidentialité des informations contenues dans le futur MARS. Il est à même de procéder à la création d'une ampliation, c'est-à-dire de la copie certifiée conforme du MARS conservé.
Dans le cas où le document n’aurait pas pu être délivré (pour un problème de format par exemple ou de délai de validité dépassé), un message est envoyé par la plate-forme à l'expéditeur du MARS directement sur son gestionnaire de messagerie.
Dès retour de l’avis de réception du MARS par la plate-forme, un second message peut informer l’utilisateur (s’il le désire) de la disponibilité de ce document et des paramètres de durée d’archivage de la version numérique du document original chez l’huissier de justice.
Dans le cas d'un retour d’un MARS (NPAI - n'habite pas à l'adresse indiquée) ou d'une signalisation d'erreur par le routeur ou le fournisseur d’accès au réseau Internet (spoliation, destruction, par exemple), une indication est tout de suite portée sur le certificat de vie. Dans la variante ou l'avis de réception ne serait pas arrivé, la plate-forme d'envoi mettra tout en oeuvre pour informer le poste informatique de l’expéditeur d'un incident et d'y trouver une réponse efficace et satisfaisante pour l'expéditeur. La plate-forme agit en toute transparence en lieu et nom de l'expéditeur.
Lors de la première utilisation du service, l'expéditeur envoie un mèl vide à une adresse prédéfinie et reçoit un fichier informatif lui expliquant le processus à suivre afin de s’inscrire et de transmettre simplement un document par un second message à la plate-forme. Il lui sera alors proposé de faire un compte de dépôt afin de lui éviter de décliner ses références bancaires systématiquement. Toutes les informations concernant les transactions effectuées et l'archivage peuvent être mémorisées dans une base de données, éventuellement intégrée au serveur centralisateur.
Si l’utilisateur se trouve sur un réseau local au sein d’une structure, il lui sera facile de cliquer sur une icône de son traitement de texte afin de réaliser automatiquement la création de l’enveloppe numérique du MARS en question.
Dans le cadre d'entreprise où le nombre de MARS est important, la plate-forme est en mesure d’archiver ces documents entrants sur plusieurs années en fonction des besoins de l'entreprise.

Les différents acteurs entrant en jeu dans des envois de MARS sont explicités ci-dessous.
Le salarié connecté à un réseau LAN clique sur une icône sur son terminal habituel. Apparaît alors une fenêtre de dialogue lui demandant les coordonnées de son destinataire et les éventuels paramètres de son profil utilisateur qu’il souhaite modifié. Une fois les données rentrées, une icône de validation lui permet de transformer sa requête en une enveloppe numérique transmise immédiatement à la plate-forme. En fonction de sa hiérarchie au sein de l’entreprise, il lui est possible de se connecter sur le site Web et de suivre en direct ses MARS. L’administrateur système de son entreprise lui aura donné un identifiant et un mot de passe dans ce sens.
L’internaute se connecte sur un site d'envoi de MARS par l’entremise de son navigateur habituel. S’il est nouveau, il devra compléter un rapide formulaire donnant ses coordonnées, ses préférences d’envoi, son numéro de carte bancaire, son mèl et ses priorités d’envoi (confidentiel, remise tardive, cryptage PGP, etc.) La page HTML sécurisée sera transmise à la plate-forme pour validation (création d’un certificat utilisateur, création d’un compte par l’attribution d’un identifiant et d’un mot-de-passe).
Il n’aura plus qu’à passer une requête d’envoi d’un MARS pour initier son compte. Pour suivre son MARS à la trace, il lui suffira de se connecter sur son compte sur le site Web ou alors de faire une simple demande par mèl en donnant le code identifiant de son MARS comme clef. Quelques secondes après, il pourra avoir le tracking complet de son document.
L’huissier de justice possède un terminal de consultation de l’ensemble des documents (enveloppes numériques MARS et certificats de vie) qui sont sur le serveur centralisateur depuis l’ouverture du service. Toutes les fois qu’un MARS arrive, il en fait un séquestre, attribue un identifiant unique et vérifie l’intégrité des informations consignées. Sur requête de l’expéditeur ou d’une Cour de justice, il est à même d’établir un procès-verbal relatif à un certificat de vie et/ou un MARS donné. Il est seul habilité à ouvrir une enveloppe électronique émise par un expéditeur donné.
Le technicien logisticien voit arriver les enveloppes numériques de requête. Il est en charge du bon état de lisibilité de chaque MARS. En cas de problème informatique, il applique strictement les consignes de travail qui lui sont imposées. Chacun de ses gestes est pris en compte pour l’écriture d’une ligne dans le certificat de vie du MARS considéré (début de l’envoi par le routeur initial, fermeture du contenant, etc.).
Le responsable du centre d’appels ou des alertes reçoit tous les matins plusieurs centaines de messages d’alerte lui donnant l’état des éventuelles erreurs de routage, fausses directions, NPAI. Il a la charge de vérifier qu’elles aient bien été traitées et d’amender le certificat de vie du mèl correspondant. En cas où l’avis de réception ne serait pas arrivé selon un délai raisonnable (généralement de cinq heures), il a le devoir d’émettre une alerte qui sera incluse dans le certificat de vie. Outre cette tâche de complétude du certificat de vie, il réponds aux réclamations téléphoniques techniques des clients et/ou prospects.
Le destinataire reçoit par l’entremise de son navigateur Internet habituel son mèl avec la demande d’avis de réception. Il accepte ou non de recevoir sa missive et émet éventuellement les restrictions liées à l’authentification visuelle de l’enveloppe électronique. Il lui est possible de refuser son MARS qui reviendra ainsi à l’expéditeur. Il est en mesure de joindre le service client pour répondre à toutes les questions ou interrogations qu’il pourrait avoir.
Le responsable Internet/réseaux a la charge d’expliquer le concept de MARS à remise sécurisé aux responsables informatiques et télécommunications des entreprises dont il a la charge. Dans le cas d’un grand compte, il est en mesure de porter un regard sur les problèmes de garde-barrières. De plus, il est en charge de la gestion des incidents de la plate-forme, de l’évolution des formats des fichiers ainsi que des évolutions produits.

Le code de stockage des mèls est alphanumérique et comporte 13 caractères. Les deux premiers sont RE (R comme Recommandé et E comme Email). Les caractères 3 à 10 sont numériques. Il ne doit pas y avoir deux numéros identiques dans une même journée pour un couple expéditeur-destinataire donné. Le caractère 11 représente le caractère de contrôle du numéro – Modulus 11 pondéré du facteur 86423597, la 11e position de la clef étant le chiffre. Les caractères 12 et 13 sont toujours le code ISO du pays de l’expéditeur sur deux caractères (FR pour France).

La présentation ne doit pas comporter d’espace vide. Un exemple : RE102823740FR.
Le caractère de contrôle en position 11 a essentiellement deux raisons d’être. Son principal objet est de permettre à l’ordinateur de déceler toute erreur humaine qui peut avoir ét écommise dans le cas où le code a été saisi manuellement. En outre, il permet de vérifier que le code exploré électroniquement est lu correctement. Il fait partie du numéro. Il est tiré d’une partie des autres caractères de ce numéro et il est calculé d’après une formule mathématique entre le caractère de contrôle et les autres caractères, si un rdinateur lit mal un caractère l’erreur apparaît.

La formule de calcul utilisée est désignée sous le nom de Modulus 11 R5R pondéré, car elle implique l’application de facteurs de pondération aux caractères initiaux, l’addition de leurs valeurs, la division de cette somme par 11, et la soustraction du reste de 11.

La formule est la suivante :
· appliquer les facteurs de pondération aux chiffres de base en utilisant le facteur 86423597,
· faire la somme des nombres obtenus,
· diviser cette somme par onze,
· si le reste est égal à zéro, utiliser cinq comme chiffre de contrôle,
· si le reste est égal à un, utiliser zéro comme chiffre de contrôle,
dans les autres cas, soustraire le reste de 11 et utiliser le chiffre obtenu comme chiffre de contrôle.

Exemples de calcul :

Nombre imprimé 1 0 2 8 2 5 7 4
Pondération x 8 6 4 2 3 5 9 7
TOTAL 8+0+8+16+6+25+63+28 = 154
154/11 = 14 reste 0
chiffre de contrôle : 5
Nombre autocontrôlé complet : 102825745.


Protocole DVCS
Loin de vouloir remplacer les produits actuels, nous nous sommes attachés à compléter l'infrastructure de certification existante afin que soit spécifié un standard pour répondre à une partie significative des besoins ci-dessus. Peter Sylvester d’EdelWeb est le co-auteur et l'éditeur de la norme RFC 3029 DVCS (Data Validation and Certification Services).
A titre d'illustration, tentons de décrire, plus que la spécification DVCS que l'on trouve à l'adresse suivante: http://www.ietf.org/rfc/rfc3029.txt, les raisons et caractéristiques de ce protocole.

Le protocole DVCS repose sur un double modèle : d'une part un modèle de document et d'autre part un modèle d'interaction avec un service. Le modèle de document reprend les exigences évoquées ci-avant. A ce jour, il repose sur CMS (Cryptographic Message Syntax), la partie de S/MIME v3 qui ne concerne que les documents à l'exclusion des problèmes de transport.
Bientôt, dès que les standards seront stabilisés, une forme équivalente, basée sur le format XML, sera spécifiée. Le modèle d'interaction avec le service est extrêmement simple : il s'agit d'un modèle de type "question/réponse" dans lequel, sans besoin de session, une requête peut être soumise au service qui génère une réponse. Le format de la requête est décrit dans la norme. La réponse est une attestation DVCS (format CMS) qui peut donc être traitée et conservée comme un document de type "attestation dématérialisée".
La conception de ce protocole découle de la nécessité, en plus des infrastructures de certificat (CA, PKI), d'offrir aux utilisateurs des fonctions complémentaires telles que :
- Le certificat C1 était il valable à la date T1?
- Le document D signé par U1 et U2 dont les certificats sont respectivement C1 et C2 est-il valable (hors sémantique de contenu) ?
- Le document D signé par U1 et U2 dont les certificats sont respectivement C1 et C2 était-il valable (hors sémantique de contenu) à la date T ?
Mieux encore : délivrez-moi une attestation (un document dématérialisé horodaté et signé) prouvant que à la date D1 j'ai bien effectué la demande de "vérification de la validité" du document D.

En prolongeant cette logique on arrive à : « délivrez-moi une attestation dématérialisée témoignant que le document D existait à la date T » ou « délivrez-moi une attestation témoignant que moi utilisateur U j'étais bien en possession du document D à la date T » ;
Pour aboutir finalement à un service générique de délivrance d'attestations dématérialisées en ligne (on peut donc envisager les équivalents des "certificats non gage", "attestation d'activité salariée", etc.).

Descriptions protocoles MARS
La solution proposée s'appuie sur des produits des postes clients (logiciel de messagerie) communiquant selon des protocoles normalisés entre eux et avec le système d'enregistrement d'évènements.
Le protocole utilisé entre des logiciels de messagerie utilise l'échange des avis de réception défini par le RFC 2643 (ESS).
L'interface avec le système d'enregistrement des événements utilise le protocole suivant. Trois événements sont traités:
- La création/émission d'un message ;
- La réception d'un message et la création d'un avis de réception ;
- La réception d'un avis de réception.

A la fin de la création d'un message le logiciel prépare une requête DVCS du type ccpd (certify claim possession of data) ou cpd (certify possession of data). Le premier type est une requête d'horodatage, le deuxième type correspond à une requête d'archivage. Le choix entre les deux requêtes est laissé libre à l’utilisateur. Les données à horodater/archiver sont le contenu du message. Le champ requester est renseigné avec l'adresse email de l'émetteur, le champ datalocations est renseigné avec les adresses des destinataires.

Le résultat de cette requête est un data validation certificat DVC, un document en format CMS. Le DVC est inclus dans le message dans la demande d'avis de réception.
Pendant la réception du message et la génération d'un avis de réception, le logiciel de messagerie prépare une requête de validate signed data DVCS. Le document à valider est le DVC inclus dans le message. Le champ requester est renseigné avec l'adresse email du destinataire.
Le résultat de cette requête est un data validation certificat DVC. Ce document en forme CMS est envoyé à l'émetteur avec l'avis de réception.
Pendant la réception d'un avis de réception, le logiciel prépare une requête de validate signed data DVCS; le document à valider est le DVC inclus dans l'avis de réception. Le champ requester est renseigné avec l'adresse email de l'utilisateur (émetteur du message original).

En outre, l'émetteur et chaque destinataire peuvent interroger le système d'événements à chaque instant pour déterminer l'état d'avancement d'un message :
L'émetteur peut préparer une requête DVCS du type validate signed data. Le document à valider est le DVC obtenu pendant l'envoi du message initial. Le résultat est un DVC qui contient l'ensemble des DVC produit pendant chaque réception du message et des avis;
Un destinataire peut préparer une requête DVCS du type validate signed data. Le document à valider est le DVC obtenu pendant la création de l'avis de réception. Si l'émetteur du message initial à reçu l'avis de réception, le résultat contient le DVC crée à cette action.
Le rôle du système d'enregistrement d'événements est de créer des attestations correspondant aux événements décrit ci-dessus. Le système stocke ces données pendant une durée configurable. Les données stockées sont les requêtes et réponses DVCS pour l'horodatage, et les requêtes sans données et les réponses en cas d'archivage.
L'ensemble des données stockées est transféré régulièrement au système de suivi.


REVENDICATIONS

1 - Procédé d'envoi de mèl à au moins un destinataire spécifique, comportant une étape de création d'une enveloppe numérique comportant au moins un élément d'identification de l'expéditeur, le contenu du mèl et les éléments permettant l'acheminement du mèl au destinataire spécifique, une étape de transmission par un réseau numérique de ladite enveloppe numérique à une plate-forme comportant un serveur centralisateur, ladite plate-forme effectuant la création d'un mèl comportant les informations liées au destinataire dudit mèl et le contenu électronique, et la transmission du mèl par l’entremise d’un fournisseur d’accès Internet, caractérisé en ce qu'il comporte en outre une étape de mémorisation des éléments contenus dans l'enveloppe numérique et des informations concernant le destinataire du courrier, ladite mémorisation étant systématiquement effectuée pendant une première durée d'au moins un jour, et, lorsque l'enveloppe numérique comporte une séquence d'instruction de conservation, pendant une seconde durée d'archivage au moins dix fois supérieure à ladite première durée, le procédé comportant en outre un étape accessoire de délivrance d'un certificat comportant les informations archivées relatives à un courrier spécifique, cette étape étant activée par une requête émise par l'expéditeur de ladite enveloppe numérique.

2 - Procédé d'envoi de mèl selon la revendication 1 caractérisé en ce qu'on mémorise en outre les informations concernant la remise du mèl au destinataire spécifique ainsi que son éventuelle volonté de refuser le mèl avec demande d’avis de réception et suivi (MARS).

3 - Procédé d'envoi de mèl selon la revendication 2 caractérisé en ce que les informations de remise du mèl comprennent une identification certaine du récepteur du mèl.

4 - Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que la mémorisation du contenu de l'enveloppe numérique utilise des moyens de certification de date et de contenu.

5 - Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que l'on crée un journal des actions effectuées depuis la réception de l'enveloppe numérique et en ce que l'on donne un accès à ce journal à l'expéditeur de l'enveloppe électronique.

6 - Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que le serveur centralisateur envoie une notification de réception de l'enveloppe numérique à l'expéditeur de ladite enveloppe.

7 - Procédé d'envoi de mèl selon la revendication 6 caractérisé en ce ladite notification, comprend la liste des éléments reçus et invite à compléter l'enveloppe numérique s'il manque des éléments nécessaires à l'envoi du mèl avec demande d’avis de réception et suivi (MARS).

8 - Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que l'expéditeur utilise un moyen d'identification certaine pour l'envoi de l'enveloppe numérique.

9 - Procédé d'envoi de mèl selon la revendication 8 caractérisé en ce que l'expéditeur transmet les documents au serveur centralisateur par un moyen de télécommunication activé par le serveur centralisateur après identification de l'expéditeur.

10 - Procédé d'envoi de mèl selon la revendication 8 ou 9 caractérisé en ce qu'il comporte une étape d'authentification de l'expéditeur par des moyens téléphoniques, biométriques ou iridologiques.

11 – Procédé de conservation de mèl selon l’une quelconque des revendications précédentes caractérisé en ce qu’il comporte un horodatage universel non répudiable et un processus de mise à niveau de la lisibilité du contenu des mèls avec demande d’avis de réception et suivi (MARS) durant toute la période d’archivage demandée à la création de ce MARS par l’expéditeur.

12 - Interface pour la mise en œuvre du procédé d'envoi de mèl selon la revendication 1, permettant la saisie de l'enveloppe numérique à envoyer.

12. - Procédé de réception de mèl selon l’une quelconque des revendications précédentes caractérisé en ce que l’on procède de la façon exactement contraire au procédé décrit dans la revendication 1, c’est-à-dire que le destinataire d’un mèl simple est en mesure de demander l’authentification horodatée avec conservation de ce mèl selon ses propres critères personnels, mais selon les caractéristiques MARS.

Libellés : ,

Ourdissons contre la viande chevaline

Alors que je me rendais à l'Hôtel Régina, un grand panneau publicitaire à deux pas du Ministère de la Culture attira mon regard. Deux images s'opposaient: 3 chevaux courant sur un champs de courses (image titrée OK) et celle d'un steack de viande rougeâtre à l'étal d'une mauvaise supérette de quartier (image titrée KO). En signature de ces deux images (3 canassons suant d'effort et une escalope sanguinolante), une adresse URL en grosse lettre rouge: "je ne mange pas de cheval". A qui devons-nous cette campagne insolente contre une des viandes les plus agréable en steack haché, malheureusement interdite en restaurant par un sournois décret d'hygiène publique? La Fondation Brigitte Bardot, 28 rue Vineuse, dans le chicissime 16e arrondissement de Paris (75). Cette campagne a pris le soin de réserver le nom de domaine signature de l'affiche avec les TLD de type .biz, .info; .com, .eu, .net et .org... dans le cas où nous n'aurions pas compris que cette campagne était sponsorisée par les vendeurs de viande d'autruche!

Libellés : ,

Association loi 1901 pour l’excellence en matière de recherches sur le nombre d’or en philologie musicale

JEAN-BERNARD CONDAT
Association loi 1901
Siège social : 47 rue des Rosiers, B.P. 59, 93402 Saint-Ouen Cedex


STATUTS
AU 22 JUILLET 2007


Article 1er – Formation
Il est fondé entre les adhérents aux présents statuts, une association régie par la loi du 1er juillet 1901 et le décret du 16 août 1901, ayant pour titre : «Jean-Bernard CONDAT».

Article 2 – Objet
L’association entend contribuer à l’excellence en matière de recherches sur le nombre d’or en philologie musicale.

Article 3 – Moyens
Pour réaliser son objet, l'association met en place tout dispositif nécessaire, notamment l'organisation de groupes de travail et de recherche, d'éditions et de publications et de productions techniques d’expositions. L'association peut engager des actions de formation.

Article 4 – Siège social
Le siège social est fixé au 47 rue des rosiers, B.P. 59, 93402 Saint-Ouen Cedex. Le siège social pourra être transféré par simple décision du Conseil d'Administration. La ratification par l'Assemblée Générale est nécessaire.

Article 5 – Durée
L’association est créée pour une durée illimitée.

Article 6 – Les membres
Sont membres, les spécialistes de philologies musicales du monde entier et les personnes morales intervenant dans le domaine de la musicologie ou de l’esthétique. Chaque personne morale est représentée par son Président élu ou par un représentant désigné par lui. Les demandes d'adhésion sont soumises à l'acceptation du Conseil d'Administration dont les décisions sont souveraines. La ratification par l'Assemblée Générale est nécessaire.

Article 7 – Radiation
La qualité de membre se perd par :
a) la démission ;
b) la dissolution de l’organisation membre de l’Association ;
c) la radiation prononcée par le Conseil d’Administration pour non paiement de la cotisation ou pour motif grave, l’intéressé ayant été invité par lettre recommandée, à se présenter devant lui pour fournir des explications.

Article 8 – Ressources de l’association
Les ressources de l’Association comprennent :
a) les cotisations et souscriptions des membres, dont le montant est déterminé annuellement par l’Assemblée Générale ;
b) les subventions d’Etat, des Régions, Départements, Communes, de tous types d’établissements à caractère public ;
c) des recettes propres (billetterie, ventes d’ouvrages…) ;
d) des aides en mécénat ;
e) des revenus des biens qu’elle possède ;
f) et de toute autre ressource autorisée par la loi.

Article 9 – Conseil d’Administration, composition
L’association est administrée par un Conseil d’Administration comprenant 2 membres élus par l’Assemblée Générale, parmi ses membres et pour une durée de deux ans. Il se compose d’un Président et d’un Trésorier. En cas de vacance (démission, exclusion…), Le Conseil d’Administration pourvoit provisoirement au déplacement de ses membres. Il est procédé à leur remplacement définitif par la prochaine Assemblée Générale. Les pouvoirs des membres ainsi élus prennent fin à l’époque où devrait normalement expirer le mandat des membres remplacés.

Article 10 – Le Conseil d’Administration, réunions
Le Conseil d’Administration se réunit sur convocation du Président ou des deux tiers de ses membres aussi souvent que l’intérêt de l’Association l’exige et au moins deux fois par an, soit au siège, soit en tout autre endroit du consentement de la moitié des administrateurs en exercice. La convocation est adressée par lettre individuelle, télécopie ou courrier électronique, au moins huit jours à l’avance. La présence au Conseil de la moitié au moins des membres est nécessaire pour qu’il puisse valablement délibérer. Les délibérations sont prises à la majorité des membres présents ou représentés, chaque administrateur disposant d’une voix. En cas de partage des voix, celle du Président est prépondérante. Le vote par procuration est autorisé sans limitation de nombre. Les pouvoirs en blanc sont attribués au Président. Nul ne peut faire partie du Conseil d’Administration s’il n’est pas majeur.

Article 11 – Pouvoirs du Conseil d’Administration
Le Conseil d’Administration est investi des pouvoirs les plus étendus pour gérer et administrer l’Association, dans la limite de son projet et des pouvoirs réservés aux Assemblées Générales. Il se propose sur l’admission des membres conformément à l’article 5, et prend les éventuelles mesures de radiation ou d’extension à leur encontre. Il propose à l’Assemblée Générale le montant des cotisations des membres adhérents. Il propose les grandes orientations de l’Association et rend compte des résultats à l’Assemblée Générale Ordinaire. Il élabore le budget qu’il soumet à l’Assemblée Générale Ordinaire. Le Conseil d'Administration peut inviter des personnalités qualifiées à participer à des groupes de travail, proposition qu’il soumettra à l’Assemblée Générale

Article 12 – Attributions des membres du Conseil d’Administration
Chacun des membres du Conseil d’Administration est spécialement chargé des fonctions suivantes :
- Le Président dirige les travaux du Conseil et assure le fonctionnement de l’Association qu’il représente en justice, tant en demande qu’en défense sans nécessité de mandat préalable et dans tous les actes de la vie civile ; il est chargé d’exécuter les décisions du Conseil d’Administration, de la rédaction des procès-verbaux et de la tenue du registre prescrit par l’article 5 de la loi du 1er juillet 1901 ;
- Le Trésorier tient les comptes de l’Association. Il contrôle les engagements fait par le Délégué Général, fait effectuer sous la surveillance du Président tous les paiements, perçoit les recettes et tient une comptabilité régulière, au jour le jour, de toutes les opérations. Il rend compte à l’Assemblée Générale annuelle qui statue sur sa gestion.

Article 13 – Dispositions communes pour la tenue des Assemblées Générales
Les Assemblées Générales se composent de tous les membres adhérents de l’Association. Elles se réunissent sur convocation du Président de l’Association, à son initiative ou à la demande du quart au moins de ses membres. Les convocations doivent mentionner l’ordre du jour de la réunion arrêté par le Président de l’Association ou par les membres qui demandent la réunion de l’Assemblée et qui doivent communiquer leur proposition, un moins avant la réunion avec la signature du quart au moins des membres. Elles sont faites par lettres individuelles adressées trois semaines au moins à l’avance. Seules sont valables les résolutions adoptées par l’Assemblée sur les points inscrits à l’ordre du jour. La présidence de l’assemblée appartient au Président de l’Association. Le secrétariat de l’assemblée est assuré par le secrétaire. Il établit une feuille de présence qui est signée par chaque membre présent et certifiée conforme par le Président de l’Assemblée. En cas de partage des voix, celle du Président de l’Assemblée est prépondérante.

Article 14 – Nature et pouvoir des assemblées
Les Assemblées Générales régulièrement constituées représentent l’universalité des membres de l’Association. Dans la limite des pouvoirs qui leur sont conférés par les présents statuts, les Assemblées obligent par leurs décisions tous les membres, y compris les absents. Le vote par procuration est autorisé par limitation de mandat. Les pouvoirs en blanc sont attribués au Président. Toutes les délibérations de l’Assemblée Générale sont constatées dans des procès-verbaux établis sur registre particulier qui pourra être le même que celui contenant les procès-verbaux du conseil et signés par le Président et le secrétaire de séance. Les copies ou les extraits de ces procès-verbaux à produire en justice ou ailleurs sont signés par le Président de l’Association et par deux membres du Conseil d’Administration.

Article 15 – Assemblée Générale Ordinaire
Au moins une fois par an, les membres sont convoqués en Assemblée Générale Ordinaire dans les conditions prévues à l’article 13. Les délibérations sont valablement prises à la majorité des voix des membres présents ou représentés. L’assemblée délibère sur les différents points de l’ordre du jour. Elle décide des grandes orientations de l’Association sur proposition du Conseil d’Administration. Elle entend chaque année le rapport du Conseil d’Administration sur sa gestion et notamment sur la situation morale et financière de l’Association. L’assemblée, après avoir délibéré et statué sur ce rapport, approuve ou redresse les comptes de l’exercice clos, vote le budget de l’exercice suivant prend acte des remplacements des administrateurs, pourvoit à leur remplacement, autorise toutes acquisitions nécessaires à la réalisation de l’objet de l’Association, tout échange ou vente ainsi que toutes les questions d’intérêt général et sur toutes celles qui lui sont soumises par le Conseil d’Administration à l’exception de celles comportant des modifications des statuts.

Article 16 – Assemblée Générale Extraordinaire
Si besoin est, ou sur la demande de la moitié plus un des membres inscrits, le Président convoque une Assemblée Générale Extraordinaire, suivant les formalités prévues par l’article 13. L’assemblée ne peut valablement délibérer que si les deux tiers des membres ayant droit de vote sont présents ou représentés. Si cette condition n’est pas remplie, l’Assemblée Extraordinaire est convoquée de nouveau à quinze jours d’intervalle ; elle peut alors délibérer quel que soit le nombre des membres présents. Les délibérations sont prises à la majorité des deux tiers des membres présents ou représentés. L’assemblée Générale Extraordinaire peut modifier les statuts dans toutes leurs dispositions. Elle peut notamment décider dans les mêmes conditions la dissolution anticipée de l’Association ou son union avec d’autres associations.

Article 17 – Exercice social
L’exercice social est de 12 mois. Il débute le 1er janvier et se termine le 31 décembre.

Article 18 – Règlement intérieur
Un règlement intérieur pourra être établi par le Conseil d’Administration. Il devra être approuvé par l’Assemblée Générale.

Article 19 – Dissolution
En cas de dissolution volontaire, statutaire ou forcée de l’Association, l’Assemblée Générale Extraordinaire désigne un ou plusieurs liquidateurs qui jouiront des pouvoirs les plus étendus pour réaliser l’actif et acquitter le passif. Le produit net de la liquidation sera dévolu à une association ou à tout établissement public ou privé d’intérêt général désigné par l’Assemblée Générale Extraordinaire. Les présents statuts ont été adoptés en assemblée générale tenue à Saint-Ouen, le dimanche 22 juillet 2007.

sous la présidence de : Jean-Bernard CONDAT, président
Assisté de : Stanislas de ROHAN, trésorier.

Signatures
Fait à Saint-Ouen, le 22 juillet 2007

Libellés : , ,