Certification Practice Statement Certificati SSL Server e Code Signing Versione: 2.3 Data: 9 dicembre 2014
Certification Practice Statement Certificati SSL Server e Code Signing Redatto da: Verificato da: Verificato da: Verificato da: Verificato da: Approvato da: Adriano Santoni Responsabile Sicurezza Fabio Omenigrandi Responsabile Servizi Tecnici Rosalia Valsecchi Responsabile Certificazione Roberto Ravazza Responsabile Produzione Giorgio Marzorati Responsabile Auditing Giorgio Girelli Direttore Generale Data Data Data Data Data Data Codice documento: Distribuzione: CAACT-03-01-05 PUBBLICA
Storia delle modifiche apportate DATA VERS. PARAGRAFI MODIFICHE AUTORE 14 dicembre 2005 1 - Prima versione del documento FP 24 giugno 2009 2 tutti Revisione dell intero documento; FP, AS ristrutturazione secondo RFC 3647 19 novembre 2009 2.0.1 1.3.1 Cambiato il nome del Presidente AS 13 maggio 2010 2.0.2 3.4 Rimossa la frase relativa all eventuale inserimento di indirizzi IP privati nei certificati (possibilità non prevista) 18 maggio 2010 2.0.3 4.2, 8.1, 8.2, 8.4, 8.5, 8.6, 9.5.2, 9.8 Precisazioni e integrazioni relative alle RA 18 maggio 2010 2.0.3 1.3.1 Aggiornato l indirizzo di Actalis; corretto il nome del Presidente 23 giugno 2011 2.0.4 1.3.1, 3.1, 4.1 Modificato il rappresentante legale di Actalis. Aggiunti chiarimenti relativi a I&A e verifiche per i certificati wildcard e multi-san 28 settembre 2011 2.1.0 Tutti Introdotta PKI a due livelli. Aggiunti dettagli sulla gestione delle chiavi di Root CA e Sub CA. Necessità di autenticazione a due fattori per le utenze che consentono l emissione dei certificati. I numeri di serie devono includere almeno 8 byte random. SHA256 usato per la firma dei certificati e delle CRL. Aggiornate lunghezze minime delle chiavi. 19 settembre 2013 2.2.0 Tutti Aggiornato frontespizio secondo l attuale organizzazione. Precisato in 5.1 che il data center di Actalis è gestito da Aruba. Diverse revisioni e precisazioni per conformità alle linee guida del CAB Forum (BR+EVCG) e alla norma ETSI TS 102 042. 8 ottobre 2013 2.2.1 Tutti Dichiarazione esplicita di rispetto dei [BR] e delle [EVCG]. Integrazione elenco delle circostanze per la revoca. Revoca immediata per attività criminali svolte col certificato. Dual control nell emissione dei certificati. Altre precisazioni. 16 ottobre 2013 2.2.2 3.6, 7.1, 6.10.3 Correzione refusi. La massima durata dei certificati SSL Server EV è 24 mesi. Il titolare deve assicurare la riservatezza del PIN o password di attivazione della propria chiave. Policy OID = anypolicy nel certificato della SubCA. 21 ottobre 2013 2.2.3 4.9.4, 9.5.3 Precisazioni sulla revoca. Precisazioni sugli obblighi del titolare. AS AS AS AS AS AS AS AS AS Copyright Actalis S.p.A. Pagina 2 di 51 9 dicembre 2014
DATA VERS. PARAGRAFI MODIFICHE AUTORE 13 novembre 2013 2.2.4 Diversi Aggiornato il nome dell Amministratore di Actalid nel par 1.3.1. Nuovo par 4.13 su segnalazione problemi sui certificati e relativa gestione. Modifica al par 1.3.2 per introduzione Enterprise RA. Introdotti profili OV nel par 1.4 e nel capitolo 7. Modificato il 3.1 per maggiore chiarezza. Precisazioni nel par 3.3 sulle verifiche. Precisazioni sull uso di CNames per l accesso a CRL e al servizio OCSP. 14 febbraio 2014 2.2.5 Diversi Precisazione sulla conformità ai requisiti del CAB Forum all inizio del capitolo 3. Precisazione sugli IDN. 03 settembre 2014 2.2.6 3.1.1, 4.13, 6.3.3 Precisato che gli hostname non sono ammessi nei certificati per Code Signing e che un certificato per Code Signing emesso erroneamente con un hostname all interno sarà revocato. Possibilità di inviare segnalazioni ad Actalis anche per telefono. La lunghezza chiavi utente di 1024 bit non è più consentita. 20 ottobre 2014 2.2.7 Diversi Supporto per i certificati di classe DV AS (Domain Validated). Firma digitale accettata come mezzo per verificare l identità individuale. Correzione di refusi e alcune precisazioni. 9 dicembre 2014 2.3 Diversi Correzione refusi. AS AS AS AS Copyright Actalis S.p.A. Pagina 3 di 51 9 dicembre 2014
Sommario 1. INTRODUZIONE... 7 1.1 SCOPO DEL DOCUMENTO... 7 1.2 IDENTIFICAZIONE DEL DOCUMENTO... 7 1.3 PARTECIPANTI ALLA PKI... 7 1.3.1 Certification Authorities... 7 1.3.1.1 1.3.1.2 Root Certification Authority... 8 Subordinate Certification Authority... 8 1.3.2 Registration Authorities... 8 1.3.3 Utenti finali (titolari)... 9 1.3.4 Relying parties... 9 1.4 USO DEI CERTIFICATI... 9 1.5 AMMINISTRAZIONE DEL CPS... 10 1.6 DEFINIZIONI E ACRONIMI... 10 1.7 RIFERIMENTI... 11 2. PUBBLICAZIONI E REPOSITORY...12 2.1 GESTIONE DEL REPOSITORY... 12 2.2 INFORMAZIONI PUBBLICATE... 12 2.3 TEMPI E FREQUENZA DELLE PUBBLICAZIONI... 12 2.4 CONTROLLO DEGLI ACCESSI... 12 3. IDENTIFICAZIONE ED AUTENTICAZIONE (I&A)...13 3.1 REGOLE DI NAMING... 13 3.1.1 Per tutte le classi di certificato... 13 3.1.2 Per i certificati di classe EV... 14 3.1.3 Per i certificati di classe DV... 14 3.2 VALIDAZIONE INIZIALE DELL IDENTITÀ... 14 3.2.1 Dimostrazione del possesso della chiave privata... 14 3.2.2 Autenticazione dell organizzazione richiedente... 14 3.2.3 Autenticazione delle identità individuali... 15 3.3 ULTERIORI VERIFICHE SVOLTE DALLA CA... 15 3.3.1 Per tutte le classi di certificato SSL Server... 15 3.3.1.1 Internationalized Domain Names (IDN)... 15 3.3.2 Per i certificati di classe EV... 16 3.4 INFORMAZIONI NON VERIFICATE DALLA CA... 16 3.5 I&A PER LE RICHIESTE DI RINNOVO... 16 3.6 I&A PER LE RICHIESTE DI SOSPENSIONE O REVOCA... 17 4. REQUISITI OPERATIVI DI GESTIONE DEI CERTIFICATI...17 4.1 RICHIESTA DEL CERTIFICATO... 17 4.2 ELABORAZIONE DELLE RICHIESTE... 19 4.3 EMISSIONE DEL CERTIFICATO... 19 4.4 ACCETTAZIONE DEL CERTIFICATO... 19 4.5 USO DELLA COPPIA DI CHIAVI E DEL CERTIFICATO... 20 4.6 RINNOVO DEL CERTIFICATO... 20 4.7 RIGENERAZIONE DELLA CHIAVE... 20 4.8 MODIFICA DEL CERTIFICATO... 20 4.9 SOSPENSIONE E REVOCA DEL CERTIFICATO... 21 4.9.1 Circostanze per la sospensione... 21 4.9.2 Chi può richiedere la sospensione... 21 4.9.3 Procedura per la sospensione... 21 4.9.4 Circostanze per la revoca... 22 4.9.5 Chi può richiedere la revoca... 23 Copyright Actalis S.p.A. Pagina 4 di 51 9 dicembre 2014
4.9.6 Procedura per la sospensione o revoca... 23 4.9.7 Frequenza di emissione della CRL... 23 4.10 SERVIZI INFORMATIVI SULLO STATO DEL CERTIFICATO... 23 4.10.1 Caratteristiche operative... 23 4.10.2 Disponibilità del servizio... 24 4.11 CESSAZIONE DEL CONTRATTO... 24 4.12 KEY ESCROW E KEY RECOVERY... 24 4.13 SEGNALAZIONE DI PROBLEMI... 25 5. MISURE DI SICUREZZA FISICA ED OPERATIVA...25 5.1 SICUREZZA FISICA... 25 5.2 SICUREZZA DELLE PROCEDURE... 26 5.3 SICUREZZA DEL PERSONALE... 26 5.4 LOGGING DEGLI EVENTI... 26 5.5 ARCHIVIAZIONE DEI DATI... 27 5.6 RINNOVO DELLA CHIAVE DELLA CA... 27 5.6.1 Root CA... 27 5.6.2 SubCA... 27 5.7 COPIE DI SICUREZZA (BACKUP)... 27 5.8 COMPROMISSIONE E DISASTER RECOVERY... 27 5.9 CESSAZIONE DELLA CA... 28 6. MISURE DI SICUREZZA TECNICA...28 6.1 GENERAZIONE DELLE CHIAVI... 28 6.1.1 Root CA... 28 6.1.2 Sub CA... 29 6.1.3 Titolari... 29 6.2 DISTRIBUZIONE DELLA CHIAVE PUBBLICA... 29 6.2.1 Root CA... 29 6.2.2 Sub CA... 29 6.2.3 Titolari... 29 6.3 LUNGHEZZA DELLE CHIAVI... 29 6.3.1 Root CA... 29 6.3.2 Sub CA... 29 6.3.3 Titolari... 29 6.4 PARAMETRI DI GENERAZIONE E QUALITÀ DELLE CHIAVI... 30 6.4.1 Root CA... 30 6.4.2 Sub CA... 30 6.4.3 Titolari... 30 6.5 KEY USAGE (ESTENSIONE X.509V3)... 30 6.5.1 Root CA... 30 6.5.2 Sub CA... 30 6.5.3 Titolari... 30 6.6 PROTEZIONE DELLA CHIAVE PRIVATA... 30 6.6.1 Root CA... 30 6.6.2 Sub CA... 31 6.6.3 Titolari... 31 6.7 STANDARD DI SICUREZZA DEI MODULI CRITTOGRAFICI... 31 6.8 MULTI-PERSON CONTROL (N DI M) DELLA CHIAVE PRIVATA... 31 6.8.1 Root CA... 31 6.8.2 Sub CA... 31 6.8.3 Titolari... 31 6.9 BACKUP E RIPRISTINO DELLA CHIAVE PRIVATA... 31 6.9.1 Root CA... 31 6.9.2 Sub CA... 31 6.9.3 Titolari... 32 6.10 DATI DI ATTIVAZIONE DELLA CHIAVE... 32 Copyright Actalis S.p.A. Pagina 5 di 51 9 dicembre 2014
6.10.1 Root CA... 32 6.10.2 Sub CA... 32 6.10.3 Titolari... 32 6.11 REQUISITI DI SICUREZZA DEGLI ELABORATORI... 32 6.12 SICUREZZA DI RETE... 32 6.13 RIFERIMENTO TEMPORALE... 33 7. PROFILO DEI CERTIFICATI E DELLE CRL...34 7.1 PROFILO DEL CERTIFICATO... 34 7.1.1 Root CA... 34 7.1.2 Sub CA... 35 7.1.3 SSL Server EV (Extended Validation)... 36 7.1.4 Code Signing EV (Extended Validation)... 37 7.1.5 SSL Server OV (Organization Validated)... 38 7.1.6 SSL Server Wildcard OV (Organization Validated)... 39 7.1.7 Code Signing OV (Organization Validated)... 40 7.1.8 SSL Server DV (Domain Validated)... 41 7.1.9 SSL Server Wildcard DV (Domain Validated)... 42 7.2 PROFILO DELLA CRL... 43 8. VERIFICHE DI CONFORMITÀ...43 8.1 FREQUENZA E CIRCOSTANZE DALLE VERIFICHE... 43 8.1.1 Root CA... 43 8.1.2 Sub CA... 43 8.1.3 Registration Authorities... 43 8.2 IDENTITÀ E QUALIFICAZIONE DEGLI ISPETTORI... 44 8.3 RELAZIONI TRA LA CA E GLI ISPETTORI... 44 8.4 ARGOMENTI COPERTI DALLE VERIFICHE... 44 8.5 AZIONI CONSEGUENTI ALLE NON-CONFORMITÀ... 44 8.6 COMUNICAZIONE DEI RISULTATI DELLE VERIFICHE... 44 9. CONDIZIONI GENERALI DEL SERVIZIO...45 9.1 TARIFFE DEL SERVIZIO... 45 9.2 RESPONSABILITÀ FINANZIARIA... 45 9.3 TUTELA DELLA RISERVATEZZA E TRATTAMENTO DEI DATI PERSONALI... 45 9.3.1 Informativa ai sensi del D.Lgs. 196/03... 45 9.3.2 Archivi contenenti dati personali... 46 9.3.3 Misure di tutela della riservatezza... 46 9.4 DIRITTI DI PROPRIETÀ INTELLETTUALE... 46 9.5 OBBLIGHI E GARANZIE... 46 9.5.1 Certification Authority... 46 9.5.2 Registration Authority... 47 9.5.3 Titolari di certificati... 47 9.5.4 Relying party... 48 9.6 ESCLUSIONE DI GARANZIE... 48 9.7 LIMITAZIONI DI RESPONSABILITÀ... 48 9.8 RISARCIMENTI... 48 9.9 DURATA E TERMINAZIONE... 49 9.10 COMUNICAZIONI... 49 9.11 EMENDAMENTI... 49 9.12 RISOLUZIONE DELLE DISPUTE... 49 9.13 LEGGE APPLICABILE... 49 9.14 CONFORMITÀ CON LE NORME APPLICABILI... 49 9.15 FORZA MAGGIORE... 49 9.16 LIVELLI DI SERVIZIO... 50 Copyright Actalis S.p.A. Pagina 6 di 51 9 dicembre 2014
1. Introduzione 1.1 Scopo del documento Actalis S.p.A., primario certificatore attivo dal 2002, accreditato presso l AgID, offre diverse tipologie di certificati e relativi servizi di gestione, oltre a diversi altri servizi e soluzioni (www.actalis.it). Un certificato lega una chiave pubblica ad un insieme d informazioni che identificano un soggetto (individuo od organizzazione). Tale soggetto, titolare del certificato, possiede ed utilizza la corrispondente chiave privata. Il certificato viene generato e fornito al titolare da una terza parte fidata detta Certification Authority (CA). Il certificato è firmato digitalmente dalla CA. L affidabilità di un certificato, ovvero l associazione certa tra una data chiave pubblica ed il soggetto identificato, dipende anche dalle procedure operative del certificatore, dagli obblighi e responsabilità che si assumono certificatore e titolare, dalle misure di sicurezza fisiche e logiche del certificatore. Tali aspetti sono descritti in un documento pubblico Certification Practice Statement (CPS). Questo documento è il CPS di Actalis relativo all emissione e gestione di due tipi di certificati: certificati per SSL Server certificati per Code Signing La struttura e di questo CPS si basa sulla specifica pubblica [RFC 3647]. Nell ambito del servizio di CA descritto in questo CPS, Actalis rispetta i Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates versione 1.1 pubblicati su http://www.cabforum.org. In caso di conflitto tra il presente documento e tali Requisiti, questi ultimi hanno la precedenza. Inoltre, per quanto riguarda i certificati di classe EV (vedere la sezione 1.4), Actalis rispetta le CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates versione 1.3 pubblicate sul sito http://www.cabforum.org. In caso di conflitto tra il presente documento e tali Linee Guida, queste ultime hanno la precedenza. 1.2 Identificazione del documento Questo documento è il Certification Practice Statement (CPS) relativo ai Certificati SSL Server e Code Signing emessi da Actalis S.p.A. La versione e la data di ultima revisione del documento sono indicate nella sua prima pagina. Questo documento è pubblicato sul sito web di Actalis in due lingue: Italiano e Inglese. Nel caso di difformità tra le due versioni, fa fede la versione in Italiano. 1.3 Partecipanti alla PKI 1.3.1 Certification Authorities La Certification Authority (CA) è il soggetto terzo e fidato che emette i certificati, firmandoli con la propria chiave privata (chiave di CA). La CA, inoltre, gestisce lo stato dei certificati. La PKI (Public Key Infrastructure) di Actalis su cui si basa il servizio di emissione e gestione dei certificati SSL Server e Code Signing è organizzata su due livelli, come mostrato nello schema seguente: Copyright Actalis S.p.A. Pagina 7 di 51 9 dicembre 2014
Root CA Sub CA 1 Sub CA 2 Sub CA... La Root CA è usata esclusivamente per emettere i certificati di SubCA e le relative CRL, ed è mantenuta off-line quando non in uso. Le Sub CA sono le CA che emettono i certificati degli utenti finali. Nell ambito del servizio qui descritto, entrambi i ruoli (Root CA e Sub CA) sono svolti dalla società Actalis S.p.A. (in seguito solo Actalis ), identificata come segue: Denominazione sociale: Actalis S.p.A. Indirizzo della sede legale: Via dell Aprica, 18 20158 Milano Legale rappresentante: Simone Braccagni (Amministratore Delegato) P.IVA e Codice Fiscale: 03358520967 N di telefono (centralino): +39 02 68825.1 DUNS number: 440-489-735 ISO Object Identifier (OID): 1.3.159 Sito web generale (informativo): http://www.actalis.it Sito web del servizio di certificazione: https://portal.actalis.it Indirizzo di posta elettronica (informativo): info@actalis.it 1.3.1.1 Root Certification Authority La Root CA è gestita da Actalis S.p.A. (cfr. il paragrafo 1.3.1). 1.3.1.2 Subordinate Certification Authority Esiste al momento una sola Sub CA, gestita da Actalis S.p.A. (cfr. il paragrafo 1.3.1). La possibilità ed opportunità di attivare ulteriori Sub CA, non gestite da Actalis, sarà valutata più avanti alla luce dei vincoli e requisiti imposti dalle norme e standard di riferimento del servizio. 1.3.2 Registration Authorities La Registration Authority (RA) è la persona, struttura od organizzazione che svolge le attività di: accoglimento e validazione delle richieste di emissione e gestione dei certificati; registrazione del soggetto richiedente e dell organizzazione di appartenenza; autorizzazione all emissione, da parte della CA, del certificato richiesto. Per i certificati di classe EV (Extended Validation), l attività di RA è svolta esclusivamente da Actalis. Copyright Actalis S.p.A. Pagina 8 di 51 9 dicembre 2014
Per i certificati di classe OV (Organization Validated) e DV (Domain Validated), l attività di RA può essere svolta dal Titolare in qualità di Enterprise RA, ove ne sussistano le condizioni, limitatamente ai domini Internet di pertinenza del Titolare. 1.3.3 Utenti finali (titolari) Gli utenti finali del servizio, ovvero i titolari dei certificati, sono le organizzazioni o enti che richiedono un certificato per SSL Server o per la firma digitale di software (code signing) e che detengono la corrispondente chiave privata. In particolare, con riferimento alla classificazione riportata nel 7.2 delle [EVCG], Actalis fornisce certificati ai seguenti tipi di organizzazioni: Private Organization (aziende private) Government Entity (enti pubblici) Con titolare del certificato si intende l entità chiamata Subscriber o Subject in [POLREQ] ed [EVCG]. In ogni caso, il titolare del certificato è una persona giuridica, non una persona fisica. Il contratto con la CA viene normalmente stipulato dal soggetto che diverrà titolare del certificato, il quale dunque coincide col cliente ( Customer ); è comunque ammesso che il cliente agisca in nome e per conto del titolare del certificato, circostanza che deve essere dimostrata in sede di richiesta (vedere la sezione 3.2.2). 1.3.4 Relying parties Le Relying Parties sono tutti i soggetti che fanno affidamento sulle informazioni contenute nel certificato. Nel caso dei certificati per SSL Server, si tratta degli utenti del sito web interessato. Nel caso dei certificati per Code Signing, si tratta degli utilizzatori del software firmato. 1.4 Uso dei certificati Il certificato SSL Server è usato per abilitare il protocollo TLS/SSL su uno o più siti web. Il certificato di Code Signing è usato per la firma digitale di codice eseguibile. Ogni altro uso dei certificati emessi da Actalis sulla base di questo CPS è proibito e può comportare, qualora Actalis ne venga a conoscenza, la revoca del certificato. Si assume che il cliente possegga le competenze e gli strumenti necessari per l uso del certificato. In caso contrario, Actalis è disponibile a fornire assistenza e consulenza al riguardo. La seguente tabella indica le classi e policy dei certificati emessi in conformità al presente CPS, e i requisiti CAB Forum applicabili. Ogni policy è identificata da un distinto OID (Object IDentifier) sotto l arco 1.3.159: Classe Policy di certificato OID Requisiti CABF EV SSL Server EV (Extended Validation) 1.3.159.1.17.1 [BR], [EVCG] EV Code Signing EV (Extended Validation) 1.3.159.1.18.1 [BR], [EVCG] OV SSL Server WildCard OV (Organization Validated) 1.3.159.1.19.1 [BR] OV SSL Server OV (Organization Validated) 1.3.159.1.20.1 [BR] OV Code Signing OV (Organization Validated) 1.3.159.1.21.1 [BR] DV SSL Server DV (Domain Validated) 1.3.159.1.22.1 [BR] DV SSL Server WildCard DV (Domain Validated) 1.3.159.1.23.1 [BR] Copyright Actalis S.p.A. Pagina 9 di 51 9 dicembre 2014
Lo OID che identifica la policy del certificato è contenuto nell estensione CertificatePolicies del certificato, come dettagliato nella sezione 7. 1.5 Amministrazione del CPS Questo CPS è redatto, pubblicato ed aggiornato da Actalis S.p.A. Richieste di informazioni o chiarimenti sul presente CPS possono essere inoltrate tramite posta elettronica all indirizzo cps-admin@actalis.it. Actalis attua una revisione periodica dei processi di certificazione che include e responsabilità per la manutenzione del CPS. Questo CPS e le certificate policy (CP) qui definite sono approvate dalla Direzione di Actalis, su raccomandazione del Responsabile del CPS, previo consulto con le funzioni aziendali interessate, tenendo conto di quanto indicato al 8.1 della norma ETSI TS 101 042 [POLREQ]. 1.6 Definizioni e acronimi AgID ARL CA CCIAA CNAME CNIPA CPS CRL CSR Agenzia per l Italia Digitale (ex DigitPA) Authority Revocation List Certification Authority Camera di Commercio, Industria, Agricoltura e Artigianato Canonical Name (vedere https://en.wikipedia.org/wiki/cname_record) Centro Nazionale per l Informatica nella Pubblica Amministrazione Certification Practice Statement Certificate Revocation List Certificate Signing Request DigitPA Nuovo nome del CNIPA come stabilito dal Dlgs 1 dicembre 2009, n.177 DN DV EV FIPS FQDN HSM HTTP I&A IDN ISO LDAP OCSP OID OV PDF PKI Distinguished Name Domain (Control) Validated Extended Validation Federal Information Processing Standard Fully Qualified Domain Name Hardware Security Module Hyper-Text Transfer Protocol Identificazione e Autenticazione Internationalized Domain Name International Standards Organization Lightweight Directory Access Protocol On-line Certificate Status Protocol Object Identifier Organization Validated Portable Document Format Public Key Infrastructure Copyright Actalis S.p.A. Pagina 10 di 51 9 dicembre 2014
RA SAN SSL TLS TVCC UPS VMD Registration Authority SubjectAlternativeNames (estensione del certificato) Secure Sockets Layer Transport layer Security TV a Circuito Chiuso Uninterruptable Power Supply Video Motion Detection 1.7 Riferimenti [DLGS196] Decreto Legislativo 30 giugno 2003, n. 196, Codice in materia di protezione dei dati personali, pubblicato nel Supplemento Ordinario n.123 della Gazzetta Ufficiale n. 174, 29 luglio 2003. [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. (http://www.ietf.org/rfc/rfc2251.txt) [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998. (http://www.ietf.org/rfc/rfc2314.txt) [RFC2560] [RFC2616] [RFC2818] [RFC3647] [RFC5280] [X.509] [POLREQ] [BR] [EVCG] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. Adams, "Online Certificate Status Protocal - OCSP", June 1999. (http://www.ietf.org/rfc/rfc2560.txt) [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners- Lee, "Hypertext Transfer Protocol, HTTP/1.1", RFC 2616, June 1999. (http://www.ietf.org/rfc/rfc2616.txt) Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. (http://www.ietf.org/rfc/rfc2818.txt) Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. (http://www.ietf.org/rfc/rfc3647.txt) Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. (http://www.ietf.org/rfc/rfc5280.txt) ITU-T Recommendation X.509 (2005) ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks. (http://www.iso.ch) ETSI TS 101 042: Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates, v2.2.1 (2011-12) CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly- Trusted Certificates, Version 1.1. CA/Browser Forum, Guidelines For The Issuance And Management Of Extended Validation Certificates, Version 1.3 Copyright Actalis S.p.A. Pagina 11 di 51 9 dicembre 2014
2. Pubblicazioni e repository Con repository si intende un insieme di archivi o registri on-line contenenti informazioni di interesse pubblico relative ai certificati e al servizio di emissione e gestione degli stessi descritto in questo CPS. 2.1 Gestione del repository Il repository di Actalis è costituito da: sito web della CA (www.actalis.it ed altri siti di Actalis in esso indicati) directory server della CA (ldap://ldap03.actalis.it) Nota: per ragioni di bilanciamento di carico, il servizio di directory è distribuito su più server con indirizzi differenti, per cui l hostname inserito nei certificati può essere diverso da ldap03; si tratta comunque di un CNAME. La CA gestisce in proprio il repository e ne è direttamente responsabile. 2.2 Informazioni pubblicate La CA pubblica almeno la seguente documentazione sul proprio sito web: Certification Practice Statement (CPS) certificati di CA (Root CA e Sub CA) Condizioni Generali di contratto tariffe massime del servizio modulistica La CA, inoltre, pubblica le CRL sul proprio directory server (per ulteriori informazioni al riguardo si rimanda alla sezione 4.10). 2.3 Tempi e frequenza delle pubblicazioni Questo CPS e la documentazione annessa vengono pubblicati sul sito web della CA in occasione di ogni aggiornamento, in formato PDF. Questo CPS viene riesaminato e se necessario aggiornato con frequenza almeno annuale. Per ulteriori informazioni sulle CRL si rimanda alla sezione 4.10. 2.4 Controllo degli accessi L accesso al repository in sola lettura ( read-only ) è completamente libero per chiunque. L accesso al repository per la pubblicazione di informazioni nuove o aggiornate è possibile solo da postazioni di lavoro attestate sulla medesima rete del repository, previa autenticazione. Copyright Actalis S.p.A. Pagina 12 di 51 9 dicembre 2014
3. Identificazione ed autenticazione (I&A) Le procedure di I&A seguite da Actalis sono conformi ai requisiti del CAB Forum. In particolare, per tutti i tipi di certificato emessi sotto questo CPS, la CA svolge perlomeno le verifiche obbligatorie previste nei Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates [BR]. Inoltre, per i certificati di classe EV, la CA svolge anche le ulteriori verifiche previste dalle Guidelines For The Issuance And Management Of Extended Validation Certificates [EVCG]. 3.1 Regole di naming Il campo Subject del certificato, se presente (secondo la classe del certificato), deve contenere informazioni facilmente comprensibili che consentano l identificazione dell organizzazione titolare. Non sono consentiti pseudonimi o nomi diversi dall effettiva denominazione ufficiale per esteso ( full legal name ) del Titolare. Non sono ammessi, nei certificati emessi per un determinato Titolare, nomi che violino diritti di proprietà intellettuale di altri soggetti. Actalis rimarrà estranea a qualsivoglia controversia riguardante la proprietà dei nomi di dominio, né si adopererà per risolvere eventuali controversie riguardanti la proprietà di nomi di dominio, nomi commerciali, marchi commerciali o di servizi. Actalis si riserva la facoltà di respingere una richiesta di certificazione e di revocare un certificato a fronte di una tale controversia. 3.1.1 Per tutte le classi di certificato Per tutti i tipi di certificato si applicano le seguenti regole di naming: La componente commonname (OID 2.5.4.3) del campo Subject: nel caso di certificato SSL Server, deve contenere un singolo indirizzo IP oppure un Fully Qualified Domain Name (FQDN) tra quelli contenuti nell estensione SAN; nel caso di certificato per Code Signing, può contenere una frase proposta dal richiedente, purché tale frase non sia tale da indurre in errore circa l identità del titolare e le finalità del software firmato. In ogni caso, non può trattarsi di un hostname (qualificato o non). Un esempio valido è ACME Code Signing. La componente organizationname (OID 2.5.4.10) del campo Subject, se presente (secondo la classe di certificato), deve contenere il nome ufficiale per esteso dell organizzazione titolare del certificato (non può trattarsi di una persona fisica). Il nome dev essere univoco, ossia non deve prestarsi ad ambiguità. Nel caso di certificato per SSL Server, deve trattarsi dell organizzazione che ha il controllo dei server indicati nel certificato; si tratta quindi, generalmente, dell organizzazione titolare dei domini indicati nel certificato, oppure dell organizzazione parente (holding), oppure un altra organizzazione che ha il diritto esclusivo di usare tali domini su delega del loro titolare. L estensione SubjectAlternativeNames (SAN), sempre presente nel caso di certificato SSL Server, deve contenere almeno una voce. Ognuna delle voci presenti dev essere l indirizzo IP oppure il FQDN di un server sotto il controllo dell organizzazione richiedente. Nota: Gli indirizzi IP interni e i domini interni sono deprecati e non saranno inclusi nei certificati con data di scadenza posteriore al 1 Novembre 2015. In ogni caso, entro il 1 ottobre 2016 la CA revocherà tutti i certificati contenenti indirizzi IP e/o domini interni. La componente organizationalunitname (OID 2.5.4.11) del campo Subject, opzionale, può contenere una stringa qualsiasi a discrezione del richiedente, purché non sia tale da indurre in errore le Relying Party circa l identità del titolare. Più in generale, nel certificato non saranno inserite informazioni potenzialmente fuorvianti; Copyright Actalis S.p.A. Pagina 13 di 51 9 dicembre 2014
La componente localityname (OID 2.5.4.7) del campo Subject, se presente (secondo la classe di certificato), deve contenere il nome della località (città) dove ha sede l organizzazione titolare; La componente stateorprovincename (OID 2.5.4.8) del campo Subject, se presente (secondo la classe di certificato), deve contenere il nome della Provincia (per i titolari con sede in Italia) o della regione o stato (per i titolari con sede all estero) dove ha sede l organizzazione titolare; La componente countryname (OID 2.5.4.6) del campo Subject, se presente (secondo la classe di certificato), deve contenere il codice ISO 3166 a due lettere (es. IT ) che identifica il paese dove ha sede l organizzazione titolare del certificato. 3.1.2 Per i certificati di classe EV In aggiunta alle regole descritte sopra, per i certificati di classe EV si applicano anche le seguenti: la componente businesscategory (OID 2.5.4.15) del campo Subject deve contenere il tipo di organizzazione (es. Private Organization oppure Government Entity ); la componente serialnumber (OID 2.5.4.5) del campo Subject deve contenere la Partita IVA (o analogo codice identificativo nel caso di organizzazioni estere) dell organizzazione titolare; la componente jurisdictionofincorporationcountryname (OID 1.3.6.1.4.1.311.60.2.1.3) del campo Subject deve contenere il codice a due lettere del paese dove l organizzazione titolare è stata legalmente costituita; La componente streetaddress (OID 2.5.4.9) del campo Subject deve contenere l indirizzo della sede legale dell organizzazione titolare (via/piazza e numero civico). 3.1.3 Per i certificati di classe DV Nei certificati di classe DV, il campo Subject contiene esclusivamente: la componente commonname, alla quale si applica quanto descritto nel paragrafo 3.1.1; la componente organizationalunitname con valore fisso Domain Validated by Actalis S.p.A.. 3.2 Validazione iniziale dell identità 3.2.1 Dimostrazione del possesso della chiave privata La dimostrazione del possesso, da parte del richiedente, della chiave privata corrispondente al certificato richiesto si basa sulla verifica crittografica della CSR (Certificate Signing Request) inviata alla CA. Il richiedente, infatti, deve inviare la propria chiave pubblica alla CA sotto forma di CSR in formato PKCS#10 [RFC2314]. La CA verifica che la firma digitale contenuta nella CSR sia valida. L invio della CSR alla CA avviene di norma via web o via posta elettronica. 3.2.2 Autenticazione dell organizzazione richiedente La verifica dell identità dell organizzazione richiedente, che non si applica ai certificati di classe DV, include in ogni caso la consultazione del database della CCIAA (Camera di Commercio, Industria e Artigianato), per le organizzazioni private, o altro database governativo per gli enti pubblici. Il nome organizzazione specificato dal richiedente deve corrispondere alla denominazione ufficiale per esteso che risulta da tale consultazione. Nel caso di mancata corrispondenza, la richiesta di certificato è respinta. Le informazioni che la CA raccoglie e verifica sulle organizzazioni richiedenti includono perlomeno (elenco non esaustivo): Copyright Actalis S.p.A. Pagina 14 di 51 9 dicembre 2014
effettiva esistenza ed attività dell organizzazione nome ufficiale per esteso dell organizzazione P.IVA (o altro identificativo univoco ufficiale) indirizzi della sede legale e delle sedi operative Qualora la CA non riesca a recuperare autonomamente tali informazioni, essere dovranno essere fornite alla CA dal richiedente in forma attendibile (es. visura camerale recente). 3.2.3 Autenticazione delle identità individuali La verifica delle identità individuali, quando richiesta (secondo la classe di certificato), avviene con uno dei seguenti metodi secondo i casi: face-to-face: esibizione di un documento ufficiale d identità ad un operatore della CA, quando applicabile; telefonicamente: un operatore della CA contatta la persona che figura come richiedente nel modulo di richiesta certificato attraverso il centralino dell organizzazione di appartenenza; mediante firma digitale: la richiesta di certificato viene sottoscritta con firma elettronica qualificata (ai sensi della norme EU), quindi l identità del firmatario viene desunta dal certificato qualificato di firma, che dev essere valido al momento della verifica da parte della CA. La CA si riserva di compiere ulteriori verifiche con modalità non prestabilite. 3.3 Ulteriori verifiche svolte dalla CA Nel caso di esito negativo o dubbio delle verifiche descritte di seguito, qualora il richiedente non sia in grado di fornire alla CA le necessarie evidenze, la richiesta di certificato è respinta. La CA si riserva la facoltà di effettuare ulteriori verifiche, in aggiunta a quelle descritte di seguito, con modalità non prestabilite. 3.3.1 Per tutte le classi di certificato SSL Server Per i certificati SSL Server, la CA verifica che tutti gli FQDN e indirizzi IP da includere nel certificato siano sotto il controllo dell organizzazione richiedente. Tale verifica è svolta in uno dei modi seguenti, secondo i casi e la classe di certificato richiesto: mediante interrogazioni WHOIS (o Reverse DNS Lookup per gli indirizzi IP); interpellando i Registrar DNS del caso, o le autorità governative di registrazione domini; comunicando con l'amministratore del dominio a un indirizzo di posta elettronica creato anteponendo admin, administrator, webmaster, hostmaster, o postmaster alla parte locale, seguito dal simbolo at (@), seguito dal nome di dominio (quest ultimo può essere ottenuto eliminando zero o più componenti dal FQDN richiesto). Qualora uno o più di tali FQDN e/o indirizzi IP siano gestiti da un soggetto diverso dal richiedente, è necessario che il richiedente fornisca alla CA l evidenza di essere stato formalmente delegato dal legittimo titolare a gestire quei domini e/o indirizzi IP. 3.3.1.1 Internationalized Domain Names (IDN) Alla data di revisione del presente CPS, gli Internationalized Domain Names (IDN) non sono ammessi; tutti gli hostname da inserire nel certificato devono pertanto essere codificati con caratteri ASCII. Copyright Actalis S.p.A. Pagina 15 di 51 9 dicembre 2014
3.3.2 Per i certificati di classe EV Per le organizzazioni private, la CA raccoglie ed esamina anche le seguenti informazioni: indirizzo della sede legale data di inizio dell attività oggetto sociale composizione del CdA elenco dei soci passaggi di proprietà poteri di firma e rappresentanza eventuali protesti e pregiudizievoli Per le gli enti pubblici, la CA raccoglie ed esamina anche le seguenti informazioni: indirizzo della sede legale nomi e ruoli dei dirigenti In entrambi i casi, si verifica che la richiesta di certificato sia stata autorizzata da un dirigente dell organizzazione dotato di opportuni poteri di rappresentanza. La CA verifica inoltre che tutti gli elementi dell indirizzo (country, stateorprovince, locality, streetaddress) da inserire nel certificato corrispondano all indirizzo dove l organizzazione richiedente ha sede. Tutte le verifiche sopra indicate sono svolte consultando il database della rilevante camera di commercio (nel caso di organizzazione privata) oppure un appropriato database governativo (nel caso di ente pubblico). Qualora l organizzazione richiedente risulti essere in attività da meno di 3 anni, la CA verifica l esistenza di un conto corrente bancario intestato al richiedente. A tal fine, l organizzazione richiedente deve fornire alla CA una lettera formale di referenze bancarie, datata e firmata dalla Banca, su carta intestata della banca stessa. Nel caso la CA rilevi situazioni pregiudizievoli a carico dell organizzazione richiedente o della persona che ha sottoscritto la richiesta di certificato (per es. procedure fallimentari, protesti, insolvenza, ecc.), la procedura viene sospesa e il caso viene portato all attenzione del Responsabile Amministrativo e del Responsabile Sicurezza della CA per essere valutato. 3.4 Informazioni non verificate dalla CA La CA non verifica gli indirizzi di posta elettronica indicati nel modulo di richiesta. In generale, la CA non verifica la correttezza delle informazioni ricevute dal richiedente che non sono destinate ad essere incluse in campi critici del certificato (ai fini della sicurezza) e che non sono necessarie per l emissione e successiva gestione (sospensione, riattivazione, revoca) del certificato. 3.5 I&A per le richieste di rinnovo Il processo di rinnovo è simile al processo di prima emissione: consiste nella generazione di una nuova coppia di chiavi, da parte del titolare, sostitutiva di quella in scadenza e nella richiesta alla CA di un corrispondente nuovo Copyright Actalis S.p.A. Pagina 16 di 51 9 dicembre 2014
certificato. Per il rinnovo sono seguiti gli stessi processi di identificazione ed autenticazione (I&A) che si applicano alla prima emissione. 3.6 I&A per le richieste di sospensione o revoca La modalità di identificazione ed autenticazione delle richieste di sospensione o revoca dipende dal canale usato per la richiesta: per poter inoltrare richieste di sospensione o revoca attraverso il portale dei servizi di CA, è necessario il login al portale mediante userid e password (fornite al cliente mediante posta elettronica); nel caso delle richieste di revoca inviate in forma cartacea alla CA, si procede come descritto nel paragrafo 3.2.3. 4. Requisiti operativi di gestione dei certificati 4.1 Richiesta del certificato La richiesta di certificato avviene mediante compilazione e consegna oppure invio alla CA (per fax, email, posta ordinaria) dell apposito modulo di richiesta scaricabile dal sito web di Actalis, insieme alla necessaria documentazione accompagnatoria. Un equivalente on-line di tale modulo è disponibile alle Enterprise RA. La richiesta di certificato, che dev essere sottoscritta dal legale rappresentante dell organizzazione richiedente, include almeno le seguenti informazioni: dati identificativi dell organizzazione richiedente dati identificativi e di contatto (email, telefono) del richiedente dati identificativi e di contatto (email, telefono) di un referente tecnico indirizzo del sito web da inserire nel certificato (per i certificati SSL Server) valore proposto per il campo commonname (per i certificati Code Signing) La richiesta di certificato include per riferimento le Condizioni Generali del servizio, pertanto la sua sottoscrizione costituisce accettazione delle Condizioni Generali da parte del richiedente. In precedenza, il richiedente ha la possibilità di valutare ogni aspetto del servizio proposto da Actalis consultando la documentazione pubblicata sul sito web della CA (www.actalis.it), nella sezione dedicata ai certificati SSL Server e Code Signing. Il modulo di richiesta certificato è disponibile nelle lingue Italiano e Inglese, così come le condizioni generali di contratto. La CA non promette di accettare richieste di certificato redatte in altre lingue. La richiesta di certificato dev essere accompagnata o seguita dalla CSR (Certificate Signing Request). Nel caso di richiesta in modalità cartacea, la CSR può essere inviata alla CA successivamente, per posta elettronica, all indirizzo indicato dal responsabile della registrazione. La CSR è normalmente generata dall organizzazione richiedente con mezzi propri. È anche possibile richiedere un certificato SSL Server di tipo wildcard (ossia valido per tutti i siti web attestati su uno specifico dominio) oppure di tipo multi-san (nel quale sono indicati molteplici siti web e/o domini per i quali lo stesso certificato è valido). In questi casi si applicano le medesime procedure di I&A: la CA verifica sempre che il richiedente effettivamente sia il legittimo proprietario dei domini e/o indirizzi IP da includere nel certificato e che si tratti di un azienda esistente, in base ai dati della camera di commercio. Copyright Actalis S.p.A. Pagina 17 di 51 9 dicembre 2014
Ai certificati di tipo wildcard e multi-san si applicano tariffe diverse da quelle dei certificati SSL Server semplici (per singoli siti web). Per ulteriori informazioni contattare la direzione commerciale di Actalis. Il massimo numero consentito di valori SAN in un certificato SSL Server è 100. Copyright Actalis S.p.A. Pagina 18 di 51 9 dicembre 2014
4.2 Elaborazione delle richieste La procedura per l emissione del certificato soddisfa il requisito del dual control, in quanto richiede sempre l intervento di due differenti operatori: operatore di RA (RAO); operatore di CA (CAO). Alla ricezione di una richiesta di certificazione, l operatore di RA svolge le seguenti attività: svolge le verifiche descritte nella sezione 3.2; svolge le ulteriori verifiche descritte nella sezione 3.3; provvede al censimento del richiedente nel database di registrazione della CA; invia all utente, mediante posta elettronica, le credenziali necessarie per accedere all area riservata del portale dei servizi della CA, per l eventuale sospensione/riattivazione o revoca del certificato. La registrazione del richiedente consiste nella memorizzazione, nel database della CA, dei dati identificativi e di contatto (telefono, email) dell organizzazione richiedente e della persona che richiede il certificato (normalmente un rappresentante legale, per es. un dirigente con opportuni poteri di firma), nonché i domini Internet controllati dall organizzazione richiedente e altre informazioni accessorie. 4.3 Emissione del certificato Se le verifiche di cui alla sezione precedente sono superate, l operatore di CA svolge le seguenti attività: verifica che le informazioni contenute nella CSR siano coerenti con quelle presenti nel database di registrazione; verifica che la CSR sia correttamente codificata e non contenga informazioni impreviste; verifica il possesso, da parte del richiedente, della chiave privata corrispondente alla CSR, come descritto nella sezione 3.2. Tali verifiche sono svolte in modo automatico dal software di CA, su comando dell Operatore di CA. Se le precedenti verifiche sono superate, l operatore di CA genera il certificato, lo memorizza nel database della CA e infine invia al cliente mediante posta elettronica: il certificato del titolare il certificato della CA emittente eventuali informazioni accessorie A questo punto, nel caso in cui il certificato non sia già stato pagato, viene inviata la fattura al cliente. 4.4 Accettazione del certificato Il certificato si intende senz altro accettato dal cliente trascorsi 30 giorni dalla data di consegna, come attestata dalla data del messaggio di posta elettronica tramite il quale esso viene inviato al cliente, in assenza di comunicazioni in senso contrario da parte del cliente stesso. Copyright Actalis S.p.A. Pagina 19 di 51 9 dicembre 2014
L uso pubblico del certificato (per es. installazione su un sito web ad accesso pubblico, firma di codice eseguibile scaricabile da siti web ad accesso pubblico), anche se temporaneo, implica in ogni caso l accettazione del certificato da parte del titolare. Qualora il certificato contenga informazioni errate a causa della errata compilazione del modulo di richiesta da parte del cliente, esso dovrà in ogni caso essere pagato. 4.5 Uso della coppia di chiavi e del certificato Il titolare usa la chiave privata per: (certificati per Code Signing) firmare digitalmente codice eseguibile (per es. applet Java, librerie dinamiche, ecc.) di propria produzione e/o del quale si assume la responsabilità; (certificati per SSL Server) attivare il protocollo TLS/SSL sul proprio sito web, consentendo la server authentication e la cifratura delle transazioni coi browser. Le relying parties usano il certificato per: (certificati per Code Signing) verificare l integrità e l origine di codice eseguibile; (certificati per SSL Server) verificare l identità di un sito web e dell organizzazione che lo gestisce, nonché scambiare in modo sicuro la chiave di sessione col web server. Vedere anche il paragrafo 1.4. 4.6 Rinnovo del certificato Il certificato ha una data di scadenza, oltre la quale esso perde ogni validità. La ragione per cui il certificato ha una durata limitata nel tempo è che la sicurezza di una coppia di chiavi crittografiche può, nel tempo, diminuire o essere addirittura compromessa, per effetto degli avanzamenti delle tecniche di criptoanalisi e degli attacchi perpetrati dai malintenzionati. Per queste ragioni, Actalis non effettua il rinnovo di un certificato, a meno che l utente non generi una nuova coppia di chiavi. A parte questa condizione, il processo di rinnovo è uguale al processo di prima emissione. 4.7 Rigenerazione della chiave Nel caso in cui l utente finale (titolare) decida di utilizzare una nuova chiave, egli deve necessariamente fare richiesta di un corrispondente nuovo certificato. 4.8 Modifica del certificato Un certificato, essendo firmato dalla CA emittente, non può essere modificato. Per rimediare ad eventuali errori nella generazione del certificato, dunque, è necessario emetterne uno nuovo (e revocare quello errato, per evidenti ragioni di sicurezza). Nel caso in cui il certificato emesso contenga informazioni errate a causa di errori commessi dalla CA o dalla RA (nel caso si tratti di struttura distinta), il certificato errato sarà revocato e ne verrà emesso uno corretto, sollecitamente, senza oneri aggiuntivi per il cliente e senza richiedere ulteriori informazioni al cliente. Nel caso in cui il certificato emesso contenga informazioni errate a causa di errori commessi dal richiedente (es. errata compilazione di uno o più campi del modulo di richiesta), il certificato errato sarà revocato. Copyright Actalis S.p.A. Pagina 20 di 51 9 dicembre 2014
4.9 Sospensione e revoca del certificato CAACT-03-01-05 Certification Practice Statement La sospensione determina un blocco temporaneo della validità di un certificato, a partire da un dato momento (data/ora). Dopo essere stato sospeso, un certificato può essere riattivato. La revoca determina la cessazione anticipata della validità di un certificato, a partire da un dato momento (data/ora). La revoca di un certificato è irreversibile e non retroattiva. L attuazione della sospensione o revoca consiste nella generazione e pubblicazione di una nuova CRL (Certificate Revocation List) che include il numero di serie del certificato sospeso o revocato. La CRL è liberamente accessibile a chiunque abbia necessità di verificare lo stato del certificato (cfr. la sezione 4.10). La riattivazione consiste nella generazione e pubblicazione di una nuova CRL nella quale non compare più il numero di serie del certificato precedentemente sospeso. 4.9.1 Circostanze per la sospensione Le condizioni che possono portare ad una richiesta di sospensione sono: sospetta compromissione della chiave privata; interruzione temporanea del uso del certificato da parte del cliente; inadempienze contrattuali da parte del cliente (es. mancato pagamento). 4.9.2 Chi può richiedere la sospensione La sospensione può essere richiesta dal cliente e/o titolare del certificato o dalla CA. In determinate circostanze il titolare ha l obbligo di richiedere la sospensione del certificato (vedere il paragrafo 9.5.3). La revoca può essere effettuata direttamente dalla CA quando essa viene a conoscenza di condizioni che potrebbero compromettere l attendibilità del certificato o costituiscono inadempienza contrattuale da parte del cliente. 4.9.3 Procedura per la sospensione La sospensione può essere richiesta dal titolare in modalità on-line (vedere il paragrafo 4.9.6). Trascorsi 15 giorni dalla sospensione, il certificato viene automaticamente riattivato. Il certificato può essere riattivato dall utente stesso, in qualsiasi momento, attraverso il portale web dei servizi della CA, previa autenticazione. Copyright Actalis S.p.A. Pagina 21 di 51 9 dicembre 2014
4.9.4 Circostanze per la revoca Le condizioni che possono determinare una revoca sono: provvedimento dell autorità giudiziaria; compromissione della chiave privata del titolare; sospetta o acclarata compromissione della chiave privata della CA emittente (SubCA); il certificato è divenuto tecnicamente insicuro, per es. a seguito della compromissione di un algoritmo crittografico e/o di una determinata lunghezza della chiave pubblica inclusa nel certificato; la CA scopre che l organizzazione titolare del certificato ha cessato la propria attività; cessazione dell attività della CA oppure perdita del suo diritto di emettere certificati conformi ai Requisiti [BR] (in mancanza di una CA sostitutiva che si faccia carico del servizio di revoca e pubblicazione delle informazioni sullo stato dei certificati); la CA scopre che il certificato contiene informazioni errate e/o fuorvianti; la CA scopre che il titolare ha violato una o più delle disposizioni del presente CPS e/o delle Condizioni Generali; la CA scopre che una o più delle informazioni contenute nel certificato ha subito variazioni (per es. è cambiata la denominazione sociale dell azienda titolare); richiesta da parte del titolare (es. motivata da cessazione dell uso del certificato); il titolare informa la CA che la richiesta del certificato non era stata autorizzata, e non intende autorizzarla retroattivamente; la CA scopre che l uso di un FQDN o di un indirizzo IP contenuto nel certificato non è più consentito (per es. quando il titolare del dominio e/o della rete non ha rinnovato la registrazione, a seguito di un provvedimento dell autorità giudiziaria, ecc); la CA scopre che la chiave del titolare è compromessa e/o che il certificato viene usato in modo improprio e/o illecito; la CA scopre che un certificato di tipo wildcard viene usato per autenticare un FQDN subordinato in modo fraudolento; errato profilo del certificato, a causa di un errore della CA (es. valori errati nelle estensioni); la CA scopre che il certificato non rispetta il presente CPS sotto qualche aspetto; la CA scopre che il certificato non è conforme ai Requisiti [BR] e alle Linee Guida [EVCG] (secondo il tipo di certificato) sotto qualche aspetto; inadempienze contrattuali da parte del cliente (es. mancato pagamento del certificato). In tutti questi casi, la CA revoca il certificato entro 24 ore. Qualora la CA scopra che il certificato viene usato dal titolare per attività criminali (es. Phishing, attacchi di tipo man-in-the-middle, distribuzione di malware, ecc.) la CA effettuerà una revoca immediata e senza preavviso del certificato. Analogamente nel caso in cui la CA scopra che il certificato è stato erroneamente emesso con CA=TRUE nella estensione KeyUsage. Copyright Actalis S.p.A. Pagina 22 di 51 9 dicembre 2014
4.9.5 Chi può richiedere la revoca La revoca può essere richiesta (secondo i casi): dal titolare del certificato; dall autorità giudiziaria; dalla CA emittente. Inoltre, chiunque può segnalare alla CA fatti o circostanze che possono, secondo i casi, indurre la CA a reputare necessaria la revoca del certificato. In determinate circostanze il titolare ha l obbligo di richiedere prontamente la revoca del certificato (vedere il paragrafo 9.5.3). 4.9.6 Procedura per la sospensione o revoca La sospensione e la revoca possono essere richieste alla CA attraverso il portale web dei servizi di Actalis, all indirizzo indicato sul sito www.actalis.it. Per accedere a tali funzionalità è necessario che il titolare si autentichi al portale con le credenziali di accesso che gli vengono fornite dalla CA all emissione del certificato. In alternativa, per la revoca è possibile utilizzare un modulo di richiesta cartaceo sottoscritto dal rappresentante del cliente. Il modulo firmato può essere consegnato a mano alla RA oppure può essere inviato direttamente alla CA (mediante fax, posta ordinaria, posta elettronica). Indipendentemente da chi richiede la sospensione o revoca, la CA invia segnala al cliente l avvenuta sospensione o revoca mediante posta elettronica, inviando una notifica all indirizzo di e-mail del responsabile tecnico indicato nel modulo di richiesta. I certificati sono sospesi/revocati entro 24 ore dalla richiesta di sospensione/revoca effettuata on-line. Le richieste di revoca inviate in forma cartacea o mediante fax/email sono evase mediamente entro 24 ore nel 90% dei casi, nei soli giorni lavorativi. 4.9.7 Frequenza di emissione della CRL Vedere il paragrafo 4.10.1. 4.10 Servizi informativi sullo stato del certificato In generale, lo stato dei certificati (attivo, sospeso, revocato) è reso disponibile a tutti gli interessati mediante pubblicazione della Certificate Revocation List (CRL) col formato definito nella specifica [RFC5280]. Per quanto riguarda i certificati degli utenti finali, è disponibile anche un servizio di verifica on-line basato sul protocollo OCSP (On-line Certificate Status Protocol) e conforme alla specifica [RFC2560]. 4.10.1 Caratteristiche operative La CRL è accessibile con due diverse modalità: con protocollo LDAP [RFC2251] sul server ldap03.actalis.it con protocollo HTTP [RFC2616] sul server crl03.actalis.it Copyright Actalis S.p.A. Pagina 23 di 51 9 dicembre 2014