Certifikattilbagekaldelsesliste er en liste over certifikater , som certificeringsmyndigheden har markeret som tilbagekaldt . Certificate Revocation Lists (CRL'er) bruges til at bestemme, om en brugers eller CA's certifikat er blevet tilbagekaldt på grund af nøglekompromittering. En vigtig egenskab ved COS er, at den kun indeholder information om certifikater, der ikke er udløbet.
Historien om oprettelsen af PKI ( Public Key Infrastructure ) går tilbage til Whitfield Diffie og Martin Hellmans originale arbejde med offentlig nøglekryptering , som foreslår en mappe med offentlige filer, som brugere kan bruge til at finde andre brugeres offentlige nøgler.
Da Lauren Confelder indså nogle af ulemperne ved denne tilgang, herunder at deaktivering af biblioteksadgang ville forhindre brugere i at kommunikere sikkert, foreslog Confelder konceptet med certifikater i 1978. Certifikater adskiller signerings- og opslagsfunktionalitet, hvilket gør det muligt for en CA at knytte et navn til en nøgle ved hjælp af en digital signatur og derefter gemme det resulterende certifikat i et lager. Fordi lagring kan replikeres og gøres fejltolerant, eliminerer CA-tilgangen mange af de problemer, der er forbundet med katalogets holdbarhed.
Et par år efter at Confelder offentliggjorde sin afhandling, indarbejdede udviklerne brugen af certifikatet i X.500 , en global fortegnelse over navngivne enheder, der drives af monopol-telekommunikationsselskaber. X.500 biblioteket foreslår en hierarkisk databasemodel med en sti gennem biblioteket defineret af en række Relative Distinguished Name (RDN) komponenter, som tilsammen danner et Distinguished Name (DN). For at beskytte adgangen til biblioteket har dets udviklere foreslået forskellige adgangskontrolmekanismer, lige fra simple adgangskodebaserede foranstaltninger til en relativt ny tilgang til brugen af digitale signaturer. Denne standard, inkluderet i X.500 , var X.509v1- standarden . I øjeblikket er der en version x.509v3.
Udviklerne baserede konceptet med SOS på kreditkorts sortlister, der blev brugt i 1970'erne. Kreditkortselskaber udskrev med jævne mellemrum hæfter med annullerede kortnumre og distribuerede dem til handlende med forventning om, at de ville tjekke alle kort, de havde med på sortlisten, før de accepterede dem. De samme problemer, som påvirkede blacklisting af kreditkort, påvirker SOS i dag.
Certificeringsmyndigheden udsteder med jævne mellemrum en liste, som den offentliggør i lageret. Hver COS indeholder et nextUpdate-felt, der angiver tidspunktet for, hvornår den næste COS vil blive frigivet. Enhver afhængig part, der har brug for certifikatstatusoplysninger og ikke allerede har en aktuel CRL, får den aktuelle liste fra butikken. Hvis certifikatet, som klienten verificerer, ikke er på listen, fortsætter arbejdet normalt, og nøglen anses for at være et valideret certifikat. Hvis certifikatet er til stede, betragtes nøglen som ugyldig og kan ikke stoles på.
For at forbedre ydeevnen kan kopier af CRL spredes på tværs af flere butikker. Hver afhængige part har brug for den mest ajourførte liste for at kunne udføre kontrollen. Når en afhængig part modtager den seneste SOS, behøver den ikke at anmode om yderligere oplysninger fra lageret, før en ny SOS er udstedt. Som et resultat, i løbet af den tidsperiode, hvor COS'en er gyldig (det vil sige den mest aktuelle), vil hver afhængige part ikke sende mere end én anmodning til lageret for COS'en. Denne anmodning vil blive fremsat for første gang, efter at den aktuelle SOS er frigivet.
Der er også en delta-SOS-mekanisme, som er en valgfri mekanisme specificeret i RFC 2459 , som kan bruges til at forbedre udbredelsen af tilbagekaldelsesinformation. Delta-CRL'erne er relativt små i størrelse og indeholder kun de ændringer i certifikattilbagekaldelseslister, der har fundet sted siden den sidste version af den absolutte liste (komplet CRL) blev kompileret af CA. Fordi delta-CRL'er er små, kan PKI-klienter downloade dem oftere end komplette CRL'er, så CA giver sine klienter mere nøjagtige oplysninger om tilbagekaldte certifikater.
Nogle problemer gør det svært at arbejde med SOS. COS er i nogle tilfælde upålidelig som en mekanisme til at udbrede certifikatstatus. Kritiske applikationer kræver øjeblikkelig tilbagekaldelse - eller mere specifikt, certifikatstatusoplysninger i realtid - og CRL'er løser ikke altid dette grundlæggende problem af flere årsager.
De vigtigste problemer ved SOS:
SOS lider af flere andre praktiske problemer. For at sikre rettidige statusopdateringer bør serveren udstede en SOS så ofte som muligt. Udstedelse af et SOS øger dog belastningen på serveren og netværket, der transmitterer det, og i mindre grad på klienten, der modtager det. For eksempel downloader 10 millioner klienter 1 MB SOS udstedt én gang i minuttet = trafik ~ 150 GB/s. Derfor er det en dyr operation. Udstedelse af et SOS én gang i minuttet giver en moderat rettidig tilbagekaldelse på bekostning af en enorm overhead, da hver afhængige part downloader en ny SOS (i mange tilfælde falder denne opgave til Delta SOS, og problemet er løst). På den anden side sikrer forsinkelse af udstedelse til én gang i timen eller om dagen ikke rettidig tilbagekaldelse, forudsat at nogle certifikater blev tilbagekaldt i denne periode.
CRL'er mangler også mekanismer til at opkræve afhængige parter for tilbagekaldelseskontrol. Når en certifikatmyndighed udsteder et certifikat, opkræver den brugeren et gebyr. Det beløb, en CA opkræver, afhænger normalt af, hvor meget den verificerer, før den udsteder et certifikat. På den anden side forventer brugerne, at CA'er opretter og udsteder SOC'er gratis. Hverken brugeren eller CA kan entydigt sige, hvem der skal kontrollere certifikatet, hvor ofte det vil blive kontrolleret, eller hvilken forsinkelse der vil være acceptabel. Denne situation tjener som en aktiv afskrækkelse for CA'er til at fokusere stærkt på SOS, da de kræver behandlingstid, en eller flere servere og betydelig netværksbåndbredde for at skabe og distribuere dem.
I øjeblikket er der flere analoger af SOS, der ikke har ulemperne ved SOS, men som samtidig har deres egne.
En af analogerne er OCSP - Online Certificate Status Protocol . Denne løsning giver et realtidssvar fra serveren om det pågældende certifikat. Denne tilgang løser mange af de problemer, der er forbundet med SOS, ved at skabe en engangs, frisk SOS med en enkelt indtastning pr. anmodning. I modsætning hertil kræver den COS-baserede model, at afhængige parter gentagne gange henter en enorm mængde irrelevante poster for at få statusoplysninger for det ene certifikat, de har brug for. OCSP har dog en omkostning. I stedet for at forberede COS'en som en offline offline-operation i baggrunden, skal CA'en nu udføre et certifikatopslag og en pseudo-COS-genereringsoperation for hver anmodning. For at gøre OCSP omkostningseffektiv skal CA opkræve et gebyr for hver tilbagekaldelseskontrol. OCSP løser dette problem ved at underskrive anmodninger om afsenderidentifikation til faktureringsformål.
Denne metode har også sine ulemper. Den største ulempe ved OCSP er, at den i stedet for et simpelt ja eller nej svar på en gyldighedsanmodning bruger flere ikke-ortogonale certifikatstatusværdier , da det ikke kan give et rigtigt præcist svar. Denne tvetydighed stammer i det mindste delvist fra den oprindelige COS-baserede certifikatstatusmekanisme. Da COS'en kun kan give et negativt resultat, betyder det, at et certifikat ikke er til stede i COS'en, ikke, at det nogensinde er blevet udstedt eller stadig er gyldigt.
Hovedproblemet med sortlistebaserede tilgange som COS og OCSP er, at de stiller det forkerte spørgsmål. I stedet for at spørge "Er certifikatet gyldigt i øjeblikket?" spørger de "Er certifikatet tilbagekaldt?", fordi det er det eneste spørgsmål, en sortliste kan besvare.
OCSP afslører også klientens forbindelseshistorik for en tredjepart (CA).
OCSP- hæftning er OCSP- hæftning Det eliminerer behovet for at genindsende OCSP-anmodningen ved at udstede et OCSP-svar sammen med selve certifikatet. Dette kaldes OCSP-hæftning, fordi serveren skal "hæfte" OCSP-svaret med certifikatet og udstede dem sammen. Når en forbindelse er etableret, sender serveren sin certifikatkæde til klienten sammen med de tilsvarende OCSP-svar. OCSP-svaret er kun gyldigt i en kort periode og er underskrevet af en CA på samme måde som et certifikat. Dette eliminerer også OCSP-privatlivsproblemet, da respondenten ikke har adgang til webstedsbesøgendes detaljer. Det er ikke bredt implementeret, kun 3% af serverne understøtter OCSP-hæftning.
En mulig anvendelse af offentlig nøgleinfrastruktur er HTTPS . Mange browsere bruger 2 hovedtilgange: SOS og OCSP. Mozilla Firefox downloader ikke automatisk SOS. Browseren bruger OCSP til at kontrollere, om certifikatet er blevet tilbagekaldt. Internet Explorer og Opera gør et meget mere grundigt stykke arbejde; de understøtter begge OCSP og CRL og udfører passende kontroller for alle typer certifikater. Men SOS bruges hovedsageligt som et faldback i denne test.
Et vigtigt anvendelsesområde for PKI, og SOS i særdeleshed, er den elektroniske signatur . Certifikatet bekræfter, at de offentlige og private nøgler tilhører dens ejer. Tilbagekaldelse af certifikatet betyder, at nøglen er blevet kompromitteret .
Verifikationsalgoritmen er som følger: