Un CRL ha un valore ed è accettabile in quanto firmato . Dal momento della firma del CRL, il modo in cui l'hai ottenuto non ha alcuna conseguenza sulla sua accettabilità. Questo è il punto di certificati e CRL: possono essere distribuiti su reti arbitrarie, protetti o meno, anche semplici HTTP, e-mail, vettori aerei ... non importa.
Viceversa, il fatto che il CRL sia "online" non lo rende migliore; devi ancora verificare la firma, le date e così via.
Quindi, CRL (o certificati, o risposte OCSP) possono essere perfettamente integrati, trasmessi insieme ai dati che qualificano, o qualsiasi altra cosa. Ad esempio, un CMS (PKCS # 7) SignedData oggetto contiene campi chiamati certificates e crls con precisione per incorporare certificati e CRL (e risposte OCSP) che i ricevitori di tale oggetto possono trovare utili per scopi di convalida. Analogamente, quando un server SSL / TLS invia il suo certificato, invia anche alcuni certificati extra (una "catena") che il cliente può utilizzare (a suo piacimento) per convalidare il certificato del server.
Quando una CA divide il CRL in più CRL sub, viene esplicitamente indicato l'ambito di ogni CRL: un certificato è nell'ambito di un CRL se il certificato contiene un'estensione% (%) critica di co_de con un "Punto di distribuzione" "che corrisponde all'estensione CRL Distribution Points nel CRL. Vedi RFC 5280 , sezione 6.3.3, passaggio (b). (2). (I ). Questa divisione CRL non è quindi un problema.
Una divisione ancora più estrema è incarnata da OCSP . OCSP è sia un formato per oggetti firmati (le "risposte OCSP"), sia un protocollo di comunicazione per ottenere una risposta OCSP da un risponditore online. Ogni risposta OCSP è funzionalmente equivalente a un CRL che parla di un singolo certificato. Quindi, questo è come il CRL più diviso che puoi immaginare, eppure non crea alcuna informazione ambigua perché ogni risposta OCSP indica esplicitamente di quale certificato si tratta.
Pertanto, che un CRL è diviso o meno non induce alcun punto debole; e ottenere un CRL nuovo dalla CA non risolverebbe nulla, dal momento che il processo di download non è comunque protetto.
Per quanto riguarda la seconda domanda: infatti, lo stato di revoca è, per definizione, una proprietà transitoria. Da un lato, che il certificato del firmatario è stato revocato a un certo punto nel passato (cioè le informazioni fornite da un vecchio CRL) non garantisce in alcun modo che il certificato sia ancora non revocato e, in particolare, che la chiave privata non sia stata compromesso nel frattempo. D'altra parte, il CRL recente non parla di certificati scaduti (e questo è il punto di scadenza del certificato: per impedire che CRL possa crescere per sempre).
L'uscita da questo enigma è data e ora . Con un timestamp, puoi in qualche modo "congelare" un oggetto in un momento nel tempo. L'idea è che, alla data T , tu prendi l'oggetto firmato, insieme a tutti i certificati e CRL che possono essere utilizzati per convalidare la firma in quella data. Si mettono tutti questi in un formato di archivio, quindi si ottiene un timestamp nel suo complesso. In un secondo momento T ', si convalida il timestamp; se il timestamp è valido (alla data T '), allora sai che tutti i contenuti dell'archivio esistevano già alla data T , e puoi quindi procedere alla convalida della firma e usa i certificati e il CRL come se la data corrente fosse ancora T . Il concetto è che SE hai fatto la convalida alla data T , POI lo ricorderesti ancora e agisci su di esso; con il timestamp, sai che alla data T tutti i certificati e il CRL esistevano così come sono, e quindi avresti potuto fare quella convalida.
Ci sono molte sottigliezze in questo processo, motivo per cui alcuni standard sono stati definiti per supportarlo correttamente. Cerca CAdES (e possibilmente i suoi fratelli XAdES e PAdES, rispettivamente per XML-DSig e PDF firmato).