Si veda l'art. 29 della Delib. CNIPA 45/2009 ("Norme Transitorie"):

• il comma 3 prescriveva che alcuni articoli dovessero essere applicati 270 giorni dopo l'entrata in vigore della delibera stessa, ossia il 3 Settembre 2010;
• il comma 4 consente l'anticipazione di tale applicazione fino a 90 giorni, ossia al 3 Giugno 2010, sotto certe condizioni improntate alla cautela

Poiché le variazioni sono piuttosto importanti e hanno per oggetto l'algoritmo di hash ed alcune importante novità nei formati dei documenti PKCS#7 (come vediamo in dettaglio più avanti in questa mail), il risultato sostanziale è che:

1. i documenti formati secondo le regole attuali (in particolare la funziona hash SHA-1 e la mancanza di alcuni attributi) NON SARANNO PIU' LEGITTIMI DOPO
2. NON E' CONSENTITO usare i nuovi formati prima del 3 Giugno

La combinazione di queste due prescrizioni impone di fatto la sostituzione di tutto il software di firma digitale tra il 3 Giugno ed il 3 Settembre 2010.

Il tutto è ulteriormente complicato dal fatto che il 17 Giugno è scaduto di nuovo il certificato del Presidente CNIPA, mentre i responsabili di DigitPA stanno pensando di modificare i meccanismi di gestione dell'Elenco Pubblico delle CA accreditate proprio per evitare questo periodico inconveniente.

Ma veniamo ai dettagli delle novità. Leggendo l'art. 29 comma 3:

• Art. 4, commi 1 e 2; art. 5 - passaggio dalla funzione hash SHA-1 alla SHA-256;

Riguardo alla firma Sha256-with-rsa ed il padding conforme a RFC3447, non è certo che tutte le smartcard consentano di computare firme basate su questo algoritmo di hash.

• Art. 17 - associazione della marca temporale al documento - qui ci sono novità importanti, perché si introduce l'idea di associare una M.T. ad una firma e non al documento nella sua interezza; questo consente di avere M.T. multiple nel documento se ci sono firme multiple. Il formato per "unire" M.T. e firma sara con estensione ".tsd". Resta però la possibilità di usare una modalità "detached" simile a quelle fin qui usate (.p7x o .m7m), ma ora basandosi sullo standard RFC5544.

Poiché è possibile convertire un .m7m o un .p7x in un .tsd questo non sembra drammatico, ma dal 3 Settembre in avanti l'uso di un formato .m7m o .p7x sarà "non conforme" e dovrebbe essere evitato

• Art. 21, comma 1- busta crittografica CAdES - si tratta di una evoluzione del PKCS#7, che prevede attributi prima non utilizzati. Allo stato non è ancora chiarissimo quali degli attributi previsti dallo standard verranno effettivamente impiegati, oltre all'attributo signed "id-aa-signingCertificateV2" (la firma viene calcolata anche su un riferimento al certificato che viene usato per la firma stessa). E' possibile che nei primi mesi di utilizzo emergano necessità di aggiustamenti in questo senso, tanto più che ad oggi stanno circolando pochissimi campioni per i test di interoperabilità.