# Delta `0.2.5-pre.001-fix.001` — correction des capacités VIEW/OWNER et du modèle d'authentification ## Base requise Ce fix s'applique après : ```text 0.2.5-pre.001 workspace.package.version = "0.2.5-pre.1" ``` Le delta historique `deltas/0.2.5/pre.001.md` reste inchangé. ## Type de livraison ```text ksp-general-0.2.5-pre.001-fix.001.zip ``` La livraison reste purement documentaire du point de vue Cargo, mais elle modifie `ROADMAP.md` à la racine ; conformément à `VER-ARCHIVE-001`, le paquet est donc de type `general` et non `doc`. ## Motif du fix Deux corrections sont nécessaires avant `pre.002`. ### 1. Identifiant de livraison La correction postérieure à `pre.001` ne doit pas réémettre silencieusement `ksp-general-0.2.5-pre.001.zip`. Conformément à `VER-ID-003`, `VER-DELTA-003` et `VER-DELTA-007`, elle devient une livraison distincte : ```text 0.2.5-pre.001-fix.001 ``` ### 2. Matrice exacte des capacités Le plan précédent formulait trop largement VIEW comme incapable de toute mutation persistante. Le contrat fonctionnel attendu est plus précis : ```text VIEW lire Pubkey / alias / notes changer uniquement son propre password VIEW VIEW -X-> signer VIEW -X-> exporter le secret VIEW -X-> modifier Pubkey / alias / notes VIEW -X-> changer le password OWNER VIEW -X-> activer/désactiver/recréer VIEW VIEW -X-> modifier le slot OWNER ou l'état OWNER-controlled OWNER tout ce que VIEW peut lire signer exporter via adapter explicitement OWNER-only modifier alias / notes changer son propre password OWNER changer le password VIEW sans connaître l'ancien password VIEW désactiver/recréer VIEW effectuer une révocation VIEW forte par rekey metadata ``` La keypair Solana reste immuable dans un `.kspwallet` V1 après création/import. ## Correction du modèle cryptographique VIEW La correction de capability impose une correction réelle du modèle d'authentification : si VIEW doit pouvoir changer son propre password sans OWNER, les champs de protection de son slot ne peuvent pas tous être couverts par une signature qui exige la clé privée d'administration OWNER à chaque réécriture. Le plan sépare donc désormais : ### État OWNER-controlled Authentifié par `state_signature` Ed25519 OWNER : ```text magic / format_version / autorité de format slot OWNER et sa protection owner-control metadata chiffrées secret chiffré descripteur stable VIEW activation/désactivation VIEW identité/rôle du slot VIEW versions/algorithmes OWNER-controlled ``` Sans OWNER, cet état ne peut pas être modifié sous l'autorité courante du wallet. ### Champs self-service du slot VIEW Le slot VIEW possède un descripteur stable OWNER-signed. Seuls ses champs de protection courants sont rotatables par VIEW : ```text paramètres Argon2id VIEW autorisés par V1 salt VIEW nonce/ciphertext du wrapping AEAD VIEW ``` Ils rewrappent **la même `K_metadata`** et sont liés par AAD au wallet, au rôle VIEW et au descripteur de slot OWNER-signed. Un VIEW authentifié peut donc : ```text ancien password VIEW -> déverrouiller K_metadata -> choisir nouveau password VIEW -> nouveaux KDF/salt/KEK -> rewrap de la même K_metadata -> même descripteur VIEW ``` Il ne peut pas transformer cette opération en écriture de metadata, changement de OWNER, désactivation de VIEW ou remplacement de keypair. ## Rotation et révocation La distinction est désormais explicite. ### Rotation VIEW par VIEW - ne requiert pas OWNER ; - ne modifie que le credential du slot VIEW courant ; - conserve `K_metadata`, Pubkey, alias, notes et keypair ; - l'ancien password ne déverrouille plus le **slot courant** ; - ce n'est pas une révocation forte d'un ancien détenteur ayant conservé une ancienne copie ou déjà extrait `K_metadata`. ### Rotation VIEW par OWNER - ne requiert pas l'ancien password VIEW ; - OWNER récupère `K_metadata` via owner-control ; - crée un nouveau wrapping du slot VIEW avec le nouveau password ; - conserve l'identité/keypair et les metadata. ### Révocation VIEW forte par OWNER - génère une nouvelle `K_metadata` ; - rechiffre les metadata ; - met à jour owner-control ; - recrée/supprime le slot VIEW selon l'opération ; - retire à une ancienne `K_metadata` l'accès aux futurs états metadata, sous réserve de la limite déjà documentée des anciennes copies/rollbacks. ### Rotation OWNER - OWNER peut changer son propre password ; - rewrap `K_owner_root` avec de nouveaux KDF/salt/KEK ; - renouvelle l'authentification OWNER correspondante ; - ne change jamais la keypair Solana. ## Invariants de sécurité conservés La correction ne réduit aucune des garanties centrales de `0.2.5` : ```text .kspwallet V1 reste entièrement autonome aucun facteur externe requis Pubkey/alias/notes cachés wallet verrouillé VIEW ne matérialise jamais le secret Solana VIEW ne signe jamais VIEW n'exporte jamais le secret VIEW ne modifie jamais Pubkey/alias/notes VIEW ne change jamais OWNER OWNER reste indépendant de VIEW OWNER peut gérer VIEW sans ancien password VIEW import => nouveau .kspwallet no-clobber keypair V1 immuable après création/import spec multi-langages + vecteurs publics restent obligatoires ``` Les permissions/ACL OS restent hors du threat model Wallet. ## Version Cargo Ce fix est documentaire et ne modifie aucun fichier consommé par le build/runtime. Conformément à `VER-ID-008` : ```text workspace.package.version = "0.2.5-pre.1" ``` `Cargo.toml` reste inchangé. ## Fichiers modifiés ```text ROADMAP.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md ``` Versions documentaires : ```text ROADMAP.md 45 -> 46 002-FUNCTIONAL_RELEASE_SEQUENCE.md 45 -> 46 012-V0_2_5_WALLET_FOUNDATION_PLAN.md 3 -> 4 ``` ## Fichier ajouté ```text deltas/0.2.5/pre.001-fix.001.md ``` ## Fichiers volontairement inchangés ```text Cargo.toml CHANGELOG.md deltas/0.2.5/pre.001.md docs/000-README.md docs/plans/000-README.md crates/** ``` ## Validations exécutées - relecture de `VERSION_WORKFLOW.md`, notamment `VER-ID-003`, `VER-ID-008`, `VER-DELTA-003`, `VER-DELTA-007` et `VER-ARCHIVE-001..004` ; - vérification que le delta historique `pre.001.md` n'est pas modifié ; - vérification que `Cargo.toml` reste identique à `pre.001` ; - vérification de la matrice VIEW/OWNER dans le plan, la séquence fonctionnelle et le roadmap ; - vérification que le transcript OWNER exclut seulement les paramètres Argon2id VIEW autorisés, le salt et le nonce/ciphertext de wrapping du slot VIEW et conserve un descripteur VIEW OWNER-signed ; - vérification que VIEW ne reçoit aucune API de mutation metadata, signature, export secret ou administration OWNER ; - vérification que OWNER peut changer les passwords OWNER et VIEW ; - vérification que l'import reste une création no-clobber d'un nouveau `.kspwallet` ; - vérification que les ACL/permissions OS restent hors des garanties Wallet. ## Validations Cargo Aucune source Rust, dépendance, configuration runtime ou version Cargo n'est modifiée par ce fix. Les validations Cargo ne sont donc pas revendiquées comme nouvelles validations de cette livraison. ## Commit attendu ```text v0.2.5-pre.001-fix.001 ``` ## Suite Après application/validation de ce fix, `0.2.5-pre.002` peut créer la foundation de `ksp-wallet-lib` en matérialisant dès l'API les capacités corrigées : VIEW lecture metadata + rotation de son seul password, OWNER administration complète + rotations OWNER/VIEW, sans codec/chiffrement lourd avant les tranches prévues.