Lista de revocare a certificatelor este o listă de certificate pe care autoritatea de certificare le- a marcat ca fiind revocate . Listele de revocare a certificatelor (CRL) sunt utilizate pentru a determina dacă certificatul unui utilizator sau al CA a fost revocat din cauza compromiterii cheii. O proprietate importantă a COS este că conține informații doar despre certificatele care nu au expirat.
Istoria creării PKI ( Public Key Infrastructure ) se întoarce la munca inițială a lui Whitfield Diffie și Martin Hellman privind criptografia cu chei publice , care propune un director de fișiere publice pe care utilizatorii le-ar putea folosi pentru a găsi cheile publice ale altor utilizatori.
Realizând unele dintre dezavantajele acestei abordări, inclusiv faptul că dezactivarea accesului la director ar împiedica utilizatorii să comunice în siguranță, Confelder a propus conceptul de certificate în 1978. Certificatele separă semnarea și funcționalitatea de căutare, permițând unei CA să asocieze un nume cu o cheie folosind o semnătură digitală și apoi să stocheze certificatul rezultat într-un depozit. Deoarece stocarea poate fi replicată și făcută tolerantă la erori, abordarea CA elimină multe dintre problemele asociate cu durabilitatea directorului.
La câțiva ani după ce Confelder și-a publicat disertația, dezvoltatorii au încorporat utilizarea certificatului în X.500 , un director global de entități denumite operate de companii de telecomunicații cu monopol. Directorul X.500 propune un model de bază de date ierarhică, cu o cale prin director definită de o serie de componente Relative Distinguished Name (RDN), care împreună formează un Distinguished Name (DN). Pentru a proteja accesul la director, dezvoltatorii săi au propus diverse mecanisme de control al accesului, de la simple măsuri bazate pe parole până la o abordare relativ nouă a utilizării semnăturilor digitale. Acest standard, inclus în X.500 , a fost standardul X.509v1 . Momentan există o versiune x.509v3.
Dezvoltatorii au bazat conceptul de SOS pe liste negre de carduri de credit care au fost folosite în anii 1970. Companiile de carduri de credit tipăriu periodic broșuri cu numerele de card anulate și le distribuiau comercianților, cu așteptarea ca aceștia să verifice toate cardurile cu care se ocupau pe lista neagră înainte de a le accepta. Aceleași probleme care au afectat lista neagră a cărților de credit afectează SOS astăzi.
Autoritatea de certificare emite periodic o listă pe care o publică în depozit. Fiecare COS include un câmp nextUpdate care indică ora la care va fi lansat următorul COS. Orice parte de încredere care are nevoie de informații despre starea certificatului și nu are deja un CRL actual primește lista curentă din magazin. Dacă certificatul pe care clientul îl verifică nu este în listă, atunci lucrul continuă în mod normal și cheia este considerată a fi un certificat validat. Dacă certificatul este prezent, atunci cheia este considerată nevalidă și nu poate fi de încredere.
Pentru a îmbunătăți performanța, copiile CRL pot fi răspândite în mai multe magazine. Fiecare parte care se bazează are nevoie de cea mai actualizată listă pentru a efectua verificarea. Odată ce o parte de încredere primește cel mai recent SOS, nu va trebui să solicite informații suplimentare de la depozit până când este emis un nou SOS. Ca urmare, în perioada de timp în care COS este valabil (adică cea mai actuală), fiecare parte care se bazează va trimite nu mai mult de o solicitare la stocarea pentru COS. Această solicitare va fi făcută pentru prima dată după lansarea actualului SOS.
Există, de asemenea, un mecanism delta-SOS, care este un mecanism opțional specificat în RFC 2459 care poate fi utilizat pentru a îmbunătăți propagarea informațiilor de revocare. CRL-urile delta au dimensiuni relativ mici, conținând doar acele modificări ale listelor de revocare a certificatelor care au avut loc de când ultima versiune a listei absolute (CRL complet) a fost compilată de CA. Deoarece delta-CRL-urile sunt mici, clienții PKI le pot descărca mai des decât CRL-urile complete, astfel încât CA oferă clienților săi informații mai precise despre certificatele revocate.
Unele probleme fac dificilă lucrarea cu SOS. COS este, în unele cazuri, nesigur ca mecanism de propagare a statutului de certificat. Aplicațiile critice necesită revocare imediată - sau mai precis, informații despre starea certificatului în timp real - și CRL-urile nu rezolvă întotdeauna această problemă de bază din mai multe motive.
Principalele probleme ale SOS:
SOS suferă de alte câteva probleme practice. Pentru a asigura actualizări de stare în timp util, serverul ar trebui să emită un SOS cât mai des posibil. Totuși, emiterea unui SOS crește încărcarea serverului și a rețelei care îl transmite și, într-o măsură mai mică, a clientului care îl primește. De exemplu, 10 milioane de clienți descarcă 1 MB de SOS emis o dată pe minut = trafic ~ 150 GB/s. Prin urmare, este o operațiune costisitoare. Emiterea unui SOS o dată pe minut oferă o revocare moderată în timp util, în detrimentul unei cheltuieli uriașe, deoarece fiecare parte care se bazează descarcă un nou SOS (în multe cazuri această sarcină revine Delta SOS și problema este rezolvată). Pe de altă parte, amânarea eliberării la o dată pe oră sau pe zi nu asigură revocarea în timp util, cu condiția ca unele certificate să fie revocate în această perioadă.
CRL-urilor nu dispun, de asemenea, de mecanisme de taxare a părților care se bazează pentru verificarea revocării. Când o autoritate de certificare emite un certificat, percepe utilizatorului o taxă. Suma percepută de un CA depinde de obicei de cât verifică înainte de a emite un certificat. Pe de altă parte, utilizatorii se așteaptă ca CA să creeze și să emită SOC-uri gratuit. Nici utilizatorul, nici CA nu pot spune fără echivoc cine va verifica certificatul, cât de des va fi verificat sau ce întârziere va fi acceptabilă. Această situație servește ca un factor de descurajare activ pentru CA de a se concentra în mare măsură pe SOS, deoarece necesită timp de procesare, unul sau mai multe servere și lățime de bandă semnificativă a rețelei pentru a le crea și distribui.
În momentul de față, există mai mulți analogi ai SOS care nu au dezavantajele SOS, dar în același timp au propriile lor.
Unul dintre analogi este OCSP - Online Certificate Status Protocol . Această soluție de soluție oferă un răspuns în timp real din partea serverului cu privire la acel certificat particular solicitat. Această abordare rezolvă multe dintre problemele inerente SOS prin crearea unui SOS unic, proaspăt, cu o singură intrare per cerere. În schimb, modelul bazat pe COS cere părților care se bazează să preia în mod repetat o cantitate imensă de înregistrări irelevante pentru a obține informații despre starea certificatului de care au nevoie. Cu toate acestea, OCSP are un cost. În loc să pregătească COS ca o operație offline de fundal, CA trebuie acum să efectueze o căutare a certificatului și o operație de generare pseudo-COS pentru fiecare cerere. Pentru ca OCSP să fie rentabil, CA trebuie să perceapă o taxă pentru fiecare control de revocare. OCSP rezolvă această problemă prin semnarea cererilor de identificare a expeditorului în scopuri de facturare.
Această metodă are și dezavantajele ei. Principalul dezavantaj al OCSP este că, în loc de un simplu răspuns da sau nu la o cerere de valabilitate, folosește mai multe valori de statut de certificat neortogonale , deoarece nu poate oferi un răspuns cu adevărat precis. Această ambiguitate provine cel puțin parțial din mecanismul original de statut al certificatului bazat pe COS. Deoarece COS poate oferi doar un rezultat negativ, faptul că un certificat nu este prezent în COS nu înseamnă că acesta a fost eliberat vreodată sau că este încă valabil.
Principala problemă cu abordările bazate pe liste negre, cum ar fi COS și OCSP, este că pun întrebarea greșită. În loc să întrebe „Este certificatul valabil în prezent?”, ei întreabă „Este certificatul revocat?”, deoarece aceasta este singura întrebare la care o listă neagră poate răspunde.
OCSP expune, de asemenea , istoricul conexiunilor clientului unei terțe părți (CA).
Capsarea OCSP este capsarea OCSP Elimină necesitatea de a retrimite cererea OCSP prin emiterea unui răspuns OCSP împreună cu certificatul în sine. Aceasta se numește Capsare OCSP deoarece serverul trebuie să „capseze” răspunsul OCSP cu certificatul și să le emită împreună. Când se stabilește o conexiune, serverul își trimite lanțul de certificate către client împreună cu răspunsurile OCSP corespunzătoare. Răspunsul OCSP este valabil doar pentru o perioadă scurtă de timp și este semnat de o CA în același mod ca un certificat. Acest lucru elimină, de asemenea, problema de confidențialitate OCSP, deoarece respondentul nu are acces la detaliile vizitatorilor site-ului web. Nu este implementat pe scară largă, doar 3% dintre servere acceptă OCSP Stapling.
O posibilă aplicație a infrastructurii cheii publice este HTTPS . Multe browsere folosesc două abordări principale: SOS și OCSP. Mozilla Firefox nu descarcă automat SOS. Browserul folosește OCSP pentru a verifica dacă certificatul a fost revocat. Internet Explorer și Opera fac o treabă mult mai amănunțită; ambele acceptă OCSP și CRL și efectuează verificări adecvate pentru toate tipurile de certificate. Dar SOS este folosit în principal ca alternativă în acest test.
Un domeniu important de aplicare pentru PKI, și SOS în special, este semnătura electronică . Certificatul atestă că cheile publice și private aparțin proprietarului său. Revocarea certificatului înseamnă că cheia a fost compromisă .
Algoritmul de verificare este următorul: