PD-81 - Review Step 3 : CONFORMITY_CHECK¶

Statut: REVIEW PHASE 1 Version: 1.0.0 Date: 2026-02-23 Perimetre: EPIC PD-189 (CRYPTO) Auditeur: Claude Opus 4.6 (auditeur technique independant)

Documents audites¶

Synthese¶

Constats detailles¶

CONSTAT-01¶

Type : Ambiguite Reference : Spec §5-N2, §7.2 LegalValidationCase, §3 "Double validation 2-of-2" Description : La specification impose une double validation DPO + LegalOfficer via adaptation de PD-82 mais ne specifie pas le TTL de la fenetre de double validation. Le besoin (§4.2) mentionne "defaut : 7 jours pour la double validation, comme PD-82" mais cette valeur n'apparait pas dans la specification contractuelle. Le champ validationTtl (§7.2) est marque obligatoire mais aucune borne dure ni valeur par defaut n'est specifiee. La section §2.3 point 8 ("Taxonomie des types de mandat et valeurs de TTL de double validation associees") confirme que cette information est manquante. Impact : Une equipe tierce ne peut pas implementer le TTL de double validation sans hypothese arbitraire. Le test N2 verifie "dans la fenetre TTL" sans connaitre cette fenetre. Gravite : Bloquant

CONSTAT-02¶

Type : Ambiguite Reference : Spec §5-N4 etape 1, §3 "Destruction cryptographique verifiable", §9.1 closeLegalAccess Description : Trois causes de cloture sont enumerees (expiration TTL, fin de consultation, revocation explicite) mais "fin de consultation" n'est pas definie. La section §2.3 point 7 confirme cette lacune : "Regles metier de 'fin de consultation' (condition de terminaison explicite)". Or, l'interface closeLegalAccess accepte END_OF_CONSULTATION comme cause. Le test L2 ("Destruction sur fin de consultation") est suppose tester ce cas sans critere observable de declenchement. Impact : Le scenario L2 n'est pas implementable de maniere deterministe. Le statut terminal COMPLETED (distinct de REVOKED/EXPIRED) est atteignable uniquement via cette cause non definie. Gravite : Bloquant

CONSTAT-03¶

Type : Ambiguite Reference : Spec §4 INV-81-07, §5-N4 etape 2, §3 "Revocation", §9.2 revokeReKey Description : INV-81-07 exige que "toute ReKey legale est destructible de facon verifiable". La definition de "Revocation" precise "effet immediat attendu" et l'interface revokeReKey a pour post-condition "ReKey invalidee immediatement". Or, "immediatement" n'est pas defini en termes d'observable contractuel (latence maximale tolerable, atomicite transactionnelle, propagation cache). Le test S3 verifie l'invalidite "immediate" apres revocation mais ne precise pas la fenetre de verification. Impact : Un test d'invalidation "immediate" peut passer ou echouer selon l'interpretation (synchrone vs async, cache invalidation delay). Risque de race condition non detectable. Gravite : Majeur

CONSTAT-04¶

Type : Contradiction Reference : Spec §4 INV-81-01 vs §7.3 LegalReKey.status Description : INV-81-01 stipule "aucun mecanisme permanent d'acces n'est cree". Le modele de donnees §7.3 definit les statuts ACTIVE, REVOKED, EXPIRED, DESTROYED. L'existence d'un statut DESTROYED distinct de REVOKED/EXPIRED implique un cycle de vie a deux etapes terminales (d'abord revocation/expiration, puis destruction). Or, la specification ne definit pas la transition entre REVOKED/EXPIRED et DESTROYED, ni le delai acceptable (§2.3 point 5 confirme cette lacune). En l'absence de transition definie, le statut DESTROYED est inatteignable contractuellement ou son atteinte est indeterministe. Impact : Le cycle de vie de la ReKey legale est incomplet. Le test N4 attend un statut terminal dans {REVOKED, EXPIRED, COMPLETED} sans mentionner DESTROYED, alors que le modele de donnees le definit comme valeur possible. Incoherence entre tests et modele de donnees. Gravite : Majeur

CONSTAT-05¶

Type : Incohérence Spec<>Tests Reference : Spec §7.3 LegalReKey.status vs Tests §2 N4 Description : Le modele de donnees definit les statuts possibles : ACTIVE, REVOKED, EXPIRED, DESTROYED. Le scenario N4 attend un statut terminal "dans {REVOKED, EXPIRED, COMPLETED}". Le statut COMPLETED n'apparait pas dans le modele de donnees §7.3. Le statut DESTROYED apparait dans le modele mais pas dans les resultats attendus de N4. Il y a deux incoherences factuelles : (1) COMPLETED est utilise dans les tests mais absent du modele, (2) DESTROYED est dans le modele mais absent des attendus de test. Impact : Un implementeur ne sait pas si COMPLETED est un statut valide de ReKey (absent du modele) ni quand DESTROYED est atteint (absent des tests nominaux). Gravite : Bloquant

CONSTAT-06¶

Type : Incohérence Spec<>Tests Reference : Spec §5-N2 vs Code PD-82 implementation (enums/validation-state.enum.ts) Description : La specification PD-81 (§5-N2 etape 3) dit "le systeme applique les regles d'etat PD-82 adaptees au contexte LEGAL_PRE_MANDATE". L'implementation PD-82 existante utilise les roles PARENT/AUTHORITY (enum ValidatorType) et les etats intermediaires PENDING_PARENT/PENDING_AUTHORITY. La specification PD-81 mentionne les roles DPO/LegalOfficer mais ne precise pas comment ces roles se mappent sur les etats PD-82. Faut-il creer des etats PENDING_DPO/PENDING_LEGAL_OFFICER, ou reutiliser PENDING_PARENT=DPO et PENDING_AUTHORITY=LegalOfficer ? Le modele §7.2 dit simplement "state (obligatoire: etats PD-82 adaptes)" sans preciser l'adaptation. Impact : L'adaptation de PD-82 est la piece maitresse de l'orchestration mais son mapping est ambigu. Le test N2 verifie des "transitions d'etat conforme PD-82 adaptee" sans que les valeurs d'etat intermediaires soient specifiees. Gravite : Majeur

CONSTAT-07¶

Type : Ambiguite Reference : Spec §5-N3 etape 1, §9.1 activateLegalAccess vs §9.2 generateLegalReKey Description : Le flux N3 etape 1 dit "le systeme appelle activateLegalAccess puis generateLegalReKey(...)". L'interface activateLegalAccess a pour post-condition "Creation d'une ReKey legale via PD-41 etat ACTIVE". Cela implique que activateLegalAccess cree deja la ReKey en interne. Mais le flux N3 dit "puis generateLegalReKey" comme un second appel distinct. Soit activateLegalAccess orchestre et appelle generateLegalReKey en interne (un seul appel API), soit ce sont deux appels distincts sequentiels. La specification est ambigue sur ce point. Impact : Le test N3 etape 1 appelle les deux fonctions, ce qui pourrait creer un doublon si activateLegalAccess encapsule deja la generation. Gravite : Majeur

CONSTAT-08¶

Type : Ambiguite Reference : Spec §9.2 generateLegalReKey signature Description : La signature de generateLegalReKey inclut alicePublicKey et bobPublicKey comme parametres. Or, dans le contexte Legal PRE, "Alice" (proprietaire du coffre) et "Bob" (autorite judiciaire destinataire) ne sont pas definis dans les definitions §3 de PD-81. La specification PD-41 definit Alice/Bob mais PD-81 ne mappe pas ces roles au contexte judiciaire. De plus, la source de bobPublicKey (cle publique de l'autorite judiciaire) n'est pas specifiee : qui la fournit, quand, et avec quelle verification d'authenticite ? Impact : Un implementeur ne sait pas d'ou provient bobPublicKey ni comment sa legitimite est verifiee. Risque que n'importe quelle cle publique soit fournie comme destinataire, contournant le controle d'acces. Gravite : Bloquant

CONSTAT-09¶

Type : Non testable Reference : Spec §10.1 "Compatibilite visee eIDAS 2.0, RGPD, NF Z42-013/ISO 14641, art. 1366 Code civil" Description : La specification vise la conformite a 5 referentiels normatifs/legaux distincts sans definir de criteres techniques observables pour chacun. Les criteres d'acceptation AC-81-15 et AC-81-16 sont deja marques "Non testable" dans la specification. Cependant, la mention §10.1 "Verification juridique finale de conformite normative: hors perimetre technique testable" cree un paradoxe contractuel : la spec fait loi mais renvoie a un controle externe non specifie. Impact : Une recette technique ne peut pas certifier la conformite normative. Le statut contractuel de cette exigence est ambigu : obligation de moyen ou de resultat ? Gravite : Mineur

CONSTAT-10¶

Type : Hypothese dangereuse Reference : Spec §5-N1 etape 3, §4 INV-81-02, §6 ERR-81-15 Description : INV-81-02 impose qu'aucun acces n'est possible sans mandat valide verifie "via TSP reel au moment de l'instruction". Le TSP est un service externe. ERR-81-15 prevoit le cas d'indisponibilite TSP avec "rejet temporaire fail-closed". Cependant, la specification ne definit pas de politique de retry, de timeout, ni de fenetre de grace. Si le TSP est intermittent au moment precis de la verification, un mandat parfaitement valide est rejete sans recours. Le test R1 ("Panne TSP intermittente") est defini en titre uniquement (section squelette §5) sans etapes ni attendus. Impact : L'hypothese implicite est que le TSP est hautement disponible. En cas de degradation prolongee, aucun mandat ne peut etre instrumente, meme urgent. Le test R1 est vide et donc non executable. Gravite : Majeur

CONSTAT-11¶

Type : Incohérence Spec<>Tests Reference : Tests §5 scenarios R1-R6, L1-L4 Description : Les scenarios de robustesse R1 a R6 et de cycle de vie L1 a L4 sont listes en titre uniquement dans le document de test. Aucune etape, aucun prerequis, aucun resultat attendu n'est defini. Pourtant, la matrice de couverture §1.1 les reference comme scenarios couvrants (ex: L1 pour INV-81-01, R1-R3 pour INV-81-11). Des invariants sont declares couverts par des scenarios inexistants. Impact : La matrice de couverture affiche une couverture faussement complete. 10 scenarios (R1-R6, L1-L4) sont des coquilles vides referenceant des invariants et criteres sans les tester reellement. Gravite : Bloquant

CONSTAT-12¶

Type : Hypothese dangereuse Reference : Spec §5-N3 etape 4, §6 ERR-81-18, §2.3 point 3 Description : Le flux N3 impose un "rate limiting contractuel anti-extraction massive" mais les parametres (seuils, fenetres, unites, comportement) sont listes comme information manquante (§2.3 point 3). Le test E18 presuppose "seuil rate limiting configure et connu en environnement QA" comme prerequis. Le point NT-81-01 confirme le statut "TESTABLE SOUS CONDITION". Or, sans parametres definis, le rate limiting est un concept non implementable et non verifiable. Impact : Le mecanisme anti-exfiltration est contractuellement exige mais techniquement non specifiable. Un implementeur peut mettre n'importe quelle valeur ou aucune. Le test E18 ne peut pas echouer faute de critere d'acceptation. Gravite : Majeur

CONSTAT-13¶

Type : Risque secu/conformite Reference : Spec §4 INV-81-04, §9.2 generateLegalReKey retour Description : INV-81-04 stipule "aucune cle persistante de document n'est exposee; seuls des artefacts temporaires de re-chiffrement sont admis". Le test S1 verifie "presence exclusive d'artefacts temporaires de rechiffrement, jamais de cle persistante document". Cependant, la specification ne definit pas ce qui constitue une "cle persistante" vs un "artefact temporaire" au niveau technique. Un ReKey est derive des cles du proprietaire. Si le ReKey est stocke indefiniment en base (le champ DESTROYED n'ayant pas de transition definie, cf. CONSTAT-04), il constitue de facto un artefact persistant capable de re-chiffrement. Impact : L'absence de transition contractuelle vers DESTROYED (avec suppression physique ou cryptographique effective) laisse un risque de persistance residuelle des artefacts de re-chiffrement, en contradiction avec INV-81-04 et INV-81-01. Gravite : Majeur

CONSTAT-14¶

Type : Contradiction Reference : Spec §4 INV-81-08 vs §7.4 LegalAccessEvent.tsaTokenRef Description : INV-81-08 exige que "chaque etape probatoire est journalisee [...] horodatee TSA". Le modele §7.4 marque tsaTokenRef comme "obligatoire pour evenement probatoire". Cela introduit une distinction entre evenements probatoires et non-probatoires, mais la specification ne definit jamais la taxonomie des evenements probatoires vs non-probatoires. Certains evenements (ex: ERR-81-18 "depassement rate limiting") produisent un "evenement d'abus" — est-il probatoire ? L'invariant dit "chaque etape probatoire" sans delimiter quelles etapes sont probatoires. Impact : Un implementeur ne sait pas quels evenements necessitent un horodatage TSA obligatoire (couteux, dependant d'un service externe) et lesquels n'en necessite pas. Si tous les evenements sont probatoires, le champ tsaTokenRef devrait etre obligatoire sans condition. Gravite : Majeur

CONSTAT-15¶

Type : Ambiguite Reference : Spec §7.4 LegalAccessEvent.merkleLeafRef, anchoringBatchRef Description : Le modele de donnees rend merkleLeafRef obligatoire et anchoringBatchRef "obligatoire des que ancre". La nuance "des que ancre" implique un delai entre emission de l'evenement et ancrage. Or, la frequence d'ancrage est listee comme information manquante (§2.3 point 4). Un evenement peut donc etre en etat de non-ancrage indefini. L'invariant INV-81-08 dit "rattachable a l'ancrage periodique", ce qui est different de "rattache a l'ancrage". Impact : La preuve composite (§7.5) reference anchoringEvidenceRef comme obligatoire, mais si l'ancrage n'a pas eu lieu au moment de la generation de la preuve, la preuve est incomplete ou sa generation doit etre bloquee. Aucune regle ne gere ce cas. Gravite : Majeur

CONSTAT-16¶

Type : Non testable Reference : Spec §10.5 "Les transitions d'etat doivent etre deterministes et auditablement reproductibles" Description : L'exigence de reproductibilite auditable des transitions suppose que la meme sequence d'entrees produise le meme resultat. Cependant, les transitions dependent de services externes (TSP, HSM, TSA) dont la disponibilite varie. Le meme mandat soumis deux fois pourrait etre accepte la premiere fois et rejete la seconde si le TSP est entre-temps indisponible. Le determinisme n'est donc garanti qu'a etat des dependances externes identique, ce qui n'est pas specifiable. Impact : Le critere "auditablement reproductible" n'est pas testable en conditions reelles sans controle total des dependances externes. Gravite : Mineur

CONSTAT-17¶

Type : Incohérence Spec<>Tests Reference : Spec §4 INV-81-03 "deux validations distinctes conformes PD-82 (DPO et LegalOfficer)" vs Tests §3 E08 Description : INV-81-03 et ERR-81-08 interdisent que les deux validations soient de meme identite juridique. Le test E08 utilise validator-dual-001 ("meme identite simulee pour test conflit"). Or, la specification PD-82 originale permet que Parent et Autorite soient des entites distinctes mais la verification d'identite porte sur le role, pas sur la personne physique. PD-81 ajoute la contrainte "meme identite juridique" (ERR-81-08) mais ne precise pas si la verification porte sur l'identite physique, le role fonctionnel, ou le certificat technique. Un DPO et un LegalOfficer pourraient etre la meme personne physique avec deux roles. Impact : Le test E08 est ambigu : validator-dual-001 simule "meme identite" mais s'agit-il du meme certificat, du meme userId, ou de la meme personne physique ? Les trois interpretations produisent des implementations differentes. Gravite : Majeur

CONSTAT-18¶

Type : Hypothese dangereuse Reference : Spec §5-N1 etape 4, §7.1 LegalMandate.scopeDocumentIds[] Description : L'extraction de scopeDocumentIds du mandat suppose que le mandat contient une liste de documentId ProbatioVault. Or, un mandat judiciaire est un document juridique externe qui ne connait pas les identifiants internes du systeme. La specification ne definit pas comment les references du mandat (descriptions de documents, numeros de pieces, etc.) sont mappees vers des documentId ProbatioVault. Impact : Le mapping entre les references du mandat et les identifiants internes est une etape critique non specifiee. Si ce mapping est errone, l'acces pourrait porter sur les mauvais documents. Aucun test ne couvre la validation de ce mapping. Gravite : Majeur

CONSTAT-19¶

Type : Risque secu/conformite Reference : Spec §9.1 getLegalAuditProof, Tests §4 S6 Description : getLegalAuditProof a pour pre-condition "Demandeur autorise a auditer" et le test S6 verifie le controle d'acces. Cependant, le modele d'habilitation du "titulaire" n'est pas defini (point NT-81-02 dans les tests). La specification §3 definit "Audit a posteriori utilisateur" comme la "capacite du titulaire du coffre" mais ne definit pas "titulaire du coffre" dans le modele de donnees PD-81. Il n'y a aucune reference croisee vers le modele de propriete des documents. Impact : Sans modele d'habilitation, le controle d'acces a la preuve composite est non implementable. Un attaquant pourrait tenter d'acceder aux preuves d'un autre utilisateur. Le test S6 est marque comme couvrant AC-81-14 mais ne peut verifier l'habilitation sans modele d'identite. Gravite : Majeur

CONSTAT-20¶

Type : Ambiguite Reference : Spec §6 ERR-81-07 vs §5-N2 Description : ERR-81-07 stipule "Tentative d'activation sans etat ACTIVATED PD-82" avec comme reponse "Refus strict, alerte d'incoherence d'etat". Le test E07 ("Activation sans etat ACTIVATED PD-82") teste avec "dossier en PENDING_BOTH (une seule ou zero validation)" puis appelle activateLegalAccess/generateLegalReKey. Cependant, la specification ne precise pas si E07 s'applique aussi aux etats terminaux REJECTED/EXPIRED (qui ne sont pas non plus ACTIVATED). Le test ne couvre que PENDING_BOTH, pas les autres etats non-ACTIVATED. Impact : Le test E07 sous-couvre le cas d'erreur. Un dossier REJECTED ou EXPIRED pourrait ne pas declencher le meme comportement si l'implementation ne verifie que state != PENDING_BOTH. Gravite : Mineur

CONSTAT-21¶

Type : Non testable Reference : Spec §10.4 "Toute rupture de chaine probatoire doit etre detectee et faire echouer l'operation concernee" Description : La "chaine probatoire" est un concept impliquant la continuite entre evenements successifs (hash chain, references croisees). Or, la specification ne definit pas formellement la structure de la chaine probatoire : les evenements (§7.4) ont un merkleLeafRef et un eventPayloadHashSha3 mais pas de reference au hash de l'evenement precedent (chain linking). Sans structure de chaine definie, la "rupture" n'est pas detectable. Impact : L'exigence de detection de rupture presuppose une structure de chaine non specifiee. Aucun test ne verifie la detection de rupture de chaine probatoire. Gravite : Mineur

CONSTAT-22¶

Type : Hypothese dangereuse Reference : Spec §5-N3 etape 3, §4 INV-81-06 Description : INV-81-06 garantit l'acces "strictement en lecture seule" et N3 autorise "les consultations uniquement sur documentId du mandat, en lecture seule". L'hypothese implicite est que le systeme de stockage documentaire (WORM) supporte un mode d'acces en lecture seule isolable du mode ecriture au niveau de la session/ReKey. Or, PD-41 (specification PRE) definit reEncrypt() qui transforme un ciphertext — c'est une operation de lecture. Mais la specification PD-81 ne definit pas comment la "consultation" est techniquement realisee (via reEncrypt ? via une API de lecture dediee ?). L'absence de specification du mecanisme de lecture rend le controle d'interdiction d'ecriture non verifiable. Impact : Si la "consultation" passe par reEncrypt() (PD-41), le service PRE n'a pas de notion de lecture/ecriture. L'interdiction d'ecriture doit etre appliquee a une couche non specifiee. Gravite : Mineur

CONSTAT-23¶

Type : Risque secu/conformite Reference : Spec §4 INV-81-10, §7.3 LegalReKey.storageDomain Description : INV-81-10 exige l'isolation du "mode Legal PRE" par rapport au "PRE standard" avec "stockage, traces, et etats separes". Le modele §7.3 definit storageDomain comme "obligatoire, valeur legale isolee". Le test S4 verifie la separation. Cependant, la specification ne definit pas les contours de l'isolation : separation logique (namespace, prefix) ou physique (base differente, partition) ? Dans l'implementation PD-41 existante, il n'y a pas de notion de storageDomain ni de stockage isole. L'extension PD-41 pour supporter cette isolation n'est pas specifiee au niveau de PD-41. Impact : L'isolation est exigee mais le mecanisme n'est pas specifie dans la dependance PD-41 qui doit la supporter. Un implementeur pourrait utiliser une separation logique faible (flag isLegal) qu'un acces PRE standard pourrait traverser. Gravite : Majeur

CONSTAT-24¶

Type : Mineur Reference : Tests §1.2 matrice de couverture AC vs Tests §1.1 INV Description : Le critere AC-81-05 est couvert par "N3, E07" dans la matrice. Or, AC-81-05 dit "generateLegalReKey() ne reussit que sur dossier ACTIVATED". Le test E07 verifie le rejet sans ACTIVATED, ce qui est correct. Mais N3 teste le succes sans verifier explicitement que le dossier est ACTIVATED au moment de l'appel (le prerequis le suppose mais ne le verifie pas comme assertion). La couverture est correcte en intention mais faible en verification explicite. Impact : Impact negligeable sur la couverture reelle mais pourrait masquer une regression si l'etape de verification d'etat est omise. Gravite : Mineur

Synthese par axe¶

1) Ambiguites (6 constats)¶

• CONSTAT-01 : TTL de double validation non specifie (Bloquant)
• CONSTAT-02 : "Fin de consultation" non definie (Bloquant)
• CONSTAT-03 : "Immediat" non borne (Majeur)
• CONSTAT-07 : Orchestration activateLegalAccess vs generateLegalReKey ambigue (Majeur)
• CONSTAT-08 : Source de bobPublicKey non specifiee (Bloquant)
• CONSTAT-15 : Ancrage "des que ancre" sans frequence (Majeur)

2) Contradictions (2 constats)¶

• CONSTAT-04 : Statut DESTROYED sans transition definie (Majeur)
• CONSTAT-14 : Evenement probatoire vs non-probatoire non delimite (Majeur)

3) Regles non testables (3 constats)¶

• CONSTAT-09 : Conformite normative non verifiable techniquement (Mineur)
• CONSTAT-16 : Reproductibilite auditable en conditions reelles (Mineur)
• CONSTAT-21 : Rupture de chaine probatoire sans structure definie (Mineur)

4) Incoherences Spec<>Tests (4 constats)¶

• CONSTAT-05 : COMPLETED absent du modele, DESTROYED absent des tests (Bloquant)
• CONSTAT-06 : Mapping roles PD-82 -> PD-81 non specifie (Majeur)
• CONSTAT-11 : 10 scenarios R/L vides references dans la matrice (Bloquant)
• CONSTAT-20 : E07 sous-couvre les etats terminaux non-ACTIVATED (Mineur)

5) Hypotheses dangereuses (4 constats)¶

• CONSTAT-10 : TSP suppose hautement disponible, R1 vide (Majeur)
• CONSTAT-12 : Rate limiting sans parametres (Majeur)
• CONSTAT-18 : Mapping documentId mandat -> systeme non specifie (Majeur)
• CONSTAT-22 : Mecanisme de consultation lecture seule non specifie (Mineur)

6) Risques securite / conformite (3 constats)¶

• CONSTAT-13 : Persistance residuelle des ReKey sans destruction definie (Majeur)
• CONSTAT-19 : Modele d'habilitation titulaire non defini (Majeur)
• CONSTAT-23 : Isolation PRE legal/standard non specifiee dans PD-41 (Majeur)

Points positifs observes (hors perimetre de correction)¶

La specification est remarquablement structuree avec une separation claire des invariants, flux, erreurs, modele de donnees et interfaces. La section §2.3 identifie honnement 8 informations manquantes. La couverture d'erreurs (18 cas) est exhaustive dans son enumeration. L'approche fail-closed est systematique et coherente.

Verdict d'auditabilite¶

La specification PD-81 presente 5 constats bloquants qui empechent une implementation contractuellement conforme et une recette deterministe :

1. TTL de double validation non specifie (CONSTAT-01)
2. "Fin de consultation" non definie (CONSTAT-02)
3. Cycle de vie COMPLETED/DESTROYED incoherent entre spec et tests (CONSTAT-05)
4. Source de la cle publique destinataire non specifiee (CONSTAT-08)
5. Scenarios de test R/L vides faussant la matrice de couverture (CONSTAT-11)

Ces 5 points doivent etre resolus avant passage a l'etape suivante du workflow.