Questioni aperte

Label 309 v1 è congelato. Il formato wire sotto la label dei metadati 309, la codifica canonica in CBOR, i registri degli algoritmi, la busta sigillata del sealed-PoE e il costrutto della firma sono ormai stabiliti: un verificatore v1 conforme legge ogni record v1, e un produttore v1 conforme emette record che ogni verificatore v1 accetta. Questa pagina non parla di cambiare tutto ciò. È il registro di ciò che oggi è confermato nello standard e di ciò che resta in prospettiva, cioè i costrutti crittografici candidati riservati a una possibile revisione futura, insieme alla procedura rigorosa per modificare una costante crittografica quando uno di essi dovesse diventare realtà.

Nulla di quanto riportato qui è una roadmap di prodotto. Ogni voce è una decisione tecnica a livello di protocollo: un identificatore di algoritmo, una derivazione, una politica del verificatore o una regola di versionamento. A chi implementa lo standard serve la metà stabilita per costruire oggi un'implementazione v1, e la metà in prospettiva per costruirla in modo che un eventuale successore post-quantistico o basato esclusivamente su RFC sia una voce di registro additiva, mai una riscrittura.

Costrutti stabiliti

Questi sono decisi. Sono enunciati in modo esplicito qui perché costituiscono le scelte portanti che chi implementa vuole più spesso trovare confermate in un unico punto; le pagine collegate riportano il costrutto completo.

Il KEM post-quantistico è incluso in v1

Il KEM ibrido X-Wing (ML-KEM-768 composto con X25519) è registrato con l'identificatore mlkem768x25519 nel registro enc.kem fin dalla prima versione. Non è un candidato per il futuro: è presente in enc.scheme: 1 accanto al KEM classico x25519, e il campo on-wire enc.kem seleziona, per ciascun record, il KEM per slot, la forma dello slot e la derivazione della chiave di cifratura della chiave (key-encryption-key).

X-Wing è consumato come scatola nera: il costrutto usa solo la sua interfaccia pubblica, cioè incapsula, decapsula e il segreto condiviso da 32 byte, e non fa alcuna assunzione sull'hashing interno del combiner. Entrambi i KEM derivano la KEK per slot sotto un'unica forma di salt a hash etichettato, SHA-256(label || enc.nonce || <materiale KEM dello slot> || pub_R), calcolata sui byte wire dello slot stesso: sul percorso ibrido, SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R). Comprimere con un hash a 32 byte fissi lega il nonce della busta, il testo cifrato e la chiave pubblica del destinatario nella KEK, dissolvendo al contempo l'ambiguità di parsing che un testo cifrato post-quantistico a lunghezza variabile creerebbe con un salt a concatenazione nuda. Viene esposta solo la variante ibrida: ML-KEM puro è volutamente escluso, così che la componente X25519 preservi la sicurezza classica nel caso in cui ML-KEM-768 venisse mai compromesso. Vedi Sealed PoE e Registri degli algoritmi.

L'impegno della chiave sigillata lega l'intestazione e la rivendicazione dell'hash

Entrambi i percorsi sigillati impegnano la chiave di cifratura del contenuto a una trascrizione chiusa, serializzata con la stessa funzione di CBOR canonico che usa il resto della busta, che fissa i campi dell'intestazione e la rivendicazione dell'hash del testo in chiaro dell'elemento (hashes_hash). Sul percorso con slot indirizzati al destinatario (enc.slots) l'impegno è on-chain: slots_mac è un HMAC con chiave derivata dalla CEK su una trascrizione che porta lo scheme, il path, gli identificatori di AEAD e KEM, il nonce, l'insieme di slot mescolato e hashes_hash, così che un relay non possa innestare un testo cifrato su un insieme di slot diverso o su una rivendicazione dell'hash diversa senza far fallire il controllo del MAC on-chain, prima ancora di recuperare il testo cifrato. Il percorso con passphrase (enc.passphrase) porta un impegno equivalente in un'intestazione di 32 byte all'interno del blob di testo cifrato, su una trascrizione che aggiunge il salt e i parametri Argon2id, così che manomettere gli input del KDF faccia fallire il controllo dell'impegno. Il contenuto vero e proprio viene poi sigillato in uno STREAM segmentato sotto una chiave del contenuto derivata dalla CEK; l'AAD per chunk è vuoto, perché ogni campo dell'intestazione è già legato a quella chiave in modo transitivo. Costrutto completo in Sealed PoE.

La profondità di conferma è una politica del verificatore

Un record viene ancorato nel momento stesso in cui la sua transazione è inclusa, ma un verificatore che deve decidere quanto regolamento richiedere prima di emettere un verdetto applica una soglia di profondità di conferma. Label 309 ne fa una politica del verificatore, non un MUST normativo. Lo standard definisce la superficie leggibile dalla macchina: una transazione al di sotto della soglia è riportata come pending (il codice tipizzato INSUFFICIENT_CONFIRMATIONS), mai come failed, e può risolversi in valid a un nuovo tentativo, mentre la soglia stessa (RACCOMANDATA ≥ 15 blocchi) è un parametro configurato in fase di deployment, non una costante incisa nel formato wire. Un verificatore che richiede un regolamento più profondo per attestazioni di valore elevato è pienamente conforme. Vedi Verifica.

La verifica Ed25519 è rigorosa

Le firme a livello di record DEVONO essere verificate secondo le regole rigorose di RFC 8032 §5.1.7, non secondo la tolleranza più permissiva della verifica batch di ZIP-215. La verifica rigorosa rifiuta le codifiche non canoniche e i punti di ordine piccolo che un verificatore permissivo accetterebbe, così che due verificatori conformi raggiungano sempre lo stesso verdetto sulla stessa firma. Chi implementa deve accertarsi che il proprio backend Ed25519 sia in modalità rigorosa; alcune librerie usano per impostazione predefinita la variante permissiva. Vedi Firme.

Il CBOR canonico è il contratto di determinismo

Ogni record è codificato come CBOR canonico secondo RFC 8949 §4.2.1: forme intere preferite, array e mappe a lunghezza definita, chiavi delle mappe ordinate byte per byte, nessuna chiave duplicata, nessun tag. È il determinismo a far sì che una firma calcolata sul corpo da un'implementazione si verifichi sotto un'altra, e che due produttori dello stesso record logico emettano byte identici. Questo requisito è inderogabile per ogni implementazione conforme ed è il fondamento del contratto di parità tra i linguaggi.

Candidati in prospettiva

Le voci qui sotto sono candidati, non costrutti già rilasciati. Nessuna è un difetto di v1; nessuna è impegnata. Sono registrate affinché un'implementazione costruita oggi lasci spazio per esse come voci di registro additive, e affinché un futuro revisore possa vedere quali evoluzioni il design agile rispetto agli algoritmi già prevede.

Un profilo alternativo di AEAD del contenuto riservato

Il livello del contenuto del sealed-PoE in v1 è chacha20-poly1305-stream64k, cioè ChaCha20-Poly1305 di RFC 8439 nel layout STREAM segmentato, a sua volta supportato da un RFC: non c'è quindi alcuna questione aperta sullo stato formale del cifrario del contenuto attuale. Ciò che resta riservato è una strada verso un AEAD del contenuto diverso, qualora un contesto di deployment dovesse mai richiederlo. L'identificatore aes-256-gcm (NIST SP 800-38D) è riservato nel registro degli AEAD a questo scopo e non fa parte di enc.scheme: 1: un record che lo nomina segue oggi la regola della busta sconosciuta.

Introdurlo sarebbe un futuro costrutto enc.scheme: 2 che conserva i modelli esistenti slots[] + slots_mac e dell'impegno con passphrase, ma sostituisce il livello del contenuto, fissando per quel cifrario la nuova dimensione del chunk, la derivazione della chiave del contenuto, la costruzione del nonce per chunk, l'AAD per chunk e l'autenticazione del chunk finale per quel cifrario. È un profilo di fallback, non una sostituzione: i record enc.scheme: 1 esistenti restano validi, e il profilo non deve essere implementato prima che esistano una definizione normativa di enc.scheme: 2 e i relativi vettori di test.

Algoritmi di firma post-quantistici riservati

La metà KEM della traiettoria post-quantistica è inclusa in v1 (vedi sopra). La metà relativa alle firme è riservata ma non ancora implementata. Due famiglie sono candidate a inserirsi nel registro delle firme esistente non appena IETF COSE avrà stabilizzato gli identificatori degli algoritmi post-quantistici:

Poiché l'algoritmo di firma è un identificatore con nome nell'header protetto COSE, registrare un successore è puramente additivo: i record Ed25519 esistenti continuano a verificarsi, e un verificatore che non riconosce un nuovo algoritmo di firma segnala un algoritmo non supportato anziché rifiutare l'attestazione sul contenuto. Una firma non riconosciuta non invalida mai la prova di esistenza sottostante. Vedi Firme.

Un possibile percorso di pubblicazione v: 2

Le singole aggiunte, un nuovo KEM, un nuovo AEAD del contenuto, un nuovo algoritmo di firma, sono voci di registro che non modificano lo schema del record di primo livello. L'aggiunta di un KEM in particolare è una voce di registro sotto enc.scheme: 1, non un incremento dello scheme; un incremento di enc.scheme è riservato a una modifica del costrutto che attraversa più KEM (un nuovo slots_mac o AEAD del contenuto che si applica a tutti i KEM in una volta sola).

Se si accumulano abbastanza candidati che modificano lo schema del record, la modifica cumulativa potrebbe giustificare un record di primo livello v: 2 pubblicato accanto a v1. Entrambe le versioni resterebbero schemi di metadati validi sotto la label 309; un verificatore sceglie in base al discriminatore v all'interno del record. I passi del percorso di standardizzazione si ripetono per la nuova revisione. È l'evoluzione di portata più ampia e si attiva solo per accumulo: nulla di quanto riportato qui è pianificato.

Risoluzione opzionale della sostituzione a un salto

Il campo opzionale supersedes di un record punta a un record precedente tramite l'hash della transazione. Risolvere quel puntatore è opzionale per un verificatore. Un verificatore che conferma che supersedes è strutturalmente un hash di 32 byte ma non recupera la transazione precedente è conforme, ma perde l'occasione di portare alla luce la catena di sostituzione. Indicazione: un verificatore PUÒ risolvere un salto, cioè interrogare di nuovo il resolver delle transazioni per l'hash riferito e riportarne l'esistenza e il block time (l'orario del blocco), senza spingersi oltre con la ricorsione. Un salto è sufficiente; l'attraversamento più profondo è responsabilità del chiamante, e la sostituzione non revoca mai il record precedente, che la blockchain mantiene verificabile in autonomia per sempre.

Migrare una costante crittografica

Ogni costrutto stabilito qui sopra dipende da costanti con nome: identificatori di algoritmi, stringhe info HKDF, salt dei KDF, lunghezze del nonce AEAD, label di separazione di dominio. Cambiare il significato di una qualsiasi di esse è una rottura del formato wire, e lo standard prescrive un unico percorso rigoroso per farlo. La regola che governa il tutto: usare la modifica di portata più piccola che risolve il problema, e non cambiare mai in silenzio il significato di una costante esistente sotto lo stesso namespace.

La procedura è additiva e retrocompatibile (i record precedenti continuano a verificarsi sotto le costanti con cui sono stati pubblicati) e procede per portata:

1. Versionare il namespace, non il valore. Una derivazione modificata incrementa il suffisso -vN su ogni stringa di separazione di dominio che tocca: stringhe info HKDF (…-v1 → …-v2), prefissi dei messaggi HMAC, salt e label. Una nuova costante vive sotto il nuovo suffisso; la costante precedente resta valida sotto il vecchio suffisso. I verificatori più vecchi rifiutano in modo netto i record più recenti già al discriminatore, anziché interpretarli in modo errato.

2. Incrementare il discriminatore che corrisponde al raggio d'impatto. Una modifica confinata a una sola famiglia di slot è selezionata da enc.kem; una modifica che attraversa più KEM al livello del contenuto o all'impegno sull'insieme degli slot è un incremento di enc.scheme; una modifica allo schema del record stesso è un incremento v di primo livello. Ogni discriminatore circoscrive la rottura al livello più piccolo che è effettivamente cambiato.

3. Mantenere verificabili i predecessori. Le versioni più vecchie dei record restano leggibili come schemi congelati. Un verificatore seleziona il costrutto in base ai discriminatori di versione del record stesso, così che una singola implementazione possa verificare v1 e un futuro successore fianco a fianco. Nessun record smette mai di verificarsi perché è arrivato un successore.

Pagine correlate

• Registri degli algoritmi: gli identificatori con nome i cui namespace vengono versionati durante una migrazione.
• Sealed PoE: il KEM ibrido X-Wing, il binding della trascrizione di impegno della chiave e i discriminatori enc.scheme / enc.kem.
• Firme: la verifica rigorosa di Ed25519 e il registro delle firme a cui si unirebbero gli algoritmi post-quantistici riservati.