Normativa per la firma digitale in vigore dal 1 gennaio 2011

giovedì 22 settembre 2011
Franco Spinella
Responsabile Ricerca e Sviluppo , Dinasty of Freedom DOF
VIMODRONE, Italia
REGOLE PER IL RICONOSCIMENTO E LA VERIFICA DEL DOCUMENTO INFORMATICO

L'italia è uno dei primi paesi al mondo che ha regolamentato le procedure di firma dei documenti elettronici. La mia società è impegnata da più di dieci anni nello sviluppo di librerie software atte a svolgere queste attività nel modo più semplice possibile, permettendo alle software House di integrare rapidamente nelle loro applicazioni software tali funzionalità, con un gran risparmio di tempo, che può essere quindi dedicato a potenziare quelle che sono le funzionalità primarie dei loro software gestionali, Qui di seguito riporto una delle normative uscite recentemente che regolano il riconoscimento e la verifica del documento Informatico, e modificano quelle che sono le modalità di Firma aggiungendo un livello di sicurezza maggiore, passando dalle firme sha-1 a quelle sha-256 con busta Cades:

=========================================
TITOLO I

DISPOSIZIONI GENERALI

Art. 1

(Definizioni)


1. Ai fini della presente deliberazione si intendono richiamate le definizioni contenute
nell'articolo 1 del decreto legislativo 7 marzo 2005, n. 82 e successive modificazioni
ed integrazioni, e nell'articolo 1 del decreto del Presidente del Consiglio dei Ministri
30 marzo 2009 e successive modificazioni. Si intende inoltre per:


a) attributo: informazione associata ad un documento informatico o ad una busta crittografica
oppure informazione elementare contenuta in un campo di un certificato elettronico
o di una CRL come un nome, un numero o una data;


b) attributo autenticato: attributo incluso nella firma elettronica di un documento
e, quindi, ad esso associato in modo protetto dalla firma stessa;


c) campo: unità informativa contenuta in un certificato o in una CRL. Può essere
composta da diverse unità informative elementari dette attributi;


d) CAdES: formato di busta crittografica definito nella norma ETSI TS 101 733 V1.7.4
basata a sua volta sulle specifiche RFC 3852 e RFC 2634 e successive modificazioni;


e) codice: il codice dell'amministrazione digitale, di cui al decreto legislativo
7 marzo 2005, n.82;


f) controfirma: la firma apposta ad una precedente firma;


g) estensione: metodo utilizzato per associare specifiche informazioni (attributi)
alla chiave pubblica contenuta nel certificato;


h) ETSI (European Telecommunications Standards Institute): organizzazione indipendente,
no profit, la cui missione è produrre standard sulle tecnologie dell'informazione
e della comunicazione (ICT). E riconosciuto ufficialmente dalla Commissione Europea
come ESO (European Standards Organisation);


i) firme multiple: firme digitali apposte da diversi sottoscrittori allo stesso documento;


l) firme parallele: le firme apposte da differenti soggetti al medesimo documento
informatico utilizzando una sola busta crittografica;


m) HTTP (Hypertext Transfer Protocol): protocollo per il trasferimento di pagine
ipertestuali e risorse in rete conforme alla specifica RFC 2616 e successive modificazioni;


n)mIETF (Internet Engineering Task Force): comunità aperta di tecnici, specialisti
e ricercatori interessati all'evoluzione tecnica e tecnologica di Internet;


o) ISO (International Organization for Standardization): organizzazione indipendente,
la cui missione è quella di produrre standard riconosciuti a livello mondiale;


p) LDAP (Lightweight Directory Access Protocol): protocollo di rete, conforme alla
specifica RFC 3494 e successive modificazioni, utilizzato per rendere accessibili
in rete informazioni con servizi di directory basati sulla famiglia di standard ITU
X.500;


q) marcatura critica: caratteristica che possono assumere le estensioni conformemente
allo specifica RFC 5280 e successive modificazioni;


r) OCSP (Online Certificate Status Protocol): protocollo di rete, conforme alla specifica
RFC 2560 e successive modificazioni, utilizzato per verificare la validità dei certificati
elettronici;


s) OID (Object IDentifier): codice univoco basato su una sequenza ordinata di numeri
per l'identificazione di evidenze informatiche utilizzate per la rappresentazione
di oggetti come estensioni, attributi, documenti e strutture di dati in genere nell'ambito
degli standard internazionali relativi alla interconnessione dei sistemi aperti che
richiedono unidentificazione univoca in ambito mondiale;


t) padding: riempimento dati di evidenze informatiche, tipicamente utilizzato nell'ambito
delle applicazioni crittografiche, al fine del raggiungimento di una lunghezza predefinita
nei formati a blocchi delle strutture dati utilizzate dagli algoritmi;


u) PAdES: formato di busta crittografica definito nella norma ETSI TS 102 778 basata
a sua volta sullo standard ISO/IEC 32000 e successive modificazioni;


v) PDF (Portable Document Format): formato documentale elettronico definito dallo
standard internazionale ISO/IEC 32000;


z) regole tecniche: le regole tecniche in materia di generazione, apposizione, verifica
delle firme digitali e validazione temporale adottate con decreto del Presidente
del Consiglio dei Ministri 30 marzo 2009 pubblicate sulla G.U. 6 giugno 2009, n.
129;


aa) RFC (Request For Comments): documenti contenenti specifiche tecniche standard,
riconosciute a livello internazionale, definite dall'nternet Engineering Task Force
(IETF) e dall'Internet Engineering Steering Group (IESG );


bb) W3C (World Wide Web Consortium): un consorzio internazionale di soggetti che
operano in Internet e con il Web, con lo scopo di sviluppare tecnologie interoperabili
come specifiche, linee guida, software e strumenti per l'evoluzione del Web;


cc) XML (eXtended Markup Language): insieme di regole per strutturare in formato
testo i dati oggetto di elaborazione.


Art. 2


(Ambito di applicazione e contenuto)


1.La presente deliberazione stabilisce le regole per il riconoscimento e la verifica
del documento informatico alle quali devono attenersi i certificatori accreditati
ai sensi dell'articolo 29 del codice, di seguito denominati certificatori accreditati.


2.Le disposizioni di cui al titolo II indicano gli algoritmi per la generazione e
verifica della firma digitale.


3.Le disposizioni di cui al titolo III definiscono il profilo dei certificati qualificati
e le informazioni che in essi devono essere contenute.


4.Le disposizioni di cui al titolo IV definiscono il profilo e le informazioni che
devono essere contenute nei certificati elettronici di certificazione e di marcatura
temporale.


5.Le disposizioni di cui al titolo V definiscono le regole per la validazione temporale,
il formato e le informazioni che devono essere contenute nelle marche temporali utilizzate
dai sistemi di validazione temporale dei documenti, così come definiti nel Titolo
IV delle regole tecniche.


6.Le disposizioni di cui al titolo VI definiscono i formati e le modalità di accesso
alle informazioni sulla revoca e sulla sospensione dei certificati, ai sensi dell'articolo
30 delle regole tecniche.


7.Le disposizioni di cui al titolo VII definiscono i formati delle buste crittografiche
destinate a contenere gli oggetti sottoscritti con firma digitale.


8.Le disposizioni di cui al titolo VIII definiscono i requisiti delle applicazioni
di apposizione e verifica della firma digitale di cui agli articoli 9, comma 10,
e articolo 10 delle regole tecniche.



TITOLO II

ALGORITMI PER LA GENERAZIONE E VERIFICA DELLA FIRMA DIGITALE

Art. 3

(Algoritmi crittografici)

1.I certificatori accreditati devono utilizzare l'algoritmo RSA (Rivest-Shamir-Adleman)
con lunghezza delle chiavi non inferiore a 1024 bit; le chiavi di certificazione
di cui all'articolo 4, comma 4, lettera b) delle regole tecniche devono avere una
lunghezza non inferiore a 2048 bit.


2.A partire dall'anno successivo a quello dell'entrata in vigore della presente deliberazione,
le firme elettroniche apposte utilizzando algoritmi di crittografia asimmetrica basati
sulle curve ellittiche hanno valore di firma digitale ai sensi della normativa vigente.


3.Ai fini della realizzazione di quanto previsto ai commi 1 e 2, i certificatori
accreditati devono rispettare le specifiche contenute nel documento ETSI TS 102 176.1
V2.0.0.


Art. 4

(Funzioni di hash)

1.I certificatori accreditati devono utilizzare per la sottoscrizione dei certificati
elettronici di certificazione, di sottoscrizione e di marcatura temporale e per la
sottoscrizione delle relative CRL, il seguente algoritmo, definito nella norma ISO/IEC
10118-3:2004:


dedicated hash-function 4, corrispondente alla funzione SHA-256.


2.Le applicazioni di generazione e verifica della firma digitale per la sottoscrizione
dei documenti informatici devono utilizzare la funzione di hash indicata al comma
1.


3.Le applicazioni di generazione e verifica della marca temporale devono utilizzare
la funzione di hash indicata al comma 1.

4.Fino allo scadere dei termini previsti nell'articolo 29 della presente deliberazione,
i certificatori accreditati devono utilizzare il seguente algoritmo, definito nella
norma ISO/IEC 10118-3:2004:


dedicated hash-function 3, corrispondente alla funzione SHA-1.


Art. 5

(Metodi di sottoscrizione)

1.Per la generazione e la verifica della firma digitale conforme alla specifica ETSI
TS 101 733 si deve utilizzare il metodo di sottoscrizione sha256-with-rsa (sha256WithRSAEncryption
(OID.1.2.840.113549.1.1.11) con padding conforme alla specifica RFC 3447.


2.Le firme di cui allarticolo 3, comma 2 devono utilizzare il metodo di sottoscrizione
ecdsa-with-Sha256 (OID 1.2.840.10045.4.3.2).


3.Nella sottoscrizione in linguaggio XML l'algoritmo per la generazione e la verifica
della firma digitale in linguaggio XML (SignatureValue) da applicare all'elemento
SignedInfo è l'algoritmo RSA-SHA256. Si deve specificare nell'attributo Algorithm
dell'elemento DigestMethod lindicatore: http://www.w3.org/2001/04/xmlenc#sha256


Nel caso di utilizzo della crittografia basata sull'algoritmo RSA l'indicatore che
deve essere indicato nell'attributo Algorithm dell'elemento SignatureMethod è: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
come indicato nella specifica RFC 4051.


Nel caso di utilizzo della crittografia basata sulle curve ellittiche l'indicatore
che deve essere indicato è: http://www.w3.org/2001/04/xmldsig-more#ecdsa-sh... come
indicato nella specifica RFC 4051.


4.La sottoscrizione in formato PDF deve utilizzare il Message Digest SHA-256.


Art. 6

(XML: Algoritmi per la canonicalizzazione)

1. L'applicazione di firma in linguaggio XML deve utilizzare per la canonicalizzazione
(versione 1.1) dell'elemento SignedInfo quanto stabilito dal seguente indicatore:
http://www.w3.org/2006/12/xml-c14n11


2. Nel caso di sottoscrizione di una parte del documento informatico deve essere
utilizzata la canonicalizzazione di tipo esclusivo (versione 1.1) definita dai seguenti
indicatori:


http://www.w3.org/2006/12/xml-c14n11#


http://www.w3.org/2006/12/xml-c14n11#WithComments

3. L'applicazione di verifica della firma in linguaggio XML deve supportare la canonicalizzazione
(versione 1.1) di cui ai commi 1 e 2 e la canonicalizzazione (versione 1.0) dell'elemento
<SignedInfo> secondo quanto stabilito dal seguente indicatore: http://www.w3.org/TR/2001/REC-xml-c14n-20010315


4. Gli indicatori di cui ai commi 1 e 2 devono essere riportati nell'attributo Algorithm
dellelemento CanonicalizationMethod.


Art. 7

(XML: Algoritmi di trasformazione)

1. L'insieme minimo di trasformazioni che le applicazioni di verifica devono essere
in grado di gestire è il seguente:


a. Base64 identificata dall'indicatore http://www.w3.org/2000/09/xmldsig#base64
b. Xpath identificata dall'indicatore http://www.w3.org/2002/06/xmldsig-filter2
c. XSLT identificata dall'indicatore http://www.w3.org/TR/1999/REC-xslt-19991116
Questa trasformazione deve essere sempre eseguita prima della canonicalizzazione.

L'indicatore che identifica la trasformazione, come stabilito nella specifica RFC
3275, deve essere riportato nell'attributo Algorithm dell'elemento Transform.


Art. 8
(XML: Regole specifiche di trasformazione)

1. Nella modalità di sottoscrizione enveloped, nel caso di firme multiple parallele,
descritte nell'articolo 24, comma 1, lettera a) è necessario assicurare che tutte
le firme successive alla prima siano riferibili ai medesimi dati sui quali è stata
calcolata la prima firma. Poiché ciò non avviene in modo automatico, si deve fare
in modo che siano gestite le strutture <ds:Signature> a partire dai dati originali
sottoscritti.

Nei casi in cui sia applicata una trasformazione XPath questa deve essere specificata
nell'elemento <ds:Transforms> all'interno dell'elemento <ds:SignedInfo>.

La trasformazione deve essere basata sulla sintassi descritta nella raccomandazione
XPath Filter 2.0 identificata dall'indicatore:http://www.w3.org/2002/06/xmldsig-filter2


o sulla sintassi XPath v2.0 identificata dall'indicatore:http://www.w3.org/TR/xpath20


Le applicazioni di firma e di verifica devono supportare le trasformazioni sopra
descritte.


2. Nella trasformazione di cui all'articolo 7, comma 1, lettera c), il foglio di
stile deve essere utilizzato al fine della presentazione all'utente del documento
informatico. Tale trasformazione, se indicata, deve essere l'unica trasformazione
di questo tipo presente nell'elemento <ds:Reference> e l'ultima nella sequenza delle
operazioni di trasformazione per questo elemento <ds:Reference>.

3. La trasformazione di cui all'articolo 7, comma 1, lettera c), deve essere in grado
di presentare all'utente il documento informatico in maniera tale da garantire la
staticità del contenuto. Se il relativo foglio di stile è autenticato, tale circostanza
deve essere presentata all'utente unitamente all'informazione dell'identità di chi
ha eseguito l'autenticazione.


4. I formati ammessi per il documento informatico risultante dalla trasformazione
sono:

a. UTF-8 e successive modifiche;
b. conformi alla specifica XHTML, versione 1.0 definita dall'indicatore:

http://www.w3.org/TR/xhtml1

dove la tipologia di documento XML da utilizzare deve essere conforme alla specifica
seguente:

http://www.w3.org/TR/2002/REC-xhtml1-20020801/D...


5. Nei casi nei quali il foglio di stile di cui al comma 3, non è completamente contenuto
nell'elemento <Transform>, ma è identificato tramite un indicatore come risorsa esterna,
il foglio di stile deve essere autenticato in conformità a quanto previsto dalla
presente deliberazione in materia di firma digitale in linguaggio XML e in particolare
a quanto stabilito nell'articolo 22, comma 2, lettera a).


Art. 9

(Elementi specifici per il profilo di firma in linguaggio XML)

1.Lelemento KeyInfo, opzionale nella specifica RFC 3275, deve essere sempre presente
nella busta crittografica.

2.Lelemento SignedInfo deve contenere un elemento Reference che includa il KeyInfo,
in modo che quest'ultimo concorra nel computo della firma.

3.Lapplicazione di firma deve includere nella struttura KeyInfo lelemento X509Data
( http://www.w3.org/2000/09/xmldsig#X509Data ) contenente il certificato qualificato
del sottoscrittore.

4.Lapplicazione di verifica deve gestire almeno l'elemento X509Data e utilizzare
il certificato contenuto nella busta per le operazioni di verifica della firma.

Art. 10
(Elementi specifici per il profilo di firma in formato PDF)

1.Gli elementi specifici per il profilo di firma in formato PDF devono essere conformi
alle specifiche ETSI TS 102 778 parte 2 e successive.


TITOLO III

PROFILO DEI CERTIFICATI QUALIFICATI

Art. 11

(Norme generali)

1. Ove non diversamente indicato, il profilo dei certificati deve essere conforme
alla specifica RFC 5280, capitolo 4, recante Profilo dei certificati e delle estensioni
dei certificati e conforme alla specifica ETSI TS 101 862 V1.3.2, recante Profilo
dei Certificati Qualificati.


Art. 12
(Profilo dei certificati qualificati)

1. Salvo quanto diversamente disposto nella presente deliberazione, ai certificati
qualificati si applica quanto stabilito nella specifica ETSI TS 102 280 V1.1.1, recante
Profilo dei certificati X.509 V.3 per certificati rilasciati a persone fisiche.

2.Il campo Issuer (emittente) del certificato deve contenere almeno i seguenti attributi:

a)organizationName (OID: 2.5.4.10), che contiene la ragione sociale o denominazione
dell'organizzazione che emette il certificato qualificato;

b)countryName (OID: 2.5.4.6), che contiene il country code ISO 3166 dello Stato in
cui è registrata l'organizzazione indicata nell'organizationName.

3.Il campo SubjectDN (Dati identificativi del titolare) del certificato deve contenere
i seguenti attributi:

a)givenName e surname (OID: 2.5.4.42 e 2.5.4.4), che contengono rispettivamente il
nome e il cognome del titolare del certificato;

b)countryName (OID: 2.5.4.6), che, nel caso in cui l'organizationName contenga il
valore non presente, contiene il country code ISO 3166 dello Stato di residenza del
titolare; nel caso in cui l'organizationName contenga un valore diverso da non presente,
contiene il country code ISO 3166 dello Stato che ha assegnato all'organizzazione
il codice identificativo riportato nell'attributo organizationName;

c)organizationName (OID: 2.5.4.10), che contiene, se applicabile, la ragione sociale
o la denominazione e il codice identificativo dellorganizzazione che ha richiesto
o autorizzato il rilascio del certificato del titolare. Il codice identificativo
è un codice rilasciato dalla competente autorità dello Stato indicato nellattributo
countryName. Se lorganizationName non è applicabile, assume il valore non presente;

d) erialNumber (OID: 2.5.4.5) che contiene il codice fiscale del titolare rilasciato
dallautorità fiscale dello Stato di residenza del titolare o, in mancanza, un analogo
codice identificativo, quale ad esempio un codice di previdenza sociale o un codice
identificativo generale. In mancanza di tale codice identificativo potrà essere utilizzato
il numero del passaporto preceduto da PASSPORT.Allo scopo di definire il contesto
per la comprensione del codice in questione, il codice stesso è preceduto dal country
code ISO 3166 e dal carattere :(in notazione esadecimale 0x3A).;

e) n alternativa agli attributi specificati alla lettera a), il certificato può contenere
lattributo pseudonym (OID: 2.5.4.65), che contiene una qualsiasi stringa univoca
nellambito del certificatore, a discrezione del titolare. La stringa utilizzata non
permette di risalire ai dati identificativi del titolare. Se lattributo pseudonym
è presente, lattributo countryName assume il valore IT, lattributo organizationName
assume il valore non presente, lattributo serialNumber il valore pseudonimo e gli
attributi title e localityName non sono presenti;

f) nQualifier (OID: 2.5.4.46), contiene il codice identificativo del titolare presso
il certificatore. Detto codice, assegnato dal certificatore, è univoco nellambito
del certificatore stesso.

4. l campo subjectDN (Dati identificativi del titolare) del certificato può contenere
altri attributi purché non in contrasto con quanto previsto dal documento ETSI TS
102 280. Leventuale codifica degli attributi title, localityName, commonName e organizationalUnitName
deve rispettare le seguenti regole:


a) itle (OID: 2.5.4.12), contiene una indicazione della qualifica specifica del titolare,
quale lappartenenza ad ordini o collegi professionali, liscrizione ad albi o il possesso
di altre abilitazioni professionali, ovvero i poteri di rappresentanza nellambito
dellorganizzazione specificata nellattributo organizationName. Nel caso in cui lattributo
organizationName contenga un valore diverso da non presente, linserimento delle informazioni
nel title è richiesto dallorganizzazione ivi indicata ed il certificatore deve conservare
tale richiesta per il periodo indicato nellarticolo 15, comma 7 delle regole tecniche;
in caso contrario deve contenere informazioni derivanti da autocertificazione effettuata
dal titolare ai sensi della normativa vigente;


b) localityName (OID: 2.5.4.7), contiene, nel caso in cui lattributo organizationName
contenga un valore diverso da non presente, informazioni pertinenti allorganizzazione
specificata;

c) commonName (OID: 2.5.4.3), in aggiunta a surname e givenName, contiene leventuale
altro nome con il quale il titolare è comunemente conosciuto.

d) organizationalUnitName (OID: 2.5.4.11), contiene ulteriori informazioni inerenti
allorganizzazione.Tale attributo può comparire, al massimo, cinque volte.


5. Il certificato deve contenere inoltre le seguenti estensioni:

a) keyUsage (OID: 2.5.29.15), che contiene esclusivamente il valore nonRepudiation
(bit 1 impostato a 1). Lestensione è marcata critica;

b) certificatePolicies (OID: 2.5.29.32), che contiene lOID della Certificate Policy
(CP) e lUniform Resource Locator (URL) che punta al Certificate Practice Statement
(CPS) nel rispetto del quale il certificatore ha emesso il certificato. Se non viene
adottata una CP definita a livello nazionale o europeo, il certificatore deve definire
una propria CP e tale OID deve essere definito e pubblicizzato dal certificatore.
Possono essere indicate più Certificate Policy (CP). LURL deve configurare un percorso
assoluto per laccesso al CPS. Lestensione non è marcata critica;

c) CRLDistributionPoints (OID: 2.5.29.31), che contiene lURL che punta alle CRL pubblicate
dal certificatore dove eventualmente saranno disponibili le informazioni relative
alla revoca o sospensione del certificato in questione. LURL configura un percorso
assoluto per laccesso alla CRL. Lo schema da utilizzare per lURL è HTTP oppure LDAP
e consente lo scaricamento anonimo della CRL. Nel caso vengano valorizzati più di
un URL per lestensione, tali URL configurano percorsi coerenti con lultima CRL pubblicata.
Lestensione non è marcata critica;

d) authorityKeyIdentifier (OID: 2.5.29.35), che contiene almeno il campo keyIdentifier.
Lestensione non è marcata critica;

e) subjectKeyIdentifier (OID: 2.5.29.14), che contiene il valore keyIdentifier per
identificare il certificato. Lestensione non è marcata critica;

f) qcStatements, identificate nel documento ETSI TS 101 862 come segue:

1) id-etsi-qcs-QcCompliance (OID: 0.4.0.1862.1.1);

2) id-etsi-qcs-QcLimitValue (OID: 0.4.0.1862.1.2) presente se sono applicabili limiti
nelle negoziazioni;

3) id-etsi-qcs-QcRetentionPeriod (OID: 0.4.0.1862.1.3) il valore indicato è pari
o superiore a 20;

4) id-etsi-qcs-QcSSCD (OID: 0.4.0.1862.1.4). Lestensione non è marcata critica.

6. Il certificato di sottoscrizione può contenere le seguenti estensioni:

a) SubjectDirectoryAttributes (OID: 2.5.29.9). Essa non contiene alcuno dei campi
indicati ai commi 3 e 4. Lattributo dateOfBirth (OID: 1.3.6.1.5.5.7.9.1), se presente,
è codificato nel formato GeneralizedTime. Lestensione non è marcata critica;

b) authorityInfoAccess (OID: 1.3.6.1.5.5.7.1.1). Nel caso in cui il certificatore
metta a disposizione, conformemente allarticolo 19, un sistema OCSP per la verifica
della validità di un certificato, lestensione AuthorityInfoAccess deve contenere
un campo accessDescription con la descrizione delle modalità di accesso al servizio
OCSP e i seguenti attributi:


1) accessMethod, che contiene lidentificativo id-ad-ocsp (OID: 1.3.6.1.5.5.7.48.1);

2) accessLocation, che contiene lURI che punta allOCSP Responder del certificatore,
utilizzabile per effettuare la verifica del certificato stesso. LURI configura un
percorso assoluto per laccesso allOCSP Responder.

Nel caso in cui siano specificati più campi accessDescription contenenti lidentificativo
id-ad-ocsp nellattributo accessMethod, tali indicazioni devono configurare diversi
percorsi alternativi per linterrogazione, tramite OCSP, dello stato del certificato.
Lestensione non è marcata critica;

c) Salvo quanto disposto allarticolo 12, comma 5, lettera f), gli eventuali ulteriori
limiti duso di cui allarticolo 41 delle regole tecniche sono inseriti nellattributo
explicitText del campo userNotice dellestensione certificatePolicies. Sul sito istituzionale
del CNIPA vengono pubblicati i testi e le codifiche delle limitazioni duso che i
certificatori devono garantire agli utenti.

d) Ulteriori estensioni possono essere inserite nel certificato purché conformi ai
documenti e alle specifiche citati nella presente deliberazione e non marcate critiche.
Possono essere utilizzate altre estensioni definite in standard internazionalmente
riconosciuti purché questi non siano in contrasto con la presente deliberazione,
anche queste non marcate critiche.


TITOLO IV

PROFILO DEI CERTIFICATI DI CERTIFICAZIONE E MARCATURA TEMPORALE 11


Art. 13

(Profilo dei certificati di certificazione e marcatura temporale)

1. Se non diversamente previsto, il profilo dei certificati di certificazione e marcatura
temporale deve essere conforme alla specifica RFC 5280.

2. Per la codifica dei certificati deve essere utilizzato il formato ASN.1 DER (ISO/IEC
8824, 8825) in rappresentazione binaria o alfanumerica ottenuta applicando la trasformazione
BASE 64 (RFC 1421 e successive modifiche). La testata e la coda previsti in RFC 1421
possono essere assenti. Nel primo caso il file contenente il certificato deve assumere
lestensione .der o .cer, nel secondo caso .b64.


Art. 14

(Uso delle estensioni nei certificati di certificazione)

1. I certificati di certificazione devono contenere le seguenti estensioni:

a) keyUsage (OID 2.5.29.15) contiene i valori keyCertSign e cRLSign (bit 5 e 6 impostati
a 1). Lestensione è marcata critica;

b) basicConstraints (OID 2.5.29.19) - contiene il valore CA=true. Lestensione è marcata
critica;

c) certificatePolicies (OID 2.5.29.32) - contiene uno o più identificativi delle
policyIdentifier e le URL dei relativi CPS. Può contenere lOID generico previsto
dallRFC 5280 (2.5.29.32.0). Lestensione non è marcata critica;

d) CRLDistributionPoints (OID 2.5.29.31) - contiene uno o più URL di accesso a CRL.
LURL configura un percorso assoluto per laccesso alla CRL. Lestensione non è marcata
critica;

e) subjectKeyIdentifier (OID 2.5.29.14) - contiene il valore keyIdentifier per identificare
il certificato. Lestensione non è marcata critica.

2. Ulteriori estensioni possono essere inserite nel certificato purché conformi agli
standard citati nella presente deliberazione e non marcate critiche.

Art. 15
(Uso delle estensioni nei certificati di marcatura temporale )


1. I certificati di marcatura temporale devono contenere le seguenti estensioni:

a) keyUsage (OID 2.5.29.15) contiene il valore digitalSignature (bit 0 impostato
a 1). Lestensione è marcata critica;


b) extendedKeyUsage (OID 2.5.29.37) contiene esclusivamente il campo keyPurposeId=timeStamping.
Lestensione è marcata critica;

c) certificatePolicies OID 2.5.29.32) contiene uno o più identificativi delle policyIdentifier
e le URL del relativo CPS. Lestensione non è marcata critica;

d) authorityKeyIdentifier (OID 2.5.29.35) contiene almeno il valore keyIdentifier
corrispondente al subjectKeyIdentifier del certificato di certificazione utilizzato
per sottoscrivere il certificato di marcatura temporale. Lestensione non è marcata
critica;

e) subjectKeyIdentifier (OID 2.5.29.14) contiene il valore keyIdentifier per identificare
il certificato. Lestensione non è marcata critica.

2. Ulteriori estensioni possono essere inserite nel certificato purché conformemente
agli standard citati nella presente deliberazione e non marcate critiche.


TITOLO V

REGOLE PER LA VALIDAZIONE TEMPORALE

Art. 16
(Regole per i servizi di Validazione Temporale)

1. Laccesso al servizio di validazione temporale fornito dai certificatori avviene
tramite il protocollo e il formato definiti nella specifica ETSI TS 101 861 V.1.2.1,
recante Profilo di Validazione Temporale e nella specifica RFC 3161 e successive
modificazioni. Le marche temporali inviate in risposta al richiedente seguono i medesimi
standard.

2. I certificatori rendono disponibile o indicano un sistema che permetta lapertura,
lanalisi e la visualizzazione delle marche temporali di cui al comma 1. Detto sistema
gestisce correttamente le strutture TimeStampToken e TimeStampResp almeno nel formato
detached, con verifica della firma del sistema di validazione temporale e della corretta
associazione, effettuata tramite la funzione di hash, con il documento per il quale
è stata generata la marca temporale stessa.

3. Lestensione associata alla struttura TimeStampToken e TimeStampResp non deve influire
sul corretto funzionamento del sistema di cui al comma 2.

4. I TimeStampToken devono includere un identificativo univoco della policy di sicurezza
in base alla quale il token stesso è stato generato. Detto identificativo, ove non
definito a livello nazionale od europeo, è definito e reso pubblico dal certificatore.


Art. 17
(Associazione di una marca temporale al documento sottoscritto)


1. Se al documento informatico viene apposta una sola firma, la marcatura temporale
del documento sottoscritto in conformità al documento ETSI TS 101 733 (CAdES) deve
essere conforme alle specifiche RFC 3161.

2. Se al documento informatico si devono applicare due o più firme e il tempo di
apposizione di ciascuna firma è rilevante, il formato da utilizzare deve essere conforme
al documento ETSI TS 101 733 (CAdES), alle specifiche RFC 3161.

3. Quando sia necessario attestare lesistenza in un dato momento dellintero documento
sottoscritto con una o più firme digitali, il formato da utilizzare deve essere conforme
alle specifiche RFC 5544.

4. Le estensioni dei file da utilizzare per i formati detached sono:

a) TimeStampedData: .tsd;
b) TimeStampResponse: .tsr;
c) TimeStampToken : .tst.


5. La marcatura temporale del documento sottoscritto utilizzando il linguaggio XML
deve essere realizzata mediante il formato XAdES-T descritto nel documento ETSI TS
101 903.

6. La marcatura temporale del documento sottoscritto utilizzando il formato PDF deve
essere realizzata conformemente alle specifiche ETSI TS 102 778.



TITOLO VI

INFORMAZIONI SULLA REVOCA E SOSPENSIONE DEI CERTIFICATI

Art. 18

(Verifica dei certificati - CRL)

1. Le informazioni sulla revoca e sospensione dei certificati pubblicate in rete
dai certificatori e rese disponibili pubblicamente tramite liste di revoca e sospensione,
hanno un formato conforme alla specifica RFC 5280, capitolo 5, esclusi i paragrafi
5.2.4 e 5.2.6.

2.Le liste di certificati revocati e sospesi sono liberamente accessibili al pubblico
tramite protocollo HTTP o LDAP.

3. I certificati revocati o sospesi devono permanere nella CRL, anche dopo la loro
naturale scadenza, fino alla scadenza del relativo certificato di certificazione.

4. La revoca o sospensione dei certificati di sottoscrizione, richiesta o prevista
dalle regole tecniche, deve essere effettuata entro ventiquattro ore dalla richiesta
pervenuta.

Art. 19

(Verifica dei certificati - OCSP)

1. Fermo restando quanto prescritto dallarticolo 18, i certificatori hanno la facoltà
di rendere disponibili le informazioni sulla revoca e sospensione dei certificati,
anche attraverso servizi OCSP. In tal caso, detti servizi devono essere conformi
alla specifica RFC 2560 e successive modificazioni.

Art. 20
(Coerenza delle informazioni sulla revoca e sospensione dei certificati)

1. Se un certificatore mette a disposizione diversi servizi per laccesso alle informazioni
sulla revoca o la sospensione dei certificati, o diversi URL di accesso allo stesso
servizio, le informazioni ottenute accedendo con le diverse modalità devono essere
coerenti, fatto salvo lintervallo temporale strettamente necessario per lallineamento.
Tale intervallo temporale deve essere non superiore a sessanta secondi.


TITOLO VII

FORMATI DI SOTTOSCRIZIONE

Art. 21
(Busta crittografica di firma)

1. La busta crittografica destinata a contenere il documento informatico sottoscritto
deve essere conforme, salvo i casi previsti dai commi 8 e 9, al documento ETSI TS
101 733 (CAdES) nella modalità denominata CAdES BES.

2. La busta crittografica di cui al comma 1 deve essere di tipo signedData (OID:
1.2.840.113549.1.7.2).

3. Per la codifica della busta crittografica deve essere utilizzato il formato ASN.1
(ISO/IEC 8824) in rappresentazione binaria (ISO/IEC 8825, BER - DER) o alfanumerica
ottenuta applicando la trasformazione BASE 64 (RFC 1421, RFC 2045). La testata e
la coda previsti nelle specifiche RFC 1421 e RFC 2045 possono essere assenti.

4. Il documento da firmare deve essere imbustato nel formato originale, senza aggiunte
in testa o in coda al formato stesso.

5. Il nome del file firmato, ossia della busta, deve assumere lulteriore estensione
p7m.

6. Le buste crittografiche di cui al comma 5 possono contenere a loro volta buste
crittografiche. In questo caso deve essere applicata una ulteriore estension
1
Franco Spinella ritiene ritengono interessante questa discussione