ADR-078 — Descellement additif couche-1-v1.7 : additifs crypto pour air-tls (AES-128-GCM, ECDSA/ECDH P-256/P-384, RSA-PSS vérif., ML-KEM-768 hybride)

Note de renumérotation (2026-07-09). couche-1-v1.7 a été attribuée aux Managers de domaine (ADR-077) et couche-1-v1.8 à l’additif air-process::spawn_process (socle posix_spawn, chantier B) — décisions BDFL, tous deux mergés & scellés. Ce descellement crypto deviendra couche-1-v1.9 au moment de sa ratification (le titre ci-dessous et les mentions v1.6 → v1.7 restent tels quels jusque-là, pour ne pas préempter la ratification).

Statut : Proposé — ratification BDFL requise. Ce descellement touche la surface cryptographique ; il sort donc de la délégation automatique « additif-seulement » du superviseur (ADR-065 §Gouvernance : « seuls sont remontés au BDFL … les compromis de sécurité ») et exige une ratification explicite + KAT-gate avant tag. RFC de structure (ADR-015). Applique le modèle de re-sceau additif de la couche 1 (ADR-062) et la discipline crypto (ADR-034). Consommateur cible : la contingence air-tls maison (ADR-042 §Contingence ; spec docs/specs/layer-2/air-tls.md).

Catégorie : Descellement additif de la couche 1 scellée (couche-1-v1.6 → couche-1-v1.7) + extension des dépendances crypto (exceptions structurantes à la règle des 80 %, ADR-024/ADR-034). Aucune rupture d’ABI ni de signature publique existante ; jalons antérieurs conservés.

Contexte

La spec air-tls maison (TLS 1.3 pur Rust, gardée ouverte par ADR-042 §Contingence) et l’audit s2n-tls établissent qu’une pile TLS interopérable avec le WebPKI réel exige des primitives absentes du cœur v1 d’air-crypto (qui n’expose qu’Ed25519 / X25519 / AES-256-GCM / ChaCha20-Poly1305 / SHA-2/3 / HKDF / HMAC / Argon2). Concrètement, il manque :

• AES-128-GCM — la suite TLS 1.3 mandatory-to-implement TLS_AES_128_GCM_SHA256 (RFC 8446 §9.1) ;
• ECDSA P-256/P-384 (signature + ECDH) — la grande majorité des chaînes serveur WebPKI et les groupes secp256r1/secp384r1 ;
• RSA-PSS (vérification) — rsa_pss_rsae_sha256/384/512 (RFC 8446 §4.2.3), sans quoi la majorité des certificats WebPKI actuels ne valide pas ;
• ML-KEM-768 — l’échange hybride post-quantique X25519MLKEM768 (consensus de déploiement 2024-2025).

air-crypto étant scellée (couche-1), tout ajout passe par un descellement additif (modèle ADR-062, précédents ADR-065/066/067). Comme il s’agit de crypto, ADR-034 s’applique (exemption de vendoring, KAT-gating, fast-lane sécurité) et la décision remonte au BDFL (surface sécurité).

Décision

Descellement additif couche-1-v1.7 : on ajoute à air-crypto (crate scellée) la surface et les dépendances suivantes — purement additives (aucune signature existante modifiée). Détail d’API dans la spec air-crypto §« Additifs planifiés ».

Chaque primitive entre KAT-gated (vecteurs officiels verts avant merge, ADR-034) et quand un consommateur atterrit — la contingence air-tls maison en tête. L’ADR autorise la surface ; l’implémentation suit le besoin (comme ADR-042 diffère l’application de son exception à l’implémentation).

Sécurité (décisions gravées — c’est le cœur de la remontée BDFL)

1. RSA : vérification seule, jamais d’opération privée. Air n’expose aucune génération / signature / déchiffrement RSA — uniquement la vérification de signatures de certificats (opération publique). L’advisory RUSTSEC-2023-0071 « Marvin » (canal temporel sur l’opération privée RSA) ne s’applique donc pas. PKCS#1 v1.5 chiffrement (Bleichenbacher) : omis ; seul RSA-PSS vérif..
2. ECDSA à nonce déterministe (RFC 6979). Élimine par construction la classe « nonce faible/réutilisé » (désastres PS3/Bitcoin). Jamais de nonce ECDSA tiré d’un PRNG.
3. ML-KEM en hybride uniquement. X25519MLKEM768 combine les deux secrets (→ HKDF) ⇒ sécurité ≥ max(X25519, ML-KEM) : si ML-KEM (récent) tombait, X25519 protège ; réciproquement contre un ordinateur quantique. ML-KEM seul refusé tant qu’il n’a pas l’ancienneté d’X25519.
4. Zéro-C maintenu. Les 5 crates sont pur Rust → check-c-surface reste vert. À re-vérifier au bump la réserve aarch64/cpufeatures déjà documentée pour aes-gcm (docs/EXCEPTIONS.md ; p256/p384 en arithmétique pure Rust n’aggravent pas cette réserve).
5. no_std-strict conservé : default-features = false, features aléa exclues (l’aléa vient toujours d’AirRandom → getrandom(2) couche 0).

Gouvernance

• Hors délégation additive automatique (ADR-065 §Gouvernance) : surface crypto = compromis de sécurité potentiel → ratification BDFL explicite requise avant tag, contrairement aux descellements additifs neutres (ADR-070/071).
• Exceptions 80 % nommées : p256/p384/rsa/ml-kem ajoutées à l’entrée air-crypto de docs/EXCEPTIONS.md et au DEPENDENCIES.md de la crate (déjà instruites, non actives avant ratification).
• Licences : MIT OR Apache-2.0 (RustCrypto) — liste blanche deny.toml. À confirmer par cargo deny au moment de l’ajout.

Conséquences

• Tag couche-1-v1.7 posé après ratification BDFL + implémentation KAT-gated + barrière 2 arches (x86_64 + aarch64). Note de re-sceau dans INDEX.md + etat-avancement.md.
• Débloque la contingence air-tls maison sur l’interop WebPKI réelle (les 3 suites AEAD × X25519/NIST/hybride × Ed25519/ECDSA/RSA-vérif.). N’impacte pas la pile de production (rustls + aws-lc-rs, ADR-042), qui embarque sa propre crypto.
• Précédent : les additifs crypto révélés par les protocoles réseau (air-quic, air-ssh) suivront le même régime (descellement additif + ADR-034 + remontée BDFL).

Alternatives rejetées

• Exposer RSA privé / signature RSA. Rejeté : rouvre la surface Marvin, inutile (Air ne signe/déchiffre jamais en RSA ; Ed25519/ECDSA suffisent côté Air).
• ML-KEM seul (non hybride). Rejeté : primitive trop récente pour être portée seule ; l’hybride est le seul régime accepté.
• Réécrire ces primitives en propre. Rejeté : dogme « zéro crypto maison » (ADR-034) — on enrobe des crates auditées.
• Rester au cœur v1 (rien ajouter). Rejeté : sans ECDSA/RSA-vérif./AES-128, une pile TLS maison ne valide quasiment aucun certificat WebPKI réel → contingence air-tls non viable.
• Attacher ces additifs à air-tls (couche 2) plutôt qu’à air-crypto. Rejeté : violerait la doctrine (les primitives vivent en couche 1, jamais dispersées ; cf. note réseau §2.4 « le Handshaker consomme air-crypto »).

Suite

• Ratification BDFL de cet ADR, puis implémentation KAT-gated à l’atterrissage du premier consommateur (air-tls maison). Tag couche-1-v1.7 ensuite.
• Câblage : registre ADRs, SUMMARY.md, INDEX.md. Mise à jour EXCEPTIONS.md + crates/air-crypto/DEPENDENCIES.md au moment de l’ajout effectif.
• Étape suivante de conception : spec air-network (substrat L2 où air-tls se branche).