Indietro

ⓘ Certificate revocation list




                                     

ⓘ Certificate revocation list

Un CRL è "un elenco di certificati digitali che sono stati revocati dalla Certification Authority, prima della data di scadenza pianificata e non dovrebbero più essere considerati attendibili.”

                                     

1. Pubblicazione CRL

Un CRL viene generato e pubblicato periodicamente, spesso ad un intervallo di tempo definito. Viene rilasciato da unentità autorizzata all’emissione di CRL, che è tipicamente la CA che ha anche rilasciato i certificati corrispondenti, ma potrebbe in alternativa essere unaltra 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 unapplicazione 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, in quanto questo formato è comunemente utilizzato dai sistemi ad infrastruttura a chiave pubblica PKI

                                     

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

                                     

3. 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 lutente 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 linvalidità temporanea del certificato ad esempio se lutente 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.



                                     

4. 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 keyCompromise1, la cACompromise2.
-- 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 }
                                     

5. 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 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 EXPLICIT Extensions OPTIONAL -- if present, version MUST be v2 }
                                     

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


                                     

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

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

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

Unalternativa all’utilizzo dei CRL è il protocollo di validazione dei certificati noto come Online certificate status protocolOCSP, 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.