Varmenteiden peruutuslista on luettelo varmenteista , jotka varmentaja on merkinnyt peruutetuiksi . Certificate Revocation List (CRL) -luetteloita käytetään määrittämään, onko käyttäjän tai varmentajan varmenne peruutettu avaimen vaarantumisen vuoksi. Tärkeä COS:n ominaisuus on, että se sisältää tietoja vain varmenteista, jotka eivät ole vanhentuneet.
PKI:n ( Public Key Infrastructure ) luomisen historia juontaa juurensa Whitfield Diffien ja Martin Hellmanin alkuperäiseen julkisen avaimen salausta koskevaan työhön , jossa ehdotetaan julkisten tiedostojen hakemistoa, jota käyttäjät voivat käyttää muiden käyttäjien julkisten avainten löytämiseen.
Confelder ymmärsi eräitä tämän lähestymistavan haittoja, mukaan lukien sen, että hakemistoon pääsyn estäminen estäisi käyttäjiä viestimästä turvallisesti, joten hän ehdotti varmenteiden käsitettä vuonna 1978. Sertifikaatit erottavat allekirjoitus- ja hakutoiminnot, jolloin CA voi liittää nimen avaimeen digitaalisen allekirjoituksen avulla ja tallentaa tuloksena olevan varmenteen arkistoon. Koska tallennustilaa voidaan replikoida ja tehdä vikasietoiseksi, CA-lähestymistapa poistaa monet hakemiston kestävyyteen liittyvät ongelmat.
Muutama vuosi sen jälkeen, kun Confelder julkaisi väitöskirjansa, kehittäjät sisällyttivät varmenteen käytön X.500 :aan , maailmanlaajuiseen hakemistoon monopolien televiestintäyritysten ylläpitämistä nimetyistä yksiköistä. X.500 - hakemisto ehdottaa hierarkkista tietokantamallia, jossa hakemiston läpi kulkevan polun määrittää sarja Relative Distinguished Name (RDN) -komponentteja, jotka yhdessä muodostavat erottuvan nimen (DN). Suojellakseen pääsyä hakemistoon sen kehittäjät ovat ehdottaneet erilaisia kulunvalvontamekanismeja, jotka vaihtelevat yksinkertaisista salasanapohjaisista toimenpiteistä suhteellisen uuteen lähestymistapaan digitaalisten allekirjoitusten käyttöön. Tämä standardi, joka sisältyy X.500 :aan , oli X.509v1- standardi . Tällä hetkellä on versio x.509v3.
Kehittäjät perustivat SOS-konseptin luottokorttien mustiin listoihin, joita käytettiin 1970-luvulla. Luottokorttiyhtiöt tulostivat ajoittain vihkoja, joissa oli peruutettu korttinumero, ja jakoivat ne kauppiaille sillä odotuksella, että he tarkistaisivat kaikki kortit, joita he käsittelevät mustalla listalla ennen niiden hyväksymistä. Samat ongelmat, jotka vaikuttivat luottokorttien mustalle listalle, vaikuttavat SOS:iin nykyään.
Varmenneviranomainen julkaisee säännöllisesti luettelon, jonka se julkaisee arkistossa. Jokainen COS sisältää nextUpdate-kentän, joka osoittaa ajan, jolloin seuraava COS julkaistaan. Jokainen luottavainen osapuoli, joka tarvitsee varmenteen tilatietoja ja jolla ei vielä ole nykyistä CRL:ää, saa nykyisen luettelon kaupasta. Jos asiakkaan tarkistama varmenne ei ole luettelossa, työ jatkuu normaalisti ja avaimen katsotaan olevan validoitu varmenne. Jos varmenne on olemassa, avainta pidetään virheellisenä eikä siihen voi luottaa.
Suorituskyvyn parantamiseksi CRL-kopiot voidaan levittää useisiin myymälöihin. Jokainen luottavainen osapuoli tarvitsee viimeisimmän luettelon tarkastuksen suorittamiseksi. Kun luottavainen osapuoli on vastaanottanut viimeisimmän SOS-ilmoituksen, sen ei tarvitse pyytää lisätietoja arkistolta ennen kuin uusi SOS on annettu. Tämän seurauksena kukin luottavainen osapuoli ei lähetä COS-muistiin enempää kuin yhden pyynnön COS:n voimassaoloaikana (eli viimeisimmänä). Tämä pyyntö tehdään ensimmäistä kertaa nykyisen SOS:n julkaisun jälkeen.
On myös delta-SOS-mekanismi, joka on RFC 2459 :ssä määritelty valinnainen mekanismi , jota voidaan käyttää parantamaan peruutustietojen leviämistä. Delta CRL:t ovat kooltaan suhteellisen pieniä, ja ne sisältävät vain ne muutokset varmenteen mitätöintiluetteloissa, jotka ovat tapahtuneet sen jälkeen, kun varmentajan viimeisin versio absoluuttisesta luettelosta (täydellinen CRL) on laadittu. Koska delta-CRL:t ovat pieniä, PKI-asiakkaat voivat ladata ne useammin kuin täydellisiä CRL:itä, joten CA tarjoaa asiakkailleen tarkempaa tietoa peruutetuista varmenteista.
Jotkut ongelmat vaikeuttavat työskentelyä SOS:n kanssa. COS on joissakin tapauksissa epäluotettava mekanismina varmenteen tilan levittämiseksi. Kriittiset sovellukset vaativat välitöntä peruuttamista - tai tarkemmin sanottuna reaaliaikaisia varmenteen tilatietoja - ja CRL:t eivät aina ratkaise tätä perusongelmaa useista syistä.
SOS:n pääongelmat:
SOS kärsii useista muista käytännön ongelmista. Oikea-aikaisten tilapäivitysten varmistamiseksi palvelimen tulee lähettää SOS-ilmoitus mahdollisimman usein. SOS-ilmoituksen antaminen kuitenkin lisää kuormitusta palvelimelle ja sitä välittävälle verkolle sekä vähemmässä määrin sen vastaanottavalle asiakkaalle. Esimerkiksi 10 miljoonaa asiakasta lataa 1 megatavun SOS:n kerran minuutissa = liikennettä ~ 150 Gt / s. Siksi se on kallis operaatio. SOS-ilmoituksen antaminen kerran minuutissa tarjoaa kohtuullisen oikea-aikaisen peruutuksen valtavien yleiskustannusten kustannuksella, koska jokainen luottavainen osapuoli lataa uuden SOS:n (monissa tapauksissa tämä tehtävä kuuluu Delta SOS:lle ja ongelma on ratkaistu). Toisaalta myöntämisen lykkääminen kerran tunnissa tai vuorokaudessa ei takaa oikea-aikaista peruuttamista, mikäli osa varmenteista on peruutettu tänä aikana.
CRL:istä puuttuu myös mekanismeja, joilla luotettavilta osapuolilta veloitetaan peruutuksen tarkistaminen. Kun varmenneviranomainen myöntää varmenteen, se veloittaa käyttäjältä maksun. Varmentajan veloittaa summa riippuu yleensä siitä, kuinka paljon se tarkistaa ennen varmenteen myöntämistä. Toisaalta käyttäjät odottavat varmentajan luovan ja myöntävän SOC:ita ilmaiseksi. Käyttäjä tai varmentaja ei voi yksiselitteisesti sanoa, kuka varmenteen tarkistaa, kuinka usein se tarkistetaan tai mikä viive on hyväksyttävä. Tämä tilanne toimii aktiivisena pelotteena CA:ille keskittyä voimakkaasti SOS:iin, koska ne vaativat käsittelyaikaa, yhden tai useamman palvelimen ja huomattavan verkon kaistanleveyden niiden luomiseen ja jakeluun.
Tällä hetkellä on olemassa useita SOS-analogeja, joilla ei ole SOS:n haittoja, mutta samalla omat.
Yksi analogeista on OCSP - Online Certificate Status Protocol . Tämä kiertotapa tarjoaa reaaliaikaisen vastauksen palvelimelta kyseisestä pyydetystä varmenteesta. Tämä lähestymistapa ratkaisee monet SOS:lle ominaisista ongelmista luomalla kertaluonteisen, tuoreen SOS:n, jossa on yksi merkintä pyyntöä kohti. Sitä vastoin COS-pohjainen malli edellyttää, että luottavat osapuolet hakevat toistuvasti valtavan määrän epäolennaisia tietueita saadakseen tarvitsemansa yhden varmenteen tilatiedot. OCSP :llä on kuitenkin hintansa. Sen sijaan, että CA valmistelee tausta-offline-toimintona, CA:n on nyt suoritettava varmennehaku ja pseudo-COS-luontitoiminto jokaiselle pyynnölle. Jotta OCSP olisi kustannustehokas, varmentajan on veloitettava maksu jokaisesta peruutustarkistuksesta. OCSP ratkaisee tämän ongelman allekirjoittamalla lähettäjän tunnistuspyynnöt laskutusta varten.
Tällä menetelmällä on myös haittapuolensa. OCSP :n suurin haitta on, että kelpoisuuspyyntöön yksinkertaisen kyllä- tai ei-vastauksen sijaan se käyttää useita ei-ortogonaalisia varmenteen tila-arvoja , koska se ei voi antaa todella tarkkaa vastausta. Tämä epäselvyys johtuu ainakin osittain alkuperäisestä COS-pohjaisesta varmenteen tilamekanismista. Koska COS voi antaa vain negatiivisen tuloksen, se, että varmennetta ei ole COS:ssä, ei tarkoita, että se on koskaan myönnetty tai että se on edelleen voimassa.
Suurin ongelma mustalle listalle perustuvissa lähestymistavoissa, kuten COS ja OCSP, on, että ne kysyvät väärän kysymyksen. Sen sijaan, että he kysyisivät "Onko varmenne voimassa?", he kysyvät "Onko varmenne peruutettu?", koska se on ainoa kysymys, johon musta lista voi vastata.
OCSP paljastaa myös asiakkaan yhteyshistorian kolmannelle osapuolelle (CA).
OCSP- nidonta on OCSP- nidonta Se eliminoi tarpeen lähettää OCSP-pyyntö uudelleen antamalla OCSP-vastauksen yhdessä varmenteen kanssa. Tätä kutsutaan OCSP-nidotukseksi, koska palvelimen on "nidottava" OCSP-vastaus varmenteeseen ja annettava ne yhdessä. Kun yhteys on muodostettu, palvelin lähettää varmenneketjunsa asiakkaalle yhdessä vastaavien OCSP-vastausten kanssa. OCSP-vastaus on voimassa vain lyhyen ajan, ja CA allekirjoittaa sen samalla tavalla kuin varmenne. Tämä poistaa myös OCSP:n tietosuojaongelman, koska vastaajalla ei ole pääsyä verkkosivuston vierailijatietoihin. Sitä ei ole laajalti otettu käyttöön, vain 3 % palvelimista tukee OCSP-nidontaa.
Yksi mahdollinen julkisen avaimen infrastruktuurin sovellus on HTTPS . Monet selaimet käyttävät kahta päätapaa: SOS ja OCSP. Mozilla Firefox ei lataa SOS:ää automaattisesti. Selain tarkistaa OCSP:n avulla, onko varmenne peruutettu. Internet Explorer ja Opera tekevät paljon perusteellisempaa työtä; ne molemmat tukevat OCSP:tä ja CRL:ää ja suorittavat asianmukaisia tarkistuksia kaikentyyppisille sertifikaateille. Mutta SOS:ää käytetään tässä testissä pääasiassa varavarana.
Tärkeä PKI:n ja erityisesti SOS:n sovellusalue on sähköinen allekirjoitus . Varmenne todistaa, että julkiset ja yksityiset avaimet kuuluvat sen omistajalle. Varmenteen peruuttaminen tarkoittaa, että avain on vaarantunut .
Varmistusalgoritmi on seuraava: