Perché vengono utilizzati i CRL anziché "liste di certificati validi" e il funzionamento interno dei CRL

Prima di tutto ricorda che X.509 è stato progettato a volte non tutti i sistemi erano online tutto il tempo.

Avere solo numeri di serie di certificati revocati su un elenco di revoche di certificati (CRL) è stato fatto principalmente per mantenere le dimensioni ridotte. Alcune CA rimuovono anche i certificati revocati scaduti nel tempo medio dal CRL proprio per questo motivo. Gli approcci più sofisticati per l'indirizzamento delle dimensioni CRL sono CRL partizionati e CRL delta.

Oggi molte distribuzioni PKI favoriscono controlli di revoca online come OSCP . Inizialmente, questo era anche progettato per indicare la revoca (a volte letto da CRL), ma alcuni risponditori OCSP interrogano anche il database della CA. C'era anche un meccanismo di convalida remoto progettato chiamato SCVP che però non è ampiamente implementato. OSCP e altri richiedono rigorosamente l'accesso online.

Come X.509, anche i CRL X.509 sono firmati sia dalla CA stessa sia da un'altra autorità di revoca delegata (CRL indiretti). Pertanto, non è un problema distribuirli tramite HTTP e HTTP non autenticato, a condizione che il partecipante che esegue il collegamento convalidi correttamente la firma. (L'utilizzo di HTTPS potrebbe causare problemi di gallina e uovo durante il controllo del certificato del server TLS rispetto a un CRL).

Un certificato revocato è un'eccezione, non la regola. Quindi accetti tutti i certificati come validi e crea un database con quelli non validi, una minoranza molto piccola.

have each certificate signed with a separate key that is stored in the CAs database

Ogni certificato è già stato firmato con la chiave CA. Avere 2 chiavi non aggiunge nulla.

and if you want to revoke the certificate you just have to delete its entry?

Questo aumenta la complessità. Ogni volta che scarichi un certificato dovrai collegarti alla CA per chiedere se il certificato è ancora valido.

doesn't this create margin for errors (aka forgetting to revoke a client certificate)?

Questo processo deve essere automatizzato. Quando si termina l'account di un utente, il processo deve revocare i suoi account, le sue credenziali e i suoi certificati.

but shouldn't the "not valid until explicitly validated"-approach not at least be an option?

E avresti bisogno di una soluzione per convalidare la convalida e una soluzione per convalidare la convalida convalidata e così via. Un'azione di revoca è meglio che convalidare e convalidare di nuovo.

Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

Da Digicert stesso:

It is digitally signed by an IA and issued periodically or as needed.

Quindi non puoi. Se falsi l'indirizzo e falsi il CRL, non puoi firmare il CRL e nessuno crederà che tu sia Digicert.

Wouldn't it make more sense to force CAs to keep databases with the certificates they issued

Trasparenza certificato è un po 'come questo, ma è meglio.

have each certificate signed with a seperate key that is stored in the CAs database and if you want to revoke the certificate you just have to delete its entry?

Com'è meglio di un CRL? Avere una chiave separata per ogni certificato sembra inutile e inutilmente complicata.

Because if you look at use cases like client certificates on Apache for instance you always have to keep track of the certificates you issued (e.g. for each employee in a company). Once an employee leaves the company you have to revoke his/her certificate.

Questo è un caso d'uso molto diverso. Con un certificato client lo stai già inviando a quel server Apache, quindi può semplicemente controllare il suo elenco locale di revoche.

Potresti imporre un controllo alla CA per vedere se un certificato è ancora valido ogni volta che visiti un sito (questo è ciò che OCSP è), ma ciò comporta molti problemi (sebbene molti di questi problemi siano risolti dalla pinzatura ) .

Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

È firmato comunque , quindi l'autenticità è già fornita e la riservatezza non è realmente necessaria.

Dobbiamo disporre di strumenti per eseguire correttamente la revoca: pinzatura OCSP combinata con Must-Staple (che indica ai browser di non eseguire il soft-fail se OCSP è mancante). Il vero problema è che nessuno li implementa correttamente .

I CRL sono progettati per essere scaricati da chiunque debba controllare la revoca. Ottenere l'elenco di tutti i certificati validi dalla CA invece di ottenere solo l'elenco di quelli revocati farebbe una grande differenza e quello che sarebbe necessario scaricare.

Inoltre, i CRL sono progettati per la memorizzazione nella cache e hanno una sorta di scadenza in cui è necessario scaricare un nuovo CRL. Sebbene sia accettabile il mancato rilevamento di un certificato revocato per un breve periodo (fino all'aggiornamento del CRL), sarebbe inaccettabile non accettare un certificato valido fino al prossimo aggiornamento dell'elenco dei certificati validi.

.. you always have to keep track of the certificates you issued

Il CRL non contiene l'intero certificato, ma solo il suo numero di serie. Pertanto, una CA deve solo conoscere il numero di serie per il certificato specifico da revocare e non è necessario tenere traccia del certificato completo.

Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

I CRL sono firmati, quindi falsificare un CRL non è possibile a meno che non venga rubata la chiave privata dell'emittente CRL (cioè la CA).