Certificate revocation list

Da Wikipedia, l'enciclopedia libera.

Un CRL (Certificate Revocation List) è "un elenco di certificati digitali che sono stati revocati dalla Certification Authority (CA), prima della data di scadenza pianificata e non dovrebbero più essere considerati attendibili.[1]


Pubblicazione CRL[modifica | modifica wikitesto]

Un CRL viene generato e pubblicato periodicamente, spesso ad un intervallo di tempo definito. Viene rilasciato da un entità autorizzata all’emissione di CRL, che è tipicamente la CA che ha anche rilasciato i certificati corrispondenti, ma potrebbe in alternativa essere un'altra autorità attendibile delegata dalla CA stessa. Le CA pubblicano i CRL per fornire informazioni sullo stato dei certificati che emettono. Ogni documento CRL ha un ambito di interesse, che è rappresentato dall’insieme dei certificati che possono comparire in quel CRL. Ad esempio potrebbe essere: “tutti i certificati emessi dalla CA X”, “tutti i certificati emessi dalla CA X che sono stati revocati per ragioni di compromissione delle chiavi”, ecc[2]. Tutti i CRL hanno una durata di vita, durante la quale sono validi; questo periodo di tempo è solitamente di 24 ore o meno. Durante il periodo di validità, un CRL può essere consultato da un'applicazione per verificare un certificato prima dell’uso.

Per prevenire attacchi di spoofing o DoS, i CRL di solito hanno una firma digitale associata alla CA che li ha pubblicati. Per convalidare un CRL specifico prima di fare affidamento su di esso, è necessario il certificato della relativa CA, che di solito si trova in una directory pubblica (ad esempio, preinstallata nei browser web).

I certificati per i quali un CRL dovrebbe essere mantenuto sono spesso conformi allo standard [X.509/public key certificates], in quanto questo formato è comunemente utilizzato dai sistemi ad infrastruttura a chiave pubblica (PKI)


Revoca vs Scadenza[modifica | modifica wikitesto]

Le date di scadenza non rappresentano un sostituto dei CRL. Mentre tutti i certificati scaduti non sono considerati validi, non tutti i certificati non scaduti dovrebbero essere validi. I CRL o altri metodi di convalida dei certificati sono una parte necessaria di qualunque infrastruttura a chiave pubblica, in quanto nelle operazioni nel mondo reale si verificano errori di verifica dei certificati e gestione delle chiavi.


Stati di revoca[modifica | modifica wikitesto]

Revocato: Un certificato viene revocato in modo irreversibile se, ad esempio, si scopre che la CA ha rilasciato in modo improprio un certificato o se si ritiene che una chiave privata sia stata compromessa. I certificati possono anche essere revocati per l’inadempimento, da parte dell’entità identificata, dei requisiti legali, come la pubblicazione di documenti falsi, la rappresentazione errata del comportamento del software o la violazione di qualsiasi altro requisito legale specificato dalla CA. Il motivo più comune per la revoca è che l'utente non è più in possesso della chiave privata (ad esempio, il token contenente la chiave privata è stato perso o rubato).

Bloccato: Questo stato reversibile può essere utilizzato per notificare l'invalidità temporanea del certificato (ad esempio se l'utente non è sicuro se la chiave privata è stata persa). Se, in questo caso, è stata trovata la chiave privata e nessuno ha avuto accesso, lo stato potrebbe essere re-instradato e il certificato ritornerebbe ad essere valido, rimuovendolo così dai CRL futuri.


Formato CRL[modifica | modifica wikitesto]

RFC 2580 p55[3] definisce la sintassi che deve essere adottata in un CRL

  CertificateList  ::=  SEQUENCE  {
       tbsCertList          TBSCertList,
       signatureAlgorithm   AlgorithmIdentifier,
       signatureValue       BIT STRING  
  }
  TBSCertList  ::=  SEQUENCE  {
       version                 Version OPTIONAL,
                                    -- if present, MUST be v2
       signature               AlgorithmIdentifier,
       issuer                  Name,
       thisUpdate              Time,
       nextUpdate              Time OPTIONAL,
       revokedCertificates     SEQUENCE OF SEQUENCE  {
            userCertificate         CertificateSerialNumber,
            revocationDate          Time,
            crlEntryExtensions      Extensions OPTIONAL
                                     -- if present, version MUST be v2
                                 }  OPTIONAL,
       crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                     -- if present, version MUST be v2
   }


Campi CRL[modifica | modifica wikitesto]

La CertificateList è composta da tre campi obbligatori quali[4]:


  • tbsCertList: questo campo è a sua volta una sequenza (TBSCertList) di parametri obbligatori e opzionali. Tra quelli obbligatori si trova il tipo di algoritmo utilizzato per firmare il CRL (signature), il nome dell’entità che ha emesso il CRL (issuer), la data di emissione (thisUpdate) e una sotto sequenza contenete la lista di certificati revocati nel caso ce ne siano (revokedCertificates). Per ogni certificato revocato, quindi, si avrà una entry nella revokedCertificates definita da un numero sequenziale (UserCertificate), dalla data di revoca (revocationDate) e da delle estensioni CRL opzionali (crlEntryExtension). Tra i campi opzionali si trova la data di emissione del prossimo CRL (nextUpdate), la versione del formato (version) e le estensioni del CRL (crlExtension).


  • signatureAlgorithm: questo campo contiene l’identificatore dell’algoritmo utilizzato per firmare il CRL. E` di tipo AlgorithmIdentifier e deve essere uguale al campo signature nella tbsCertList.


  • signatureValue: questo campo contiene la firma digitale calcolata sulla codifica della tbsCertList. La codifica della tbsCertList viene usata come input nella funzione di firma, questo valore viene poi codificato come una BIT STRING ed infine inserito all’interno di questo campo.


Estensioni CRL[modifica | modifica wikitesto]

Il formato dei CRL permette alle comunità di definire delle estensioni private con lo scopo di riportare informazioni riservate. Ogni estensione CRL può essere progettata di tipo critico o non critico. Se un CRL contiene un’estensione critica che una applicazione non riesce a processare, allora l’applicazione non deve utilizzare quel CRL per determinare lo stato del certificato. Dall’altro canto un’applicazione potrebbe ignorare un’estensione non riconosciuta di tipo non critico[5].


  • ReasonCode: Rappresenta un’estensione di tipo non critico che identifica le ragioni di revoca di un certificato. Le autorità di emissione dei CRL sono fortemente incoraggiate ad includere ragioni il più significative possibili. Tra i principali si rilevano la keyCompromise(1), la cACompromise(2)[6].
 -- reasonCode ::= { CRLReason }
    CRLReason ::= ENUMERATED {
         unspecified             (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6),
            -- value 7 is not used
         removeFromCRL           (8),
         privilegeWithdrawn      (9),
         aACompromise           (10) 
    }


  • Delta CRL Indicator: Rappresenta un’estensione critica che identifica un CRL come un Delta CRL. I Delta CRL contengono aggiornamenti sulle informazioni di revoca precedentemente distribuite, anziché tutte le informazioni che apparirebbero in un CRL. L’utilizzo dei Delta CRL riduce significativamente il carico sulla rete ed i tempi di elaborazione in certi ambienti. Essendo tipicamente più leggeri dei CRL completi, le applicazioni che ottengono un Delta CRL consumano molto meno banda di rete rispetto alle applicazioni che ottengono il corrispondente CRL completo[7].


Problemi con i CRL[modifica | modifica wikitesto]

Le migliori pratiche richiedono che lo stato del certificato debba essere verificato ogni volta che si desidera contare su di esso. In caso contrario, un certificato revocato potrebbe essere erroneamente considerato valido. Ciò significa che per utilizzare in modo efficiente un’ infrastruttura a chiave pubblica è necessario accedere ai CRL attuali. Questo requisito di convalida on-line annulla uno dei principali vantaggi su i protocolli di crittografia simmetrica (rendendo il certificato “auto-autenticante”). I protocolli simmetrici come Kerberos dipendono anche dall’esistenza di certi servizi on-line (un key distribution center nel caso di Kerberos)

Un alternativa all’utilizzo dei CRL è il protocollo di validazione dei certificati noto come Online certificate status protocol(OCSP), che ha come vantaggio principale di richiedere meno banda, consentendo un controllo dello stato in tempo reale per operazione di alto volume.

A partire da firefox 28, Mozzilla ha annunciato di deprecare i CRL in favore di OCSP[8].

I file CRL possono diventare molto grandi col passare del tempo (es. negli USA, per alcune istituzioni multipli di MegaByte). Di conseguenza sono stati progettati dei CRL incrementali detti Delta CRL. Tuttavia vengono implementati da pochi client.