Gazzetta n. 51 del 3 marzo 2005 (vai al sommario)
CENTRO NAZIONALE PER L'INFORMATICA NELLA PUBBLICA AMMINISTRAZIONE
DELIBERAZIONE 17 febbraio 2005
Regole per il riconoscimento e la verifica del documento informatico. (Deliberazione n. 4/2005).
IL COLLEGIO

Visto il decreto legislativo 12 febbraio 1993, n. 39, cosi' 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.
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, unita' informativa contenuta nel certificato. Puo' essere composta da diverse unita' 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 standard internazionali 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 e' produrre standard sulle telecomunicazioni. E' 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, cosi' come definiti nel titolo IV delle regole tecniche.
5. Le disposizioni di cui al titolo V definiscono i formati e le modalita' 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.
 
Art. 3.
Norme generali
1. Il profilo dei certificati e', 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 e' 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 e' un codice rilasciato dall'autorita' governativa preposta dello Stato indicato nell'attributo countryName. Se l'organizationName non e' applicabile, assume il valore «non presente»;
d) serialNumber (OID: 2.5.4.5) che contiene il codice fiscale del titolare rilasciato dall'autorita' 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 e' preceduto dal country code ISO 3166 e dal carattere «:» (in notazione esadecimale «0x3A»);
e) in alternativa agli attributi specificati alla lettera a), il certificato puo' 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 e' 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, e' univoco.
4. Il campo subjectDN (Dati identificativi del titolare) del certificato puo' contenere altri attributi purche' 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 e' 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 e' comunemente conosciuto;
d) organizationalUnitName (OID: 2.5.4.11), contiene ulteriori informazioni inerenti all'organizzazione. Tale attributo puo' 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 e' 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 e' definito e pubblicizzato dal certificatore. Possono essere indicate piu' Certificate Policy (CP). L'URL configura un percorso assoluto per l'accesso alla CRL. L'estensione non e' 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 e' HTTP oppure LDAP e consente lo scaricamento anonimo della CRL. Nel caso vengano valorizzati piu' di un URL per l'estensione, tali URL configurano percorsi coerenti con l'ultima CRL/CSL pubblicata. L'estensione non e' marcata critica;
d) authorityKeyIdentifier (OID: 2.5.29.35) che contiene almeno l'attributo keyIdentifier. L'estensione non e' marcata critica;
e) subjectKeyIdentifier (OID: 2.5.29.14) che contiene almeno l'attributo keyIdentifier. L'estensione non e' 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 e' pari o superiore a «10»;
4) id-etsi-qcs-QcSSCD (OID: 0.4.0.1862.1.4).
L'estensione non e' marcata critica.
6. Il certificato di sottoscrizione puo' 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, e' codificato nel formato GeneralizedTime. L'estensione non e' 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 validita' di un certificato, l'estensione Authority InfoAccess contiene un campo accessDescription con la descrizione delle modalita' 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 piu' 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 e' 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 purche' conformi agli standard citati nella presente deliberazione e non marcate critiche.
 
Art. 5.
Profilo dei certificati di certificazione e marcatura temporale
1. Se non diversamente previsto, il profilo dei certificati e' 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 e' marcata critica;
b) basicConstraints (OID 2.5.29.19), contiene il valore CA=true. L'estensione e' marcata critica;
c) certificatePolicies (OID 2.5.29.32), contiene uno o piu' identificativi delle policyIdentifier e le relative URL del CPS. Puo' contenere l'OID generico previsto dall'RFC 3280 (2.5.29.32.0). L'estensione non e' marcata critica;
d) CRLDistributionPoints (OID 2.5.29.31), contiene uno o piu' URL di accesso a CRL/CSL. L'URL configura un percorso assoluto per l'accesso alla CRL. L'estensione non e' marcata critica;
e) subjectKeyIdentifier (OID 2.5.29.14), contiene il valore keyIdentifier. L'estensione non e' marcata critica.
2. Ulteriori estensioni possono essere inserite nel certificato purche' 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 e' marcata critica;
b) extendedKeyUsage (OID 2.5.29.37), contiene il valore keyPurposeId=timeStamping. L'estensione e' marcata critica;
c) certificatePolicies OID 2.5.29.32), contiene uno o piu' identificativi delle policyIdentifier e le relative URL del CPS. L'estensione non e' marcata critica;
d) authorityKeyIdentifier (OID 2.5.29.35), contiene almeno un keyIdentifier. L'estensione non e' marcata critica;
e) subjectKeyIdentifier (OID 2.5.29.14), contiene almeno un keyIdentifier. L'estensione non e' marcata critica.
2. Ulteriori estensioni possono essere inserite nel certificato purche' conformemente agli standard citati nella presente deliberazione e non marcate «critiche».
 
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 e' 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 e' stato generato. Detto identificativo, se non definito a livello nazionale od europeo, e' definito e reso pubblico dal certificatore.
 
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 facolta' 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 per l'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 modalita' devono essere coerenti se cio' e' compatibile con la tecnologia utilizzata.
 
Art. 12.
Busta crittografica di firma
1. La busta crittografica destinata a contenere l'oggetto sottoscritto e' 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 e' 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 e' 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 e' applicata una ulteriore estensione «p7m».
7. L'eventuale presenza di attributi autenticati nella busta crittografica non e' considerata critica. La gestione degli stessi non deve rappresentare un vincolo per le applicazioni di verifica di cui all'art. 14.
8. Il CNIPA puo' stabilire, con apposito provvedimento, ulteriori formati standard di busta crittografica, riconosciuti a livello nazionale o internazionale, conformi a specifiche pubbliche (Publicly Available Specification-PAS).
9. Il CNIPA puo' 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 disponibilita' 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 disponibilita' 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 disponibilita', 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 capacita' 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 autorita' 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 possibilita' 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 necessita' di evitare effetti negativi sulla interoperabilita'.
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 piu' 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 e' 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 pubblicita' 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 puo' contenere piu' 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 e' 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.
 
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 e' 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 validita'.
 
Art. 15.
Operativita'
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 e' un certificato qualificato e che la chiave privata, corrispondente alla chiave pubblica presente nel certificato qualificato, e' 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 valore id-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
 
Gazzetta Ufficiale Serie Generale per iPhone