Certificate Revocation List je seznam certifikátů , které certifikační autorita označila jako odvolané . Seznamy odvolaných certifikátů (CRL) se používají k určení, zda byl certifikát uživatele nebo CA odvolán kvůli kompromitaci klíče. Důležitou vlastností COS je, že obsahuje informace pouze o certifikátech, které nevypršely.
Historie vytvoření PKI ( Infrastructure Public Key Infrastructure ) sahá k původní práci Whitfielda Diffieho a Martina Hellmana o kryptografii s veřejným klíčem , která navrhuje adresář veřejných souborů, které by uživatelé mohli použít k nalezení veřejných klíčů jiných uživatelů.
Confelder si v roce 1978 uvědomila některé z nevýhod tohoto přístupu, včetně toho, že zakázání přístupu k adresářům by uživatelům bránilo v bezpečné komunikaci, navrhla koncept certifikátů. Certifikáty oddělují funkce podepisování a vyhledávání, což umožňuje CA přiřadit jméno ke klíči pomocí digitálního podpisu a poté uložit výsledný certifikát do úložiště. Vzhledem k tomu, že úložiště lze replikovat a zajistit odolnost vůči chybám, přístup CA eliminuje mnoho problémů spojených s trvanlivostí adresářů.
Několik let poté, co Confelder zveřejnil svou dizertační práci, vývojáři začlenili použití certifikátu do X.500 , globálního adresáře pojmenovaných subjektů provozovaných monopolními telekomunikačními společnostmi. Adresář X.500 navrhuje hierarchický databázový model s cestou přes adresář definovanou řadou komponent RDN (Relative Distinguished Name), které dohromady tvoří rozlišovací název (DN). K ochraně přístupu k adresáři jeho vývojáři navrhli různé mechanismy řízení přístupu, od jednoduchých opatření založených na heslech až po relativně nový přístup k používání digitálních podpisů. Tento standard, zahrnutý v X.500 , byl standardem X.509v1 . V tuto chvíli existuje verze x.509v3.
Vývojáři založili koncept SOS na blacklistech kreditních karet, které se používaly v 70. letech. Společnosti vydávající kreditní karty pravidelně tiskly brožury se zrušenými čísly karet a distribuovaly je obchodníkům s očekáváním, že před přijetím zkontrolují všechny karty, se kterými se zabývají, na černé listině. Stejné problémy, které ovlivnily blacklist kreditních karet, ovlivňují SOS i dnes.
Certifikační autorita pravidelně vydává seznam, který zveřejňuje v úložišti. Každý COS obsahuje pole nextUpdate, které označuje čas, kdy bude uvolněn další COS. Každá spoléhající strana, která potřebuje informace o stavu certifikátu a ještě nemá aktuální CRL, získá aktuální seznam z úložiště. Pokud certifikát, který klient ověřuje, není v seznamu, práce pokračuje normálně a klíč je považován za ověřený certifikát. Pokud je certifikát přítomen, je klíč považován za neplatný a nelze mu důvěřovat.
Pro zlepšení výkonu lze kopie CRL rozmístit ve více obchodech. Každá spoléhající strana potřebuje k provedení kontroly nejaktuálnější seznam. Jakmile spoléhající strana obdrží nejnovější SOS, nebude muset vyžadovat další informace z úložiště, dokud nebude vydáno nové SOS. Výsledkem je, že během časového období, během kterého je COS platný (tj. nejaktuálnější), každá spoléhající se strana nepošle do úložiště pro COS více než jeden požadavek. Tento požadavek bude proveden poprvé po vydání aktuálního SOS.
Existuje také mechanismus delta-SOS, což je volitelný mechanismus specifikovaný v RFC 2459 , který lze použít ke zlepšení šíření informací o odvolání. Rozdílové seznamy CRL mají relativně malou velikost a obsahují pouze změny v seznamech zneplatněných certifikátů, ke kterým došlo od doby, kdy CA sestavil poslední verzi absolutního seznamu (úplného seznamu CRL). Protože jsou delta-CRL malá, klienti PKI si je mohou stahovat častěji než kompletní CRL, takže CA poskytuje svým klientům přesnější informace o odvolaných certifikátech.
Některé problémy znesnadňují práci s SOS. COS je v některých případech nespolehlivý jako mechanismus pro šíření stavu certifikátu. Kritické aplikace vyžadují okamžité odvolání – nebo konkrétněji informace o stavu certifikátu v reálném čase – a seznamy CRL tento základní problém vždy nevyřeší z několika důvodů.
Hlavní problémy SOS:
SOS trpí několika dalšími praktickými problémy. Pro zajištění včasných aktualizací stavu by měl server vydávat SOS co nejčastěji. Vydání SOS však zvyšuje zatížení serveru a sítě, která jej přenáší, a v menší míře i klienta, který jej přijímá. Například 10 milionů klientů si stáhne 1 MB SOS vydané jednou za minutu = provoz ~ 150 GB/s. Jedná se tedy o nákladnou operaci. Vydání SOS jednou za minutu poskytuje středně včasné odvolání na úkor obrovské režie, protože každá spoléhající strana stahuje nové SOS (v mnoha případech tento úkol spadá do Delta SOS a problém je vyřešen). Na druhou stranu odložení vydání na jednu hodinu nebo den nezajistí včasnou revokaci za předpokladu, že některé certifikáty byly v tomto období revokovány.
Seznamy CRL také postrádají mechanismy pro zpoplatnění spoléhajících se stran za kontrolu odvolání. Když certifikační autorita vydá certifikát, účtuje uživateli poplatek. Částka, kterou CA účtuje, obvykle závisí na tom, kolik ověřuje před vydáním certifikátu. Na druhou stranu uživatelé očekávají, že CA budou vytvářet a vydávat SOC zdarma. Uživatel ani CA nemohou jednoznačně říci, kdo bude certifikát kontrolovat, jak často bude kontrolován nebo jaké zpoždění bude přijatelné. Tato situace slouží jako aktivní odstrašující prostředek pro CA, aby se výrazně zaměřily na SOS, protože jejich vytvoření a distribuce vyžadují dobu zpracování, jeden nebo více serverů a značnou šířku pásma sítě.
V současné době existuje několik analogů SOS, které nemají nevýhody SOS, ale zároveň mají své vlastní.
Jedním z analogů je OCSP - Online Certificate Status Protocol . Toto zástupné řešení poskytuje odpověď serveru v reálném čase o konkrétním požadovaném certifikátu. Tento přístup řeší mnoho problémů spojených s SOS vytvořením jednorázového, čerstvého SOS s jediným záznamem na požadavek. Naproti tomu model založený na COS vyžaduje, aby spoléhající strany opakovaně stahovaly obrovské množství irelevantních záznamů, aby získaly stavové informace pro jeden certifikát, který potřebují. OCSP však něco stojí. Namísto přípravy COS jako offline operace na pozadí musí nyní certifikační úřad pro každý požadavek provést vyhledání certifikátu a operaci generování pseudo-COS. Aby byl OCSP nákladově efektivní, musí CA účtovat poplatek za každou kontrolu zrušení. OCSP řeší tento problém podepisováním žádostí o identifikaci odesílatele pro účely fakturace.
Tato metoda má také své nevýhody. Hlavní nevýhodou OCSP je, že namísto jednoduché odpovědi ano nebo ne na žádost o platnost používá několik neortogonálních hodnot stavu certifikátu , protože nemůže poskytnout skutečně přesnou odpověď. Tato nejednoznačnost pramení alespoň částečně z původního mechanismu stavu certifikátu založeného na COS. Protože COS může poskytnout pouze negativní výsledek, skutečnost, že certifikát není přítomen v COS, neznamená, že byl někdy vydán nebo je stále platný.
Hlavním problémem přístupů založených na černé listině, jako jsou COS a OCSP, je to, že kladou špatnou otázku. Namísto otázky „Je certifikát aktuálně platný?“ se ptají „Je certifikát odvolán?“, protože to je jediná otázka, na kterou může blacklist odpovědět.
OCSP také zpřístupňuje historii připojení klienta třetí straně (CA).
Sešívání OCSP je sešívání OCSP Eliminuje potřebu znovu zadávat požadavek OCSP vydáním odpovědi OCSP spolu se samotným certifikátem. Toto se nazývá sešívání OCSP, protože server musí „sešívat“ odpověď OCSP s certifikátem a vydat je společně. Když je navázáno spojení, server odešle svůj řetězec certifikátů klientovi spolu s odpovídajícími odpověďmi OCSP. Odpověď OCSP je platná pouze po krátkou dobu a je podepsána CA stejným způsobem jako certifikát. Tím také odpadá problém ochrany osobních údajů OCSP, protože respondent nemá přístup k údajům o návštěvnících webových stránek. Není široce implementován, pouze 3% serverů podporuje OCSP Stapling.
Jednou z možných aplikací infrastruktury veřejného klíče je HTTPS . Mnoho prohlížečů používá 2 hlavní přístupy: SOS a OCSP. Mozilla Firefox automaticky nestahuje SOS. Prohlížeč používá protokol OCSP ke kontrole, zda byl certifikát odvolán. Internet Explorer a Opera odvádějí mnohem důkladnější práci; oba podporují OCSP a CRL a provádějí příslušné kontroly všech typů certifikátů. Ale SOS se v tomto testu používá hlavně jako záložní.
Důležitou oblastí použití PKI a SOS zvláště je elektronický podpis . Certifikát potvrzuje, že veřejný a soukromý klíč patří jeho vlastníkovi. Zrušení certifikátu znamená, že klíč byl kompromitován .
Algoritmus ověření je následující: