Bénéficiaires

Guide bénéficiaire

Tu as reçu un mail de ProofIt. Voilà ce que tu reçois, ce que ça prouve, comment l'utiliser, et comment vérifier toi-même que tout est en ordre.

Les mails que tu peux recevoir

📧 Mail témoin

Envoyé automatiquement à une boîte tierce (en général pas la tienne — elle est interne au service). Atteste qu'une session a été ouverte à l'instant T avec un certain session_id et un certain hash.

📧 Mail d'ouverture si manifest

Si la session porte un manifest prévisionnel, tu reçois ce mail au moment où l'utilisateur valide son OTP. Il liste les opérations qui DEVRAIENT se passer dans cette session + le planned_root_hash en évidence.

À conserver précieusement : c'est ta preuve PRÉVISIONNELLE opposable. À la clôture, le hash doit matcher.

📧 Mail de clôture

Envoyé à la fin de la session. Contient :

session_id, dates d'ouverture/clôture, acteur
session_root_hash et last_entry_hash (état cryptographique final)
Empreintes des clés organisation + master (16 chars de fingerprint)
Si manifest : verdict (MATCH/PARTIAL/DIVERGENT/EMPTY) + les deux hashes côte à côte

Pourquoi ces mails sont opposables

Ils sont DKIM-signés par le service au moment de l'envoi. La clé DKIM publique est publiée dans le DNS du domaine émetteur. Ça veut dire que :

• Une fois reçus, ils sont à jamais cryptographiquement liés à ton fournisseur mail (Gmail, Outlook) qui les stocke avec leurs en-têtes DKIM
• Personne — même pas le service ProofIt — ne peut les ré-écrire rétroactivement sans casser la signature DKIM (qui s'invaliderait visuellement dans n'importe quel client mail)
• Tu peux donc demander à un huissier de constater leur contenu et la validité DKIM des années plus tard

Cross-check manifest : les deux mails doivent matcher

Si tu as reçu mail d'ouverture ET mail de clôture pour la même session, vérifie une chose :

Le planned_root_hash du mail d'ouverture DOIT être identique à celui du mail de clôture.

Si tu vois deux hashes différents, c'est une fraude détectable cryptographiquement — quelqu'un a modifié le plan entre les deux moments. Conserve les deux mails et contacte ton interlocuteur organisation.

Recevoir le dossier de preuve (ASiC-E)

L'organisation peut te transmettre le bundle .asice (un ZIP). Il contient :

README.txt + TIMELINE.txt + VERIFICATION.txt — lisibles humain
entries/{hash}.json — chaque entrée d'audit avec ses deux signatures Ed25519
emails/*.eml — copie EXACTE des mails que tu as reçus, avec leur DKIM
anchors/{id}/*.ots + *.tsr — ancrages OpenTimestamps Bitcoin + TSP qualifié
CANARY.json — snapshot de la vérification chaîne au moment du build
PLAN.json + PLAN_VERIFICATION.txt — le manifest exact (si applicable)
META-INF/manifest.json + .sig — manifest signé par la master key

Vérifier toi-même (sans nous faire confiance)

Le bundle est vérifiable hors-ligne avec un outil Python open source :

pip install session-proof-verify
session-proof-verify bundle.asice --root-key https://proof.example/keys/master.pub

✓ Manifest signature OK
✓ 47/47 audit entries signatures verified
✓ Chain integrity OK (prev_hash matches throughout)
✓ Canary attestation valid
✓ OpenTimestamps anchor verified against Bitcoin block 825042
✓ Universign RFC 3161 token verified
✓ PLAN.json planned_root_hash matches SESSION_PLAN_COMMITTED entry
✓ verdict: MATCH (planned_root_hash == executed_root_hash)

Pas besoin du service en ligne. Pas besoin de leur faire confiance. Tout est vérifiable à partir des éléments du ZIP + une clé publique connue.

En cas de litige

Présente devant le tribunal :

Les mails DKIM-signés tels que reçus (constat d'huissier sur ta boîte)
Le dossier ASiC-E tel que reçu
Le rapport du verifier Python (si tu l'as exécuté)

L'article 25.1 eIDAS garantit que ces éléments seront recevables. L'article 26 garantit que la signature est qualifiée comme AES (Avancée). Si l'organisation a aussi signé via un PSCo qualifié (Yousign QES, Certinomis…), tu as la QES Article 25.2 par-dessus.

← Accueil docs Voir le code