💡 Esempio completo funzionante disponibile su GitHub:
firma-parola-con-certificati-ml-dsa-dotnet
Il Vecchio Metodo Era un Piano di Progetto
Chiedi cosa serve per rendere la firma dei documenti post-quantum e otterrai una roadmap: valutare gli algoritmi, scegliere una libreria, scrivere uno strato di astrazione sul codice di firma, pianificare un periodo di doppia firma, destinare un trimestre al budget.
La maggior parte di ciò è ancora valida per la parte organizzativa – approvvigionamento dei certificati, policy, supporto dei validatori. La parte di codice si è rivelata più piccola di quanto suggerisca la roadmap, e vale la pena saperlo prima che qualcuno assegni un trimestre al budget.
La firma ML-DSA è una funzionalità di GroupDocs.Signature per .NET che firma documenti Word con certificati basati su FIPS 204, lo standard NIST per firme post-quantum. È arrivata nella versione 26.9 e, dal punto di vista del codice chiamante, è un file PFX diverso.
C’è un Modo Migliore
Ecco l’intero cambiamento di codice:
using var signature = new Signature(sourcePath);
var options = new DigitalSignOptions(pfxPath)
{
Password = certificatePassword
};
SignResult result = signature.Sign(outputPath, options);
Questa è la stessa chiamata usata per un certificato RSA. L’algoritmo è una proprietà del certificato, quindi nessuna opzione lo seleziona, non è necessario alcuno strato di astrazione e non appare un secondo percorso di codice per il periodo di transizione. Puntare DigitalSignOptions a un PFX ML-DSA e l’output sarà una firma ML-DSA.
Leggere il certificato dal risultato è utile quando sono in gioco più certificati:
var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";
Scegliere un Livello, Con Numeri Invece di Opinioni
ML-DSA è disponibile in tre set di parametri, corrispondenti alle categorie di sicurezza NIST 2, 3 e 5. Più forte significa più grande – sia la chiave che la firma – e il modo sensato per decidere è firmare il proprio documento tre volte e osservare:
var levels = new Dictionary<string, string>
{
["ML-DSA-44"] = MlDsa44Pfx,
["ML-DSA-65"] = MlDsa65Pfx,
["ML-DSA-87"] = MlDsa87Pfx
};
Il campione scrive una copia firmata per livello e registra ogni dimensione, quindi il compromesso è una misurazione piuttosto che una tabella da una specifica. Per un singolo contratto la differenza è trascurabile; per un archivio di diversi milioni di documenti firmati è una questione di capacità che vale la pena considerare prima di standardizzare sul livello più alto.
ML-DSA-65 è il valore predefinito ragionevole quando nessuna policy ne prescrive uno. Profili come CNSA 2.0 indicano esplicitamente ML-DSA-87, e ML-DSA-44 ha senso solo quando la dimensione è più importante del margine.
La Verifica Richiede Solo il Certificato Pubblico
La storia della distribuzione è invariata rispetto a RSA, il che è la seconda buona notizia:
var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
options.Password = password;
}
VerificationResult result = signature.Verify(options);
Il destinatario ha bisogno del .cer del firmatario e nient’altro. Il risultato è valido solo quando la firma corrisponde al contenuto e il certificato corrisponde per numero di serie e impronta digitale, quindi un documento firmato da una parte diversa fallisce il controllo – cosa che il campione dimostra eseguendo la verifica due volte, una volta con il certificato corretto e una volta con quello di qualcun altro.
Fianco a Fianco: Previsto vs. Reale
| Ciò che un piano di migrazione presume | Ciò che 26.9 richiede realmente | |
|---|---|---|
| Modifica del codice | strato di astrazione sulla firma | un percorso PFX diverso |
| Superficie API | nuovi metodi post-quantum | DigitalSignOptions, invariato |
| Selezione del livello | configurazione della libreria | quale certificato carichi |
| Verifica | nuovi strumenti per i destinatari | il .cer pubblico del firmatario |
| Lavoro sulla piattaforma | gestione delle chiavi per OS | nessuno – la libreria ricade internamente |
| Copertura dei formati | tutti i formati | solo formati Word, per ora |
Cosa Non Funziona Ancora
Due limiti, entrambi utili da conoscere prima di promettere qualsiasi cosa.
La copertura dei formati è solo Word in 26.9 – DOCX, DOC, ODT e il resto della famiglia Word. PDF, fogli di calcolo e presentazioni non possono essere firmati con ML-DSA. Per una pipeline incentrata su PDF, questa versione è per prototipazione e misurazione piuttosto che per migrazione.
Il supporto dei validatori è l’altro. Non esiste ancora un identificatore XML‑DSig standard per ML-DSA, quindi Microsoft Word potrebbe non segnalare la firma come valida anche se è crittograficamente corretta e verifica correttamente tramite l’API. Si tratta di una lacuna di standard più che di un difetto, e significa che la verifica deve avvenire nel tuo codice piuttosto che in un revisore che apre il file e guarda il banner.
C’è anche un dettaglio della piattaforma che non richiede azioni: .NET non può leggere le chiavi ML-DSA ovunque, incluso Linux su .NET 8. Dove non può, GroupDocs.Signature legge il certificato tramite il motore Word, così la stessa build funziona su un laptop di sviluppo e su un container Linux senza codice condizionale.
Vale la Pena Farlo Ora, Dati Questi Limiti?
Sì, per due ragioni che non hanno nulla a che fare con il codice. L’approvvigionamento dei certificati è lento – le CA pubbliche stanno ancora rilasciando certificati ML-DSA – quindi il lavoro dal lato organizzativo beneficia di un avvio precoce. E “possiamo produrre una firma post‑quantum oggi” è una domanda che i team di conformità stanno iniziando a porre; poter rispondere con un documento firmato anziché con un piano vale il pomeriggio necessario.
Cosa Dimostra Realmente il Campione
Quattro metodi, eseguiti in ordine, con il codice di uscita legato al risultato. Firma il contratto con ML-DSA-65 e stampa il soggetto del certificato utilizzato. Firma lo stesso contratto a tutti e tre i livelli e stampa le dimensioni risultanti. Verifica il file firmato due volte – una volta con il certificato pubblico del firmatario, aspettandosi il successo, e una volta con il certificato di un altro firmatario, aspettandosi il fallimento. Poi elenca le firme digitali trovate nell’output.
La seconda verifica è quella che vale la pena copiare. Una routine che è stata mostrata solo con input validi non ti dice nulla sul fatto che rifiuterebbe un input non valido, e per le firme questa è l’intera questione.
Esempio Reale: Il Contratto di Trenta Anni
Gli archivi a lungo termine sono dove questo smette di essere teorico. Un contratto firmato oggi e conservato per trent’anni deve rimanere verificabile indipendentemente da ciò che accade alla crittografia in quel periodo, e “raccogliere ora, decifrare più tardi” è un modello di minaccia documentato per esattamente questo tipo di materiale.
Per un archivio del genere, la mossa pratica oggi è a doppio binario: mantenere RSA per i formati che ML-DSA non copre ancora, iniziare a firmare l’output Word con ML-DSA-65 o 87, e registrare quale algoritmo è stato usato per documento così un audit futuro può distinguerli senza aprire i file.
Una Cosa da Correggere nel Campione Prima di Copiarlo
Il repository fornisce certificati ML-DSA autofirmati così la dimostrazione funziona subito, il che significa quattro file PFX e una password codificata in modo statico presenti in documents/. Per un certificato di test usa e getta valido solo all’interno di quel campione, va bene.
Non è un modello da portare nel proprio repository. Genera certificati di test al runtime, come fa il campione di validità del certificato di GroupDocs, oppure tienili completamente fuori dal controllo di versione. Una chiave committata è difficile da revocare e tende a sopravvivere alla demo per cui è stata scritta.
Conclusione
Le parti costose della migrazione post‑quantum sono i certificati, le policy e i validatori. Il codice, almeno per i documenti Word in .NET, è un PFX diverso e la stessa chiamata DigitalSignOptions. Clona il campione, puntalo a uno dei tuoi contratti, e avrai tre file firmati, due risultati di verifica e un confronto delle dimensioni in pochi minuti – il che è una base migliore per un piano di migrazione rispetto a una stima.