|
(Documento pubblicato sul sito del CNIPA)
INTRODUZIONE
La recente sottoscrizione di un protocollo d'intesa per la disponibilità
del formato di firma digitale definito nelle specifiche PDF (Portable Document
Format) ha suscitato una serie di commenti in alcuni specialisti del settore.
Nel seguito viene descritto lo scenario normativo e tecnico nel quale il
protocollo d'intesa si va a porre e le nuove regole che introduce.
A tale scopo iniziamo dalla descrizione della situazione normativa sia di rango
legislativo che di rango tecnico.
LA SITUAZIONE NORMATIVA
Allo stato attuale la firma digitale pone le proprie basi giuridiche nel
decreto legislativo 7 marzo 2005, n. 82 "Codice dell'amministrazione
digitale".
In particolare, l'articolo 1, comma 1, alle lettere r) e s) definisce
rispettivamente la firma elettronica qualificata e la firma digitale. Per
brevità non riportiamo il testo delle definizioni facilmente reperibile per il
lettore.
Attenendosi alle definizioni e a quanto stabilito dal Codice è indispensabile
stabilire regole tecniche che garantiscano l'interoperabilità nello scambio
dei documenti informatici e in particolare garantiscano regole per il
riconoscimento e la verifica delle firme digitali utilizzate per la
sottoscrizione dei documenti informatici.
Il CNIPA ha sempre prestato particolare attenzione al tema dell'interoperabilità
e sulla materia ha emesso la Deliberazione 4 del 17 febbraio 2005 che è stata
pubblicata in Gazzetta Ufficiale il 3 marzo 2005. Per consentire al mercato di
adeguarsi alle nuove regole tecniche, la Deliberazione è entrata in vigore il 3
dicembre 2005 e subito dopo ADOBE ha richiesto di aderire a quanto stabilito
nell'articolo 12, comma 9 della Deliberazione:
"Il CNIPA può sottoscrivere specifici protocolli d'intesa al fine di
rendere disponibili ulteriori formati di firma. Detti protocolli d'intesa
devono contenere l'impegno del sottoscrittore ad assicurare:
a) la disponibilità delle specifiche necessarie per lo sviluppo di prodotti di
verifica o di generazione e eventuali librerie software necessarie per lo
sviluppo di prodotti di verifica di firme digitali conformi al formato oggetto
del protocollo d'intesa;
b) l'assenza di qualunque onere finanziario a carico di chi sviluppa,
distribuisce o utilizza i prodotti menzionati al comma precedente;
c) la disponibilità di ogni modifica inerente a quanto indicato alla lettera a)
con un anticipo di almeno 90 giorni rispetto alla data del rilascio di nuove
versioni del prodotto che implementa il formato di busta crittografica oggetto
del protocollo d'intesa;
d) la disponibilità, a titolo gratuito per uso personale, di un prodotto per
verificare firme digitali del formato oggetto del protocollo d'intesa e
visualizzare il documento informatico oggetto della sottoscrizione;
e) la capacità di utilizzare le informazioni contenute nell'elenco pubblico
dei certificatori di cui all'articolo 41 delle regole tecniche e nelle liste
di revoca di cui all'articolo 29 del citato provvedimento nel prodotto di
verifica di cui al comma precedente."
L'obiettivo di questo comma è di aprire il mondo della firma digitale a
nuovi formati nell'ambito delle garanzie previste dal comma stesso.
E' importante ricordare che all'interno della stessa Deliberazione 4 si
stabilisce che l'utilizzo da parte delle pubbliche amministrazioni di questi
nuovi formati avviene volontariamente, modificando esplicitamente il
procedimento amministrativo e fornendo inoltre comunicazione al CNIPA. Le
pubbliche amministrazioni devono continuare a garantire il supporto per il
formato crittografico PKCS#7.
Vediamo adesso perché è stato possibile accettare il formato di firma digitale
definito nelle specifiche PDF.
IL PROTOCOLLO D'INTESA CNIPA-ADOBE
Già con la diffusione della versione 6, ADOBE si è confrontato con il CNIPA
per garantire che l'evoluzione del proprio prodotto fosse in linea con l'evoluzione
delle norme tecniche. Il CNIPA quando sono state rese disponibili le prime
versioni beta della release 7 ha iniziato l'analisi tecnica e in particolare
ha verificato che fossero soddisfatti i requisiti stabiliti dalla Deliberazione
4 in termini di apertura dei formati. L'articolo 13, comma 9 è risultato
pienamente soddisfatto. Cioè, evidenziando gli aspetti principali stabiliti dal
comma, chiunque può scrivere un verificatore di firma digitale, gli utenti
utilizzano gratuitamente il verificatore delle firme presente nel "Reader".
Altre questioni di tipo organizzativo, come l'impegno a comunicare le
modifiche delle specifiche con adeguato anticipo sono sancite nell'impegno
rappresentato dal protocollo d'intesa.
Il formato di firma digitale definito nelle specifiche PDF risulta così
affiancato al PKCS#7 (Sviluppato e mantenuto dalla società americana RSA
Security). Attualmente il PKCS#7 è utilizzato nelle modalità definite nella
specifica pubblica IETF RFC 2315. In modo analogo la specifica pubblica IETF RFC
3778 definisce il formato (MIME type) del PDF.
L'analisi di questi formati ci permette di affermare che da un punto di vista
tecnologico la firma digitale definita nelle specifiche PDF è sostanzialmente
equivalente a quella definita nel PKCS#7. In entrambi i casi si tratta di buste
crittografiche IETF RFC 2315 (PKCS#7) con la sola differenza del formato di
trasporto del file. Questo offre dei vantaggi che vedremo tra breve.
E' opportuno, inoltre, precisare che il PDF nulla ha che vedere con Acrobat,
il prodotto commerciale che manipolando il formato aperto PDF è in grado di
gestire flussi di documenti in modo innovativo. In generale risulta quindi
impreciso dire che il generatore del formato di firma deve essere gratuito o
open source. Il software di firma digitale dei certificatori accreditati, che
genera formati PKCS#7, per esempio non è open source e non è gratuito.
Peraltro esiste software open source per la firma digitale che può essere
liberamente adattato alla normativa italiana e che conseguentemente può gestire
file firmati digitalmente utilizzando il formato PDF.
Stesso discorso per le librerie software da utilizzare per le smart card,
necessarie nell'ambito del loro ruolo di "dispositivi sicuri per la
creazione della firma" definito nella normativa vigente.
Il particolare metodo utilizzato dal formato di firma digitale definito nel PDF,
consente una migliore gestione delle macro che è completamente assente nel
formato PKCS#7. Quest'ultimo infatti non prevede alcun controllo su quanto
inserito nella sotto busta denominata PKCS#7 DATA, in quanto tale controllo è
al di fuori di quanto previsto dallo standard.
Ne consegue che i problemi di lettura di formati di file sottoscritti mediante
il PKCS#7 a causa dell'obsolescenza dei pacchetti software è totalmente
indipendente dai meccanismi di firma.
Per esempio se abbiamo sottoscritto, utilizzando una busta PKCS#7, un file
generato con un prodotto di videoscrittura in ambiente MS-DOS di qualche anno
fa, saremo ancora di verificare la firma (la rappresentazione della struttura
dati firmata è binaria) ma per la lettura del file sottoscritto dovremo
disporre dello specifico prodotto che la ha generato. Per quanto appena detto è
indispensabile che i formati dei documenti informatici prodotti siano "aperti"
ovvero pubblicamente documentati.
Per quanto riguarda la specifica gestione delle firme digitali nell'ambito
del formato PDF si rimanda alla documentazione tecnica di riferimento (giunta
alla versione 1.6) e disponibile al link http://partners.adobe.com/asn/tech/pdf/specifications.jsp
.
Per concludere si può senz'altro affermare che il principale vantaggio per l'utente
nell'utilizzo del formato PDF sta nel dover gestire solo un file (con la firma
al proprio interno) piuttosto che due file, uno firmato e uno no, con la
contemporanea esigenza di installare un prodotto per la verifica della firma in
PKCS#7.
LO SCENARIO PROSSIMO FUTURO
Sono in corso da parte del CNIPA una serie di valutazioni di altri formati
che sono candidati ad altri protocolli d'intesa. In particolare una serie di
prodotti che utilizzano i formati della firma digitale in XML. Anche in queste
analisi dovranno ovviamente essere soddisfatti i requisiti dell'articolo 12,
comma 9 della Deliberazione 4/2005 del CNIPA.
Di particolare interesse anche l'iniziativa del CNIPA che in conformità all'articolo
12, comma 8 della Deliberazione 4/2005 e su proposta dell'Associazione dei
certificatori di firma digitale (ASSOCERTIFICATORI) sta redigendo specifiche
regole di interoperabilità sulla firma nel linguaggio XML.
Si ricorda che il sopra citato articolo 12, comma 8 stabilisce che:
"Il CNIPA può stabilire, con apposito provvedimento, ulteriori formati
standard di busta crittografica, riconosciuti a livello nazionale o
internazionale, conformi a specifiche pubbliche (Publicly Availbale
Specification - PAS)."
Questa ulteriore apertura dovrà tenere in conto del fatto che già adesso
prodotti di video scrittura, anche open source, dichiarano di essere conformi
alla specifica pubblica IETF RFC 3275 "XML-Signature Syntax and Processing".
CONCLUSIONI
La firma digitale è uno strumento abilitante all'uso di procedimenti
amministrativi che non utilizzano la carta. Essa deve essere utilizzata con i
corretti formati in base allo specifico contesto di utilizzo. Ne consegue che in
certi scenari applicativi può essere valido il PKCS#7, in altri la firma in XML,
come nella cooperazione applicativa del Sistema Pubblico di Connettività e
Cooperazione (SPC) e in altri ancora il formato previsto nel PDF.
Specifiche applicazioni come la conservazione documentale per lunghi periodi
devono prima definire le modalità di gestione dei formati dei documenti e la
loro scrittura e mantenimento contro l'obsolescenza dei supporti di
memorizzazione.
In questo settore ci sono importanti studi che ipotizzano l'utilizzo dell'XML
(che è un linguaggio e quindi va specializzato nel contesto) e di sottoinsiemi
del PDF, come il PDF/A che è stato standardizzato in ambito internazionale con
il documento ISO 19005-1:2005, Document management - Electronic file format
for long-term preservation - Part 1: Use of PDF 1.4 (PDF/A-1).
|
Pagina stampabile
