Certificate revocation list

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.”

Pubblicazione CRL

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. 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

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

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.

Ragioni di revoca

• ReasonCode: 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).

 -- 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) 
    }

Formato CRL

RFC 5280 p55 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

La CertificateList è composta da tre campi obbligatori quali:

• 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 contenente 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. È 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

Le estensioni definite da ANSI X9, ISO/IEC, e ITU-T per i CRL conformi allo standard X.509 forniscono metodi per associare attributivi aggiuntivi. il formato dei CRL permette anche alle comunità di definire delle estensioni private con lo scopo di riportare informazioni riservate. Ogni estensione CRL può essere implementata 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.

Estensioni principali:

• Authority Key Identifier
• Issuer Alternative Name
• CRL number
• Delta CRL Indicator

Problemi con i CRL

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, Mozilla ha annunciato di deprecare i CRL in favore di OCSP .

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.