|
IL COLLEGIO
Visto il
decreto legislativo 12 febbraio 1993, n. 39, così come
modificato dall'art. 176, comma 3, del decreto
legislativo 30 giugno 2003, n. 196;
Visto il decreto del Presidente della Repubblica 28
dicembre 2000, n. 445, recante testo unico delle
disposizioni legislative e regolamentari in materia di
documentazione amministrativa;
Visto il decreto legislativo 23 gennaio 2002, n. 10,
recante attuazione della direttiva 1999/93/CE, relativa
ad un quadro comunitario per le firme elettroniche;
Visto l'art. 40, comma 4, del decreto del Presidente del
Consiglio dei Ministri 13 gennaio 2004;
Delibera
di
emanare le seguenti regole per il riconoscimento e la
verifica del documento informatico.
Titolo I
DISPOSIZIONI GENERALI
Art. 1.
Definizioni
1. Fatte salve le definizioni contenute negli articoli 1
e 22 del decreto del Presidente della Repubblica 28
dicembre 2000, n. 445, e successive modificazioni, ai
fini delle presenti regole si intende per:
a) testo unico, il testo unico delle disposizioni
legislative e regolamentari in materia di documentazione
amministrativa, emanato con decreto del Presidente della
Repubblica 28 dicembre 2000, n. 445;
b) regole tecniche, le regole tecniche per la
formazione, la trasmissione, la conservazione, la
duplicazione, la riproduzione e la validazione, anche
temporale, dei documenti informatici emanate con decreto
del Presidente del Consiglio dei Ministri 13 gennaio
2004 pubblicate nella Gazzetta Ufficiale 27 aprile 2004,
n. 98;
c) firme multiple, firme digitali apposte da diversi
sottoscrittori allo stesso documento;
d) campo, unità informativa contenuta nel certificato.
Può essere composta da diverse unità informative
elementari dette «attributi»;
e) estensione, metodo utilizzato per associare
specifiche informazioni (attributi) alla chiave pubblica
contenuta nel certificato, utilizzata per fornire
ulteriori informazioni sul
titolare del certificato e per gestire la gerarchia di
certificazione;
f) attributo, informazione elementare contenuta in un
campo di un certificato elettronico come un nome, un
numero o una data;
g) attributi autenticati, insieme di attributi
sottoscritti con firma elettronica dal sottoscrittore;
h) marcatura critica, caratteristica che possono
assumere le estensioni conformemente allo standard RFC
3280;
i) marca temporale, un'evidenza informatica che consente
la validazione temporale;
l) OID (Object Identifier), codice numerico standard per
l'identificazione univoca di evidenze informatiche
utilizzate per la rappresentazione delle strutture di
dati nell'ambito degli standardinternazionali relativi
alla interconnessione dei sistemi aperti;
m) RFC (Request For Comments), documenti contenenti
specifiche tecniche standard, riconosciute a livello
internazionale, definite dall'Internet Engineering Task
Force (IETF) e dall'Internet Engineering Steering Group
(IESG);
n) ETSI (European Telecommunications Standards Institute),organizzazione
indipendente, no profit, la cui missione é produrre
standard sulle telecomunicazioni. é ufficialmente
responsabile per la creazione di standard in Europa;
o) HTTP (Hypertext Transfer Protocol), protocollo per il
trasferimento di pagine ipertestuali e risorse in rete
conforme allo standard RFC 2616 e successive
modificazioni;
p) LDAP (Lightweight Directory Access Protocol),
protocollo di rete utilizzato per rendere accessibili
informazioni in rete conforme allo standard RFC 3494 e
successive modificazioni.
Art. 2.
Ambito di applicazione e contenuto
1. La presente deliberazione stabilisce, ai sensi
dell'art. 40,comma 4 delle regole tecniche, le regole
per il riconoscimento e la verifica del documento
informatico cui i certificatori accreditati devono
attenersi al fine di ottenere e mantenere il
riconoscimento di
cui all'art. 28, comma 1 del testo unico.
2. Le disposizioni di cui al titolo II definiscono il
formato dei certificati qualificati e le informazioni
che in essi devono essere contenute.
3. Le disposizioni di cui al titolo III definiscono il
formato dei certificati elettronici di certificazione e
le informazioni che in essi devono essere contenute,
generati ai sensi dell'art. 13, comma 2, delle regole
tecniche, e il formato dei certificati elettronici di
marcatura temporale e le informazioni che in essi devono
essere contenute.
4. Le disposizioni di cui al titolo IV definiscono 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.
5. Le disposizioni di cui al titolo V definiscono i
formati e le modalità di accesso alle informazioni
sulla revoca e la sospensione dei certificati, ai sensi
dell'art. 29, comma 1, delle regole tecniche.
6. Le disposizioni di cui al titolo VI definiscono i
formati delle buste crittografiche destinate a contenere
gli oggetti sottoscritti con firma digitale.
7. Le disposizioni di cui al titolo VII definiscono i
requisiti delle applicazioni di verifica della firma
digitale di cui all'art. 10 delle regole tecniche.
Titolo II
PROFILO DEI CERTIFICATI QUALIFICATI
Art. 3.
Norme generali
1. Il profilo dei certificati é, se non diversamente
indicato,conforme alla specifica RFC 3280, capitolo 4,
recante «Profilo dei certificati e delle liste di revoca
dei certificati
nell'infrastruttura a chiave pubblica» e, se non
diversamente indicato, conforme alla specifica ETSI TS
101 862 V1.3.2, recante «Profilo dei certificati
qualificati».
Art. 4.
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 contiene
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 contiene i seguenti attributi:
a) givenName e surname (OID: 2.5.4.42 e 2.5.4.4) che
contengono rispettivamente nome di battesimo e 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 dell'organizzazione che ha
richiesto o autorizzato il rilascio del certificato del
titolare. Il codice identificativo é un codice
rilasciato dall'autorità governativa preposta dello
Stato indicato nell'attributo countryName. Se l'organizationName
non é applicabile, assume il valore «non presente»;
d) serialNumber (OID: 2.5.4.5) che contiene il codice
fiscale del titolare rilasciato dall'autorità 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. 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) in alternativa agli attributi specificati alla
lettera a), il certificato può contenere l'attributo
pseudonym (OID: 2.5.4.65), che contiene una qualsiasi
stringa univoca, a discrezione del titolare.
La stringa utilizzata non permette di risalire ai dati
identificativi del titolare. Se l'attributo pseudonym é
presente, l'attributo countryName assume il valore «IT»,
l'attributo organizationName assume il valore «non
presente», l'attributo serialNumber il valore
«pseudonimo» e gli attributi title e localityName non
sono presenti;
f) dnQualifier (OID: 2.5.4.46), contiene il codice
identificativo del titolare presso il certificatore.
Detto codice, assegnato dal certificatore, é univoco.
4. Il 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. L'eventuale codifica degli attributi title,
localityName, commonName e
organizational UnitName rispetta le seguenti regole:
a) title (OID: 2.5.4.12), contiene una indicazione della
qualifica specifica del titolare, quale l'appartenenza
ad ordini o collegi professionali, l'iscrizione ad albi
o il possesso di altre abilitazioni professionali,
ovvero i poteri di rappresentanza nell'ambito
dell'organizzazione specificata nell'attributo
organizationName. Nel caso in cui l'attributo
organizationName contenga un valore diverso da «non
presente», l'inserimento delle
informazioni nel title é richiesto dall'organizzazione
stessa. In caso contrario contiene informazioni
derivanti da autocertificazione effettuata dal titolare
ai sensi della normativa vigente;
b) localityName (OID: 2.5.4.7), contiene, nel caso in
cui l'attributo organizationName contenga un valore
diverso da «non presente», informazioni pertinenti
all'organizzazione specificata;
c) commonName (OID: 2.5.4.3), in aggiunta a surname e
givenName,contiene l'eventuale altro nome con il quale
il titolare é comunemente conosciuto;
d) organizationalUnitName (OID: 2.5.4.11), contiene
ulteriori informazioni inerenti all'organizzazione. Tale
attributo può comparire, al massimo, cinque volte.
5. Il certificato contiene inoltre le seguenti
estensioni:
a) keyUsage (OID: 2.5.29.15) che contiene esclusivamente
il valore nonRepudiation (bit 1 impostato a 1).
L'estensione é marcata critica;
b) certificatePolicies (OID: 2.5.29.32) che contiene l'OID
della Certificate Policy (CP) e l'Uniform 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
definisce una propria CP e tale OID é definito e
pubblicizzato dalcertificatore. Possono essere indicate
più Certificate Policy (CP).
L'URL configura un percorso assoluto per l'accesso alla
CRL.
L'estensione non é marcata critica;
c) CRLDistributionPoints (OID: 2.5.29.31) che contiene
l'URL che punta alle CRL/CSL pubblicate dal
certificatore dove eventualmente saranno disponibili le
informazioni relative alla revoca o sospensione del
certificato in questione. L'URL configura un percorso
assoluto per l'accesso alla CRL. Lo schema da utilizzare
per l'URL é HTTP oppure LDAP e consente lo scaricamento
anonimo della CRL. Nel caso vengano valorizzati più di
un URL per l'estensione, tali URL configurano percorsi
coerenti con l'ultima CRL/CSL pubblicata.
L'estensione non é marcata critica;
d) authorityKeyIdentifier (OID: 2.5.29.35) che contiene
almeno l'attributo keyIdentifier. L'estensione non é
marcata critica;
e) subjectKeyIdentifier (OID: 2.5.29.14) che contiene
almeno l'attributo keyIdentifier. L'estensione 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 «10»;
4) id-etsi-qcs-QcSSCD (OID: 0.4.0.1862.1.4).
L'estensione 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.
L'attributo dateOfBirth (OID: 1.3.6.1.5.5.7.9.1), se
presente, é codificato nel formato GeneralizedTime.
L'estensione 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 all'art. 10, un sistema OCSP per la
verifica della validità di un certificato, l'estensione
Authority InfoAccess
contiene un campo accessDescription con la descrizione
delle modalità di accesso al servizio OCSP, e contiene
i seguenti attributi:
1) accessMethod, che contiene l'identificativo
id-ad-ocsp (OID:
1.3.6.1.5.5.7.48.1);
2) accessLocation, che contiene l'URI che punta all'OCSP
Responder del certificatore, utilizzabile per effettuare
la verifica del certificato stesso. L'URI configura un
percorso assoluto per l'accesso all'OCSP Responder.
Nel caso in cui siano specificati più campi access
Description contenenti l'identificativo id-ad-ocsp
nell'attributo accessMethod,tali indicazioni configurano
diversi percorsi alternativi per l'interrogazione,
tramite OCSP, dello stato del certificato.
L'estensione non é marcata critica;
c) salvo quanto disposto all'art. 4, comma 5, lettera
f), gli eventuali ulteriori limiti d'uso di cui all'art.
43 delle regole tecniche sono inseriti nell'attributo
explicitText del campo
userNotice dell'estensione certificatePolicies;
d) ulteriori estensioni possono essere inserite nel
certificato purché conformi agli standard citati nella
presente deliberazione e non marcate critiche.
Titolo III
PROFILO DEI CERTIFICATI DI CERTIFICAZIONE E MARCATURA
TEMPORALE
Art. 5.
Profilo dei certificati di certificazione e marcatura
temporale
1. Se non diversamente previsto, il profilo dei
certificati éconforme alla specifica RFC 3280.
Art. 6.
Uso delle estensioni nei certificati di certificazione
1. I certificati di certificazione contengono le
seguenti estensioni:
a) keyUsage (OID 2.5.29.15), contiene i valori
keyCertSign e cRLSign (bit 5 e 6 impostati a 1).
L'estensione é marcata critica;
b) basicConstraints (OID 2.5.29.19), contiene il valore
CA=true.
L'estensione é marcata critica;
c) certificatePolicies (OID 2.5.29.32), contiene uno o
più identificativi delle policyIdentifier e le relative
URL del CPS. Può contenere l'OID generico previsto
dall'RFC 3280 (2.5.29.32.0).
L'estensione non é marcata critica;
d) CRLDistributionPoints (OID 2.5.29.31), contiene uno o
più URL di accesso a CRL/CSL. L'URL configura un
percorso assoluto per l'accesso alla CRL. L'estensione
non é marcata critica;
e) subjectKeyIdentifier (OID 2.5.29.14), contiene il
valore keyIdentifier. L'estensione non é marcata
critica.
2. Ulteriori estensioni possono essere inserite nel
certificato purché conformi agli standard citati nella
presente deliberazione e non marcate «critiche».
Art. 7.
Uso delle estensioni nei certificati di marcatura
temporale
1. I certificati di marcatura temporale contengono le
seguenti estensioni:
a) keyUsage (OID 2.5.29.15), contiene il valore
digitalSignature (bit 0 impostato a 1). L'estensione é
marcata critica;
b) extendedKeyUsage (OID 2.5.29.37), contiene il valore
keyPurposeId=timeStamping. L'estensione é marcata
critica;
c) certificatePolicies OID 2.5.29.32), contiene uno o
più identificativi delle policyIdentifier e le relative
URL del CPS.
L'estensione non é marcata critica;
d) authorityKeyIdentifier (OID 2.5.29.35), contiene
almeno un keyIdentifier. L'estensione non é marcata
critica;
e) subjectKeyIdentifier (OID 2.5.29.14), contiene almeno
un keyIdentifier. L'estensione non é marcata critica.
2. Ulteriori estensioni possono essere inserite nel
certificato purché conformemente agli standard citati
nella presente deliberazione e non marcate «critiche».
Titolo IV
REGOLE PER LA VALIDAZIONE TEMPORALE
Art. 8.
Regole per i servizi di validazione temporale
1. L'accesso 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 l'apertura, l'analisi e la
visualizzazione di 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. L'estensione 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, se
non definito a livello nazionale od europeo, é definito
e reso pubblico dal certificatore.
Titolo V
INFORMAZIONI SULLA REVOCA E SOSPENSIONE DEI CERTIFICATI
Art. 9.
Verifica dei certificati - CRL
1. Le informazioni sulla revoca e sospensione dei
certificati,pubblicate dai certificatori e disponibili
pubblicamente tramite liste di revoca e sospensione,
hanno un formato conforme alla specifica RFC 3280,
capitolo 5, esclusi i paragrafi 5.2.4 e 5.2.6.
2. Le liste di certificati revocati e sospesi sono
accessibili al pubblico tramite protocollo HTTP o LDAP.
Art. 10.
Verifica in tempo reale dei certificati - OCSP
1. Fermo restando quanto prescritto dall'art. 9, 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 alle specifica RFC
2560 e
successive modificazioni.
Art. 11.
Coerenza delle informazioni sulla revoca e sospensione
dei certificati
1. Se un certificatore mette a disposizione diversi
servizi perl'accesso 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 se ciò
é compatibile con la tecnologia utilizzata.
Titolo VI
FORMATI DI FIRMA
Art. 12.
Busta crittografica di firma
1. La busta crittografica destinata a contenere
l'oggetto sottoscritto é conforme, salvo i casi
previsti dai commi 8 e 9, alla specifica RFC 2315 (PKCS7
ver. 1.5).
2. La busta crittografica di cui al comma 1 é di tipo
signedData (OID: 1.2.840.113549.1.7.2).
3. Per la codifica della busta crittografica possono
essere utilizzati i formati ASN.1-DER (ISO 8824, 8825) o
BASE64 (RFC 1421).
4. Il documento da firmare é imbustato nel formato
originale,senza aggiunte in testa o in coda al formato
stesso.
5. Il nome del file firmato, ossia della busta, assume
l'ulteriore estensione «p7m».
6. Le buste crittografiche di cui al comma 5 possono
contenere a loro volta buste crittografiche. In questo
caso é applicata una ulteriore estensione «p7m».
7. L'eventuale presenza di attributi autenticati nella
busta crittografica non é considerata critica. La
gestione degli stessi non deve rappresentare un vincolo
per le applicazioni di verifica di cui all'art. 14.
8. Il CNIPA può stabilire, con apposito provvedimento,
ulteriori formati standard di busta crittografica,
riconosciuti a livello nazionale o internazionale,
conformi a specifiche pubbliche (PubliclyAvailable
Specification-PAS).
9. 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'art.
41 delle regole tecniche e nelle liste di revoca di cui
all'art. 29 del citato
provvedimento nel prodotto di verifica di cui al comma
precedente.
10. Fermo restando il rispetto delle condizioni previste
al comma 9, il CNIPA, consultando preventivamente le
autorità di settore e le associazioni di categoria
maggiormente rappresentative, valuta le richieste di
sottoscrizione dei protocolli d'intesa previsti dal
comma sopra citato avendo riguardo:
a) alla rilevanza delle esigenze che essi consentono di
soddisfare;
b) alla possibilità di assicurare un idoneo supporto e
un'adeguata diffusione sul mercato nazionale ed
internazionale dei prodotti che realizzano la struttura
informatica del documento sottoscritto, tali da essere
riconosciuti ed accettati quali standard
di riferimento;
c) alla necessità di evitare effetti negativi sulla
interoperabilità.
11. Le pubbliche amministrazioni possono accettare
documenti informatici sottoscritti con i formati di
firma di cui ai commi 8 e 9 e, nel caso ritengano
opportuno accettare uno o più di detti formati,
dovranno farne apposita menzione nei procedimenti
amministrativi cui si applicano e comunicarlo al CNIPA.
Le pubbliche amministrazioni garantiscono la gestione
del formato di cui al comma 1.
12. Il soggetto che sottoscrive il protocollo d'intesa
di cui al comma 9 indica al CNIPA gli indirizzi internet
dove é possibile ottenere, gratuitamente e liberamente,
quanto indicato alle lettere a) e d) del medesimo comma
9,
13. Il CNIPA rende disponibili sul proprio sito
internet: l'elenco dei formati oggetto di protocolli
d'intesa, gli indirizzi internet di cui al comma 12 e
gli eventuali formati di busta crittografica di cui al
comma 8.
14. In caso di inadempienza da parte del sottoscrittore
del protocollo d'intesa di quanto previsto ai commi 9 e
12, il CNIPA informa tempestivamente il soggetto
interessato e, nel caso lo stesso non ottemperi
rapidamente alla piena osservanza di quanto previsto,
revoca il protocollo d'intesa dandone pubblicità
nell'elenco di cui al comma 13 ed informandone
tempestivamente le pubbliche amministrazioni di cui al
comma 11.
Art. 13.
Regole per l'apposizione di firme multiple
1. Una stessa busta crittografica può contenere più
firme digitali. Queste ultime sono identificate in:
a) «Firme parallele», in tal caso il sottoscrittore,
utilizzando la propria chiave privata, firma solo i dati
contenuti nella busta stessa (OID: 1.2.840.113549.1.7.1)
;
b) «Controfirme», in tal caso il sottoscrittore,
utilizzando la propria chiave privata, firma una
precedente firma (OID:
1.2.840.113549.1.9.6) apposta da altro sottoscrittore.
2. Il formato delle firme multiple definite nel presente
articolo é conforme alla specifica RFC 2315.
3. L'apposizione di firme multiple di cui al presente
articolo non comporta l'applicazione di ulteriori
estensioni al file firmato,oltre alla prima.
Titolo VII
APPLICAZIONI DI VERIFICA DELLA FIRMA
Art. 14.
Requisiti delle applicazioni di verifica
1. Le applicazioni di verifica della firma digitale
indicate o distribuite dai certificatori accreditati, ai
sensi dell'art. 10 delle regole tecniche, oltre a
gestire correttamente i certificati elettronici il cui
formato é stabilito nella presente deliberazione,
riconoscono i seguenti elementi dei certificati
qualificati:
a) l'attributo DateOfBirth dell'estensione
SubjectDirectoryAttributes;
b) le seguenti qcStatements:
1) id-etsi-qcs-QcCompliance (OID: 0.4.0.1862.1.1);
2) id-etsi-qcs-QcLimitValue (OID: 0.4.0.1862.1.2);
3) id-etsi-qcs-QcRetentionPeriod (OID: 0.4.0.1862. 1.3);
4) id-etsi-qcs-QcSSCD (OID: 0.4.0.1862.1.4).
2. Oltre a quanto prescritto al precedente comma 1, le
applicazioni di verifica della firma digitale indicate o
distribuite dai certificatori accreditati gestiscono i
formati di firma e le buste crittografiche di cui
all'art. 12, commi da 1 a 7, e all'art. 13.
3. Le applicazioni di cui al presente articolo
gestiscono correttamente il processo di verifica delle
firme digitali prodotte precedentemente all'entrata in
vigore della presente deliberazione che non perdono la
loro specifica validità.
Titolo VIII
DISPOSIZIONI FINALI E TRANSITORIE
Art. 15.
Operatività
1. La presente deliberazione entra in vigore a decorrere
da nove mesi dalla data di pubblicazione nella Gazzetta
Ufficiale.
2. L'obbligo di utilizzo della codifica UTF-8, previsto
nella RFC 3280, ha effetto a decorrere da nove mesi
dall'entrata in vigore della presente deliberazione.
3. L'obbligo di cui all'art. 4, comma 5, lettera f) ha
effetto a decorrere da nove mesi dall'entrata in vigore
della presente deliberazione. Fino a tale data, se il
certificato non contiene nell'estensione qcStatement i
valori id-etsi-qcs-QcCompliance e id-etsi-qcs-QcSSCD,
almeno una delle policy indicate nel certificato indica
esplicitamente che il certificato é un certificato
qualificato e che la chiave privata, corrispondente alla
chiave
pubblica presente nel certificato qualificato, é
memorizzata su un dispositivo sicuro per la generazione
della firma conforme alle normative vigenti.
4. Durante il periodo di proroga di cui al comma 3, se
il certificato non contiene nell'estensione qcStatement
il valoreid-etsi-qcs-QcLimitValue, gli eventuali limiti
di negoziazione sono inseriti nell'attributo
explicitText del campo userNotice.
5. Le disposizioni di cui all'art. 14 hanno effetto a
decorrere da nove mesi dall'entrata in vigore della
presente deliberazione.
6. I certificati elettronici emessi precedentemente
all'entrata in vigore della presente deliberazione
rimangono validi fino alla scadenza prevista al momento
dell'emissione, salvo precedente revoca o sospensione.
Roma, 17 febbraio 2005
Il presidente: Zoffoli |
