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 ?
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.
Oui, je suis d'accord le principe est assez étrange. Mais il s'agit juste d'empêcher quelqu'un de dire qu'il n'a pas eu le document, pas de garantir ce qu'il a signé.
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.
J'y ai pensé mais le temps de ma maîtrise d'ouvrage doit être trop précieux : ils refusent qu'un document refasse un deuxième tour s'il n'est pas modifié.
Comme j'ai dit, le principe est que l'on a confiance en ce que le document deviendra après soi. L'idée est que l'on définit un circuit et que l'on contrôle ensuite s'il a été bien suivi. On ne veut donc pas certifier le contenu du document, juste son circuit.
Tes impressions ?
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.
Oui, je suis d'accord le principe est assez étrange. Mais il s'agit
juste d'empêcher quelqu'un de dire qu'il n'a pas eu le document, pas
de garantir ce qu'il a signé.
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.
J'y ai pensé mais le temps de ma maîtrise d'ouvrage doit être trop
précieux : ils refusent qu'un document refasse un deuxième tour s'il
n'est pas modifié.
Comme j'ai dit, le principe est que l'on a confiance en ce que le
document deviendra après soi. L'idée est que l'on définit un circuit
et que l'on contrôle ensuite s'il a été bien suivi. On ne veut donc
pas certifier le contenu du document, juste son circuit.
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.
Oui, je suis d'accord le principe est assez étrange. Mais il s'agit juste d'empêcher quelqu'un de dire qu'il n'a pas eu le document, pas de garantir ce qu'il a signé.
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.
J'y ai pensé mais le temps de ma maîtrise d'ouvrage doit être trop précieux : ils refusent qu'un document refasse un deuxième tour s'il n'est pas modifié.
Comme j'ai dit, le principe est que l'on a confiance en ce que le document deviendra après soi. L'idée est que l'on définit un circuit et que l'on contrôle ensuite s'il a été bien suivi. On ne veut donc pas certifier le contenu du document, juste son circuit.
Tes impressions ?
Philippe Martin
Pierre Goupil wrote:
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.
Note que les sources de svn sont disponibles (pour la pérénité).
Philippe
Pierre Goupil wrote:
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.
Note que les sources de svn sont disponibles (pour la pérénité).
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.
Note que les sources de svn sont disponibles (pour la pérénité).
Philippe
Patrick 'Zener' Brunet
Bonjour.
Je réponds à Pierre Goupil
Bonjour à tous !
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. [...]
J'ai eu une longue journée de ménage binaire, alors je vais essayer de faire simple mais pas trop simpliste...
En fait si je comprends bien:
- Chaque personne doit signer un état du document à un moment donné.
- Ce qui est demandé, c'est de valider le fait que le document a bien suivi le workflow.
- Le fait de conserver l'historique des modifications est secondaire, et peut être sous-traité à une autre partie de l'outil (beaucoup l'embarquent par défaut, Word par exemple a son mode de gestion des modifications)... Mais s'il y a litige on peut imaginer de localiser l'erreur en refaisant les modifications et en comparant avec les signatures...
Dans cette logique il me semble que chaque signature doit être un certificat attaché au document, et composé:
- d'une clé identifiant le signataire (sa clé publique par exemple), - d'un hash cryptographique calculé sur l'état courant du document, - d'un hash cryptogaphique calculé sur la (ou la chaîne de) signature précédente au sens du workflow, - l'ensemble de ce certificat étant indissociable et scellé par la clé privée du signataire, - les certificats étant en plus numérotés en clair pour un bon enchaînement.
Dans ces conditions, il est a priori garanti que :
- chaque signature est inviolable, non déplaçable, et garde la trace de ce qu'elle a avalisé, - le document reste librement modifiable, - le suivi des modifications peut se faire selon la méthode de votre choix, - en cas de litige, ce suivi n'est pas nécessaire pour localiser le chaînon litigieux dans le workflow (parole des précédents contre parole des suivants), - si l'enjeu nécessite une preuve formelle de la faute, alors il est possible de refaire l'historique en validant chaque étape par comparaison avec les hash signés.
J'espère que je n'ai pas fait la grosse bévue :-)
Votre avis ?
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à Pierre Goupil <goupilpierre@gmail.com>
Bonjour à tous !
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.
[...]
J'ai eu une longue journée de ménage binaire, alors je vais essayer de faire
simple mais pas trop simpliste...
En fait si je comprends bien:
- Chaque personne doit signer un état du document à un moment donné.
- Ce qui est demandé, c'est de valider le fait que le document a bien suivi
le workflow.
- Le fait de conserver l'historique des modifications est secondaire, et
peut être sous-traité à une autre partie de l'outil (beaucoup l'embarquent
par défaut, Word par exemple a son mode de gestion des modifications)...
Mais s'il y a litige on peut imaginer de localiser l'erreur en refaisant les
modifications et en comparant avec les signatures...
Dans cette logique il me semble que chaque signature doit être un certificat
attaché au document, et composé:
- d'une clé identifiant le signataire (sa clé publique par exemple),
- d'un hash cryptographique calculé sur l'état courant du document,
- d'un hash cryptogaphique calculé sur la (ou la chaîne de) signature
précédente au sens du workflow,
- l'ensemble de ce certificat étant indissociable et scellé par la clé
privée du signataire,
- les certificats étant en plus numérotés en clair pour un bon enchaînement.
Dans ces conditions, il est a priori garanti que :
- chaque signature est inviolable, non déplaçable, et garde la trace de ce
qu'elle a avalisé,
- le document reste librement modifiable,
- le suivi des modifications peut se faire selon la méthode de votre choix,
- en cas de litige, ce suivi n'est pas nécessaire pour localiser le chaînon
litigieux dans le workflow (parole des précédents contre parole des
suivants),
- si l'enjeu nécessite une preuve formelle de la faute, alors il est
possible de refaire l'historique en validant chaque étape par comparaison
avec les hash signés.
J'espère que je n'ai pas fait la grosse bévue :-)
Votre avis ?
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
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. [...]
J'ai eu une longue journée de ménage binaire, alors je vais essayer de faire simple mais pas trop simpliste...
En fait si je comprends bien:
- Chaque personne doit signer un état du document à un moment donné.
- Ce qui est demandé, c'est de valider le fait que le document a bien suivi le workflow.
- Le fait de conserver l'historique des modifications est secondaire, et peut être sous-traité à une autre partie de l'outil (beaucoup l'embarquent par défaut, Word par exemple a son mode de gestion des modifications)... Mais s'il y a litige on peut imaginer de localiser l'erreur en refaisant les modifications et en comparant avec les signatures...
Dans cette logique il me semble que chaque signature doit être un certificat attaché au document, et composé:
- d'une clé identifiant le signataire (sa clé publique par exemple), - d'un hash cryptographique calculé sur l'état courant du document, - d'un hash cryptogaphique calculé sur la (ou la chaîne de) signature précédente au sens du workflow, - l'ensemble de ce certificat étant indissociable et scellé par la clé privée du signataire, - les certificats étant en plus numérotés en clair pour un bon enchaînement.
Dans ces conditions, il est a priori garanti que :
- chaque signature est inviolable, non déplaçable, et garde la trace de ce qu'elle a avalisé, - le document reste librement modifiable, - le suivi des modifications peut se faire selon la méthode de votre choix, - en cas de litige, ce suivi n'est pas nécessaire pour localiser le chaînon litigieux dans le workflow (parole des précédents contre parole des suivants), - si l'enjeu nécessite une preuve formelle de la faute, alors il est possible de refaire l'historique en validant chaque étape par comparaison avec les hash signés.
J'espère que je n'ai pas fait la grosse bévue :-)
Votre avis ?
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Pierre Goupil
Bingo ! C'est tout-à-fait ce que je voulais ! Merci beaucoup !
Bingo ! C'est tout-à-fait ce que je voulais ! Merci beaucoup !
Bingo ! C'est tout-à-fait ce que je voulais ! Merci beaucoup !
godin.v
Je crois comprendre qu'il faut associer un UUID au document et faire signer cet UUID et la date (inutile de calculer un hash du document). Mais il nous manque des données importantes pour comprendre le projet : c'est l'architecture globale du système : où sont placés les signatures ? Dans le document, dans un flux associé, dans une base de données...?
Bon courrage
Je crois comprendre qu'il faut associer un UUID au document et faire
signer cet UUID et la date (inutile de calculer un hash du document).
Mais il nous manque des données importantes pour comprendre le projet
: c'est l'architecture globale du système : où sont placés les
signatures ? Dans le document, dans un flux associé, dans une base de
données...?
Je crois comprendre qu'il faut associer un UUID au document et faire signer cet UUID et la date (inutile de calculer un hash du document). Mais il nous manque des données importantes pour comprendre le projet : c'est l'architecture globale du système : où sont placés les signatures ? Dans le document, dans un flux associé, dans une base de données...?
Bon courrage
Pierre Goupil
Bonjour !
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
Pour ce qui est des signatures, je prévois qu'elle soient stockées sur le serveur. Le but est de tout gérer informatiquement, pour masquer la complexité afin que les utilisateurs aient juste à rentrer leur mot de passe au moment de signer. Je ne leur demande pas de s'impliquer en ayant la moindre connaissance de la cuisine interne, juste en se rendant compte qu'ils prennent un réel engagement, quand ils signent.
Pierre
Je crois comprendre qu'il faut associer un UUID au document et faire signer cet UUID et la date (inutile de calculer un hash du document). Mais il nous manque des données importantes pour comprendre le projet : c'est l'architecture globale du système : où sont placés les signatures ? Dans le document, dans un flux associé, dans une base de données...?
Bon courrage
Bonjour !
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
Pour ce qui est des signatures, je prévois qu'elle soient stockées
sur le serveur. Le but est de tout gérer informatiquement, pour
masquer la complexité afin que les utilisateurs aient juste à rentrer
leur mot de passe au moment de signer. Je ne leur demande pas de
s'impliquer en ayant la moindre connaissance de la cuisine interne,
juste en se rendant compte qu'ils prennent un réel engagement, quand
ils signent.
Pierre
Je crois comprendre qu'il faut associer un UUID au document et faire
signer cet UUID et la date (inutile de calculer un hash du document).
Mais il nous manque des données importantes pour comprendre le projet
: c'est l'architecture globale du système : où sont placés les
signatures ? Dans le document, dans un flux associé, dans une base de
données...?
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
Pour ce qui est des signatures, je prévois qu'elle soient stockées sur le serveur. Le but est de tout gérer informatiquement, pour masquer la complexité afin que les utilisateurs aient juste à rentrer leur mot de passe au moment de signer. Je ne leur demande pas de s'impliquer en ayant la moindre connaissance de la cuisine interne, juste en se rendant compte qu'ils prennent un réel engagement, quand ils signent.
Pierre
Je crois comprendre qu'il faut associer un UUID au document et faire signer cet UUID et la date (inutile de calculer un hash du document). Mais il nous manque des données importantes pour comprendre le projet : c'est l'architecture globale du système : où sont placés les signatures ? Dans le document, dans un flux associé, dans une base de données...?
Bon courrage
Emile
Bonjour !
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
Je me posais la même question. En surfant sur internet, on trouve
http://www.zopevillage.com/contributions/index_html/uuidgen J'ai appris du neuf
Emile
Bonjour !
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
Je me posais la même question. En surfant sur internet, on trouve
http://www.zopevillage.com/contributions/index_html/uuidgen
J'ai appris du neuf
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
Je me posais la même question. En surfant sur internet, on trouve
http://www.zopevillage.com/contributions/index_html/uuidgen J'ai appris du neuf
Emile
Patrick 'Zener' Brunet
Bonjour. (j'ai remis dans l'ordre)
Je réponds à Pierre Goupil
Je crois comprendre qu'il faut associer un UUID au document et faire signer cet UUID et la date (inutile de calculer un hash du document). Mais il nous manque des données importantes pour comprendre le projet
c'est l'architecture globale du système : où sont placés les signatures ? Dans le document, dans un flux associé, dans une base de
données...?
Bonjour !
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
En principe, c'est Universally Unique IDentifier, c'est à dire un record garanti unique en lieu et en date. En pratique on ne peut que l'approximer (probabilité de collision statistiquement infime), et si on est un puriste on appelle ça un GUID (Globally...).
Mais ce genre de chose sert à immatriculer de manière garantie unique une entité dans un écosystème où ont lieu des nommages concurrents et non concertés (sans distributeur d'ID centralisé).
Ca ne s'applique pas forcément au problème car il est bien nécessaire de calculer un hash sur l'ensemble du document dans son état courant, afin de le signer de manière irréversible. Immatriculer la version ne la protègerait pas d'une correction a posteriori et insérée "au-dessus" de la signature.
Par contre les certificats peuvent être simplement annexés directement ou virtuellement (et non incorporés) au document, à moins que les perdre au passage soit un scénario d'attaque crédible.
Pour ce qui est des signatures, je prévois qu'elle soient stockées sur le serveur. Le but est de tout gérer informatiquement, pour masquer la complexité afin que les utilisateurs aient juste à rentrer leur mot de passe au moment de signer. Je ne leur demande pas de s'impliquer en ayant la moindre connaissance de la cuisine interne, juste en se rendant compte qu'ils prennent un réel engagement, quand ils signent.
C'est exactement ce que je voulais dire en écrivant que la reconstitution de l'historique avec vérification des tags ne serait nécessaire qu'en cas de litige. A priori l'irréversibilité connue de l'enchaînement des signatures, mettant en évidence le point d'anomalie (avant même de chercher à la caractériser) sera dissuasif dans la plupart des cas.
Il vous appartient de décider par quel moyen "light" assurer la sauvegarde des différentiels de versions. L'algorithme du file compare peut s'appliquer même à du binaire, sinon on peut imaginer que chacun conserve sur sa machine et sous forme compressée la dernière version de la copie qu'il a signée, durant un temps suffisant pour boucler le cycle du document. Si je devais répondre des éventuelles conneries des autres, j'aurais tendance à le faire de moi-même !
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
(j'ai remis dans l'ordre)
Je réponds à Pierre Goupil <goupilpierre@gmail.com>
Je crois comprendre qu'il faut associer un UUID au document et faire
signer cet UUID et la date (inutile de calculer un hash du document).
Mais il nous manque des données importantes pour comprendre le projet
c'est l'architecture globale du système : où sont placés les
signatures ? Dans le document, dans un flux associé, dans une base de
données...?
Bonjour !
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
En principe, c'est Universally Unique IDentifier, c'est à dire un record
garanti unique en lieu et en date.
En pratique on ne peut que l'approximer (probabilité de collision
statistiquement infime), et si on est un puriste on appelle ça un GUID
(Globally...).
Mais ce genre de chose sert à immatriculer de manière garantie unique une
entité dans un écosystème où ont lieu des nommages concurrents et non
concertés (sans distributeur d'ID centralisé).
Ca ne s'applique pas forcément au problème car il est bien nécessaire de
calculer un hash sur l'ensemble du document dans son état courant, afin de
le signer de manière irréversible. Immatriculer la version ne la protègerait
pas d'une correction a posteriori et insérée "au-dessus" de la signature.
Par contre les certificats peuvent être simplement annexés directement ou
virtuellement (et non incorporés) au document, à moins que les perdre au
passage soit un scénario d'attaque crédible.
Pour ce qui est des signatures, je prévois qu'elle soient stockées
sur le serveur. Le but est de tout gérer informatiquement, pour
masquer la complexité afin que les utilisateurs aient juste à rentrer
leur mot de passe au moment de signer. Je ne leur demande pas de
s'impliquer en ayant la moindre connaissance de la cuisine interne,
juste en se rendant compte qu'ils prennent un réel engagement, quand
ils signent.
C'est exactement ce que je voulais dire en écrivant que la reconstitution de
l'historique avec vérification des tags ne serait nécessaire qu'en cas de
litige. A priori l'irréversibilité connue de l'enchaînement des signatures,
mettant en évidence le point d'anomalie (avant même de chercher à la
caractériser) sera dissuasif dans la plupart des cas.
Il vous appartient de décider par quel moyen "light" assurer la sauvegarde
des différentiels de versions. L'algorithme du file compare peut s'appliquer
même à du binaire, sinon on peut imaginer que chacun conserve sur sa machine
et sous forme compressée la dernière version de la copie qu'il a signée,
durant un temps suffisant pour boucler le cycle du document. Si je devais
répondre des éventuelles conneries des autres, j'aurais tendance à le faire
de moi-même !
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
Je crois comprendre qu'il faut associer un UUID au document et faire signer cet UUID et la date (inutile de calculer un hash du document). Mais il nous manque des données importantes pour comprendre le projet
c'est l'architecture globale du système : où sont placés les signatures ? Dans le document, dans un flux associé, dans une base de
données...?
Bonjour !
Pourrais-tu, stp, préciser ce que tu appelles un UUID ?
En principe, c'est Universally Unique IDentifier, c'est à dire un record garanti unique en lieu et en date. En pratique on ne peut que l'approximer (probabilité de collision statistiquement infime), et si on est un puriste on appelle ça un GUID (Globally...).
Mais ce genre de chose sert à immatriculer de manière garantie unique une entité dans un écosystème où ont lieu des nommages concurrents et non concertés (sans distributeur d'ID centralisé).
Ca ne s'applique pas forcément au problème car il est bien nécessaire de calculer un hash sur l'ensemble du document dans son état courant, afin de le signer de manière irréversible. Immatriculer la version ne la protègerait pas d'une correction a posteriori et insérée "au-dessus" de la signature.
Par contre les certificats peuvent être simplement annexés directement ou virtuellement (et non incorporés) au document, à moins que les perdre au passage soit un scénario d'attaque crédible.
Pour ce qui est des signatures, je prévois qu'elle soient stockées sur le serveur. Le but est de tout gérer informatiquement, pour masquer la complexité afin que les utilisateurs aient juste à rentrer leur mot de passe au moment de signer. Je ne leur demande pas de s'impliquer en ayant la moindre connaissance de la cuisine interne, juste en se rendant compte qu'ils prennent un réel engagement, quand ils signent.
C'est exactement ce que je voulais dire en écrivant que la reconstitution de l'historique avec vérification des tags ne serait nécessaire qu'en cas de litige. A priori l'irréversibilité connue de l'enchaînement des signatures, mettant en évidence le point d'anomalie (avant même de chercher à la caractériser) sera dissuasif dans la plupart des cas.
Il vous appartient de décider par quel moyen "light" assurer la sauvegarde des différentiels de versions. L'algorithme du file compare peut s'appliquer même à du binaire, sinon on peut imaginer que chacun conserve sur sa machine et sous forme compressée la dernière version de la copie qu'il a signée, durant un temps suffisant pour boucler le cycle du document. Si je devais répondre des éventuelles conneries des autres, j'aurais tendance à le faire de moi-même !
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Pierre Goupil
Je viens de faire moi aussi des recherches sur les UUID. Et j'avoue ne pas trop voir le bénéfice : gain de place en n'ayant pas à stocker chaque version du document ?
Il y a sûrement quelque chose à en faire, mais quoi ?
Je viens de faire moi aussi des recherches sur les UUID. Et j'avoue ne
pas trop voir le bénéfice : gain de place en n'ayant pas à stocker
chaque version du document ?
Il y a sûrement quelque chose à en faire, mais quoi ?
Je viens de faire moi aussi des recherches sur les UUID. Et j'avoue ne pas trop voir le bénéfice : gain de place en n'ayant pas à stocker chaque version du document ?
Il y a sûrement quelque chose à en faire, mais quoi ?
