On me demande actuellement de faire une application qui permettrait de
faire "avaliser" un document =E9l=E9ctronique. La signature
=E9l=E9ctronique, je sais faire mais ce n'est pas ce qu'on me demande. Je
vous explique :
On me demande de faire une application o=F9 un document suit un circuit
pr=E9defini entre diff=E9rents utilisateurs (ce qu'on appelle un
workflow) et o=F9 chaque personne peut "signer" le document qui est
ensuite modifi=E9 par d'autres.
Signer un document signifierait qu'une personne "appose une marque",
qui permettrait ensuite de pouvoir dire de fa=E7on certaine que c'est
bien elle qui a sign=E9, d'une part, et que le document n'a pas =E9t=E9
modifi=E9, d'autre part.
Mais ici on me demande juste d'authentifier le signataire : il faut que
le document puisse ensuite =EAtre modifi=E9, tout en restant sign=E9.
Je ne sais pas comment on appelle ce proc=E9d=E9, aussi lui avons-nous
donn=E9 le nom employ=E9 dans la r=E9alit=E9 : avaliser un document...
Mais plus grave ! Je ne sais pas comment authentifier un document
soumis =E0 modifications. Et on me demande une authentification assez
forte pour pouvoir servir =E0 des administrations.
Je pense actuellement =E0 un syst=E8me o=F9 on signerait (au sens propre)
le document =E0 chaque =E9tape du workflow, puis o=F9 on journaliserait
chaque modification. Deux probl=E8mes :
-D'abord, il faut sauvegarder chaque modification de chaque fichier, ce
qui devient vite lourd, m=EAme en effa=E7ant r=E9guli=E8rement les
"vieilles" versions.
-Ensuite, si on peut effectivement garantir que telle ou telle version
du document a bien =E9t=E9 sign=E9e par telle personne, comment garantir
le circuit ? Car on veut aussi pouvoir certifier qu'apr=E8s que Bob ait
sign=E9, le document a =E9t=E9 re=E7u par Alice.
Voil=E0 ma probl=E9matique. Quelqu'un aurait-il une id=E9e ?
On me demande actuellement de faire une application qui permettrait de faire "avaliser" un document éléctronique. La signature éléctronique, je sais faire mais ce n'est pas ce qu'on me demande. Je vous explique : On me demande de faire une application où un document suit un circuit prédefini entre différents utilisateurs (ce qu'on appelle un workflow) et où chaque personne peut "signer" le document qui est ensuite modifié par d'autres. Signer un document signifierait qu'une personne "appose une marque", qui permettrait ensuite de pouvoir dire de façon certaine que c'est bien elle qui a signé, d'une part, et que le document n'a pas été modifié, d'autre part. Mais ici on me demande juste d'authentifier le signataire : il faut que le document puisse ensuite être modifié, tout en restant signé. Je ne sais pas comment on appelle ce procédé, aussi lui avons-nous donné le nom employé dans la réalité : avaliser un document... Mais plus grave ! Je ne sais pas comment authentifier un document soumis à modifications. Et on me demande une authentification assez forte pour pouvoir servir à des administrations. Je pense actuellement à un système où on signerait (au sens propre) le document à chaque étape du workflow, puis où on journaliserait chaque modification. Deux problèmes : -D'abord, il faut sauvegarder chaque modification de chaque fichier, ce qui devient vite lourd, même en effaçant régulièrement les "vieilles" versions. -Ensuite, si on peut effectivement garantir que telle ou telle version du document a bien été signée par telle personne, comment garantir le circuit ? Car on veut aussi pouvoir certifier qu'après que Bob ait signé, le document a été reçu par Alice. Voilà ma problématique. Quelqu'un aurait-il une idée ?
Si le document doit être *modifié* à de nombreuses reprises, une seule solution est possible: garder les versions précédentes intactes; sans quoi il sera impossible de certifier que X... avait réellement signé le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document; et je classerais le contenu par date de modidification, le plus récent au-dessus. Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent son nom.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Par exemple, supposons un recueil d'avis sur une date de réunion: "Réunion de la commission fromage le 15 août".
Tout le monde regarde la date, mais une personne change le texte et le signe: "Réunion de la commission vin le 2 septembre".
Rien à faire à cela, il faut qu'il y ait une supervision par quelqu'un afin que l'on ne remplace pas quelques mots en catimini. C'est souvent comme ça, par une adjonction ou soustraction de virgule, que les textes de loi sont falsifiés avant leur publication au Journal Officiel.
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Hello !
"Pierre Goupil" <goupilpierre@gmail.com> wrote:
On me demande actuellement de faire une application qui permettrait de
faire "avaliser" un document éléctronique. La signature
éléctronique, je sais faire mais ce n'est pas ce qu'on me demande. Je
vous explique :
On me demande de faire une application où un document suit un circuit
prédefini entre différents utilisateurs (ce qu'on appelle un
workflow) et où chaque personne peut "signer" le document qui est
ensuite modifié par d'autres.
Signer un document signifierait qu'une personne "appose une marque",
qui permettrait ensuite de pouvoir dire de façon certaine que c'est
bien elle qui a signé, d'une part, et que le document n'a pas été
modifié, d'autre part.
Mais ici on me demande juste d'authentifier le signataire : il faut que
le document puisse ensuite être modifié, tout en restant signé.
Je ne sais pas comment on appelle ce procédé, aussi lui avons-nous
donné le nom employé dans la réalité : avaliser un document...
Mais plus grave ! Je ne sais pas comment authentifier un document
soumis à modifications. Et on me demande une authentification assez
forte pour pouvoir servir à des administrations.
Je pense actuellement à un système où on signerait (au sens propre)
le document à chaque étape du workflow, puis où on journaliserait
chaque modification. Deux problèmes :
-D'abord, il faut sauvegarder chaque modification de chaque fichier, ce
qui devient vite lourd, même en effaçant régulièrement les
"vieilles" versions.
-Ensuite, si on peut effectivement garantir que telle ou telle version
du document a bien été signée par telle personne, comment garantir
le circuit ? Car on veut aussi pouvoir certifier qu'après que Bob ait
signé, le document a été reçu par Alice.
Voilà ma problématique. Quelqu'un aurait-il une idée ?
Si le document doit être *modifié* à de nombreuses reprises, une seule solution est possible: garder les versions précédentes intactes; sans quoi il sera impossible de certifier que X... avait réellement signé le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document; et je classerais le contenu par date de modidification, le plus récent au-dessus.
Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent son nom.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Par exemple, supposons un recueil d'avis sur une date de réunion:
"Réunion de la commission fromage le 15 août".
Tout le monde regarde la date, mais une personne change le texte et le signe:
"Réunion de la commission vin le 2 septembre".
Rien à faire à cela, il faut qu'il y ait une supervision par quelqu'un afin que l'on ne remplace pas quelques mots en catimini. C'est souvent comme ça, par une adjonction ou soustraction de virgule, que les textes de loi sont falsifiés avant leur publication au Journal Officiel.
--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
On me demande actuellement de faire une application qui permettrait de faire "avaliser" un document éléctronique. La signature éléctronique, je sais faire mais ce n'est pas ce qu'on me demande. Je vous explique : On me demande de faire une application où un document suit un circuit prédefini entre différents utilisateurs (ce qu'on appelle un workflow) et où chaque personne peut "signer" le document qui est ensuite modifié par d'autres. Signer un document signifierait qu'une personne "appose une marque", qui permettrait ensuite de pouvoir dire de façon certaine que c'est bien elle qui a signé, d'une part, et que le document n'a pas été modifié, d'autre part. Mais ici on me demande juste d'authentifier le signataire : il faut que le document puisse ensuite être modifié, tout en restant signé. Je ne sais pas comment on appelle ce procédé, aussi lui avons-nous donné le nom employé dans la réalité : avaliser un document... Mais plus grave ! Je ne sais pas comment authentifier un document soumis à modifications. Et on me demande une authentification assez forte pour pouvoir servir à des administrations. Je pense actuellement à un système où on signerait (au sens propre) le document à chaque étape du workflow, puis où on journaliserait chaque modification. Deux problèmes : -D'abord, il faut sauvegarder chaque modification de chaque fichier, ce qui devient vite lourd, même en effaçant régulièrement les "vieilles" versions. -Ensuite, si on peut effectivement garantir que telle ou telle version du document a bien été signée par telle personne, comment garantir le circuit ? Car on veut aussi pouvoir certifier qu'après que Bob ait signé, le document a été reçu par Alice. Voilà ma problématique. Quelqu'un aurait-il une idée ?
Si le document doit être *modifié* à de nombreuses reprises, une seule solution est possible: garder les versions précédentes intactes; sans quoi il sera impossible de certifier que X... avait réellement signé le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document; et je classerais le contenu par date de modidification, le plus récent au-dessus. Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent son nom.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Par exemple, supposons un recueil d'avis sur une date de réunion: "Réunion de la commission fromage le 15 août".
Tout le monde regarde la date, mais une personne change le texte et le signe: "Réunion de la commission vin le 2 septembre".
Rien à faire à cela, il faut qu'il y ait une supervision par quelqu'un afin que l'on ne remplace pas quelques mots en catimini. C'est souvent comme ça, par une adjonction ou soustraction de virgule, que les textes de loi sont falsifiés avant leur publication au Journal Officiel.
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Manu
Pierre Goupil wrote:
Voilà ma problématique. Quelqu'un aurait-il une idée ?
Est-ce qu'un système de gestion de source genre SubVersion ou Arch acceptant de faire de la signature ne suffirait pas ? En le mettant sur un serveur tu dois pouvoir assurer la traçabilité et en le "customisant" (via les hooks de SubVersion par exemple) tu dois pouvoir également forcer le fait que le document doivent passer par une personne avant une autre.
Pierre Goupil wrote:
Voilà ma problématique. Quelqu'un aurait-il une idée ?
Est-ce qu'un système de gestion de source genre SubVersion ou Arch
acceptant de faire de la signature ne suffirait pas ?
En le mettant sur un serveur tu dois pouvoir assurer la traçabilité et
en le "customisant" (via les hooks de SubVersion par exemple) tu dois
pouvoir également forcer le fait que le document doivent passer par une
personne avant une autre.
Voilà ma problématique. Quelqu'un aurait-il une idée ?
Est-ce qu'un système de gestion de source genre SubVersion ou Arch acceptant de faire de la signature ne suffirait pas ? En le mettant sur un serveur tu dois pouvoir assurer la traçabilité et en le "customisant" (via les hooks de SubVersion par exemple) tu dois pouvoir également forcer le fait que le document doivent passer par une personne avant une autre.
Pierre Goupil
Merci beaucoup de ta réactivité !
Si le document doit être *modifié* à de nombreuses reprises, une s eule solution est possible: garder les versions précédentes intactes; s ans quoi il sera impossible de certifier que X... avait réellement sign é le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document ; et je classerais le contenu par date de modidification, le plus récent au-dessus. Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent so n nom.
C'est bien ainsi que je comptais procéder.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Le presupposé de mon application est que l'on fait confiance à la personne suivante du circuit : une fois le document signé, on le transmet au suivant qui peut modifier le document à sa guise tout en pouvant dire "Bon, Alice vient de m'envoyer le devis. Je le remplit et je le transmets à Bob". Et au total, on peut certifier que le document final est bien le resultat des modifications d'Alice et Bob.
Bien sûr, je garantis qu'un même document n'est "travaillé" que par une personne à la fois.
Mon système repose sur des condensés de message SHA1 et des signatures DSA 1024 bits avec bien sûr un système de clés privées / clés publiques. Et on admet que l'on peut faire confiance quant au CONTENU des modifications apportées après soi.
Si je suis ta pensée, mon système est donc fiable ? :-)
Cordialement,
Pierre Goupil
Merci beaucoup de ta réactivité !
Si le document doit être *modifié* à de nombreuses reprises, une s eule solution est possible: garder les versions précédentes intactes; s ans quoi il sera impossible de certifier que X... avait réellement sign é le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document ; et je classerais le contenu par date de modidification, le plus récent au-dessus.
Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent so n nom.
C'est bien ainsi que je comptais procéder.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Le presupposé de mon application est que l'on fait confiance à la
personne suivante du circuit : une fois le document signé, on le
transmet au suivant qui peut modifier le document à sa guise tout en
pouvant dire "Bon, Alice vient de m'envoyer le devis. Je le remplit et
je le transmets à Bob". Et au total, on peut certifier que le document
final est bien le resultat des modifications d'Alice et Bob.
Bien sûr, je garantis qu'un même document n'est "travaillé" que par
une personne à la fois.
Mon système repose sur des condensés de message SHA1 et des
signatures DSA 1024 bits avec bien sûr un système de clés privées /
clés publiques. Et on admet que l'on peut faire confiance quant au
CONTENU des modifications apportées après soi.
Si je suis ta pensée, mon système est donc fiable ? :-)
Si le document doit être *modifié* à de nombreuses reprises, une s eule solution est possible: garder les versions précédentes intactes; s ans quoi il sera impossible de certifier que X... avait réellement sign é le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document ; et je classerais le contenu par date de modidification, le plus récent au-dessus. Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent so n nom.
C'est bien ainsi que je comptais procéder.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Le presupposé de mon application est que l'on fait confiance à la personne suivante du circuit : une fois le document signé, on le transmet au suivant qui peut modifier le document à sa guise tout en pouvant dire "Bon, Alice vient de m'envoyer le devis. Je le remplit et je le transmets à Bob". Et au total, on peut certifier que le document final est bien le resultat des modifications d'Alice et Bob.
Bien sûr, je garantis qu'un même document n'est "travaillé" que par une personne à la fois.
Mon système repose sur des condensés de message SHA1 et des signatures DSA 1024 bits avec bien sûr un système de clés privées / clés publiques. Et on admet que l'on peut faire confiance quant au CONTENU des modifications apportées après soi.
Si je suis ta pensée, mon système est donc fiable ? :-)
Cordialement,
Pierre Goupil
Pierre Goupil
Et bien, j'y ai un peu pensé aussi, mais cela me paraît beaucoup plus lourd et surtout je n'aime pas trop cette dépendance à un produit externe.
Pour la dépendance, je peux m'arranger, étant donné que les solutions libres ne manquent pas..
Mais quand je parle de lourdeur, c'est parce que je travaille sur des fichiers de virtuellement n'importe quel type : et une analyse de différence sur un fichier Word, j'avoue que je ne sais pas trop ce que cela peut donner ! :s
Je vais me renseigner plus avant.
Merci !
Pierre
Est-ce qu'un système de gestion de source genre SubVersion ou Arch acceptant de faire de la signature ne suffirait pas ? En le mettant sur un serveur tu dois pouvoir assurer la traçabilité et en le "customisant" (via les hooks de SubVersion par exemple) tu dois pouvoir également forcer le fait que le document doivent passer par une personne avant une autre.
Et bien, j'y ai un peu pensé aussi, mais cela me paraît beaucoup plus
lourd et surtout je n'aime pas trop cette dépendance à un produit
externe.
Pour la dépendance, je peux m'arranger, étant donné que les
solutions libres ne manquent pas..
Mais quand je parle de lourdeur, c'est parce que je travaille sur des
fichiers de virtuellement n'importe quel type : et une analyse de
différence sur un fichier Word, j'avoue que je ne sais pas trop ce que
cela peut donner ! :s
Je vais me renseigner plus avant.
Merci !
Pierre
Est-ce qu'un système de gestion de source genre SubVersion ou Arch
acceptant de faire de la signature ne suffirait pas ?
En le mettant sur un serveur tu dois pouvoir assurer la traçabilité et
en le "customisant" (via les hooks de SubVersion par exemple) tu dois
pouvoir également forcer le fait que le document doivent passer par une
personne avant une autre.
Et bien, j'y ai un peu pensé aussi, mais cela me paraît beaucoup plus lourd et surtout je n'aime pas trop cette dépendance à un produit externe.
Pour la dépendance, je peux m'arranger, étant donné que les solutions libres ne manquent pas..
Mais quand je parle de lourdeur, c'est parce que je travaille sur des fichiers de virtuellement n'importe quel type : et une analyse de différence sur un fichier Word, j'avoue que je ne sais pas trop ce que cela peut donner ! :s
Je vais me renseigner plus avant.
Merci !
Pierre
Est-ce qu'un système de gestion de source genre SubVersion ou Arch acceptant de faire de la signature ne suffirait pas ? En le mettant sur un serveur tu dois pouvoir assurer la traçabilité et en le "customisant" (via les hooks de SubVersion par exemple) tu dois pouvoir également forcer le fait que le document doivent passer par une personne avant une autre.
Laurent Jumet
Hello !
"Pierre Goupil" wrote:
Si le document doit être *modifié* à de nombreuses reprises, une seule solution est possible: garder les versions précédentes intactes; sans quoi il sera impossible de certifier que X... avait réellement signé le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document; et je classerais le contenu par date de modidification, le plus récent au-dessus. Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent son nom.
C'est bien ainsi que je comptais procéder.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Le presupposé de mon application est que l'on fait confiance à la personne suivante du circuit : une fois le document signé, on le transmet au suivant qui peut modifier le document à sa guise tout en pouvant dire "Bon, Alice vient de m'envoyer le devis. Je le remplit et je le transmets à Bob". Et au total, on peut certifier que le document final est bien le resultat des modifications d'Alice et Bob.
Bien sûr, je garantis qu'un même document n'est "travaillé" que par une personne à la fois.
Mon système repose sur des condensés de message SHA1 et des signatures DSA 1024 bits avec bien sûr un système de clés privées / clés publiques. Et on admet que l'on peut faire confiance quant au CONTENU des modifications apportées après soi.
Si je suis ta pensée, mon système est donc fiable ? :-)
Si on peut avoir confiance dans chaque personne qui modifie, alors oui c'est fiable. À la fin du processus, on fait un ZIP ou un RAR du tout qu'on archive.
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Hello !
"Pierre Goupil" <goupilpierre@gmail.com> wrote:
Si le document doit être *modifié* à de nombreuses reprises, une seule
solution est possible: garder les versions précédentes intactes; sans quoi
il sera impossible de certifier que X... avait réellement signé le
brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document;
et je classerais le contenu par date de modidification, le plus récent
au-dessus.
Chaque signataire renomme le document en y ajoutant son nom, et puis,
après l'avoir relu et éventuellement modifié, le signe en "signature
séparée". Les fichiers de signature séparée viennent naturellement se
mettre juste avant le fichier auquel elles se rapportent, et portent son
nom.
C'est bien ainsi que je comptais procéder.
Le point faible du système n'est pas cryptologique; il repose dans le
fait de savoir ce que chaque intervenant à changé dans le texte.
Le presupposé de mon application est que l'on fait confiance à la
personne suivante du circuit : une fois le document signé, on le
transmet au suivant qui peut modifier le document à sa guise tout en
pouvant dire "Bon, Alice vient de m'envoyer le devis. Je le remplit et
je le transmets à Bob". Et au total, on peut certifier que le document
final est bien le resultat des modifications d'Alice et Bob.
Bien sûr, je garantis qu'un même document n'est "travaillé" que par
une personne à la fois.
Mon système repose sur des condensés de message SHA1 et des
signatures DSA 1024 bits avec bien sûr un système de clés privées /
clés publiques. Et on admet que l'on peut faire confiance quant au
CONTENU des modifications apportées après soi.
Si je suis ta pensée, mon système est donc fiable ? :-)
Si on peut avoir confiance dans chaque personne qui modifie, alors oui c'est fiable. À la fin du processus, on fait un ZIP ou un RAR du tout qu'on archive.
--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
Si le document doit être *modifié* à de nombreuses reprises, une seule solution est possible: garder les versions précédentes intactes; sans quoi il sera impossible de certifier que X... avait réellement signé le brouillon avant que Y... l'ait modifié puis signé.
Ce que je ferais, avec GnuPG, c'est consacrer un dossier par document; et je classerais le contenu par date de modidification, le plus récent au-dessus. Chaque signataire renomme le document en y ajoutant son nom, et puis, après l'avoir relu et éventuellement modifié, le signe en "signature séparée". Les fichiers de signature séparée viennent naturellement se mettre juste avant le fichier auquel elles se rapportent, et portent son nom.
C'est bien ainsi que je comptais procéder.
Le point faible du système n'est pas cryptologique; il repose dans le fait de savoir ce que chaque intervenant à changé dans le texte.
Le presupposé de mon application est que l'on fait confiance à la personne suivante du circuit : une fois le document signé, on le transmet au suivant qui peut modifier le document à sa guise tout en pouvant dire "Bon, Alice vient de m'envoyer le devis. Je le remplit et je le transmets à Bob". Et au total, on peut certifier que le document final est bien le resultat des modifications d'Alice et Bob.
Bien sûr, je garantis qu'un même document n'est "travaillé" que par une personne à la fois.
Mon système repose sur des condensés de message SHA1 et des signatures DSA 1024 bits avec bien sûr un système de clés privées / clés publiques. Et on admet que l'on peut faire confiance quant au CONTENU des modifications apportées après soi.
Si je suis ta pensée, mon système est donc fiable ? :-)
Si on peut avoir confiance dans chaque personne qui modifie, alors oui c'est fiable. À la fin du processus, on fait un ZIP ou un RAR du tout qu'on archive.
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Francois Cartegnie
Pierre Goupil wrote:
-D'abord, il faut sauvegarder chaque modification de chaque fichier, ce qui devient vite lourd, même en effaçant régulièrement les "vieilles" versions.
Sauvegarder et faire signer uniquement le diff de chaque document modifié. Difficilement efficace avec les formats binaires compressés, c'est là qu'OOO vient à la rescousse avec son format XML proprice aux diffs...
Pierre Goupil wrote:
-D'abord, il faut sauvegarder chaque modification de chaque fichier, ce
qui devient vite lourd, même en effaçant régulièrement les
"vieilles" versions.
Sauvegarder et faire signer uniquement le diff de chaque document modifié.
Difficilement efficace avec les formats binaires compressés, c'est là
qu'OOO vient à la rescousse avec son format XML proprice aux diffs...
-D'abord, il faut sauvegarder chaque modification de chaque fichier, ce qui devient vite lourd, même en effaçant régulièrement les "vieilles" versions.
Sauvegarder et faire signer uniquement le diff de chaque document modifié. Difficilement efficace avec les formats binaires compressés, c'est là qu'OOO vient à la rescousse avec son format XML proprice aux diffs...
Pierre Goupil
Tout à fait ! Mais nous voulons pouvoir gérer n'importe quel type de document. Et tout bien réfléchi, je ne suis plus si sûr que sauvegarder tout un document a chacune de ses modifications soient mauvais : avec les systèmes de gestions de versions, on a les fameux problèmes de conflit, qui doivent être résolus à la main. Mais nous, nous voulons la plus grande transparence possible => le moins d'ennui possible pour l'utilisateur.
Et je vois mal ma secrétaire résoudre un conflit de mise-à-jour quand elle sauvegarde un document Word...
Je crois qu'il s'agit de trouver le bon compromis.
Tout à fait ! Mais nous voulons pouvoir gérer n'importe quel type de
document. Et tout bien réfléchi, je ne suis plus si sûr que
sauvegarder tout un document a chacune de ses modifications soient
mauvais : avec les systèmes de gestions de versions, on a les fameux
problèmes de conflit, qui doivent être résolus à la main. Mais
nous, nous voulons la plus grande transparence possible => le moins
d'ennui possible pour l'utilisateur.
Et je vois mal ma secrétaire résoudre un conflit de mise-à-jour
quand elle sauvegarde un document Word...
Je crois qu'il s'agit de trouver le bon compromis.
Tout à fait ! Mais nous voulons pouvoir gérer n'importe quel type de document. Et tout bien réfléchi, je ne suis plus si sûr que sauvegarder tout un document a chacune de ses modifications soient mauvais : avec les systèmes de gestions de versions, on a les fameux problèmes de conflit, qui doivent être résolus à la main. Mais nous, nous voulons la plus grande transparence possible => le moins d'ennui possible pour l'utilisateur.
Et je vois mal ma secrétaire résoudre un conflit de mise-à-jour quand elle sauvegarde un document Word...
Je crois qu'il s'agit de trouver le bon compromis.
philippe
"Pierre Goupil" a écrit dans le message de news:
Tout à fait ! Mais nous voulons pouvoir gérer n'importe quel type de document. Et tout bien réfléchi, je ne suis plus si sûr que sauvegarder tout un document a chacune de ses modifications soient mauvais : avec les systèmes de gestions de versions, on a les fameux problèmes de conflit, qui doivent être résolus à la main. Mais nous, nous voulons la plus grande transparence possible => le moins d'ennui possible pour l'utilisateur.
Et je vois mal ma secrétaire résoudre un conflit de mise-à-jour quand elle sauvegarde un document Word...
Je crois qu'il s'agit de trouver le bon compromis.
Tu as a mettre en place un truc d'une complexité significative et le fait que tu le developpes toi meme n'est pas un signe de perenité pour ta boite :-). Tu ne t'embetes pas, tu prends une solution industrielle d'outil de workflow.
Slts
/Philippe
"Pierre Goupil" <goupilpierre@gmail.com> a écrit dans le message de news:
1155813014.136147.3030@74g2000cwt.googlegroups.com...
Tout à fait ! Mais nous voulons pouvoir gérer n'importe quel type de
document. Et tout bien réfléchi, je ne suis plus si sûr que
sauvegarder tout un document a chacune de ses modifications soient
mauvais : avec les systèmes de gestions de versions, on a les fameux
problèmes de conflit, qui doivent être résolus à la main. Mais
nous, nous voulons la plus grande transparence possible => le moins
d'ennui possible pour l'utilisateur.
Et je vois mal ma secrétaire résoudre un conflit de mise-à-jour
quand elle sauvegarde un document Word...
Je crois qu'il s'agit de trouver le bon compromis.
Tu as a mettre en place un truc d'une complexité significative et le fait
que tu le developpes toi meme n'est pas un signe de perenité pour ta boite
:-).
Tu ne t'embetes pas, tu prends une solution industrielle d'outil de
workflow.
Tout à fait ! Mais nous voulons pouvoir gérer n'importe quel type de document. Et tout bien réfléchi, je ne suis plus si sûr que sauvegarder tout un document a chacune de ses modifications soient mauvais : avec les systèmes de gestions de versions, on a les fameux problèmes de conflit, qui doivent être résolus à la main. Mais nous, nous voulons la plus grande transparence possible => le moins d'ennui possible pour l'utilisateur.
Et je vois mal ma secrétaire résoudre un conflit de mise-à-jour quand elle sauvegarde un document Word...
Je crois qu'il s'agit de trouver le bon compromis.
Tu as a mettre en place un truc d'une complexité significative et le fait que tu le developpes toi meme n'est pas un signe de perenité pour ta boite :-). Tu ne t'embetes pas, tu prends une solution industrielle d'outil de workflow.
Slts
/Philippe
Pierre Goupil
Inline
Tu as a mettre en place un truc d'une complexité significative et le fa it que tu le developpes toi meme n'est pas un signe de perenité pour ta bo ite
Bah le système qui tourne actuellement est on ne peut plus simple ! Juste de quoi signer des documents, quoi ! De façon très transparente pour les utilisateurs, d'ailleurs : ils ne savent même pas qu'il y a des clés et autre. Ils cliquent sur un bouton et c'est fini.
Et si je le code moi-même, c'est pasque je fais partie de l'équipe de développement.
Tu ne t'embetes pas, tu prends une solution industrielle d'outil de workflow.
Et si on le fais nous-même c'est parce qu'on est des concurrents ! =)
Bon, je vais faire comme dit Laurent : j'y pensais c'est gentil à lui d'avoir confirmé. Merci.
Cordialement,
Pierre
Inline
Tu as a mettre en place un truc d'une complexité significative et le fa it
que tu le developpes toi meme n'est pas un signe de perenité pour ta bo ite
Bah le système qui tourne actuellement est on ne peut plus simple !
Juste de quoi signer des documents, quoi ! De façon très transparente
pour les utilisateurs, d'ailleurs : ils ne savent même pas qu'il y a
des clés et autre. Ils cliquent sur un bouton et c'est fini.
Et si je le code moi-même, c'est pasque je fais partie de l'équipe de
développement.
Tu ne t'embetes pas, tu prends une solution industrielle d'outil de
workflow.
Et si on le fais nous-même c'est parce qu'on est des concurrents ! =)
Bon, je vais faire comme dit Laurent : j'y pensais c'est gentil à lui
d'avoir confirmé. Merci.
Tu as a mettre en place un truc d'une complexité significative et le fa it que tu le developpes toi meme n'est pas un signe de perenité pour ta bo ite
Bah le système qui tourne actuellement est on ne peut plus simple ! Juste de quoi signer des documents, quoi ! De façon très transparente pour les utilisateurs, d'ailleurs : ils ne savent même pas qu'il y a des clés et autre. Ils cliquent sur un bouton et c'est fini.
Et si je le code moi-même, c'est pasque je fais partie de l'équipe de développement.
Tu ne t'embetes pas, tu prends une solution industrielle d'outil de workflow.
Et si on le fais nous-même c'est parce qu'on est des concurrents ! =)
Bon, je vais faire comme dit Laurent : j'y pensais c'est gentil à lui d'avoir confirmé. Merci.
Cordialement,
Pierre
*core*administrator
On 17 Aug 2006 01:05:32 -0700, "Pierre Goupil" wrote:
Mais ici on me demande juste d'authentifier le signataire : il faut que le document puisse ensuite être modifié, tout en restant signé.
Excusez moi mais je crois que je comprends mal. Voulez-vous dire que l'on demande à quelqu'un de SIGNER (donc donner son aval) un document SANS en connaitre le contenu final ? C'est plutot étrange.
Ne serait-ce pas plus logique, et sécurisant, de faire effectuer deux tours au document ? Un premier tour ou chacun apporterait les modifications puis un second tour "de signature" ou chacun confirmerait son accord avec le contenu et ou le document serait "non modifiable" dès que la première signature aurait été aposée.
On 17 Aug 2006 01:05:32 -0700, "Pierre Goupil"
<goupilpierre@gmail.com> wrote:
Mais ici on me demande juste d'authentifier le signataire : il faut que
le document puisse ensuite être modifié, tout en restant signé.
Excusez moi mais je crois que je comprends mal. Voulez-vous dire
que l'on demande à quelqu'un de SIGNER (donc donner son aval) un
document SANS en connaitre le contenu final ? C'est plutot étrange.
Ne serait-ce pas plus logique, et sécurisant, de faire effectuer
deux tours au document ? Un premier tour ou chacun apporterait les
modifications puis un second tour "de signature" ou chacun
confirmerait son accord avec le contenu et ou le document serait "non
modifiable" dès que la première signature aurait été aposée.
On 17 Aug 2006 01:05:32 -0700, "Pierre Goupil" wrote:
Mais ici on me demande juste d'authentifier le signataire : il faut que le document puisse ensuite être modifié, tout en restant signé.
Excusez moi mais je crois que je comprends mal. Voulez-vous dire que l'on demande à quelqu'un de SIGNER (donc donner son aval) un document SANS en connaitre le contenu final ? C'est plutot étrange.
Ne serait-ce pas plus logique, et sécurisant, de faire effectuer deux tours au document ? Un premier tour ou chacun apporterait les modifications puis un second tour "de signature" ou chacun confirmerait son accord avec le contenu et ou le document serait "non modifiable" dès que la première signature aurait été aposée.
