Open eIDAS — Les services de confiance eIDAS comme infrastructure ouverte

Démocratiser la confiance numérique eIDAS dans toute l'économie, de façon sûre, ouverte et sans rente.

Le règlement européen eIDAS a posé le cadre juridique de la confiance numérique : horodatage qualifié, signature et cachet électroniques, archivage à valeur probante, envoi recommandé et portefeuilles d'identité numérique (eIDAS 2.0 / EUDI).

Pourtant, dans la pratique économique, ces briques indispensables restent captives d'un modèle de rente oligopolistique :

• Facturation au jeton ou à l'acte, transformant des obligations légales (facturation électronique obligatoire B2B, archivage légal, contractualisation dématérialisée) en péage privé récurrent ;
• Friction technique et contractuelle majeure : portails fermés, SDK propriétaires, délais d'intégration qui se comptent en semaines ;
• Fracture pour l'économie réelle : là où de grands groupes négocient des volumes, les TPE/PME, éditeurs indépendants et administrations de proximité sont freinés ou contraints de bricoler sans garanties de conformité.

Le même verrou existait pour le chiffrement web avant Let's Encrypt.

Open eIDAS applique le modèle de l'ISRG à l'écosystème eIDAS : une gouvernance d'intérêt général à but non lucratif, une infrastructure cryptographique souveraine et auditable, des API ouvertes et standardisées, et un coût d'accès nul ou à prix coûtant. Notre mission est de démocratiser eIDAS dans l'économie de manière rigoureuse et pérenne — sans compromis sur la sécurité.

---

Notre premier service : l'horodatage qualifié (RFC 3161)

Pour bâtir un édifice de confiance, il faut d'abord maîtriser le temps. L'horodatage qualifié est le premier service développé par Open eIDAS : il constitue le socle d'antériorité et d'intégrité temporelle universel, nécessaire à la signature électronique (validité à long terme LTA), au cachet d'entreprise, à la facturation électronique et à l'archivage à valeur probante.

Là où le marché impose des barrières contractuelles, l'intégration Open eIDAS est immédiate :

DIGEST=$(sha256sum facture.pdf | cut -d' ' -f1)

curl -s -X POST http://localhost:8318/api/v1/timestamp \
     -H 'Content-Type: application/json' \
     -d "{\"hash\":\"$DIGEST\"}"

Voilà l'intégration complète. Pas de compte, pas de SDK propriétaire, pas de bon de commande.

La feuille de route d'Open eIDAS étendra progressivement ce socle aux autres services de confiance essentiels : cachet électronique de personne morale (seal) automatisable, validation de signatures qualifiées, et passerelles d'attestation conformes à eIDAS 2.

---

Ce que fait ce dépôt

Ce dépôt héberge le prototype fonctionnel et vérifiable du premier service Open eIDAS — l'autorité d'horodatage (TSA) :

• un service d'horodatage RFC 3161 écrit en Rust (mémoire sûre par construction — unsafe_code interdit dans tout le workspace sauf le module d'accès au HSM), dont la clé de signature ne quitte jamais un module cryptographique (PKCS#11) ;
• une autorité de certification écrite en propre — racine, CA émettrice, profils compilés et testés, approbation RA effective, publication de la CRL et réponses OCSP — qui délivre le certificat de l'unité d'horodatage par enrôlement automatisé ;
• une matrice de conformité ETSI générée depuis le code (docs/CONFORMITE-ETSI.md) : chaque exigence applicable est portée par un mécanisme identifié et un test exécutable, ou déclarée comme écart avec sa cible — la CI échoue si une ligne perd l'un des deux ;
• un HSM logiciel SoftHSM2 parlant le protocole d'un HSM certifié, pour que le passage en production soit un changement de configuration, pas de code ;
• une heure traçable jusqu'à UTC : le service recoupe deux serveurs de laboratoires de métrologie (Observatoire de Paris, PTB) et cesse d'émettre dès que la dérive dépasse le seuil annoncé, comme l'exige ETSI EN 319 421 ;
• un journal d'audit chaîné par hachage, contresigné par des TSA tierces publiques (FreeTSA.org, DigiCert) : chaque scellement se vérifie avec les outils RFC 3161 standards, sans dépendre de la confiance en Open eIDAS ;
• le tout orchestré en docker compose, démarrable en une commande.

Ce n'est pas encore une TSA qualifiée : les écarts avec le référentiel eIDAS sont listés explicitement dans docs/ARCHITECTURE.md et, exigence par exigence, dans docs/CONFORMITE-ETSI.md — HSM certifié, cérémonie de clé sous double contrôle, opérateur RA nominatif, redondance, audit d'un organisme accrédité. Le chiffrage de ce chemin est connu : 70 à 95 k€ pour l'infrastructure et l'audit initial.

Démarrage

Prérequis : Docker avec le plugin Compose, git, openssl, curl.

git clone https://github.com/otspi/open-eidas.git
cd open-eidas

make up      # amorce la CA, émet les certificats TSU et OCSP, démarre la pile
make demo    # horodate un fichier et vérifie le jeton avec openssl ts

make up est idempotent et prend quelques minutes au premier lancement : l'essentiel du temps est la génération des bi-clés dans les tokens SoftHSM (racine et CA émettrice en RSA-4096, TSU et répondeur OCSP en RSA-3072). La cérémonie de clé est rejouée à chaque démarrage sans jamais recréer de hiérarchie existante.

Chaque demande de certificat attend l'approbation d'un opérateur d'enregistrement : make up l'accorde automatiquement sous un compte technique pour que la démonstration s'amorce seule — écart assumé, tracé comme tel au journal d'audit (voir docs/CA.md).

Vérifier un jeton avec les outils standards

openssl ts -query -data facture.pdf -sha256 -cert -out facture.tsq

curl -s -H 'Content-Type: application/timestamp-query' \
     --data-binary @facture.tsq http://localhost:8318/tsa -o facture.tsr

curl -s http://localhost:8318/api/v1/certificate -o tsa-chain.pem
awk '/BEGIN CERTIFICATE/{n++} {print > (n == 1 ? "tsu.pem" : "ca.pem")}' tsa-chain.pem

openssl ts -verify -in facture.tsr -queryfile facture.tsq -CAfile ca.pem

L'interface d'administration de la PKI est disponible sur https://localhost:8443/webui/ (certificat auto-signé).

Relire le journal d'audit

docker compose exec tsa tsa-server verify-audit

Autres cibles : make test, make lint, make audit, make logs, make down, make purge.

Déployer sur Kubernetes

La même pile est packagée en chart Helm, pour un déploiement piloté par ArgoCD ou un helm install direct :

helm install open-eidas deploy/helm/open-eidas --namespace open-eidas --create-namespace

Voir deploy/helm/open-eidas/README.md et le dépôt app-of-apps otspi/deploy.

Documentation

• Architecture technique — choix de conception, séquence de démarrage, écarts au référentiel, trajectoire de qualification.
• Référence de l'API — endpoints, codes d'erreur RFC 3161, variables de configuration.
• Chart Helm — déploiement Kubernetes / ArgoCD.

Structure du dépôt

bin/tsa-server/        point d'entrée de la TSA : enroll, serve, verify-audit
bin/ca-server/         autorité de certification : ceremony, serve, ra, revoke
bin/ocsp-responder/    répondeur OCSP (RFC 6960)
crates/oe-tsa-core/    cœur RFC 3161 : validation, TSTInfo, CMS SignedData
crates/oe-conformance/ exigences ETSI sous forme exécutable, et la matrice
crates/oe-ca-core/     moteur d'émission : profils, cérémonie, CRL
crates/oe-raflow/      machine à états d'enrôlement et d'approbation RA
crates/oe-castore/     registre de la CA (PostgreSQL, et mémoire pour les tests)
crates/oe-hsm/         accès PKCS#11 aux clés de signature (seule crate autorisant `unsafe`)
crates/oe-timesource/  surveillance de la traçabilité de l'heure
crates/oe-audit/       journal d'audit chaîné par hachage
crates/oe-crosstsa/    contreseing du journal par des TSA tierces publiques
crates/oe-enroll/      client d'enrôlement auprès de la CA
crates/oe-httpapi/     endpoints HTTP (RFC 3161 + façade JSON)
deploy/                images des trois services, chart Helm
scripts/               amorçage et démonstration

Modèle & Sûreté

• Gouvernance non lucrative d'intérêt général : association financée par le mécénat et le soutien d'acteurs de la souveraineté numérique. Service gratuit ou à prix coûtant, sans quota commercial ni rente monopolistique. La frugalité se vérifie : la pile complète tient dans ~200 Mio de RAM demandée, mesuré service par service dans docs/SIZING.md.
• Sûreté intransigeante : aucun compromis sur la sécurité. L'architecture est conçue pour satisfaire rigoureusement les normes ETSI (EN 319 421, EN 319 422, etc.) et les exigences de qualification eIDAS / ANSSI.
• Transparence intégrale : code source libre, politiques de service publiques, traçabilité métrologique documentée et rapports d'audit tiers publiés.

Contribuer

Les contributions sont bienvenues, en particulier sur l'intégration de HSM certifiés, le journal d'audit inaltérable, la redondance du service, la conformité ETSI EN 319 421 / 319 422 et le développement des futurs services de confiance.

Contact & Liens

• Site web officiel : https://open-eidas.eu
• Contact : contact@open-eidas.eu
• Organisation GitHub : github.com/otspi
• Code source du site web : otspi/website

Licence

Open eIDAS est distribué sous double licence, au choix de celui qui le réutilise (identifiant SPDX EUPL-1.2 OR AGPL-3.0-only) :

• la licence publique de l'Union européenne EUPL v1.2 — voir LICENSE ;
• la GNU Affero General Public License v3 (version 3 uniquement) — voir LICENSE-AGPL-3.0.

Les deux sont des licences à réciprocité (copyleft) : toute version modifiée et distribuée, y compris lorsqu'elle est mise à disposition en tant que service en réseau, doit rester publiée sous la licence choisie. La branche AGPL permet d'intégrer directement Open eIDAS dans un projet sous AGPL ou GPL v3, sans passer par l'annexe de compatibilité de l'EUPL.

Les versions publiées avant le passage à l'EUPL restaient déjà disponibles sous AGPL v3.