Premessa.
Com'e' noto, con il decreto del Presidente della Repubblica
10 novembre 1997, n. 513 (recante: "Regolamento recante criteri e
modalita' per la formazione, l'archiviazione e la trasmissione di
documenti con strumenti informatici e telematici, a norma dell'art.
15, comma 2, della legge 15 marzo 1997, n. 59") e' stata introdotta,
nel nostro ordinamento, la firma digitale. L'art. 8, comma 3, del
citato decreto del Presidente della Repubblica n. 513/1997 stabilisce
che le attivita' di certificazione sono effettuate da certificatori
inclusi in apposito elenco pubblico, consultabile in via telematica,
predisposto, tenuto e aggiornato dall'Autorita' per l'informatica
nella pubblica amministrazione.
Con la circolare 26 luglio 1999, n. AIPA/CR/22 sono state stabilite
le modalita' con le quali le societa' interessate ad esercitare
l'attivita' di certificatore devono inoltrare, all'Autorita', la
domanda di iscrizione nell'elenco pubblico di cui al citato art. 8.
In base a tale norma, i certificatori devono essere dotati di
appositi requisiti e, per quanto riguarda le specifiche tecniche,
essi devono osservare le regole di cui al decreto del Presidente del
Consiglio dei Ministri 8 febbraio 1999.
La disciplina dei requisiti tecnici di sicurezza, pur riferendosi a
standard internazionali, da' facolta', ad ogni certificatore, di
scegliere fra diverse tecnologie e strutture dei certificati. E'
pertanto possibile che, a causa di incompatibilita' delle tecnologie
e della struttura dei certificati utilizzati, soggetti, che
possiedono firme digitali certificate da differenti certificatori,
non siano in grado di scambiarsi, tra loro, documenti elettronici
firmati. La problematica, peraltro, non ha trovato soluzione neppure
con l'emanazione della direttiva europea sulla firma digitale, dove
il problema dell'interoperabilita' della firma digitale viene
demandato ad un processo di standardizzazione internazionale a medio
e lungo termine.
Ad un anno circa dalla pubblicazione delle regole tecniche, sette
certificatori sono stati inclusi nell'elenco pubblico tenuto
dall'Autorita' e altri sono in procinto di iscriversi. Al fine
percio' di garantire l'omogeneita' operativa e la corretta
interazione tra gli utenti che utilizzano la firma digitale, e' stata
avviata, dall'Autorita', un'azione di sensibilizzazione su queste
tematiche nei confronti di tutti i certificatori iscritti, come pure
nei confronti di quelli che hanno presentato domanda di iscrizione,
affinche' concordassero, in base all'art. 17 dell'allegato tecnico al
decreto del Presidente del Consiglio dei Ministri 8 febbraio 1999,
sulla necessita' di individuare un documento di linee guida, che, ad
integrazione degli standard esistenti, fornisse chiare indicazioni su
come affrontare i problemi sulla struttura del certificato e sulle
sue estensioni, sulla struttura delle liste di revoca e su quelle
delle "buste elettroniche". Cio', al fine di colmare le lacune dovute
ad un'interpretazione proprietaria di alcune regole sintattiche e
semantiche degli standard, come, peraltro, gia' segnalato agli
intermediari finanziari ed ai gestori dei sistemi di pagamento dalla
Banca d'Italia, nell'ambito dell'analisi dei requisiti necessari al
pieno e sicuro utilizzo della firma digitale nei trasferimenti
elettronici di moneta.
La normativa vigente consente l'utilizzo di una serie di algoritmi
e strutture dati, definiti in standard de jure o de facto. Non
essendo possibile imporre regole precise, poiche' ogni riferimento
diretto ad una specifica tecnica potrebbe generare squilibri sul
mercato o, addirittura, provocare, a priori, l'esclusione di alcuni
fornitori, si ritiene comunque necessario fornire, con le presenti
linee guida, delle indicazioni di riferimento, anche tenendo conto
dei suggerimenti provenienti dagli attori di mercato.
L'Autorita', per suo conto, ritiene che la soluzione del problema
dell'interoperabilita' della firma digitale e' condizione necessaria
per consentire il pieno utilizzo dei servizi di interoperabilita'
della rete unitaria e per l'erogazione dei servizi diretti al
cittadino.
Con la presente circolare, resa disponibile anche sul sito Internet
dell'Autorita' per l'informatica www.aipa.it, tenuto anche conto del
disposto di cui all'art. 21 del decreto del Presidente del Consiglio
dei Ministri 8 febbraio 1999 in tema di accordi tra certificatori,
vengono appunto indicate le linee guida per garantire l'omogeneita'
operativa e la corretta interazione tra gli utenti che utilizzano la
firma digitale e la massima diffusione ed efficienza dei processi
connessi alla firma digitale.
1. Il processo di firma digitale.
Solo attraverso una piena interoperabilita' tra i documenti
elettronici firmati utilizzando certificatori diversi si garantisce
piena efficienza e diffusione ai processi amministrativi utilizzanti
la firma digitale.
La soluzione al problema puo' essere duplice:
a livello organizzativo, con un servizio fornito dai
certificatori ed in grado di interpretare e tradurre i vari formati
di firma;
a livello tecnico, concordando uno standard per la pubblica
amministrazione italiana in termini di struttura del certificato e
delle sue estensioni.
Appare evidente che la soluzione a livello tecnico e' la piu'
semplice in quanto non richiede sforzi realizzativi onerosi ed
inoltre consente di seguire con sufficiente coerenza e tempestivita'
le evoluzioni degli standard internazionali.
Ai fini di un primo livello base di interoperabilita' sono da
prendere in considerazione, oltre ai contenuti del certificato ed
alla loro rappresentazione:
le estensioni del certificato ed i loro contenuti;
le liste di revoca e di sospensione ed i loro contenuti;
la rappresentazione delle informazioni nelle buste PKCS#7.
La redazione delle linee guida discende da un'analisi degli attuali
standard internazionali e delle caratteristiche offerte dai prodotti
di mercato.
Le tipologie di certificati cui si applicano le convenzioni
stabilite nelle presenti linee guida sono esclusivamente le seguenti:
1. certificati relativi a chiavi di certificazione di chiavi di
sottoscrizione ai sensi del decreto del Presidente del Consiglio dei
Ministri 8 febbraio 1999;
2. certificati relativi a chiavi di certificazione di chiavi di
marcatura temporale ai sensi del decreto del Presidente del Consiglio
dei Ministri 8 febbraio 1999;
3. certificati relativi a chiavi di sottoscrizione ai sensi del
decreto del Presidente del Consiglio dei Ministri 8 febbraio 1999;
4. certificati relativi a chiavi di marcatura temporale ai sensi
del decreto del Presidente del Consiglio dei Ministri 8 febbraio
1999.
Nessun certificato delle tipologie sopra indicate puo' essere
utilizzato per scopo diverso da quello cui e' destinato secondo la
normativa.
Vengono presi in esame solo i formati di codifica, certificazione
ed imbustamento delle firme utilizzate da tutti i certificatori
finora iscritti nell'elenco pubblico, che sono, rispettivamente il
PKCS#1 (RSA), lo X.509 ed il PKCS#7 ver 1.5 (RFC 2315).
Per quanto attiene alle possibili differenze di formato, tutti i
certificatori tratteranno le componenti di firma indistintamente nei
formati ASN.1-DER (ISO 8824, 8825), BASE64 (RFC 1421) e PKCS#7 (RFC
2315).
Cio' significa che saranno elaborate correttamente tutte le
componenti (certificato, busta PKCS#7, dati firmati, ecc.)
indipendentemente da quale dei tre formati citati venga utilizzato
per la trasmissione del dato.
Inoltre, si e' convenuto che un ulteriore standard di riferimento
dovesse essere il RFC 2459 "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile".
2. Contenuti del certificato e loro rappresentazione.
L'aderenza agli standard internazionali sulla certificazione delle
chiavi pubbliche non e' sufficiente a garantire la corretta
rappresentazione delle informazioni relative all'identificazione del
titolare.
In particolare, le varie possibilita' offerte dagli standard in
termini di rappresentazione dei dati e la loro realizzazione nei
prodotti commerciali non garantiscono una completa interazione tra i
vari prodotti.
Ulteriore difficolta' e' la mancanza di una collocazione naturale
per alcune tipologie di dati come il codice fiscale, che e' di poco
interesse in senso generale, ma ampiamente utilizzato (in verita' e'
obbligatorio) nella pubblica amministrazione italiana.
Nell'intento di porre rimedio a questi problemi, si e' stabilito
che debbano essere inserite determinate informazioni e con una certa
struttura in alcune componenti dell'identificativo del titolare
(campo subject) nel certificato. Le componenti interessate (la cui
presenza e' quindi da considerarsi obbligatoria) sono:
common name (object ID = 2.5.4.3);
description (object ID = 2.5.4.13).
Di seguito si forniscono le regole per la valorizzazione e
strutturazione delle due componenti.
a) Common Name = "cognome"/"nome"/"codice fiscale
titolare"/"identificativo titolare presso il certificatore".
Le parentesi acute individuano gli elementi non terminali. Il
carattere / (slash) viene utilizzato come separatore di campo.
I quattro campi devono essere codificati usando il set di caratteri
PrintableString.
Il campo "identificativo titolare presso il certificatore" contiene
il dato di cui all'art. 11, comma 1, lettera c) del decreto del
Presidente del Consiglio dei Ministri 8 febbraio 1999. Questo dato
viene conservato nel COMMON NAME per garantire l'univocita' del
certificato e favorire eventuali operazioni di inserimento e ricerca
all'interno del Directory X.500. Ai fini dell'interoperabilita', non
e' importante identificare il meccanismo attraverso il quale il
certificatore attribuisce questo dato, ne' la forma assunta dal
medesimo.
Qualora uno stesso soggetto sia titolare di piu' certificati per
piu' ruoli, deve possedere piu' codici identificativi distinti (come
previsto dall'art. 22, comma 3 del del decreto del Presidente del
Consiglio dei Ministri 8 febbraio 1999).
Per quanto riguarda l'informazione relativa al ruolo del titolare,
che permette di avere, per uno stesso soggetto, diversi certificati
presso lo stesso certificatore (art. 22, comma 3 del decreto del
Presidente del Consiglio dei Ministri 8 febbraio 1999), questa puo'
essere inserita nella DESCRIPTION (discusso di seguito).
Esempio: Common Name = "Rossi/Mario/ RSSMRA60D02F220M/XYZ123456"
b) Description = "C= "cognome esteso" /N= "nome esteso" /D= "data
di nascita"["/R= "ruolo titolare"].
Il valore di description e' quindi ottenuto dalla concatenazione di
quattro campi "etichettati" (tagged), il cui ordine non e' rilevante.
In grassetto sono evidenziate le etichette (tag) da utilizzare. Ai
quattro campi si applicano le seguenti regole:
"cognome esteso" e' il cognome per esteso del titolare,
eventualmente multiplo (es. "Battistotti Sassi");
"nome esteso" e' il nome per esteso del titolare, eventualmente
multiplo (es. "Carlo Maria");
"la data di nascita" deve essere rappresentata nel formato
"GG-MM-AAAA" con il carattere "0" (zero) a completamento dei numeri
ad una cifra;
il "ruolo del titolare" e' l'unico campo opzionale. Trattandosi
di un dato di interesse applicativo e non determinante ai fini
dell'interoperabilita', non si impongono regole nel suo formato.
La stringa risultante dalla concatenazione dei quattro campi puo'
essere codificata col set di caratteri BMPString quando cio' e'
necessario per rendere in modo esatto l'ortografia originale del nome
e cognome estesi del titolare (es. nel caso di nomi francesi,
spagnoli, ecc.).
Es.: description = "C GroÞmann =
/N=Günther/D=03-11-1947/R=Direttore Generale".
3. Estensioni del certificato e suoi contenuti.
Le linee guida prevedono che le estensioni che devono essere
contenute nei certificati siano:
Authority Key Identifier: seleziona una chiave tra quelle
utilizzate dal certificatore;
Subject Key Identifier: seleziona una chiave tra quelle a
disposizione del titolare;
Key usage: indica l'uso delle chiavi;
Extended Key Usage: fornisce indicazioni ulteriori sull'uso delle
chiavi;
Basic Constraints: specifica se la chiave corrispondente al
certificato e' una chiave di certificazione;
Certificate Policies: specifica la policy di riferimento del
certificato ed il sito di distribuzione del manuale operativo;
CrlDistributionPoint: indica dove reperire la CRL;
La presenza e le caratteristiche di un'estensione dipendono dalla
tipologia del certificato. La tabella che segue definisce, per i tre
tipi di certificato considerati dalla normativa, le modalita' di
utilizzo di ciascuna estensione. Per l'interpretazione degli elementi
si vedano le note esplicative appresso riportate.
----> Vedere Tabella di pag. 74 <----
4. Contenuti delle liste di revoca e sospensione.
La rappresentazione delle liste di revoca e sospensione e'
identica, in quanto le liste di sospensione si possono considerare
delle liste di revoca con il codice di revoca (CRLReason) di valore
pari a 6 ("certificate hold"). Ad ogni emissione verra' prodotta
un'unica lista contenente sia i certificati revocati, sia quelli
sospesi.
Le liste di revoca e sospensione, emesse in formato X.509v2, oltre
alle informazioni obbligatorie devono contenere le seguenti
estensioni:
estensioni al livello dell'intera lista: cRLNumber (il numero
della CRL);
estensioni a livello di singola entry: reasonCode.
Il valore di tale estensione, a livello di singola entry o di
intera lista e' a discrezione del certificatore, purche' si seguano
le regole fornite nella specifica pubblica RFC 2459.
5. Rappresentazione delle informazioni nelle buste PKCS#7
La struttura delle buste PKCS#7 deve essere aderente a quanto
previsto nella specifica pubblica RFC 2315.
Le criticita' individuate sono due:
la rappresentazione dei dati interna ed esterna alla busta;
l'attributo autenticato "signing time".
Per quanto concerne la rappresentazione dei dati, viene previsto
quanto segue:
il documento deve sempre essere contenuto nella busta
crittografica (ovvero, non e' ammessa la "detached signature");
il documento da firmare deve essere imbustato nel formato
originale (senza header o trailer aggiuntivi);
il nome del file firmato (ossia della busta) deve assumere una
doppia estensione in modo da conservare l'informazione relativa al
tipo di documento che e' stato firmato; il file firmato avra' quindi
un nome del tipo: nome file.tipo documento originale.P7M.
Il tipo documento deve seguire la prassi standard delle estensioni
(".DOC" per i documenti MS WordTM, ".PDF" per quelli Adobe AcrobatTM,
".HTM" per la pagine web, ecc.). Eventuali collisioni che si
venissero a determinare devono essere gestite a parte.
Per quanto concerne gli attributi autenticati, con le presenti
linee guida si stabilisce quanto segue.
L'attributo autenticato "signing time" si deve considerare
opzionale, sia dal punto di vista della sua presenza/assenza nella
busta PKCS#7, sia dal punto di vista dell'utilizzo del suo valore.
Per garantire l'interoperabilita' nell'ambito della pubblica
amministrazione, questo dato non puo' essere considerato critico.
L'eventuale presenza di questo attributo autenticato (o di altri
attributi autenticati) nella busta PKCS#7, quindi, non deve
comportare di per se' l'accettazione piuttosto che il rifiuto della
busta stessa. L'eventuale presenza di attributi autenticati sara'
significativa solo in base a specifiche esigenze del particolare
contesto applicativo in cui si opera, mentre non deve essere
considerata significativa a livello di API crittografiche.
Il presidente: Rey
Riferimenti.
Si riportano alcuni standard presi a riferimento per la stesura
delle presenti linee guida:
RFC 1421 (P.E.M.)
RFC 2437 (PKCS#1)
RFC 2459
RFC 2314 (PKCS#10)
RFC 2315 (PKCS#7)
X.501 - X.509 - X.520 - X.690 - X.691
ISO 10118-3 (Algoritmi di hash)