CRL on objekt, mis sisaldab antud CA poolt tühistatud sertifikaatide seerianumbrite loendit. See on allkirjastatud objekt; CRL-i väljastaja on tavaliselt CA ise (sama võtmega), kuid selle volituse saab delegeerida.
OCSP-vastus on see, mille OCSP-vastaja tagastab, kui ta saab sellekohase päringu sertifikaadi kehtetuks tunnistamise olek. Taotluse / vastuse protokoll on täpsustatud RFC 2560. Vastused ise on vastaja allkirjastatud ja neil võib olla iseseisev elu; see tähendab, et antud OCSP vastust saab pidada spetsiaalseks CRL-iks, mis räägib ühest sertifikaadist.
Sertifikaadi valideerimise ajal kontrollib tõendaja (nt veebibrauser serveri sertifikaat) peab ehitama ühest oma usalduse ankrust (aka juursertifikaadid) sertifikaatide ahela, kontrollima kõiki allkirju, nimesid ja laiendusi ning seejärel jätkama tühistamise oleku ahela igast sertifikaadist. See viimane etapp hõlmab CRL-i ja / või OCSP-vastuste hankimist, nende kinnitamist (mis tähendab nende allkirjade kontrollimist) ja nende sisu lugemist. See tõstatab kahte erinevat tüüpi küsimust:
- kuidas kontrollib kontrollija, kas CRL-i või OCSP-vastus on tõeline ja ajakohane ning kehtib tegelikult olemasoleva sertifikaadi kohta?
- Kuidas saab tõendaja kõigepealt CRL-i või OCSP-vastuse?
CRL / OCSP sobib sertifikaadiga
Keskendume järgmisele seadistamisele: kontrollija soovib saada sertifikaadi T tühistamise oleku ("sihtmärgina"). Ta on juba loonud ja kontrollinud sertifikaatide ahela, mis lõpeb CA-sertifikaadiga C , millele järgneb T , mis tähendab, et allkiri T -il vastab avalik võti C s. Samuti on kinnitatud C tühistamise olek ja nüüd on kontrollija huvitatud T st. T võib olla lõpp- üksuse sertifikaat (nt SSL-serveri sertifikaat) või mõni muu CA-sert pikema keti osana, mis ulatub väljapoole T.
CRL on allkirjastatud; Kes sellele alla kirjutab, on vaja peenet vahet teha X.509 ja selle PKIX-tõlgenduse vahel Interneti kontekstis. "Algse" X.509 puhul on CRL kehtiv, kui sellele on alla kirjutanud üksus, kellel on kehtiv sertifikaat ja millel on sama eristatav nimi kui CA-l. See töötab hästi, kui CRL-i allkirjastab sama avalik võti kui T , st CA võti C : sel hetkel C on täielikult valideeritud sertifikaat, nii et selle avalikku võtit saab "usaldada" (tõendaja on piisavalt kindel, et avalik võti kuulub tegelikult üksusele, mis asub C 's antud nime all subjektDN väli). See võib olla aga mõni muu sellenimeline sertifikaat, mis asub kehtiva oma ahela lõpus (mis võib tähendada CRL-i suurema rajamist, valideerimist ja töötlemist). X.509-s on eristatavad nimed kõik, sest X.509 oli mõeldud kataloogi jaoks, ülemaailmseks LDAP-laadseks serverikogumiks, kus kõigele on selle ainulaadne viide .
Internetiga tegelev töögrupp PKIX on märganud, et kataloogil on nii imeline kui ka müütilised loomad, näiteks Mokèlé-mbèmbé, mõned omadused, täpsemalt, et see ei tunduvad üldse olemas olevat (vähemalt pole kinnitatud nähtavust teatatud). Vastavalt rakendab PKIX piirangut probleemide hoidmiseks: CRL-i väljaandja sertifikaat peab olema tee lõpus, mis algab sama usalduse ankruga kui teekond, mis lõpeb tähega T . See peaks vältima juurtevahelisi probleeme, kui kaks erinevat CA-d, kes teineteist ei tunne, kasutasid lõpuks samu eristavaid nimesid (nad oleksid võinud probleemi kohe märgata, kui oleksid töötanud kataloogi kontekstis, kui see oleks olemas). See konkreetne punkt on RFC 5280 jaotise 6.3.3 etapis (f).
CRL-i väljaandja rolli saab delegeerida ja sel juhul on CRL-i eristatav nimi väljaandja on leitud laiendist CRL levitamispunktid T endas ja vastav Issuing Distribution Point laiend leitakse CRL-ist.
OCSP-vastuste jaoks kasutatakse sarnast süsteemi. OCSP vastuse võib CA ise allkirjastada (võtmega klahvis C ); või võib olla spetsiaalne emitent. Asjad on seal piiratumad: kui on olemas spetsiaalne väljaandja, peab tal olema sertifikaat, mille on otse välja andnud C ise ja millel on konkreetne laiendus, mis tähistab teda OCSP-vastajana ( Extended Võtme kasutamine koos koodiga id-kp-OCSPSigning OID, vt RFC 2560 jaotist 4.2.2.2). Selle vastaja sertifikaadi saab lisada ise OCSP-vastusele (väljaspool allkirjastatud ala, kuid sellegipoolest kodeeritud samas plekis).
Oluline on see, et pole oluline, kuidas CRL-i või OCSP-vastus saadi : need on allkirjastatud objektid, allkirjade kontrollimine ning kogu nimede sobitamise ja laienduse sisu on piisav. Objekt ise saab rännata üle TCP-ühenduste, meilide, USB-võtmete, kaamelite haagissuvilate, õppinud peast ja Shakespearian näitleja poolt ära kuulutatud. Allkiri võtab need üksikasjad ära. Sertifikaate, CRL-i ja OCSP-vastuseid ei saa allkirja kehtetuks muutmisega "manipuleerida".
CRL-i ja OCSP-vastustel on kehtivuse kuupäevad . Neil mõlemal on väli thisUpdate , mis annab teada nende väljastamise ajast (ametlikult kuupäev, millal neis sisalduv teave koguti). Neil on ka väli nextUpdate , mis on kuupäev, enne mida tuleks uuem versioon välja anda; seega on see omamoodi aegumiskuupäev. Eeldatakse, et kontrollijad vahemällu salvestavad CRL-i ja OCSP-vastused, kasutades neid kuupäevi, et teada saada, kas vahemällu salvestatud versioon on endiselt kasutatav või tuleks hankida uus.
Kuidas leida CRL-i ja OCSP-vastuseid
CRL-i või OCSP-vastuse levitamise viis pole turvalisuse jaoks oluline, kuid loomulikult ei saa kontrollija URL-i tühjast kohast ära arvata. URL, kust CRL-i alla saab laadida, on kodeeritud sertifikaadi T laiendisse CRL-i jaotuspunktid (sellel laiendil on kaks rolli: valideeriv roll CRL-i väljaandmise volituste delegeerimisel ja kirjeldav roll, mis annab viite kohtadele, kust saab tegeliku CRL-i alla laadida). http: // URL on tavaline, kuid ka ldap: // URL (eriti suletud keskkonnas, näiteks ettevõtte võrkudes). https: // URL CRL-i allalaadimiseks võib viia tsüklini (kuna allalaadimine tähendab muu SSL-serveri sertifikaadi kinnitamist), mistõttu seda ei toetata hästi või üldse (Windows ei järgi sellist URL-i).
Samamoodi on URL, kust leiate OCSP-vastaja, sertifikaadi T.
laiendis Authority Information Access ainult soovituslik; tõendaja võib kasutada mis tahes CRL- või OCSP-vastust, mille ta võib saada, olenemata selle päritolust, tingimusel et kõik allkirjad on kontrollitud. Kuna CRL-i ja OCSP-vastuste eluiga on tühine, on mõttekas need vahemällu salvestada ja uuesti kasutada. OCSP klammerdamine on viis, kuidas SSL server saab oma sertifikaadi jaoks OCSP-vastused ja pakub neid kliendile, eeldades, et klient võib neid vajada. See muudab kogu protsessi efektiivsemaks: klient ei pea ise OCSP-vastuste saamiseks täiendavaid ühendusi avama ning server võib sama aja jooksul raamistiku jooksul kõigile klientidele sama OCSP-vastuse saata. Üks võimalus selle nägemiseks on see, et SSL-server toimib veebipuhverserverina OCSP-vastuste allalaadimiseks.
OCSP-klammerdamine sõltub täielikult SSL-serverist; sertifikaatide ja OCSP-vastuste sisu ei muutu. CA või OCSP-vastaja ei pea teadma, et klammerdamist üldse esineb.
OCSP klammerdamise lipu "käepigistuselt" eemaldamine katkestaks sõnumi Valmis . käepigistus, seega pole see ründajal teostatav, kui see ei võimaldaks tal kogu käepigistus enne lõppu murda. Kuid see pole nii: OCSP klammerdamise puudumine ei tähenda, et klient ei tuvastaks tühistamise olekut; see tähendab lihtsalt seda, et klient on omaette ja peab ise saama CRL-i või OCSP-vastused.
OCSP klammerdamise puhul on kahetsusväärne see, et seda veel ei toetata. Idee on siiski kindel. Selle turvamõju on see, et klammerdamise korral on SSL-serveril võimas argument veenda veebibrauserit tegelikult oma tööd tegema ja mitte tühistamise oleku kontrolle üldse vahele jätma, nagu paljud veebibrauserid on kahjuks altid tegema (asjad muutuvad selles küsimuses, kuid aeglaselt).
Märkus: CRL / OCSP vastuse eluiga ulatub tavaliselt mõnest minutist mõne päevani. Kuupäevad kontrollitakse kliendi aja mõistega; aegunud kelladega kliendid võivad hätta jääda.