Durante la normale convalida della catena, si suppone di controllare lo stato di revoca di ciascun certificato nella catena. Per verificare lo stato di revoca, è necessario ottenere una risposta CRL o OCSP; entrambi i tipi di oggetti sono firmati e, prima dell'uso, devono essere convalidati. La convalida di una risposta CRL o OCSP implica la verifica di una firma, relativamente alla chiave pubblica dell'emittente dell'oggetto, la chiave pubblica ottenuta da ... la convalida di un'altra catena di certificati. L'intero processo è ricorsivo e si può finire con la convalida di molti certificati nel processo.
Ovviamente, la ricorsione ha potenziale per i loop e i loop sono cattivi.
Considera un percorso semplice: Root - > SubCA - > EE.
Stai convalidando il percorso, hai verificato tutte le firme e hai raggiunto un punto in cui hai anche verificato che il SubCA non è stato revocato. Ora stai considerando il certificato EE. Il certificato EE contiene un'estensione AIA che punta a un risponditore OCSP; parli con quel risponditore e ottieni una risposta OCSP. Grande ! La risposta OCSP sembra essere stata firmata direttamente da SubCA, utilizzando la sua chiave privata (la stessa chiave privata utilizzata per firmare il certificato EE). Questo è buono: hai già convalidato quella chiave, incluso lo stato di revoca , quindi è sufficiente controllare la firma sulla risposta OCSP, e quindi puoi usarla ("usare" una risposta OCSP significa guardare i suoi contenuti e fidandosi di loro).
Questo modello sopra è "situazione 2" dalla sezione 4.2.2.2 di RFC 2560 : il certificato utilizzato per convalidare il La risposta OCSP è uguale al certificato della CA che ha emesso il certificato di destinazione ("SubCA" nel nostro esempio).
Si suppone che un altro modello sia supportato, descritto come "situazione 3" dalla sezione 4.2.2.2: la risposta OCSP è firmata da un risponditore dedicato, che ha un certificato (chiamiamolo "Resp") che è emesso da SubCA. Il certificato Resp è incorporato nella risposta OCSP. Come lo convalidi? È abbastanza facile controllare le firme e anche controllare che Resp sia l'EKU specifico che contrassegna i risponditori OCSP delegati. Ma come ci si assicura che il certificato Resp non sia stato revocato?
I tre modi possibili sono:
- Usi un CRL o un altro risponditore OCSP che ti darà le informazioni. Questo, ovviamente, rende il processo ricorsivo.
- Resp è fatto per includere l'estensione specifica
id-pkix-ocsp-nocheck , il che rende il certificato Resp "non revocabile" (quindi non è necessario ottenere lo stato di revoca, poiché non è definito per definizione).
- La CA non interessa, e include in Resp un AIA che punta a sé come responder OCSP. Pertanto, per convalidare Resp, devi prima convalidare Resp. Affrontati da questo problema di pollo e uova, piangi, quindi unisciti alla CA nella sua apatia e considera semplicemente che Resp è "probabilmente soddisfacente".
Sfortunatamente, ho incontrato la terza via nel grande PKI sponsorizzato da grandi corporation o stati sovrani che dovrebbero davvero conoscere meglio.
La sezione 4.2.2.2 di RFC 2560 allude anche a una "situazione 1" in cui il risponditore OCSP è "qualcos'altro" che il motore di validazione sa in qualche modo di essere sicuro attraverso qualche "configurazione locale" (l'espressione "configurazione locale" è RFC-speak to sign "dalla magia delle Fate").
Il testo che citi significa che Windows, fino a Vista, sa come gestire le situazioni 2 e 3. Da Vista SP1 in poi, gestisce anche la situazione 1, con la seguente svolta: il certificato del risponditore OCSP può essere "qualsiasi certificato" ma CryptoAPI richiederà CRL per convalidarlo. Questo è un modo drastico per evitare loop di validazione.
Riepilogo: se si sta creando la PKI, il metodo che causerà il minimo problema consiste nell'utilizzare la chiave CA per firmare le risposte OCSP. Se veramente è necessario utilizzare una chiave distinta (ad esempio, la CA deve essere offline, ma il risponditore OCSP, per sua natura, è online), quindi rilasciare alla CA un certificato dedicato per il risponditore OCSP . Questo certificato di risponditore dedicato deve contenere id-kp-OCSPSigning EKU e l'estensione id-pkix-ocsp-nocheck . Poiché un certificato non reversibile può essere considerato una grave violazione della politica, il modo consigliato è di renderlo molto breve: impostare il certificato di risposta in modo che sia valido per una quindicina di giorni e emetterne uno nuovo molto a settimana.
Come altri hanno notato, molte implementazioni non controllano lo stato di revoca dei certificati "extra" (i certificati non nella catena principale, ma che sono usati per verificare gli oggetti di revoca come le risposte CRL o OCSP), che è sciatta ma spesso resa necessaria (in modo commerciale) per far fronte al grande PKI che non fa le cose correttamente. È vostro dovere morale fare di meglio (come espongo in precedenza) in modo da avvicinarci al punto in cui PKI effettivamente, sapete, funzionerà e fornirà sicurezza.