Mentre studio un corso sulla sicurezza mi è stata posta questa stessa domanda:
Perché il CRL viene periodicamente rinnovato, anche se non ci sono nuovi certificati revocati da aggiungere all'elenco?
Onestamente non riesco a trovare la risposta, se qualcuno di voi potrebbe essere così gentile da far luce su di esso, sarei molto grato.
Un paio di cose fondamentali:
La base di un CRL è una promessa per un certo periodo di tempo. Ciò significa un orario di inizio e un orario di fine. Una volta che un CRL è stato creato e firmato, non può essere modificato, quindi dura fino a quando dura e non può più essere considerato affidabile.
In sostanza, non lo saprai finché non controlli. Un CRL nella sua forma normale è una grande lista. Non si può presumere che la dimensione sia un'indicazione ... il verificatore deve sapere esattamente cosa i Certificati non sono più considerati attendibili. Quindi è necessario ottenere una nuova copia, in entrambi i casi. Non c'è alcun protocollo da verificare "è uguale al mio vecchio?"
L'implementazione primaria dei CRL non è "vai a prenderne uno quando ne hai bisogno" ma "fallo prima del tempo e controlla quando è necessario". Il che significa che il meccanismo principale di distribuzione è una serie di download di file e cache. Un server non sa che il prossimo CRL è esattamente uguale al CRL in scadenza fino a quando non ha entrambi: a che punto, se hai una nuova versione, perché controllare? Se ciò che è necessario è un tipo "chiedi quando ne hai bisogno, avrai sempre accesso", quindi vai con OSCP.
Il fondamento logico delle date di validità è consentire agli implementatori di PKI di prendere una decisione consapevole sulla durata del check-in con l'emittente del CRL. Un sistema PKI prenderà questa decisione su un emittente per emittente, in base al rischio per il sistema e ai modelli del suo uso previsto. È una vera sfida: la validità dovrebbe essere commisurata al rischio: per quanto tempo i protettori del sistema sono disposti ad aspettare prima di fare il check-in nella lista dei "cattivi noti"?
C'è una premessa di base qui che mi riferisco a guardare il cibo in scatola in un sottomarino ... la data di scadenza è quanto a lungo il produttore prometterà che sarà OK consumarlo . Puoi mangiare carne un giorno dopo la data di scadenza? Sì. In effetti, la carne di un giorno è un modo migliore di morire di fame. Che dire della carne che è passata 6 mesi dalla sua data di scadenza? Beh ... che tipo di germi hai contro? C'è una possibilità reale che questo cibo ti renda più malato di non mangiare nulla (basta chiudere e non fare transazioni finché non hai un CRL recente). In tutti i casi, la realtà è che pesi il costo di fare affari contro il rischio di dati incerti.
NOTA: Tutto ciò si applica solo a una varietà di giardino, CRL. C'è un certo numero di formati alternativi là fuori. L'ultima volta che ho guardato, erano tutti proprietari ... ma è passato un po 'di tempo ... alcuni di questi formati alternativi possono funzionare in modo diverso, poiché tutti mirano a semplificare.
Nel modello X.509, non ci sono restrizioni su download . Quando un verificatore (ad esempio un browser Web) desidera convalidare un certificato, cercherà di ottenere informazioni aggiuntive attraverso altri oggetti: certificati, CRL ... e potrebbe ottenere questi oggetti su canali non sicuri. Questo è il punto in cui CRL è firmato : un verificatore si fiderà di un CRL non perché lo ha appena ottenuto da un sito Web specifico, ma perché il CRL è firmato da un emittente CRL autorizzato (di solito la CA stessa) .
Il lato positivo di questo principio è che rende i certificati X.509 applicabili a tutti i tipi di reti. Altrimenti, avresti un problema di pollo e uova piuttosto duro: come ti fiderei di avere le giuste informazioni di revoca più recenti? Perché l'hai scaricato da un server HTTPS? Ma come hai verificato il certificato di quel server? E così via ...
Ma c'è un lato oscuro, ovviamente: un CRL è uno istantanea di informazioni di revoca in una determinata data. Essendo firmato, è immutabile. Non può essere cambiato. È quindi sempre un po 'stantio. Un verificatore richiede che il CRL utilizzato sia "non troppo vecchio" e che, implicitamente, implichi la pubblicazione periodica del CRL più recente.
Dal punto di vista tecnico, possiamo prevedere un tipo specifico di CRL che non contiene l'intero elenco di certificati revocati (che può essere ingombrante) ma solo un breve messaggio che dice "nessun certificato revocato da quella data ", permettendo così di estendere in qualche modo la durata di un CRL. Questo esiste; si chiama delta CRL . Con delta CRL, un nuovo CRL viene virtualmente emesso a intervalli regolari, senza necessariamente forzare il download di un nuovo file di grandi dimensioni.
Sfortunatamente, non tutti i software là fuori sanno come usare delta CRL.
Un'altra tecnica è segmentazione : dividi il CRL in molti file più piccoli, ciascuno dei quali parla solo di un sottoinsieme di certificati. In questa strada si trovano cRL molto piccoli che affermano lo stato di revoca di un solo certificato alla volta; questo è noto come OCSP . Anche in questo caso, il supporto è nella distribuzione.
A certificate revocation list (CRL) is a time-stamped listidentifying revoked certificates that is signed by a CA or CRL issuerand made freely available in a publicrepository.Each revoked certificate is identified in a CRL by itscertificate serial number.
When a certificate-using system uses a certificate (e.g., for verifying a remote user's digital signature), that system not only checks the certificate signatureand validity but also acquires a suitably recent CRL and checks hat the certificate serial number is not on that CRL.
The meaning of "suitably recent" may vary with local policy, but it usuallymeans the most recently issued CRLA new CRL is issued on a regular periodic basis (e.g., hourly, daily, or weekly).
An entryis added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyondthe revoked certificate's validity period.
An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves, namely, via untrusted servers and untrusted communications.CRl's would revoke when private key of an asymmetric encryption key pair (whose public key has been certified by the CA) is stolen.In such a situation, anybody with the private key could decrypt all communication between a user and the certified entity.
CRLs Will be issued periodically, in which case certificates that have expired may be tagged as revoked, or they may be issued as soon as a certificate is revoked. To keep CRLs from being faked, they are signed by the public key of the CA and contain a timestamp, after which the CRLs themselves expire.
Motivi della revoca :
Secondo ietf i motivi comuni per la revoca erano:
keyCompromise
CACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
removeFromCRL
privilegeWithdrawn
AACompromise
Leggi altre domande sui tag certificates certificate-authority certificate-revocation