Криптографиялық кілттерді растау механизмі

Кіріспе

Криптографиялық кілттерді аутентификациялау механизмі
интернет қауіпсіздігі веб-сайты

Криптографияда сенім желісі – PGP, GnuPG және басқа OpenPGP үйлесімді жүйелерде ашық кілт пен оның иесі арасындағы байланыстың нақтылығын анықтау үшін қолданылатын түсінік. Оның таралымды сенім моделі – тек сертификаттау органына (немесе олардың иерархиясына) ғана сүйенетін ашық кілт инфрақұрылымының (PKI) орталықтандырылған сенім моделіне балама болып табылады. Компьютерлік желілердегідей, сенімнің көптеген тәуелсіз желілері бар, және әрбір пайдаланушы (өз ашық кілт сертификаты арқылы) бірнеше желінің құрамында болуы және оларды байланыстырушы буин болуы мүмкін. Сенім желісі тұжырымдамасын алғаш рет 1992 жылы PGP авторы Фил Циммерман PGP 2.0 нұсқасының нұсқаулығында ұсынды:

Осы контекстте «пайда болу» сөзін қолдануға назар аударыңыз. Сенім желісі «пайда болу» ұғымын пайдаланады.

Сенім желісінің жұмыс істеуі

OpenPGP-ге сәйкес келетін барлық жүзеге асырулар осыған көмектесу үшін сертификатты растау схемасын қамтиды; оның жұмысы «сенім желісі» деп аталады. OpenPGP сертификаттарында (оларға иеленуші туралы ақпаратпен бірге бір немесе бірнеше ашық кілттер кіреді) басқа пайдаланушылар цифрлық қол қоя алады, осы әрекет арқылы сертификатта көрсетілген тұлға немесе ұйыммен аталған ашық кілттің байланысын жақтайды. Бұл көбінесе кілттерді қол қою шараларында жасалады. OpenPGP-ге сәйкес келетін жүзеге асырулар сонымен қатар дауыс санау схемасын қамтиды, оны пайдаланушы PGP қолданғанда қай ашық кілттің иесімен байланысын сенімді деп санайтынын анықтау үшін пайдалануға болады. Мысалы, егер үш жартылай сенімді растаушы сертификатқа кепілдік берсе (осылайша оның кіретін ашық кілті мен иесінің байланысын растаса), немесе егер бір толық сенімді растаушы мұны жасаса, онда сертификаттағы иесі мен ашық кілт арасындағы байланыс дұрыс деп есептеледі. Параметрлер пайдаланушылармен реттеледі (мысалы, ешқандай жартылай растаулар болмауы, немесе мүмкін алты жартылай растау) және қажет болса, оларды толығымен айналып өтуге болады. Бұл схема, көптеген ашық кілттер инфрақұрылымдық жобаларынан айырмашылығы, икемді және сенім туралы шешімдерді жеке пайдаланушылардың қолына қалдырады. Ол мінсіз емес және пайдаланушылардың сақтықты сақтауын және ақылмен бақылауын қажет етеді. Көптеген PKI жобалары аз икемді және пайдаланушылардан PKI құрамында жасалған, сертификаттау органы (CA) қол қойған сертификаттарға сенуді талап етеді.

Қарапайым түсіндірме

Адамға қатысты екі кілт бар: ашық түрде таралған ашық кілт және иесі құпия сақтайтын жеке кілт. Иесінің жеке кілті оның ашық кілтімен шифрланған кез келген ақпаратты ашады. Сенім желісінде әрбір пайдаланушыда басқа адамдардың ашық кілттерінен құралған кілт жинағы болады. Жіберуші ақпаратты алушының ашық кілтімен шифрлайды, және оны алушының жеке кілті ғана аша алады. Әрбір жіберуші содан кейін шифрланған ақпаратқа өз жеке кілтімен цифрлық қолтаңба қояды. Алушы алынған шифрланған ақпаратты жіберушінің ашық кілтімен тексергенде, оның жіберушіден келгенін растай алады. Бұл шифрланған ақпараттың белгілі бір пайдаланушыдан келгенін және өзгертілмегенін, сондай-ақ ақпаратты тек көздеген алушы ғана аша алатынын (өйткені жеке кілт тек оларға ғана белгілі) қамтамасыз етеді.

Типтік PKI-мен салыстыру

WOT-тан өзгеше, әдеттегі X.509 PKI әрбір сертификатқа бір ғана тараптан қол қоюға мүмкіндік береді: сертификаттау органы (CA). CA сертификатының өзі басқа CA-ның қолымен, тіпті «өз-өзіне қол қойылған» түбірлік сертификатқа дейін қол қойылуы мүмкін. Түбірлік сертификаттар төменгі деңгейдегі CA сертификатын пайдаланатындарға қолжетімді болуы керек, сондықтан олар кеңінен таралған. Мысалы, олар браузерлер және электрондық пошта клиенттері сияқты қосымшалармен бірге таратылады. Осылайша SSL/TLS қорғалған веб-беттер, электрондық пошта хабарламалары және т.б. пайдаланушылардан түбірлік сертификаттарды қолмен орнатуды қажет етпей, куәландырылуы мүмкін. Қолданбалар көбінесе ондаған PKI-ден жүзден астам түбірлік сертификаттарды қамтиды, осылайша оларға қайта жететін сертификаттар иерархиясына дефолтты түрде сенімділік береді. WOT сенімділік нүктелерін орталықсыздандыруды жақтайды, бұл бір ғана сәтсіздіктің CA иерархиясын құлатуына жол бермеу үшін.

Жеке кілттердің жоғалуы

OpenPGP сенімді желісі компаниялардың банкроттығы сияқты жағдайларға негізінен бейтарап және аз өзгерістермен жұмыс істеуді жалғастырып келеді. Дегенмен, осыған байланысты бір мәселе туындайды: жеке тұлғалар немесе ұйымдар өздерінің жеке кілтін жоғалтқан жағдайда, оларға жіберілген және OpenPGP сертификатындағы сәйкес ашық кілтпен шифрланған хабарламаларды енді аша алмайды. Алғашқы PGP сертификаттарында жарамдылық мерзімі көрсетілмеген, сондықтан олардың өмірі шексіз болды. Пайдаланушылар сәйкес жеке кілт жоғалған немесе құрысқа ұшыраған кезде қол қойылған жою сертификатын дайындауға міндетті болды. Белгілі бір криптограф әлі күнге дейін жеке кілтін жоғалтқан ашық кілтпен шифрланған хабарламаларды алып тұрады. Олар бұл хабарламалармен көп нәрсе жасай алмайды, тек оларды жіберушіге оқылмайтындығын хабарлап, сәйкес жеке кілтісі бар ашық кілтпен қайта жіберуді сұрайды. Кейінгі PGP және барлық OpenPGP сәйкес сертификаттары жарамдылық мерзімін қамтиды, бұл ақылмен пайдаланғанда мұндай мәселелерді (әдетте) автоматты түрде болдырмайды. Бұл мәселені 1990 жылдардың басында енгізілген «белгіленген қайтарушылар» арқылы оңай болдырмауға болады. Кілттің иесі кілттің иесінің кілтін қайтаруға рұқсат берілген үшінші тарапты тағайындай алады (егер кілттің иесі өзінің жеке кілтін жоғалтса және осылайша өзінің кілтін қайтару мүмкіндігінен айырылса).

Ашық кілтінің шынайылығын тексеру

PGP/OpenPGP типті жүйелердегі сенім желісімен байланысты техникалық емес, әлеуметтік қиындық – орталық басқарушысы жоқ (мысалы, CA) жағдайда, әрбір сенім желісінің сену үшін басқа пайдаланушыларға тәуелді болуы. Жаңа сертификаттары бар (яғни, жаңа кілт жұбын жасау процесінде алынған) пайдаланушыларға басқа пайдаланушылардың жүйелері, яғни олармен жеке кездеспегендер, жаңа сертификатқа жеткілікті мақұлдаулар табылғанға дейін оңай сенім артпайды. Бұл көптеген Web of Trust пайдаланушыларының сертификатты тексеруінде, әдетте белгісіз сертификатқа бір немесе бірнеше толық сенімді мақұлдаушы (немесе бірнеше ішінара мақұлдаушы) талап ететіндігіне байланысты. Осы сертификаттағы ашық кілтті хабарларды дайындау, қолтаңбаларды тексеру және т.б. үшін пайдалану үшін бұл қажет. OpenPGP-ге сәйкес жүйелердің кеңінен қолданылуына және көптеген кілт серверлерінің қолжетімділігіне қарамастан, жаңа сертификатты мақұлдайтын адамды (немесе бірнеше адамды) табу қиын болуы мүмкін (мысалы, физикалық сәйкестендіруді кілт иесі туралы ақпаратпен салыстырып, жаңа сертификатқа цифрлық қол қою арқылы). Мысалы, шалғай немесе дамылмаған аймақтардағы пайдаланушылар басқа пайдаланушыларды табуда қиындықтарға тап болуы мүмкін. Егер екінші тараптың сертификаты да жаңа болса (және басқалардан қолтаңбалардың жоқтығы немесе азайып кетуі), онда оның жаңа сертификатқа қойған қолы басқа тараптардың жүйелеріне сенімділік деңгейін арттыруға және олармен қауіпсіз түрде хабар алмасуға көмектеспейді. Кілтті мақұлдау жиналыстары – бұл қолданыстағы сенім желісіне өз сертификатын орнатуға мүмкіндік беретін басқа пайдаланушыларды табу мәселесін шешуге бағытталған салыстырмалы түрде танымал механизм. Басқа OpenPGP пайдаланушыларын табу және кілтті мақұлдауды ұйымдастыру үшін веб-сайттар да бар. Gossamer Spider Web of Trust кілтті тексеруді жеңілдетеді, OpenPGP пайдаланушыларын иерархиялық сенім желісі арқылы байланыстырады, онда соңғы пайдаланушылар кірістіруші ретінде бекітілген адамға кездейсоқ немесе мақсатты түрде сену арқылы немесе GSWoT-тің жоғарғы деңгейлі кілтіне ең төменгі деңгейдегі 2-деңгейлі кірістіруші ретінде сену арқылы пайда ала алады (жоғарғы деңгейлі кілт 1-деңгейлі кірістірушілерді мақұлдайды). Сертификаттар тізбегін табу мүмкіндігі көбінесе "кіші әлем құбылысымен" түсіндіріледі: екі адамның арасында олардың арасындағы әрбір адам алдыңғы және келесі сілтемелерді білетін қысқа тізбек табуға болады. Алайда, мұндай тізбек әрқашан пайдалы бола бермейді: электрондық поштаны шифрлайтын немесе қолтаңбаны тексеріп отырған адам өз жеке кілтінен хат алмасушының кілтіне дейін тізбек табуға ғана емес, сонымен қатар тізбектегі әрбір адамның кілттерді қол қоюда адал және білікті екеніне сенуі керек (яғни, олардың кілттерді қол қоюдан бұрын адамдардың сәйкестігін тексеру туралы нұсқауларды адал орындай алатынына көз жеткізуі керек). Бұл күшті талап. Тағы бір кедергі – жеке тұлғамен кездесу қажеттігі (мысалы, кілтті мақұлдау жиналысында) олардың сәйкестігін және ашық кілт пен электрондық пошта мекенжайына иелігін растау үшін, бұл екі тарапқа да жол шығыстарын және кестелеу қиындықтарын тудыруы мүмкін. Бағдарламалық жасақтаманы пайдаланушы әлемнің түкпір-түкпірінде орналасқан мыңдаған әзірлеушілер жасаған жүздеген бағдарламалық компоненттерді тексеруі керек. Бағдарламалық жасақтаманы пайдаланушылардың көпшілігі барлық бағдарламалық жасақтама әзірлеушілерімен жеке кездесіп тікелей сенім орната алмайтындықтан, олар салыстырмалы түрде баяу таралатын жанама сенімге сүйенуі керек. Автордың (немесе әзірлеушінің, баспагердің және т.б.) PGP/GPG кілтін ашық кілт серверінен алу да тәуекелдерді тудырады, өйткені кілт сервері үшінші тараптың аралық буыны болып табылады және ол өзі зиянды пайдалануға немесе шабуылға ұшырауы мүмкін. Бұл тәуекелден қашу үшін автор өзінің ашық кілтін өз кілт серверінде (яғни, оларға тиесілі домендік атау арқылы қол жетімді және олардың жеке кеңсесінде немесе үйінде орналасқан веб-серверде) жариялауды және олардың ашық кілтін беру үшін HKPS шифрланған қосылымдарын пайдалануды талап ете алады. Толық мәліметтер үшін төмендегі WOT көмектесетін шешімдерін қараңыз.

A non technical, social difficulty with a Web of Trust like the one built into PGP/OpenPGP type systems is that every web of trust without a central controller (e. g., a CA) depends on other users for trust. Those with new certificates (i. e., produced in the process of generating a new key pair) will not likely be readily trusted by other users' systems, that is by those they have not personally met, until they find enough endorsements for the new certificate. This is because many other Web of Trust users will have their certificate vetting set to require one or more fully trusted endorsers of an otherwise unknown certificate (or perhaps several partial endorsers) before using the public key in that certificate to prepare messages, believe signatures, etc. Despite the wide use of OpenPGP compliant systems and easy availability of on line multiple key servers, it is possible in practice to be unable to readily find someone (or several people) to endorse a new certificate (e. g., by comparing physical identification to key owner information and then digitally signing the new certificate). Users in remote areas or undeveloped ones, for instance, may find other users scarce. And, if the other's certificate is also new (and with no or few endorsements from others), then its signature on any new certificate can offer only marginal benefit toward becoming trusted by still other parties' systems and so able to securely exchange messages with them. Key signing parties are a relatively popular mechanism to resolve this problem of finding other users who can install one's certificate in existing webs of trust by endorsing it. Websites also exist to facilitate the location of other OpenPGP users to arrange keysignings. The Gossamer Spider Web of Trust also makes key verification easier by linking OpenPGP users via a hierarchical style web of trust where end users can benefit by coincidental or determined trust of someone who is endorsed as an introducer, or by explicitly trusting GSWoT's top level key minimally as a level 2 introducer (the top level key endorses level 1 introducers). The possibility of finding chains of certificates is often justified by the "small world phenomenon": given two individuals, it is often possible to find a short chain of people between them such that each person in the chain knows the preceding and following links. However, such a chain is not necessarily useful: the person encrypting an email or verifying a signature not only has to find a chain of signatures from their private key to their correspondent's, but also to trust each person of the chain to be honest and competent about signing keys (that is, they have to judge whether these people are likely to honestly follow the guidelines about verifying the identity of people before signing keys). This is a much stronger constraint. Another obstacle is the requirement to physically meet with someone (for example, at a key signing party) to verify their identity and ownership of a public key and email address, which may involve travel expenses and scheduling constraints affecting both sides. A software user may need to verify hundreds of software components produced by thousands of developers located around the world. As the general population of software users cannot meet in person with all software developers to establish direct trust, they must instead rely on the comparatively slower propagation of indirect trust. Obtaining the PGP/GPG key of an author (or developer, publisher, etc.) from a public key server also presents risks, since the key server is a third party middle man, itself vulnerable to abuse or attacks. To avoid this risk, an author can instead choose to publish their public key on their own key server (i. e., a web server accessible through a domain name owned by them, and securely located in their private office or home) and require the use of HKPS encrypted connections for the transmission of their public key. For details, see WOT Assisting Solutions below.

Қатты жиынтық

Қатты жиынтық – күшті байланысқан PGP кілттерінің ең ірі жиынтығы. Ол сенімнің жаһандық желісінің негізін қалайды. Қатты жиынтықтағы кез келген екі кілттің арасында байланыс бар; өзара қол қоятын, бірақ жеке топта бөлініп қалған кілттер жиынтықтары болуы мүмкін, алайда мұндай топтың бір ғана мүшесі қатты жиынтықпен қолтаңба алмасса, сол топ та қатты жиынтықтың құрамына кіреді. 2015 жылдың басында қатты жиынтықтың көлемі шамамен 55000 кілтті құрады.

Ең қысқа орташа қашықтық

PGP/GnuPG/OpenPGP сенім желісінің статистикалық талдауында орташа ең қысқа қашықтық (MSD) – бұл сенім желісін құрайтын PGP кілттерінің берілген PGP кілтіне дейінгі байланыстылығының өлшемі, яғни кілттің қаншалықты "сенімді" екенін көрсетеді. MSD PGP кілттері жиынтығын талдау үшін кеңінен қолданылатын көрсеткіш болып табылады. Көп жағдайда MSD кілттердің белгілі бір тобы үшін есептеледі және әлемдік сенім желісінің іріктемелеріндегі кілттердің орналасуын көрсететін жалпы MSD-мен салыстырылады.

ЖОҚ-қа көмекші шешімдер

Бастапқы әзірлеушімен немесе автормен жеке кездесу PGP/GPG кілттерін алу, тарату, тексеру және сенім білдірудің ең жақсы тәсілі болып табылады және ең сенімді жолдың ең жоғары деңгейі болып қала береді. Бастапқы автордың/әзірлеушінің кеңінен танымал (физикалық/қағаз материалға негізделген) кітапқа толық GPG/PGP кілтін немесе кілт саусағының толық ізін жариялау, пайдаланушылармен және олар үшін сенімді кілтті бөлісудің екінші ең жақсы тәсілі болып табылады. Әзірлеушімен немесе автормен кездесу алдында пайдаланушылар кітапханада және интернетте әзірлеуші немесе автор туралы өздігінен зерттеу жүргізіп, оның фотосуреті, жұмысы, жария кілтінің саусағының іздері, электрондық пошта мекенжайы және т.б. туралы білуі керек. Алайда, миллиондаған пайдаланушылар үшін қауіпсіз байланыс құру үшін әрбір алушымен жеке кездесу мүмкін емес, сондай-ақ, бағдарламалық жасақтаманы пайдаланушы миллиондаған адам үшін жүздеген бағдарламалық жасақтаманы әзірлеушілермен немесе авторлармен жеке кездесу де мүмкін емес, олардың бағдарламалық жасақтамасы немесе файлға қол қою үшін PGP/GPG ашық кілтін тексергісі келеді және оны өздерінің компьютерлерінде пайдалануы керек. Сондықтан, пайдаланушылар үшін қол жетімді және пайдалана алатын, әлемдегі миллиондаған пайдаланушыларға сенімді тексеру немесе сенімділік беру қызметтерін кез келген уақытта ұсына алатын бір немесе бірнеше сенімді үшінші тараптың (TTPA) ұйымы немесе тобы болуы керек. Іс жүзінде, жүктеп алынған немесе алынған мазмұнның, деректердің, электрондық поштаның немесе файлдың шынайылығын тексеру үшін пайдаланушы жүктеп алынған негізгі мазмұнның немесе негізгі деректердің/электрондық поштаның немесе негізгі файлдың PGP/GPG қолтаңба кодын/файлын (ASC, SIG) тексеруі керек. Пайдаланушылар бастапқы әзірлеушінің немесе автордың сенімді және тексерілген ашық кілтін пайдалануы керек немесе осы ашық кілттің бастапқы иесіне сенім білдіріп, сенімді файлға қол қоюға арналған ашық кілтін пайдалануы керек. Нақты PGP/GPG кілтіне сенім білдіру үшін пайдаланушылар әрбір нақты түпнұсқа автормен немесе әзірлеушімен жеке кездесуі керек, немесе файлға қол қою кілтін шығарған түпнұсқа адаммен жеке кездесуі керек, немесе WOT сенімді тізбегіндегі (яғни басқа пайдаланушы немесе басқа әзірлеуші немесе басқа автор, ол осы нақты түпнұсқа автормен немесе әзірлеушімен сенімді) басқа сенімді пайдаланушыны тауып, оның PGP/GPG кілтімен оның сәйкестігін тексеру үшін онымен жеке кездесуі керек (сондай-ақ, екі тараптың бір-бірінің PGP/GPG кілтіне қол қоюы/куәландыруы үшін өзінің сәйкестігін және кілтін басқа пайдаланушыға беруі керек). Бағдарламалық жасақтама танымал болсын, болмасын, оны пайдаланушылар әдетте әлемнің әртүрлі жерінде орналасқан. Бастапқы автордың немесе әзірлеушінің немесе файл шығарушының миллиондаған пайдаланушыларға ашық кілт, сенім немесе сәйкестік тексеру қызметтерін ұсынуы физикалық тұрғыдан мүмкін емес. Сондай-ақ, бағдарламалық жасақтаманы пайдаланушы миллиондаған адамның әр бағдарламалық жасақтаманы немесе бағдарламалық кітапхананы немесе кодты әзірлеушімен немесе автормен немесе шығарушымен жеке кездесуі де мүмкін емес, оларды өздерінің компьютерлерінде пайдаланады немесе пайдалануы керек. WOT сенімді тізбегіндегі бірнеше сенімді адамдардың (түпнұсқа автордан) болуына қарамастан, әр әзірлеушінің немесе автордың басқа пайдаланушылармен кездесуі де физикалық немесе практикалық тұрғыдан мүмкін емес, сондай-ақ, әрбір пайдаланушының олар пайдаланатын немесе жұмыс істейтін бағдарламалық жасақтаманы әзірлеушілердің жүздегенімен кездесуі де мүмкін емес. Бұл орталықтандырылған иерархияға негізделген WoT тізбекті моделі танымал болып, жақын маңдағы пайдаланушылардың көпшілігі қолданған кезде ғана жеке кездесулер мен кілтті растау және қол қою WoT процедурасы жеңілдетіледі. Шешімдер: бастапқы автор/әзірлеуші алдымен өз файлын қол қою кілтімен қол қою/куәландыру үшін сенім деңгейін орнатуы керек. Содан кейін жаңартылған ашық кілттер мен жаңартылған файлға қол қою ашық кілттері пайдаланушыларға онлайн режиміндегі қауіпсіз және шифрланған орта арқылы жариялануы және таратылуы (немесе қолжетімді болуы) керек, сонда әлемнің кез келген жерінен кез келген пайдаланушы дұрыс, сенімді және өзгертілмеген ашық кілтті ала алады. Әрбір пайдаланушының дұрыс және сенімді ашық кілттерді және қол қойылған кодты/файлды алуын қамтамасыз ету үшін бастапқы әзірлеуші/автор немесе бастапқы шығарушы өздерінің жаңартылған ашық кілттерін өздерінің кілт серверінде жариялауы керек және HKPS шифрланған қосылысын пайдалануды міндеттеуі керек, немесе өздерінің жаңартылған және толық ашық кілттерін (және қол қойылған кодты/файлды) өздерінің HTTPS шифрланған веб-бетінде, өздерінің веб-серверінде, өздерінің негізгі домендік веб-сайтынан (сыртқы серверлерде орналасқан кез келген қосалқы домендерден емес, кез келген көшірмелерден емес, кез келген сыртқы/ортақ форумдардан/викилерден емес, кез келген қоғамдық немесе сыртқы/ортақ бұлттық немесе хостингтік қызметтердің серверлерінен емес) жариялауы керек және олар өздерінің үйлерінде, үй кеңселерінде немесе кеңселерде қауіпсіз сақталуы керек. Осылайша, кілттердің/кодтың осы кішкентай бөліктері интернет арқылы зақымдалмай өтеді және транзиттің кезінде өзгертілмейді (шифрланған байланыс болғандықтан) және пайдаланушы тарапына жетіп, бір немесе бірнеше арналы TTPA негізінде тексерілгендіктен сенімді ашық кілттер ретінде қарастырылуы мүмкін. Ашық кілт бастапқы әзірлеушінің өз веб-серверінен бірнеше TTPA (сенімді үшінші тарап) негізіндегі қауіпсіз, тексерілген және шифрланған байланыс арқылы алынса, ол одан да сенімді болады. Егер түпнұсқа ашық кілттер/қол қойылған кодтар әзірлеушінің немесе автордың өз веб-серверінде немесе кілт серверінде шифрланған байланыс немесе шифрланған веб-бет арқылы көрсетілсе, басқа файлдар, деректер немесе мазмұн кез келген типтегі шифрланбаған байланыс арқылы берілуі мүмкін, мысалы: HTTP/FTP және т.б., кез келген қосалқы домен серверінен немесе кез келген көшірмеден немесе кез келген ортақ бұлттық/хостингтік серверлерден, өйткені шифрланбаған байланыс негізінде жүктелген элементтер/деректер/файлдар бастапқы автордың/әзірлеушінің өз серверінен қауіпсіз, шифрланған және сенімді (яғни тексерілген) байланыс/арналар арқылы алынған түпнұсқа ашық кілттер/қол қойылған кодтарды пайдаланып кейінірек расталуы мүмкін. Кілттерді немесе қолтаңба/қолтаңба кодын/файлдарды беру үшін шифрланған байланысты пайдалану бағдарламалық жасақтама пайдаланушыларына PKI TTPA (сенімді үшінші тарап) сенімін, мысалы, қоғамдық CA (Сертификаттық Орган) жүктеуге мүмкіндік береді, бұл бастапқы әзірлеушінің/автордың веб-сервері мен әлемнің миллиондаған пайдаланушыларының компьютерлері арасындағы сенімді байланысты қамтамасыз етуге көмектеседі. Егер бастапқы автордың/әзірлеушінің домендік аты мен атау сервері DNSSEC арқылы қол қойылса, және егер қолданылатын SSL/TLS ашық сертификаты TLSA/DANE DNSSec DNS ресурстық жазбасында жарияланса (және егер веб-серверлер HPKP техникасын пайдаланып сенім тізбегіндегі SSL/TLS сертификаттары бекітілсе), онда веб-сервердің веб-бетін немесе деректерін қоғамдық CA-дан басқа DNSSEC және DNS атау кеңістігін сақтаушы ICANN сияқты тағы бір PKI TTPA арқылы да тексеруге болады. DNSSEC – PGP/GPG WOT-тың атау серверлері үшін тағы бір түрі; ол адамдар емес, атау серверлері үшін бірінші болып сенімді тізбек құрайды, содан кейін адамдардың/пайдаланушылардың PGP/GPG кілттері мен саусағының іздері сервердің DNSSEC DNS жазбаларына да қосылуы мүмкін. Сондықтан, қауіпсіз байланыс құруды (немесе кез келген бағдарламалық жасақтама пайдаланушысы) қалайтын кез келген пайдаланушы деректерін/кілтін/кодын/веб-бетін және т.б. бір уақытта екі (яғни қос/екі есе) сенімді PKI TTPAs/арналар арқылы тиімді тексеруге/растауға алады: ICANN (DNSSEC) және CA (SSL/TLS сертификаты). Сондықтан, PGP/GPG кілті/қол қойылған кодтық деректер (немесе файл) HKPS, HKPS+DNSSEC+DANE, HTTPS, HTTPS+HPKP немесе HTTPS+HPKP+DNSSEC+DANE сияқты шешімдер мен техникалар қолданылғанда сенімді болуы мүмкін. Егер көптеген пайдаланушылардың тобы өздерінің жаңа DLV негізіндегі DNSSEC тізімін жасаса және пайдаланушылар осы жаңа DLV-ді (ICANN DNSSEC-пен бірге) өздерінің жергілікті DNSSEC негізіндегі DNS шешушісінде/серверінде қолданса және домен иелері оны өздерінің домендік аттарына қосымша қол қою үшін де қолданса, онда жаңа үшінші TTPA пайда болуы мүмкін. Мұндай жағдайда, кез келген PGP/GPG кілті/қол қойылған кодтық деректер немесе веб-бет немесе веб-деректер үш/үш есе арна арқылы тексерілуі мүмкін. ISC-нің DLV өзі кеңінен қолданылатындықтан және белсенді болғандықтан, үшінші TTPA ретінде де пайдаланылуы мүмкін, сондықтан тағы бір жаңа DLV төртінші TTPA болады.

Physically meeting with original developer or author, is always the best way to obtain and distribute and verify and trust PGP/GPG Keys with highest trust level, and will remain as the best level of best trustworthy way. Publishing of GPG/PGP full Key or full Key fingerprint on/with widely known (physical/paper material based) book, by the original author/developer, is the 2nd best form of sharing trustworthy key with and for users. Before meeting a developer or author, users should research on their own on the developer or author in book library and via internet, and aware of developer's or author's photo, work, pub key fingerprint, email address, etc. However, it is not practical for millions of users who want to communicate or message securely to physically meet with each recipient users, and it is also not practical for millions of software users who need to physically meet with hundreds of software developers or authors, whose software or file signing PGP/GPG public Key they want to verify and trust and ultimately use in their computers. Therefore, one or more trusted third party authority (TTPA) type of entity or group need to be available for users and be usable by users, and such entity/group need to be capable of providing trusted verification or trust delegation services for millions of users around the world, at any time. Practically, to verify any downloaded or received content or data or email or file's authenticity, a user need to verify their downloaded main content or main data/email or main file's PGP/GPG signature code/file (ASC, SIG). So users would need to use original developer's or original author's trustworthy and verified public key, or users would need to use trustworthy file signing public key trusted by the original owner of that public key. And to really trust a specific PGP/GPG key, users would need to physically meet with every specific original author or developer, or users would need to physically meet with the original releaser of file signing pub key, or, users would need to find another alternative trustworthy user, who is in trusted chain of WOT (aka, another user or another developer or another author, who is trusted by that very specific original author or developer), and then physically meet with that person, to verify their real ID with his/her PGP/GPG key (and also provide your own ID and key to the other user, so that both side can sign/certify and trust each other's PGP/GPG key). Whether a software is popular or not, software users are usually located around the world in different locations. It is physically not possible for an original author or developer or file releaser to provide public key or trust or ID verification services to millions of users. Neither is it practical for millions of software users to physically meet with each and every software or every software library or every piece of code's developer or author or releaser, which they will (use or) need to use in their computers. Even with multiple trusted people/person (by original author) in trusted chain from WOT, its still not physically or practically possible for every developer or author to meet with every other users, and it is also not possible for every users to meet with hundreds of developers whose software they will be using or working on. When this decentralized hierarchy based WoT chain model will become popular and used by most nearby users, only then physical meeting and pub key certify and sign procedure of WoT will be easier. A few solutions are: original author/developer need to first set a trust level to sign/certify their own file signing key. Then updated public keys and updated file signing public keys must also have to be published and distributed (or made accessible) to users, via online secure and encrypted mediums, so that any user from any location in world, can get the correct and trusted and unmodified public key. To make sure that each users are getting the correct and trusted public keys and signed code/file, original dev/author or original releaser must publish their updated public keys on their own key server and force HKPS encrypted connection usage, or publish their updated and full public keys (and signed code/file) on their own HTTPS encrypted webpage, under their own web server, from their own primary domain website, (not from any sub domains which are located in external servers, not from any mirror, not from any external/shared forum/wiki etc website servers, not from any public or external/shared cloud or hosting service servers), and must have to be located and kept securely inside their own premises: own home, own home office, or own office. In that way, those small pieces of original keys/code, will travel intact through internet and will remain unmodified during transit (because of encrypted connection) and will reach destination without being eavesdropped or modified, into user's side, and can be treated as trustworthy public keys because of single or multi channel TTPA based verification. When a public key is obtained (from original developer's own web server) via more than one TTPA (trusted third party authority) based secured, verified and encrypted connection, then it is more trustworthy. When original public keys/signed codes are shown in original dev's or author's own web server or key server, over encrypted connection or encrypted webpage, then any other files, data or content can be transferred over any type of non encrypted connection, like: HTTP/FTP etc from any sub domain server or from any mirror or from any shared cloud/hosting servers, because, non encrypted connection based downloaded items/data/files can be authenticated later, by using the original public keys/signed codes, which were obtained from the original author's/developer's own server over secured, encrypted, and trusted (aka, verified) connection/channels. Using encrypted connection to transfer keys or signed/signature code/files, allow software users to delegate their trust with a PKI TTPA (trusted third party authority), like public CA (Certificate Authority), to help in providing trusted connection in between the original developer/author's web server, and millions of worldwide users' computers, at any time. When the original author/developer's domain name and name server is signed by DNSSEC, and when used SSL/TLS public certificate is declared/shown in TLSA/DANE DNSSec DNS resource record, (and when SSL/TLS Certs in the trust chain are pinned and used via HPKP technique by web servers), then a web server's webpage or data can also be verified via another PKI TTPA: DNSSEC and DNS namespace maintainer ICANN, other than a public CA. DNSSEC is another form of PGP/GPG WOT but for name servers; it creates a trusted chain for name servers first (instead of people/person), and then people/person's PGP/GPG Keys and fingerprints can also be added into a server's DNSSEC DNS records. So any users who want to communicate securely (or any software users), can effectively get/receive their data/key/code/webpage etc. verified (aka, authenticated) via two (aka, dual/double) trusted PKI TTPAs/Channels at the same time: ICANN (DNSSEC) and CA (SSL/TLS Certificate). So PGP/GPG key/signed code data (or file) can be trusted, when such solutions and techniques are used: HKPS, HKPS+DNSSEC+DANE, HTTPS, HTTPS+HPKP or HTTPS+HPKP+DNSSEC+DANE. If a vast number of user's group create their own new DLV based DNSSEC registry, and if users use that new DLV (along with ICANN DNSSEC) root key in their own local DNSSEC based DNS Resolver/Server, and if domain owners also use it for additional signing of their own domain names, then there can be a new third TTPA. In such case, any PGP/GPG Key/signed code data or a webpage or web data can be three/triple channel verified. ISC's DLV itself can be used as a third TTPA as its still used widely and active, so availability of another new DLV will become fourth TTPA.