Concepts

Vérifier une attestation

Vos attestations portent trois contrôles indépendants. Votre auditeur peut les mener sans nous, sur son poste, et sans rien nous envoyer. Cette page donne la séquence exacte.

Ce que porte une pièce

Chaque attestation reçoit une référence citable de la forme ATT-2026-000042, stable dans le temps. Régénérer la même pièce sur le même périmètre conserve cette référence et incrémente son numéro d’émission ; elle ne fabrique pas un second numéro pour le même document.

Depuis votre tableau de bord, une pièce s’exporte en quatre formats. Le PDF est la pièce elle-même. La forme canonique est le fichier exact sur lequel porte l’empreinte et la signature. Les deux fichiers de signature accompagnent ce dernier.

Contrôle 1 : le fichier PDF

Le plus simple, et le seul qui détecte une retouche du document lui-même : une note ajoutée, une valeur blanchie, un montant modifié dans un éditeur de PDF.

shasum -a 256 mafate-ATT-2026-000042-rgpd.pdf

Comparez le résultat aux empreintes publiées sur mafate.io/verify/ATT-2026-000042. Aucun outillage n’est nécessaire, shasum existe sur tout poste.

Une empreinte absente de la liste a deux explications, et une seule est une fraude. Le PDF n’est pas reproductible : régénérer produit un fichier différent. Le numéro d’émission imprimé sur votre exemplaire tranche entre « je détiens une version antérieure » et « ce document a été modifié ». Seules les 50 dernières émissions sont conservées.

Contrôle 2 : les données attestées

La signature porte sur la forme canonique, une sérialisation figée de ce que la pièce affirme : référentiel, période, mesures, acteurs, mode d’intégration constaté. Elle détecte toute modification de ces données.

Deux signatures accompagnent chaque pièce. Utilisez celle que votre poste sait lire.

curl -sO https://www.mafate.io/legal/attestation-key-ed25519.pem

openssl pkeyutl -verify -pubin -inkey attestation-key-ed25519.pem -rawin \
  -in mafate-ATT-2026-000042-canonique.json \
  -sigfile mafate-ATT-2026-000042-sig-ed25519.sig

Réponse attendue : Signature Verified Successfully. Sur un contenu modifié d’un seul octet : Signature Verification Failure.

Contrôle 3 : la même chose, à l’épreuve du quantique

La signature ML-DSA-65 (FIPS 204) couvre le même contenu et résiste à un adversaire quantique. C’est celle qui compte pour une pièce archivée plusieurs années.

curl -sO https://www.mafate.io/legal/attestation-key-mldsa.pem

openssl pkeyutl -verify -pubin -inkey attestation-key-mldsa.pem -rawin \
  -in mafate-ATT-2026-000042-canonique.json \
  -sigfile mafate-ATT-2026-000042-sig-mldsa.sig

Cette commande exige OpenSSL 3.5 ou plus, sorti en 2025. Sur Debian 12 ou RHEL 9, qui embarquent OpenSSL 3.0, elle échouera. C’est la raison d’être de la signature Ed25519 : elle se vérifie avec tout OpenSSL depuis 2018. Si votre poste le permet, préférez ML-DSA.

Ce que ces contrôles ne prouvent pas

La clé privée qui signe est un secret d’application, elle n’est pas détenue par un module matériel : notre module de sécurité ne porte aucun algorithme post-quantique. Quiconque obtiendrait ce secret pourrait signer en notre nom. Nous préférons l’écrire plutôt que de laisser supposer une protection que nous n’avons pas.

La page publique de vérification publie la signature, elle ne la vérifie pas. Vérifier demande les octets de la forme canonique, que nous ne stockons pas et que seul le détenteur de la pièce possède. Une page qui afficherait « signature valide » affirmerait ce qu’elle n’est pas en position d’établir.

Enfin, une attestation n’est pas un certificat. Elle constate ce que le journal d’audit établit sur une période, elle ne délivre aucune qualification.

Pièces émises avant le 13 août 2026

Elles ne portent ni signature ni empreinte de fichier, et la page de vérification l’indique. Ce n’est pas une signature invalide : elles ont été émises avant que le dispositif existe. Les régénérer sur le même périmètre leur donne les trois contrôles, en conservant leur référence.