"Provozovatel domény pomocí tohoto záznamu v DNS určí, které autority jsou oprávněny certifikát pro danou doménu vystavovat. Kontrola tohoto záznamu je pro autoritu zatím dobrovolná, ale jde o jakousi pojistku navíc, protože chrání autoritu před chybným vystavením certifikátu."
Neunika ti nic ... zabrani ti znacka (50) profrcet ten usek kilo? Nezabrani ... tohle funguje stejne.
A psat nekde ze neco co je nekde v nejakym RFC nekdo MUSI ... megalol ...
Kdyby vsem slo o to blaho a bezpeci ... tak by vyslo RFC, ze browser ani zadna dalsi aplikace nesmi ve vychozim stavu obsahovat ZADNOU CA ... ze musi akceptovat bez kecu libovolnej cert protistrany, a ze kecy muze mit az v pripade, ze si bud nekde neco ulozi uzivatel nebo existuje dane ...
Vis co je prca? Pravidelne resim s ruznejma obchodnima partnerama vsemoznou komunikaci na tema objednavky .... a prevazne se to resi na https ... vsichni bez vyjimek zcela vzdy vypinaji jakoukoli validaci certifikatu, protoze to veci tak maximalne rozbiji. Ostatne, neni to tak dlouho co zakaznik aktualizoval phpcko ... a neco mu prestalo fungovat ... nacez se zjistilo, ze ponovu je potreba prave tu validaci explicitne vypnout (jelikoz a protoze na nejaky importy CA a jejich udrzovani se muze kazdej krajcvajc ...).
Tohle "řeší" jen to, že si budeš teoreticky moct omezit okruh CA, které tě eventuálně vypečou. Prakticky to samozřejmě je k ničemu, poněvadž technicky nic nebrání těm zbylým "zakázaným" CA ten certifikát vydat stejně, a klient nic nepozná a navíc to ověřovat ani nesmí.
Teoreticky samozřejmě se do těch záznamů dají nacpat kraviny typu (viz odkazované RFC)
CAA 0 issue "ca.example.net; account=123456"
přičemž ten account by (třeba) podle politiky CA měl být ten jeden jediný správný, ze kterého by o ten certifikát mohl někdo požádat. Prakticky to samozřejmě nikdo nezaručí. Ze stejného soudku (bezcenná šaškárna) je pak ten tag "iodef" (viz 5.4).
No, tak jsem to prve pochopil správně. "Nechápu" ale, proč se řeší kam strčit další cert nebo nějaké info o něm, když ty problémy jsou přece někde jinde?
1. problém: CA se nedá věřit, resp. není systém vydávání certifikátů natolik robustní, aby si nemohl vydat kdokoliv cokoliv za kohokoliv a celé to stojí jenom na dobrém slovu.
2. Jak zaručit první request (třeba na bankovnictví), aby někdo nepodvrhl cert po ceste za svůj, tzn už při prvním erquestu musí být cert "ověřený"
To jsou dva problémy, které na sobě v současné podobě závisí - kdyby se odstranil jeden z nich nebo oba, tak je vše vyřešeno - a kolem nich se to celé ty roky točí a pořád někdo cpe někam nějaký záznam, jeden nahoru, druhý dolů, třetí doprostřed, jiný zase vlevo doprostřed, ale zase tím vznikne někdo (zas nějaká jiná CA BLA BLA . . . ) kdo bude někde ručit tak akorát hezkým úsměvem . . . .
No rozuměj, když jako obchodník s deštěm léta účtuješ stovky/tisíce dolarů za kus a máš z toho zlatý důl, zatímco začíná být čím dál tím víc jasné, že jsi podvodník, tak si musíš vylepšit pyj-ár a předstírat nějakou "bohulibou" činnost. Jako že teda sice je to na houby a vylejzá na tebe jeden průser za druhým, ale soudruzi, my přece usilovně pracujeme na tom, aby se to zlepšilo. Podívejte, třeba tuhle dvoumetrovou jámu ve zdi jsme schovali za krásný velký květináč a zavazujem se, že tu palmu v něm budem pravidelně zalejvat, aby nechcípla a tu díru nebylo vidět. :-D
@NULL
"CA se nedá věřit, resp. není systém vydávání certifikátů natolik robustní, aby si nemohl vydat kdokoliv cokoliv za kohokoliv a celé to stojí jenom na dobrém slovu"
Gratuluju!
Prave si uplne presne shrnul problematiku PKI do jedny vety! :o))
Mam tip! Posli tu vetu do Wikipedie at to daj jako definici pod heslo CA/PKI.
Protoze tohle by mohli pochopit i BFU :o)))
ČLÁNKY DO MAILU