La forme du lien est-elle optimale?
TimeStamp-Action-HashSource-HashCible-HashMeta-Signataire-Signature
Avec HashCible et HashMeta facultatifs.
Le Signataire et la Signature (obligatoirement présente mais éventuellement nulle) sont deux éléments indissociables et à la fin. Ils valident ainsi le (reste du) lien.
Mais ils pourraient tout aussi bien être au début, à la façon d’une ouverture de trame. Leur présence serait ainsi logique juste après le TimeStamp… ou juste avant.
Signataire-Signature-TimeStamp-Action-HashSource-HashCible-HashMeta
Il y a par contre un champ qui a tout intérêt à être à un extrême de la ligne, c’est la Signature. Celle-ci est calculée sur tout le lien sauf elle-même, n’étant pas connu au moment de créer l’empreinte du lien. Elle est dans ce cas calculée avec un champ soit vide soit avec une valeur prédéfinie (nulle). Ca tombe bien, ce champ est justement obligatoire, même avec une valeur nulle. Il faut donc prépositionner cette valeur lorsque l’on calcule la signature.
Autre avantage à placer le Signataire et la Signature en début de lien, c’est qu’il est plus facile de travailler sur les différents champs HashXxxxxx si les deux derniers sont facultatifs.
Signature-Signataire-TimeStamp-Action-HashSource-HashCible-HashMeta
C’est humainement un peu plus lisible, empilés les uns sur les autres. Mais est-ce que ça a de l’importance ? Qui consultera les liens brute de fonderie ?
Mettre la Signature en début de ligne et non en fin, c’est aussi un inconvénient. Lorsque l’on aura une grande quantité de signatures à vérifier, et qu’il faudra prépositionner cette signature pour la recalculer, changer le premier caractère en 0 et définir le deuxième comme la fin de ligne est plus rapide que de ré-écrire tous les caractères de la signature. En plus, il faut dans le deuxième cas déplacer tous les champs de quelques caractères vers la droite…
TimeStamp-Action-HashSource-HashCible-HashMeta-Signataire-0ignature
0-Signataire-TimeStamp-Action-HashSource-HashCible-HashMetaHashMeta
On peut utiliser une autre méthode, pour les langages de programmation qui le supportent. Cette ligne de caractères représentant le lien sera sûrement stocké en mémoire sous forme d’un tableau de caractères. ce tableau est repéré par un pointeur en mémoire. Il suffit d’écrire un 0 sur le dernier caractère de la signature et de changer le pointeur vers ce 0.
Signatur0-Signataire-TimeStamp-Action-HashSource-HashCible-HashMeta
On aura toujours beaucoup plus de liens à vérifier que de liens à signer.
A moins qu’il ne soit préférable de remplacer la signature pour sa vérification par… rien… ce qui est encore plus rapide car c’est juste un changement de pointeur.
Signature-Signataire-TimeStamp-Action-HashSource-HashCible-HashMeta
Ensuite, après la Signature, faut-il mettre le TimeStamp ou le Signataire ?
Le TimeStamp est une valeur assez relative, surtout d’une entité à l’autre. Pour pouvoir réellement exploiter le TimeStamp, il faut de tout façon connaître l’entité, c’est à dire le Signataire.
le champ Action décrit comment va être interprété le reste des champs. Dans le lien, il est le lien entre la partie entité, celui qui parle, et la partie contenu, ce qu’il dit.
Enfin, les derniers champs ont un ordre imposé. HashSource est obligatoire. HashCible et HashMeta sont facultatifs. Cependant, si il n’y a qu’un seul champ après le HashSource, c’est forcément un HashCible.
La forme finale du registre de lien :
Signature-Signataire-TimeStamp-Action-HashSource-HashCible-HashMeta
Quelques questions encore en attente :
- Le registre de lien doit-il être en ASCII et rester lisible par des humains? Ou être encodé en binaire et nécessiter un programme spécifique pour simplement le lire?
- Le séparateur « – » de champs est-il opportun ?
- Quel séparateur(s) de liens ? Espace ? CR ? CR LF ?
- Les champs
HashCibleetHashMetarestent-ils optionnels ou sont-ils obligatoires aussi mais potentiellement nuls ? Simplicité de traitement… - Quel est la compressibilité des liens ? Quel gain de taille peut-on attendre lors d’un transfert avec compression ?
- Doit-on faire précéder les hashs de son type? MD5? SHA? …