PD-34 — Acceptabilité¶
📚 Navigation User Story
| Document | | | ---------- | -- | | 📋 [Spécification](PD-34-specification.md) | | | 🛠️ [Plan d'implémentation](PD-34-plan.md) | | | ✅ **Critères d'acceptation** | *(ce document)* | | 📝 [Retour d'expérience](PD-34-rex.md) | | [← Retour à crypto](../PD-189-epic.md) · [↑ Index User Story](index.md)Objectif¶
Vérifier que l’implémentation est conforme à la spécification, respecte l’ensemble des invariants ProbatioVault et ne présente aucune incohérence ou oubli critique.
Périmètre de vérification¶
La revue d’acceptabilité vérifie explicitement :
- la conformité stricte à la spécification fonctionnelle
- le respect de tous les invariants applicables
- la couverture des scénarios de test définis
- l’absence d’incohérences, oublis ou régressions
Écarts identifiés¶
Chaque écart constaté doit être documenté et classé selon sa gravité.
Classification des écarts¶
| Niveau | Définition |
|---|---|
| BLOQUANT | Violation d’un invariant, faille de sécurité, non-conformité majeure à la spec |
| MAJEUR | Fonction incomplète, comportement non conforme mais sans rupture de sécurité |
| MINEUR | Détail, dette acceptable, amélioration non critique |
Détail des écarts¶
| ID | Description | Référence | Gravité |
|---|---|---|---|
| E-01 | Domain separation string non conforme : l’info HKDF utilisée est \"ProbatioVault::Kdoc::v1\" (sans underscore) au lieu de \"ProbatioVault::K_doc::v1\" défini par la spec, ce qui produit des K_doc incompatibles avec une implémentation conforme à la spec. | Spec §Paramètres cryptographiques (K_doc) ; src/services/hkdf.ts | MAJEUR |
| E-02 | IKM de K_doc : la dérivation utilise K_share (K_master → HKDF(salt fixe) → K_share → HKDF(docId) → K_doc) alors que la spec demande K_master_user comme IKM direct pour K_doc ; résultat non aligné avec le contrat de la spec même si conforme au plan interne. | Spec §Paramètres cryptographiques (IKM = K_master_user) ; src/services/hkdf.ts (deriveDocumentKey, deriveShareKey) | MAJEUR |
| E-03 | Validation docId insuffisante : deriveDocumentKey accepte toute chaîne (fallback TextEncoder) alors que la spec/plan imposent un UUID converti en 16 bytes ; risque d’incohérences de dérivation et de non-respect des invariants d’ID. | Spec §Paramètres cryptographiques (Salt = UUID 16 bytes), Plan Phase 3 & Points de vigilance ; src/services/hkdf.ts | MINEUR |
| E-04 | Implémentation HKDF-Extract non conforme RFC 5869 : hkdfExtract appelle hkdf() (extract+expand) au lieu de produire la PRK brute, ce qui n’est pas aligné avec la spec de primitives standardisées et peut invalider des contrôles/audits basés sur RFC 5869. | Plan Phase 1 (Primitives HKDF conformes RFC 5869) ; src/services/hkdf.ts (hkdfExtract) | MAJEUR |
Conclusion d’acceptabilité¶
⚠️ ACCEPTÉ AVEC RÉSERVES — écarts MAJEURS/MINEURS documentés (domain separation, IKM attendu, validation docId, conformité HKDF-Extract).