البـــــوابـــة
Les documents tiennent une place importante dans l'entreprise, 82 % d'entre elles affirment même que cette place est cruciale dans la réussite de leur organisation. C'est ce qui ressort d'une étude réalisée par IDC pour le lyonnais Esker, leader mondial de la dématérialisation des documents, et publiée sous forme d'un livre blanc.
Si cette importance est acquise, il ressort pourtant que la majorité des entreprises ne savent pas identifier exactement les volumes de documents qui entrent et sortent de l'entreprise, et moins encore évaluer le coût global de ces flux. Pourtant, selon IDC, les directeurs financiers auraient évalué le coût annuel de la gestion des documents entre 5 % et 15 % du chiffre d'affaires ! En apportant des solutions permettant de réduire l'usage du papier au niveau des processus de gestion et de communication de l'entreprise, mais aussi de créer des documents personnalisés plus rapidement et plus efficacement, la dématérialisation s'impose pour maîtriser les flux de la gestion des documents. IDC a ainsi relevé les problématiques d'origine des projets de dématérialisation : la volonté de réduction des coûts, le recentrage de l'activité des collaborateurs sur le c?ur de métier de l'entreprise, la refonte de système d'information, le besoin d'automatiser les tâches récurrentes, l'accélération de certains processus (réduire le temps des saisies manuelles et prévenir les erreurs humaines), la mise en conformité et la gestion des baisses d'effectifs. Mais pour cela, il faudra maîtriser les canaux de diffusion qui se sont multipliés Certes, l'essentiel des volumes porte encore classiquement sur les envois postaux et le fax, mais les nouveaux médias électroniques - messageries, Web, flux XML, SMS - ne cessent de progresser. L'entreprise devra s'équiper de systèmes de diffusion multicanaux et multimédia de documents. Ainsi que d'interfaces avec les applications de gestion. De son étude, IDC a tiré un certain nombre d'avantages liés à l'interfaçage : disposer des informations relatives à un client dans un même dossier, automatiser des tâches de saisie, intégrer les documents papier dans un flux de tâches électroniques, mettre en forme et personnaliser les documents ou les flux émis par les applications de gestion, réconcilier les données en rapprochant documents entrants et sortants, remonter les statuts d'émission directement dans les applications de gestion. Quels seront les bénéfices pour l'entreprise ? IDC en a identifié quatre : - L'automatisation des tâches C'est l'impact directement visible car elle va entraîner rapidement une diminution des coûts pour l'entreprise, une réduction des erreurs et indirectement une création de valeur. - La personnalisation de documents et de leur envoi L'entreprise va améliorer son image par la pertinence des informations communiquées et par leur présentation. - La réactivité de l'entreprise Grâce à l'intégration des outils composant le système de gestion documentaire. - La gestion de l'ensemble des processus Avec une solution globale qui va de la réception à la diffusion, en passant par la mise en forme, l'archivage et la traçabilité des envois de documents.
Un marché d'avenir
La dématérialisation est l'un des rares marchés informatique dont la croissance s'annonce supérieure à 20 %. IDC évalue cette progression au niveau mondial à 24,2 % en 2006 pour les ventes de licences et la maintenance au niveau mondial. Et 22,7 % jusqu'en 2009. Le chiffre d'affaires dégagé devrait donc atteindre 601 millions de dollars en 2006 et 1.662 millions et 2009. C'est le secteur de la création et de la diffusion de contenu personnalisé qui devrait être le plus dynamique, avec une croissance moyenne de 27,2 % entre 2005 et 2009, contre 16,6 % pour la LAD (lecture automatique de documents. Pour comparaison, le marché des applicatifs (ERP, CRM, BI) devrait, selon IDC, enregistrer une croissance annuelle moyenne sur la même période de 5,7 %, pour passer de 104 milliards de dollars en 2005 à 130 milliards en 2009
La dématérialisation des documents et de leurs échanges, quelques réflexions
--------------------------------------------------------------------------------
L'objectif de cet article de Paul-André Pays est de partager quelques éléments de réflexions concernant les exigences fonctionnelles des solutions à mettre en place pour la dématérialisation des documents et de leurs échanges. Après une analyse des besoins, quelques éléments de solution seront présentés comme une illustration du possible en la matière. On trouvera notamment une brève présentation du protocole DVCS (RFC3029), protocole pour un service générique de validation de documents et de délivrance d'attestations dématérialisées.
Contexte et Objectifs Rappels sur quelque mécanismes de base Exigences pour une infrastructure de documents dématérialisés Protocole et service DVCS (RFC3029) Conclusion
Contexte et Objectifs
Quelques semaines après la parution du décret d'application du 30 mars 2001 portant sur la signature électronique, il est grand temps de se poser la question de la reconnaissance de la valeur légale des documents et des échanges dématérialisés. En effet le manque de maturité, pour ne pas dire le manque d'adéquation aux besoins des produits actuellement disponibles ne permet pas de se dire qu'il suffit ou suffira d'utiliser les produits du marché et qu'il sera possible de faire l'économie de cette réflexion. Les documents et les échanges qui nous concernent ici sont les documents et les échanges "professionnels" au sein d'une entreprise ou d'un organisme et ceux échangés "formellement" entre organismes.
Cet article ne vise pas à présenter les technologies ou les services de base (dont un minimum de connaissance est supposé connu), mais plutôt à partager quelques réflexions sur "comment les utiliser".
La demande du marché n'est donc pas celle de la reconnaissance de la signature -ce que couvre la loi et les décrets qui sont indispensables- mais bien celle de la reconnaissance de la valeur des documents, documents dématérialisés qu'ils soient mémorisés ou échangés et ce qu'elle qu'en soit le medium (échange par email, par web, par envoi de disquette ou CD, etc...).
Enfin, on peut considérer que l'objectif principal de cet article est que, devenant un acteur averti, chaque lecteur devienne un acheteur très exigeant et force ainsi les offreurs à améliorer sérieusement leurs solutions et à ne pas se contenter des produits très faibles et insuffisants qu'ils osent prétendre nous convaincre d'acheter.
Cet article reprend partiellement et prolonge une présentation donnée lors de la conférence TET2000 (Trusting Electronic Trade) dont le support est accessible par http://www.edelweb.fr/EdelStuff/EdelPages/TET2000/.
Rappels sur quelque mécanismes de base
Signature numérique: Elle repose sur l'utilisation de la cryptographie asymétrique (type RSA), elle consiste à attacher à un document un complément d'information -la signature- qui :
Ne peut avoir été produit que par un utilisateur bien identifié, titulaire d'un bi-clé dont il utilise la clé privée, et ne pouvant donc pas répudier cette signature (sémantique de type "lu et approuvé" ou "persiste et signe")
Permet -par chiffrement d'un condensat (hash) du message- de vérifier l'intégrité du document et donc de détecter tout changement fortuit ou malveillant intervenu depuis "l'apposition de la signature".
La signature numérique est à ce jour la seule forme de signature électronique connue et donc éventuellement à même de répondre aux exigences et caractéristiques de la directive européenne et de sa transposition en droit français. NOTA : il n'existe pas de forme de signature électronique reposant sur une caractéristique biométrique ou sur la graphie d'une signature manuscrite, mais ceci est un autre débat, voire une autre croisade que nous ne manquerons pas d'aborder dans un prochain numéro. La biométrie est une excellente base de l'authentification de personnes, mais ne peut sous-tendre un service de non-répudiation (caractéristique essentielle d'une signature).
Certification - Certificat de clé publique : La certification est le moyen indispensable qui permet d'associer (garantir le lien entre) un possesseur de clé privée d'une part et une identité d'autre part. On conçoit bien que -informatique ou pas- il ne suffit pas d'une auto-proclamation pour apporter à ses interlocuteurs la preuve que l'on est bien celui qu'on prétend être. Il faut disposer d'une forme d'attestation "le certificat", établie par une "autorité" reconnue (l'Autorité de Certification), qui garantit que le possesseur de la clé privée utilisée pour la signature est bien l'utilisateur (le seul) dont l'identité est donnée dans le certificat.
NOTA : Savoir quelle est la "bonne Autorité" dans un contexte donné est à la fois crucial mais hors du champs de cet article. Indiquons toutefois qu'il n'y a pas de vérité unique et que se contenter de prendre telle quelle la liste des CA livrées avec les produits est certainement la pire des méthodes. Il revient aux responsables d'un organisme ou d'une communauté de définir quelles autorités --pas forcément des prestataires de service de certification à la Verisign- et quels certificats sont "utilisables" dans chaque contexte applicatif.
Horodatage -- Estampille horaire : Mécanisme permettant de disposer d'une attestation dématérialisée indiquant l'heure de référence et émise par une source "une Autorité" reconnue. En pratique, l'heure de référence est cryptographiquement signée par la TSA (Time Stamping Authority).
Exigences pour une infrastructure de documents dématérialisés
Prenons un exemple de document "formel" en contexte professionnel pour identifier les différents éléments qui contribuent à sa "validité" et dont nous devrons retrouver les équivalents, d'une façon ou d'une autre dans un document dématérialisé.
Une rapide observation permet d'identifier les éléments suivants :
Un contenu : C'est la raison d'être de tout document. Ce contenu peut être plus ou moins structuré (un objet, un corps) et contenir des composants de nature différents et dans différentes représentations tel que du texte (word, ou RTF ou HTML par exemple) ou des graphiques. Nous ne nous intéressons pas ici au contenu dès lors qu'il en existe une représentation informatique permettant la dématérialisation de l'échange.
Une forme d'identification entreprise (Nom, Logo ; Siège Social, Capital, RCS et souvent un "tampon") dont une partie est imposée par la loi. N'oublions pas que quel que soit l'employé qui signe c'est d'abord la responsabilité de la personne morale qui est engagée. Il est donc normal et indispensable que les informations permettant d'identifier cette structure juridique soient présentes dans le document.
Une ou plusieurs signatures : Dans le cas présent, nous y trouvons la signature de l'auteur et le visa d'un directeur. On sait qu'il existe fréquemment dans les entreprises des règles imposant la double signature à partir d'un certain niveau d'engagement ; un contrat est signé par au moins un représentant de chacune des parties ; un "procès-verbal" de délibération sera signé par un président, un secrétaire et au moins un assesseur. Ce qu'il convient de retenir c'est que
il convient de permettre plusieurs signatures, li>qu'il est prudent de ne pas viser une sémantique universelle des signatures (les multiples formes de signature, contre-signature, visa, etc...) et se contenter de permettre ces signatures.
Une ou plusieurs dates : on peut dans l'exemple distinguer la date d'établissement du document, la date d'apposition du visa. On pourrait également y trouver une date de "prise en compte". Là encore, bornons nous à souligner qu'il faut savoir inclure de multiples dates sans se préoccuper outre mesure de leurs sémantiques respectives. Notons cependant que l'ETSI (en charge d'établissement de standard européens en la matière) vient de reconnaître qu'une signature sans date n'apportait rien -- en version dématérialisée également-.
Une référence : ce qu'il convient d'observer à ce niveau c'est que la raison d'être de cette référence est le fait que l'entreprise émettrice garde un "double" des documents formels envoyés à des tiers (c'est normal, ce sont ses engagements -- autant les connaître-) et qu'il est donc possible de retrouver le double du document "Ref. RxxxXXXX", même en l'absence de son auteur. Retenons l'existence d'une archive "entreprise" jouant un rôle essentiel. Notons en outre qu'en cas de chiffrement en confidentialité, il est fondamental pour un organisme de disposer, sous une forme ou une autre d'un mécanisme de recouvrement permettant à sa structure (entreprise, administration...) en cas d'indisponibilité de la personne ayant "les clés" d'avoir accès au document concerné.
Implicitement des règles et procédures : Ces règles et procédures régissent les conditions dans lesquelles les personnels de la société peuvent prendre des engagements au nom de la structure ; Notons que cela peut venir de divers niveaux depuis les statuts (clause limitation des pouvoirs du président) jusqu'à des engagements contractuels vis à vis de clients ou fournisseurs en passant par le règlement intérieur. De façon symétrique, il existe --parfois en partie implicitement- dans la structure des règles et procédures qui "disent" comment traiter et reconnaître les documents venant de l'extérieur. Parmi ces règles notons celles concernant la production de documents confidentiels dont typiquement un exemplaire doit être déposé au coffre dans une enveloppe indiquant dans quelles conditions et qui peut en prendre connaissance.
Une simple lecture de ce qui précède apporte une liste d'exigences minimales pour toute solution de dématérialisation utilisable en contexte professionnel. Elle peut se résumer comme suit :
Capacité du système à indiquer, en plus d'un utilisateur signataire la structure (entreprise, organisme) au nom de laquelle le document est établi.
Capacité du système à accepter de multiples signatures (pour les apposer ou les vérifier). Ces signatures doivent pouvoir être datées.
Capacité du système à se servir d'un service d'horodatage à partir d'une source reconnue: il ne suffit pas de distribuer l'heure, encore faut-il la lier avec le document ou un événement (signature).
Capacité du système à respecter et faire respecter (i.e. imposer aux utilisateurs) la politique de sécurité et de confiance de l'organisme lors de la réception de documents dématérialisés ; c'est la traduction informatique d'une partie des règles et procédures évoquées ci-dessus : celle qui traite des exigences concernant la reconnaissance des autorités de certification, les certificats acceptables, et plus généralement des exigences autour de la forme des documents dématérialisés.
Capacité du système à respecter et faire respecter les règles de sécurité et de confiance lors de la production de documents destinés à l'extérieur.
De ce qui précède, chacun peut facilement déduire une première série d'exigences et de critères quant aux services fonctionnels des solutions.
Avec une pointe d'esprit critique :-) on peut également s'apercevoir que concernant les produits actuels qui prétendent offrir ce qu'il faut pour la dématérialisation, si ils savent effectivement d'un point de vue technique apposer ou vérifier une signature numérique, ils sont en revanche bien loin de satisfaire à la majorité des critères évoqués.
Une autre exigence, un peu moins évidente, mais fondamentale pour un service de dématérialisation, concerne les moyens disponibles pour "vérifier la validité" des documents dématérialisés ; c'est tout aussi nécessaire pour les documents reçus de l'extérieur que pour ceux repris après archivage pendant une certaine durée :
Il n'est évidemment pas question ici de s'occuper des éléments sémantiques qui conditionnent cette validité (par exemple : M. Untel est habilité à signer des commandes jusqu'à un montant de 50 000 Euros, ou ne pas accepter les commandes de la société XXX tant qu'elle ne nous a pas réglé ses dettes) mais uniquement de ce qui peut et normalement doit être "automatisé"
Il faut donc que le système soit capable de vérifier la validité technique (conformité à la spécification) d'une signature ; tous les produits savent le faire aujourd'hui.
Il faut également que le système soit capable de connaître --dans le contexte applicatif donné- quels sont les Autorités et les Certificats "acceptables" ou "reconnus" par l'organisme. Ce n'est pas vraiment le cas aujourd'hui puisque les produits utilisent une base d'AC prédéfinie par l'éditeur du logiciel et modifiable par chaque utilisateur : il est donc impossible de mettre en place simplement le respect de la politique (les choix) de l'organisme en la matière. Seul un système permettant à l'organisme (via un administrateur habilité) de modifier cette base de référence et interdisant à chaque personnel d'y toucher permettra de respecter cette exigence.
Il faut que le système permette de vérifier la validité d'un document dématérialisé longtemps après sa date de production, c'est à dire longtemps après la fin de vie du ou des certificats correspondants aux signatures présentes. Cela impose d'une part la présence d'une estampille horaire incontestable et donc vérifiable dans le document et, d'autre part, l'existence d'un service permettant de vérifier ces éléments qui ne sont plus disponibles sur une simple station utilisatrice puisqu'ils supposent des bases de données de référence possiblement très grandes. Un cas particulier de document à vérifier est un certificat de clé publique : pour cela -- mieux que les CRL (listes de révocation de certificats) dont l'utilisation à grande échelle est irréaliste- des services et protocoles ont été définis récemment, OCSP et DVCS au sein du groupe de travail PKIX de l'IETF (Les fameux RFC de l'Internet : http://www.ietf.org/rfc.html). Le protocole et les services DVCS seront présentés un peu plus loin.
Protocole et service DVCS (RFC3029)
Du constat précédent, plutôt que de baisser les bras devant les manques et faiblesses des 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. Cela s'est traduit par notre contribution significative à l'élaboration du RFC 3029 DVCS : Data Validation and Certification Services (Peter Sylvester de EdelWeb est co-auteur et éditeur de cette norme).
Le point de départ est le constat de la nécessité, en plus des infrastructures de certificat (CA, PKI), d'un service permettant à des utilisateurs d'un organisme (entreprise, communauté de travail, etc...) de disposer de fonctions 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, 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...) EdelWeb a d'ailleurs développé, sous le nom EdelSafe, une architecture complète de solution basée sur ce modèle. Cette base logicielle --déclaration SCSSI en 1998- a servi par la suite à divers projets dont le service démonstrateur Clepsydre pour La Poste qui, outre vérifier la conformité et l'interopérabilité de leurs produits.
NOTES concernant la standardisation IETF en la matière :
Historique : DVCS a été proposé initialement par Entrust dans le contexte PKIX comme une extension du 'time stamp service' et de service de validation de certificat. C'est en raison du refus des auteurs (Verisign) de OCSP de procéder aux extensions souhaitées par le groupe de travail que DCS est devenu DVCS en incluant ces services de validation en ligne.
Les activités du groupe PKIX ne sont pas particulièrement orientées vers la dématérialisation, l'objectif premier du groupe PKIX est de déterminer les profils d'utilisation d'X.509 et de définir les services supplémentaires d'une PKI.
C'est pour cela que, par exemple, la normalisation du time stamping a pris un retard excessif (plus que 4 ans) et que la définition minimaliste de la version actuelle est toujours sujette à de fortes contestations, et est même incomplète (par exemple pour la vérification de la validité d'un time stamp).
Plusieurs activités en cours de normalisation au sein du groupe PKIX concernent les services de validation de certificats: Après OCSP et DVCS, qui ont atteint le stade RFC, de nouvelles approches concurrentes OCSP-V2, SVCP, DPV essaient de répondre à certaines lacunes de OCSP, l'ensemble des drafts RFC dans le domaine témoignent du manque de maturité des efforts et/ou des tentatives de certains industriels d'occuper le terrain.
Le groupe de travail S/MIME de l'ietf semble a priori le meilleur endroit pour discuter des documents dématérialisés et de leurs échanges. Il y a effectivement des propositions comme CMS (cryptographic message syntax) ou ESS (extended security services) qui peuvent être utilisées comme base. Malheureusement, les mécanismes de protection S/MIME sont simplement utilisés comme un moyen d'assurer la sécurité des échanges par messageries (avec des vérifications en quasi temps réel).
Au sein de W3C les activités de standardisation autour de la signature numérique xml (xmldsig) ont pris un grand retard pour plusieurs raisons, et même si les problèmes de canonisation sont en passe d' être résolus, la norme exclut toute sorte de certification, ou plus exactement repose sur des services supplémentaires, par exemple XKMS.
Nous recommandons de se reporter au documents référencés pour une explication simple du modèle (http://www.edelweb.fr/EdelStuff/EdelPages/TET2000/).
Le protocole DVCS
A titre d'illustration, tentons de décrire, plus que la spécification DVCS que l'on trouve dans http://www.ietf.org/rfc/rfc3029.txt, les raisons et caractéristiques de ce 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 équivalent 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 "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".
Conclusion
Nous souhaitons que ce qui précède, sans prétendre à l'exhaustivité, aidera chacun à formuler ses propres exigences et à ne pas se laisser piéger par des discours commerciaux qui tendent à dire : les PKI existent, les produits gèrent S/MIME, tout est là, vous n'avez besoin de rien d'autre.
Nous espérons avoir éveillé votre curiosité et attiré votre attention sur quelques aspects importants de la dématérialisation. Pour en savoir plus et nous contacter, vous trouverez toutes les informations sur notre serveur Web : ou sur les services équivalents du groupe ON-X
Si cette importance est acquise, il ressort pourtant que la majorité des entreprises ne savent pas identifier exactement les volumes de documents qui entrent et sortent de l'entreprise, et moins encore évaluer le coût global de ces flux. Pourtant, selon IDC, les directeurs financiers auraient évalué le coût annuel de la gestion des documents entre 5 % et 15 % du chiffre d'affaires ! En apportant des solutions permettant de réduire l'usage du papier au niveau des processus de gestion et de communication de l'entreprise, mais aussi de créer des documents personnalisés plus rapidement et plus efficacement, la dématérialisation s'impose pour maîtriser les flux de la gestion des documents. IDC a ainsi relevé les problématiques d'origine des projets de dématérialisation : la volonté de réduction des coûts, le recentrage de l'activité des collaborateurs sur le c?ur de métier de l'entreprise, la refonte de système d'information, le besoin d'automatiser les tâches récurrentes, l'accélération de certains processus (réduire le temps des saisies manuelles et prévenir les erreurs humaines), la mise en conformité et la gestion des baisses d'effectifs. Mais pour cela, il faudra maîtriser les canaux de diffusion qui se sont multipliés Certes, l'essentiel des volumes porte encore classiquement sur les envois postaux et le fax, mais les nouveaux médias électroniques - messageries, Web, flux XML, SMS - ne cessent de progresser. L'entreprise devra s'équiper de systèmes de diffusion multicanaux et multimédia de documents. Ainsi que d'interfaces avec les applications de gestion. De son étude, IDC a tiré un certain nombre d'avantages liés à l'interfaçage : disposer des informations relatives à un client dans un même dossier, automatiser des tâches de saisie, intégrer les documents papier dans un flux de tâches électroniques, mettre en forme et personnaliser les documents ou les flux émis par les applications de gestion, réconcilier les données en rapprochant documents entrants et sortants, remonter les statuts d'émission directement dans les applications de gestion. Quels seront les bénéfices pour l'entreprise ? IDC en a identifié quatre : - L'automatisation des tâches C'est l'impact directement visible car elle va entraîner rapidement une diminution des coûts pour l'entreprise, une réduction des erreurs et indirectement une création de valeur. - La personnalisation de documents et de leur envoi L'entreprise va améliorer son image par la pertinence des informations communiquées et par leur présentation. - La réactivité de l'entreprise Grâce à l'intégration des outils composant le système de gestion documentaire. - La gestion de l'ensemble des processus Avec une solution globale qui va de la réception à la diffusion, en passant par la mise en forme, l'archivage et la traçabilité des envois de documents.
Un marché d'avenir
La dématérialisation est l'un des rares marchés informatique dont la croissance s'annonce supérieure à 20 %. IDC évalue cette progression au niveau mondial à 24,2 % en 2006 pour les ventes de licences et la maintenance au niveau mondial. Et 22,7 % jusqu'en 2009. Le chiffre d'affaires dégagé devrait donc atteindre 601 millions de dollars en 2006 et 1.662 millions et 2009. C'est le secteur de la création et de la diffusion de contenu personnalisé qui devrait être le plus dynamique, avec une croissance moyenne de 27,2 % entre 2005 et 2009, contre 16,6 % pour la LAD (lecture automatique de documents. Pour comparaison, le marché des applicatifs (ERP, CRM, BI) devrait, selon IDC, enregistrer une croissance annuelle moyenne sur la même période de 5,7 %, pour passer de 104 milliards de dollars en 2005 à 130 milliards en 2009
La dématérialisation des documents et de leurs échanges, quelques réflexions
--------------------------------------------------------------------------------
L'objectif de cet article de Paul-André Pays est de partager quelques éléments de réflexions concernant les exigences fonctionnelles des solutions à mettre en place pour la dématérialisation des documents et de leurs échanges. Après une analyse des besoins, quelques éléments de solution seront présentés comme une illustration du possible en la matière. On trouvera notamment une brève présentation du protocole DVCS (RFC3029), protocole pour un service générique de validation de documents et de délivrance d'attestations dématérialisées.
Contexte et Objectifs Rappels sur quelque mécanismes de base Exigences pour une infrastructure de documents dématérialisés Protocole et service DVCS (RFC3029) Conclusion
Contexte et Objectifs
Quelques semaines après la parution du décret d'application du 30 mars 2001 portant sur la signature électronique, il est grand temps de se poser la question de la reconnaissance de la valeur légale des documents et des échanges dématérialisés. En effet le manque de maturité, pour ne pas dire le manque d'adéquation aux besoins des produits actuellement disponibles ne permet pas de se dire qu'il suffit ou suffira d'utiliser les produits du marché et qu'il sera possible de faire l'économie de cette réflexion. Les documents et les échanges qui nous concernent ici sont les documents et les échanges "professionnels" au sein d'une entreprise ou d'un organisme et ceux échangés "formellement" entre organismes.
Cet article ne vise pas à présenter les technologies ou les services de base (dont un minimum de connaissance est supposé connu), mais plutôt à partager quelques réflexions sur "comment les utiliser".
La demande du marché n'est donc pas celle de la reconnaissance de la signature -ce que couvre la loi et les décrets qui sont indispensables- mais bien celle de la reconnaissance de la valeur des documents, documents dématérialisés qu'ils soient mémorisés ou échangés et ce qu'elle qu'en soit le medium (échange par email, par web, par envoi de disquette ou CD, etc...).
Enfin, on peut considérer que l'objectif principal de cet article est que, devenant un acteur averti, chaque lecteur devienne un acheteur très exigeant et force ainsi les offreurs à améliorer sérieusement leurs solutions et à ne pas se contenter des produits très faibles et insuffisants qu'ils osent prétendre nous convaincre d'acheter.
Cet article reprend partiellement et prolonge une présentation donnée lors de la conférence TET2000 (Trusting Electronic Trade) dont le support est accessible par http://www.edelweb.fr/EdelStuff/EdelPages/TET2000/.
Rappels sur quelque mécanismes de base
Signature numérique: Elle repose sur l'utilisation de la cryptographie asymétrique (type RSA), elle consiste à attacher à un document un complément d'information -la signature- qui :
Ne peut avoir été produit que par un utilisateur bien identifié, titulaire d'un bi-clé dont il utilise la clé privée, et ne pouvant donc pas répudier cette signature (sémantique de type "lu et approuvé" ou "persiste et signe")
Permet -par chiffrement d'un condensat (hash) du message- de vérifier l'intégrité du document et donc de détecter tout changement fortuit ou malveillant intervenu depuis "l'apposition de la signature".
La signature numérique est à ce jour la seule forme de signature électronique connue et donc éventuellement à même de répondre aux exigences et caractéristiques de la directive européenne et de sa transposition en droit français. NOTA : il n'existe pas de forme de signature électronique reposant sur une caractéristique biométrique ou sur la graphie d'une signature manuscrite, mais ceci est un autre débat, voire une autre croisade que nous ne manquerons pas d'aborder dans un prochain numéro. La biométrie est une excellente base de l'authentification de personnes, mais ne peut sous-tendre un service de non-répudiation (caractéristique essentielle d'une signature).
Certification - Certificat de clé publique : La certification est le moyen indispensable qui permet d'associer (garantir le lien entre) un possesseur de clé privée d'une part et une identité d'autre part. On conçoit bien que -informatique ou pas- il ne suffit pas d'une auto-proclamation pour apporter à ses interlocuteurs la preuve que l'on est bien celui qu'on prétend être. Il faut disposer d'une forme d'attestation "le certificat", établie par une "autorité" reconnue (l'Autorité de Certification), qui garantit que le possesseur de la clé privée utilisée pour la signature est bien l'utilisateur (le seul) dont l'identité est donnée dans le certificat.
NOTA : Savoir quelle est la "bonne Autorité" dans un contexte donné est à la fois crucial mais hors du champs de cet article. Indiquons toutefois qu'il n'y a pas de vérité unique et que se contenter de prendre telle quelle la liste des CA livrées avec les produits est certainement la pire des méthodes. Il revient aux responsables d'un organisme ou d'une communauté de définir quelles autorités --pas forcément des prestataires de service de certification à la Verisign- et quels certificats sont "utilisables" dans chaque contexte applicatif.
Horodatage -- Estampille horaire : Mécanisme permettant de disposer d'une attestation dématérialisée indiquant l'heure de référence et émise par une source "une Autorité" reconnue. En pratique, l'heure de référence est cryptographiquement signée par la TSA (Time Stamping Authority).
Exigences pour une infrastructure de documents dématérialisés
Prenons un exemple de document "formel" en contexte professionnel pour identifier les différents éléments qui contribuent à sa "validité" et dont nous devrons retrouver les équivalents, d'une façon ou d'une autre dans un document dématérialisé.
Une rapide observation permet d'identifier les éléments suivants :
Un contenu : C'est la raison d'être de tout document. Ce contenu peut être plus ou moins structuré (un objet, un corps) et contenir des composants de nature différents et dans différentes représentations tel que du texte (word, ou RTF ou HTML par exemple) ou des graphiques. Nous ne nous intéressons pas ici au contenu dès lors qu'il en existe une représentation informatique permettant la dématérialisation de l'échange.
Une forme d'identification entreprise (Nom, Logo ; Siège Social, Capital, RCS et souvent un "tampon") dont une partie est imposée par la loi. N'oublions pas que quel que soit l'employé qui signe c'est d'abord la responsabilité de la personne morale qui est engagée. Il est donc normal et indispensable que les informations permettant d'identifier cette structure juridique soient présentes dans le document.
Une ou plusieurs signatures : Dans le cas présent, nous y trouvons la signature de l'auteur et le visa d'un directeur. On sait qu'il existe fréquemment dans les entreprises des règles imposant la double signature à partir d'un certain niveau d'engagement ; un contrat est signé par au moins un représentant de chacune des parties ; un "procès-verbal" de délibération sera signé par un président, un secrétaire et au moins un assesseur. Ce qu'il convient de retenir c'est que
il convient de permettre plusieurs signatures, li>qu'il est prudent de ne pas viser une sémantique universelle des signatures (les multiples formes de signature, contre-signature, visa, etc...) et se contenter de permettre ces signatures.
Une ou plusieurs dates : on peut dans l'exemple distinguer la date d'établissement du document, la date d'apposition du visa. On pourrait également y trouver une date de "prise en compte". Là encore, bornons nous à souligner qu'il faut savoir inclure de multiples dates sans se préoccuper outre mesure de leurs sémantiques respectives. Notons cependant que l'ETSI (en charge d'établissement de standard européens en la matière) vient de reconnaître qu'une signature sans date n'apportait rien -- en version dématérialisée également-.
Une référence : ce qu'il convient d'observer à ce niveau c'est que la raison d'être de cette référence est le fait que l'entreprise émettrice garde un "double" des documents formels envoyés à des tiers (c'est normal, ce sont ses engagements -- autant les connaître-) et qu'il est donc possible de retrouver le double du document "Ref. RxxxXXXX", même en l'absence de son auteur. Retenons l'existence d'une archive "entreprise" jouant un rôle essentiel. Notons en outre qu'en cas de chiffrement en confidentialité, il est fondamental pour un organisme de disposer, sous une forme ou une autre d'un mécanisme de recouvrement permettant à sa structure (entreprise, administration...) en cas d'indisponibilité de la personne ayant "les clés" d'avoir accès au document concerné.
Implicitement des règles et procédures : Ces règles et procédures régissent les conditions dans lesquelles les personnels de la société peuvent prendre des engagements au nom de la structure ; Notons que cela peut venir de divers niveaux depuis les statuts (clause limitation des pouvoirs du président) jusqu'à des engagements contractuels vis à vis de clients ou fournisseurs en passant par le règlement intérieur. De façon symétrique, il existe --parfois en partie implicitement- dans la structure des règles et procédures qui "disent" comment traiter et reconnaître les documents venant de l'extérieur. Parmi ces règles notons celles concernant la production de documents confidentiels dont typiquement un exemplaire doit être déposé au coffre dans une enveloppe indiquant dans quelles conditions et qui peut en prendre connaissance.
Une simple lecture de ce qui précède apporte une liste d'exigences minimales pour toute solution de dématérialisation utilisable en contexte professionnel. Elle peut se résumer comme suit :
Capacité du système à indiquer, en plus d'un utilisateur signataire la structure (entreprise, organisme) au nom de laquelle le document est établi.
Capacité du système à accepter de multiples signatures (pour les apposer ou les vérifier). Ces signatures doivent pouvoir être datées.
Capacité du système à se servir d'un service d'horodatage à partir d'une source reconnue: il ne suffit pas de distribuer l'heure, encore faut-il la lier avec le document ou un événement (signature).
Capacité du système à respecter et faire respecter (i.e. imposer aux utilisateurs) la politique de sécurité et de confiance de l'organisme lors de la réception de documents dématérialisés ; c'est la traduction informatique d'une partie des règles et procédures évoquées ci-dessus : celle qui traite des exigences concernant la reconnaissance des autorités de certification, les certificats acceptables, et plus généralement des exigences autour de la forme des documents dématérialisés.
Capacité du système à respecter et faire respecter les règles de sécurité et de confiance lors de la production de documents destinés à l'extérieur.
De ce qui précède, chacun peut facilement déduire une première série d'exigences et de critères quant aux services fonctionnels des solutions.
Avec une pointe d'esprit critique :-) on peut également s'apercevoir que concernant les produits actuels qui prétendent offrir ce qu'il faut pour la dématérialisation, si ils savent effectivement d'un point de vue technique apposer ou vérifier une signature numérique, ils sont en revanche bien loin de satisfaire à la majorité des critères évoqués.
Une autre exigence, un peu moins évidente, mais fondamentale pour un service de dématérialisation, concerne les moyens disponibles pour "vérifier la validité" des documents dématérialisés ; c'est tout aussi nécessaire pour les documents reçus de l'extérieur que pour ceux repris après archivage pendant une certaine durée :
Il n'est évidemment pas question ici de s'occuper des éléments sémantiques qui conditionnent cette validité (par exemple : M. Untel est habilité à signer des commandes jusqu'à un montant de 50 000 Euros, ou ne pas accepter les commandes de la société XXX tant qu'elle ne nous a pas réglé ses dettes) mais uniquement de ce qui peut et normalement doit être "automatisé"
Il faut donc que le système soit capable de vérifier la validité technique (conformité à la spécification) d'une signature ; tous les produits savent le faire aujourd'hui.
Il faut également que le système soit capable de connaître --dans le contexte applicatif donné- quels sont les Autorités et les Certificats "acceptables" ou "reconnus" par l'organisme. Ce n'est pas vraiment le cas aujourd'hui puisque les produits utilisent une base d'AC prédéfinie par l'éditeur du logiciel et modifiable par chaque utilisateur : il est donc impossible de mettre en place simplement le respect de la politique (les choix) de l'organisme en la matière. Seul un système permettant à l'organisme (via un administrateur habilité) de modifier cette base de référence et interdisant à chaque personnel d'y toucher permettra de respecter cette exigence.
Il faut que le système permette de vérifier la validité d'un document dématérialisé longtemps après sa date de production, c'est à dire longtemps après la fin de vie du ou des certificats correspondants aux signatures présentes. Cela impose d'une part la présence d'une estampille horaire incontestable et donc vérifiable dans le document et, d'autre part, l'existence d'un service permettant de vérifier ces éléments qui ne sont plus disponibles sur une simple station utilisatrice puisqu'ils supposent des bases de données de référence possiblement très grandes. Un cas particulier de document à vérifier est un certificat de clé publique : pour cela -- mieux que les CRL (listes de révocation de certificats) dont l'utilisation à grande échelle est irréaliste- des services et protocoles ont été définis récemment, OCSP et DVCS au sein du groupe de travail PKIX de l'IETF (Les fameux RFC de l'Internet : http://www.ietf.org/rfc.html). Le protocole et les services DVCS seront présentés un peu plus loin.
Protocole et service DVCS (RFC3029)
Du constat précédent, plutôt que de baisser les bras devant les manques et faiblesses des 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. Cela s'est traduit par notre contribution significative à l'élaboration du RFC 3029 DVCS : Data Validation and Certification Services (Peter Sylvester de EdelWeb est co-auteur et éditeur de cette norme).
Le point de départ est le constat de la nécessité, en plus des infrastructures de certificat (CA, PKI), d'un service permettant à des utilisateurs d'un organisme (entreprise, communauté de travail, etc...) de disposer de fonctions 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, 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...) EdelWeb a d'ailleurs développé, sous le nom EdelSafe, une architecture complète de solution basée sur ce modèle. Cette base logicielle --déclaration SCSSI en 1998- a servi par la suite à divers projets dont le service démonstrateur Clepsydre pour La Poste qui, outre vérifier la conformité et l'interopérabilité de leurs produits.
NOTES concernant la standardisation IETF en la matière :
Historique : DVCS a été proposé initialement par Entrust dans le contexte PKIX comme une extension du 'time stamp service' et de service de validation de certificat. C'est en raison du refus des auteurs (Verisign) de OCSP de procéder aux extensions souhaitées par le groupe de travail que DCS est devenu DVCS en incluant ces services de validation en ligne.
Les activités du groupe PKIX ne sont pas particulièrement orientées vers la dématérialisation, l'objectif premier du groupe PKIX est de déterminer les profils d'utilisation d'X.509 et de définir les services supplémentaires d'une PKI.
C'est pour cela que, par exemple, la normalisation du time stamping a pris un retard excessif (plus que 4 ans) et que la définition minimaliste de la version actuelle est toujours sujette à de fortes contestations, et est même incomplète (par exemple pour la vérification de la validité d'un time stamp).
Plusieurs activités en cours de normalisation au sein du groupe PKIX concernent les services de validation de certificats: Après OCSP et DVCS, qui ont atteint le stade RFC, de nouvelles approches concurrentes OCSP-V2, SVCP, DPV essaient de répondre à certaines lacunes de OCSP, l'ensemble des drafts RFC dans le domaine témoignent du manque de maturité des efforts et/ou des tentatives de certains industriels d'occuper le terrain.
Le groupe de travail S/MIME de l'ietf semble a priori le meilleur endroit pour discuter des documents dématérialisés et de leurs échanges. Il y a effectivement des propositions comme CMS (cryptographic message syntax) ou ESS (extended security services) qui peuvent être utilisées comme base. Malheureusement, les mécanismes de protection S/MIME sont simplement utilisés comme un moyen d'assurer la sécurité des échanges par messageries (avec des vérifications en quasi temps réel).
Au sein de W3C les activités de standardisation autour de la signature numérique xml (xmldsig) ont pris un grand retard pour plusieurs raisons, et même si les problèmes de canonisation sont en passe d' être résolus, la norme exclut toute sorte de certification, ou plus exactement repose sur des services supplémentaires, par exemple XKMS.
Nous recommandons de se reporter au documents référencés pour une explication simple du modèle (http://www.edelweb.fr/EdelStuff/EdelPages/TET2000/).
Le protocole DVCS
A titre d'illustration, tentons de décrire, plus que la spécification DVCS que l'on trouve dans http://www.ietf.org/rfc/rfc3029.txt, les raisons et caractéristiques de ce 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 équivalent 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 "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".
Conclusion
Nous souhaitons que ce qui précède, sans prétendre à l'exhaustivité, aidera chacun à formuler ses propres exigences et à ne pas se laisser piéger par des discours commerciaux qui tendent à dire : les PKI existent, les produits gèrent S/MIME, tout est là, vous n'avez besoin de rien d'autre.
Nous espérons avoir éveillé votre curiosité et attiré votre attention sur quelques aspects importants de la dématérialisation. Pour en savoir plus et nous contacter, vous trouverez toutes les informations sur notre serveur Web : ou sur les services équivalents du groupe ON-X
