stringtranslate.com

Сертификат открытого ключа

В криптографии сертификат открытого ключа , также известный как цифровой сертификат или сертификат личности , представляет собой электронный документ, используемый для подтверждения действительности открытого ключа . [1] [2] Сертификат включает в себя открытый ключ и информацию о нем, информацию о личности его владельца (называемую субъектом) и цифровую подпись лица, проверившего содержимое сертификата (называемого эмитентом). Если устройство, проверяющее сертификат, доверяет эмитенту и обнаруживает, что подпись является действительной подписью этого эмитента, то оно может использовать включенный открытый ключ для безопасного взаимодействия с субъектом сертификата. В системах шифрования электронной почты , подписи кода и электронной подписи субъектом сертификата обычно является физическое лицо или организация. Однако в Transport Layer Security (TLS) субъектом сертификата обычно является компьютер или другое устройство, хотя сертификаты TLS могут идентифицировать организации или отдельных лиц в дополнение к их основной роли в идентификации устройств. TLS, иногда называемый старым названием Secure Sockets Layer (SSL), примечателен тем, что является частью HTTPS , протокола для безопасного просмотра веб-страниц .

В типичной схеме инфраструктуры открытых ключей (PKI) эмитентом сертификата является центр сертификации (CA), [3] обычно компания, которая взимает с клиентов плату за выдачу для них сертификатов. Напротив, в схеме сети доверия люди подписывают ключи друг друга напрямую в формате, который выполняет функцию, аналогичную сертификату открытого ключа. В случае компрометации ключа сертификат может потребоваться отозвать .

Наиболее распространенный формат сертификатов открытых ключей определяется X.509 . Поскольку X.509 является очень общим, формат дополнительно ограничен профилями, определенными для определенных случаев использования, таких как инфраструктура открытых ключей (X.509) , как определено в RFC  5280.

Виды сертификатов

Роли корневого сертификата, промежуточного сертификата и сертификата конечного объекта как в цепочке доверия .

Сертификат сервера TLS/SSL

Протокол Transport Layer Security (TLS), а также его устаревший предшественник, протокол Secure Sockets Layer (SSL), гарантируют безопасность связи между клиентским компьютером и сервером . Протокол требует, чтобы сервер предоставил цифровой сертификат, подтверждающий, что это предполагаемый пункт назначения. Подключающийся клиент проводит проверку пути сертификации , гарантируя, что:

  1. Субъект сертификата соответствует имени хоста (не путать с именем домена ), к которому пытается подключиться клиент.
  2. Доверенный центр сертификации подписал сертификат.

Поле «Субъект» сертификата должно указывать основное имя хоста сервера как общее имя . [ необходимо разъяснение ] Сертификат может быть действителен для нескольких имен хостов (например, домена и его поддоменов). Такие сертификаты обычно называются сертификатами альтернативного имени субъекта (SAN) или сертификатами унифицированных коммуникаций (UCC) . Эти сертификаты содержат поле «Альтернативное имя субъекта» , хотя многие центры сертификации также помещают их в поле «Общее имя субъекта» для обеспечения обратной совместимости. Если некоторые имена хостов содержат звездочку (*), сертификат также можно назвать сертификатом с подстановочными знаками .

После успешной проверки пути сертификации клиент может установить зашифрованное соединение с сервером.

Серверы с выходом в Интернет, такие как общедоступные веб-серверы , должны получать свои сертификаты от доверенного общедоступного центра сертификации (CA).

Сертификат клиента TLS/SSL

Сертификаты клиента аутентифицируют клиента, подключающегося к службе TLS, например, для обеспечения контроля доступа. Поскольку большинство служб предоставляют доступ отдельным лицам, а не устройствам, большинство клиентских сертификатов содержат адрес электронной почты или личное имя, а не имя хоста. Кроме того, центром сертификации, выдающим сертификат клиента, обычно является поставщик услуг, к которому подключается клиент, поскольку именно этому поставщику необходимо выполнить аутентификацию. Некоторые поставщики услуг даже предлагают бесплатные сертификаты SSL как часть своих пакетов. [4]

Хотя большинство веб-браузеров поддерживают клиентские сертификаты, наиболее распространенной формой аутентификации в Интернете является пара имени пользователя и пароля. Клиентские сертификаты чаще встречаются в виртуальных частных сетях (VPN) и службах удаленных рабочих столов , где они аутентифицируют устройства.

Сертификат электронной почты

В соответствии с протоколом S/MIME сертификаты электронной почты могут как устанавливать целостность сообщения, так и шифровать сообщения. Чтобы установить зашифрованную связь по электронной почте, общающиеся стороны должны заранее иметь свои цифровые сертификаты. Каждый должен отправить другому электронное письмо с цифровой подписью и выбрать импорт сертификата отправителя.

Некоторые общедоступные центры сертификации предоставляют сертификаты электронной почты, но чаще всего S/MIME используется при общении внутри конкретной организации, и эта организация имеет собственный центр сертификации, которому доверяют участники этой системы электронной почты.

Самозаверяющие и корневые сертификаты

Самозаверяющий сертификат — это сертификат, субъект которого соответствует его эмитенту, и подпись, которую можно проверить с помощью собственного открытого ключа.

Самоподписанные сертификаты имеют свое ограниченное применение. Они имеют полное значение доверия, если эмитент и единственный пользователь являются одним и тем же лицом. Например, шифрованная файловая система в Microsoft Windows выдает самозаверяющий сертификат от имени шифрующего пользователя и использует его для прозрачного расшифровывания данных на лету. Цепочка доверия цифровых сертификатов начинается с самозаверяющего сертификата, называемого корневым сертификатом , якорем доверия или корнем доверия . Центр сертификации самостоятельно подписывает корневой сертификат, чтобы иметь возможность подписывать другие сертификаты.

Промежуточный сертификат имеет то же назначение, что и корневой сертификат: его единственное назначение — подписывать другие сертификаты. Однако промежуточный сертификат не является самоподписанным. Его необходимо подписать корневым сертификатом или другим промежуточным сертификатом.

Сертификат конечного объекта или листовой сертификат — это любой сертификат, который не может подписывать другие сертификаты. Например, сертификаты сервера и клиента TLS/SSL, сертификаты электронной почты, сертификаты подписи кода и квалифицированные сертификаты — все это сертификаты конечного объекта.

Другие сертификаты

Общие поля

Это одни из наиболее распространенных полей сертификатов. Большинство сертификатов содержат ряд полей, не перечисленных здесь. Обратите внимание, что с точки зрения представления сертификата X.509 сертификат не является «плоским», а содержит эти поля, вложенные в различные структуры сертификата.

Пример

Это пример декодированного сертификата SSL/TLS, полученного с веб-сайта SSL.com. Общее имя эмитента (CN) отображается как SSL.com EV SSL Intermediate CA RSA R3, что указывает на сертификат расширенной проверки (EV). В поле указана проверенная информация о владельце сайта (SSL Corp) Subject. Поле X509v3 Subject Alternative Nameсодержит список доменных имен, на которые распространяется сертификат. Поля X509v3 Extended Key Usageи X509v3 Key Usageпоказывают все соответствующие варианты использования.

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31 Алгоритм подписи: sha256WithRSAEncryption Эмитент: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3 Период действия Не раньше: 18 апреля 22:15:06 2019 г. по Гринвичу Не после: 17 апреля 22:15:06 2021 г. по Гринвичу Тема: C=США, ST=Техас, L=Хьюстон, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Частная организация/street=3100 Richmond Ave/jurisdictionST=Nevada/ юрисдикцияC=США Информация об открытом ключе субъекта: Алгоритм открытого ключа: rsaEncryption Открытый ключ RSA: (2048 бит) Модуль: 00:ad:0f:ef:c1:97:5a:9b:d8:1e ... Экспонента: 65537 (0x10001) Расширения X509v3: Идентификатор авторизационного ключа X509v3: keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD Доступ к информации органов власти: Эмитенты ЦС — URI: http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP — URI: http://ocsps.ssl.com X509v3 Альтернативное имя субъекта: DNS:www.ssl.com, DNS:ответы.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS: secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com Политики сертификатов X509v3: Политика: 2.23.140.1.1 Политика: 1.2.616.1.113527.2.5.1.1 Политика: 1.3.6.1.4.1.38064.1.1.1.5 CPS: https://www.ssl.com/repository Использование расширенного ключа X509v3: Аутентификация веб-клиента TLS, Аутентификация веб-сервера TLS Точки распространения CRL X509v3: Полное имя: URI: http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl X509v3 Идентификатор ключа субъекта: E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B Использование ключа X509v3: критическое Цифровая подпись, шифрование ключей Предварительные сертификаты CT SCT: Временная метка подписанного сертификата: Версия: v1 (0x0) Идентификатор журнала: 87:75:BF:E7:59:7C:F8:8C:43:99 ... Временная метка: 18 апреля 22:25:08.574 2019 г. по Гринвичу. Расширения: нет Подпись: ecdsa-with-SHA256 30:44:02:20:40:51:53:90:C6:A2 ... Временная метка подписанного сертификата: Версия: v1 (0x0) Идентификатор журнала: A4:B9:09:90:B4:18:58:14:87:BB ... Временная метка: 18 апреля 22:25:08.461 2019 г. по Гринвичу. Расширения: нет Подпись: ecdsa-with-SHA256 30:45:02:20:43:80:9Э:19:90:ФД... Временная метка подписанного сертификата: Версия: v1 (0x0) Идентификатор журнала: 55:81:D4:C2:16:90:36:01:4A:EA ... Временная метка: 18 апреля 22:25:08.769 2019 г. по Гринвичу. Расширения: нет Подпись: ecdsa-with-SHA256 30:45:02:21:00:C1:3E:9F:F0:40 ... Алгоритм подписи: sha256WithRSAEncryption 36:07:e7:3b:b7:45:97:ca:4d:6c ...

Использование в Европейском Союзе

В Европейском Союзе (расширенные) электронные подписи на юридических документах обычно выполняются с использованием цифровых подписей с сопровождающими сертификатами личности. Однако только квалифицированные электронные подписи (которые требуют использования квалифицированного поставщика доверенных услуг и устройства создания подписи) имеют ту же силу, что и физическая подпись.

Центры сертификации

Процедура получения сертификата открытого ключа

В модели доверия X.509 за подпись сертификатов отвечает центр сертификации (CA). Эти сертификаты действуют как средство знакомства между двумя сторонами, а это означает, что центр сертификации выступает в качестве доверенной третьей стороны. Центр сертификации обрабатывает запросы от людей или организаций, запрашивающих сертификаты (называемых подписчиками), проверяет информацию и потенциально подписывает сертификат конечного объекта на основе этой информации. Чтобы эффективно выполнять эту роль, центру сертификации необходимо иметь один или несколько корневых сертификатов с широким доверием или промежуточных сертификатов и соответствующие закрытые ключи. Центры сертификации могут добиться такого широкого доверия, включив свои корневые сертификаты в популярное программное обеспечение или получив перекрестную подпись от другого центра сертификации, делегирующего доверие. Другим центрам сертификации доверяют в относительно небольшом сообществе, например в бизнесе, и они распространяются с помощью других механизмов, таких как групповая политика Windows .

Центры сертификации также несут ответственность за поддержание актуальной информации об отзыве выданных ими сертификатов с указанием того, действительны ли сертификаты. Они предоставляют эту информацию через протокол статуса онлайн-сертификатов (OCSP) и/или списки отзыва сертификатов (CRL). Некоторые из крупнейших центров сертификации на рынке включают IdenTrust , DigiCert и Sectigo . [8]

Корневые программы

Некоторые основные программы содержат список центров сертификации, которым по умолчанию доверяют. [ нужна цитация ] Это упрощает проверку сертификатов конечным пользователям, а людям и организациям, которые запрашивают сертификаты, легче узнать, какие центры сертификации могут выдать сертификат, которому будет широко доверять. Это особенно важно для HTTPS, где оператор веб-сайта обычно хочет получить сертификат, которому доверяют почти все потенциальные посетители его веб-сайта.

Политики и процессы, которые поставщик использует для принятия решения о том, каким центрам сертификации должно доверять его программное обеспечение, называются корневыми программами. Наиболее влиятельными корневыми программами являются: [ нужна ссылка ]

Браузеры, отличные от Firefox, обычно используют возможности операционной системы, чтобы решить, каким центрам сертификации можно доверять. Так, например, Chrome в Windows доверяет центрам сертификации, включенным в корневую программу Microsoft, а в macOS или iOS Chrome доверяет центрам сертификации в корневой программе Apple. [9] Edge и Safari также используют хранилища доверенных сертификатов своих операционных систем, но каждое из них доступно только в одной ОС. Firefox использует доверенное хранилище корневой программы Mozilla на всех платформах.

Корневая программа Mozilla работает публично, а ее список сертификатов является частью веб-браузера Firefox с открытым исходным кодом , поэтому он широко используется за пределами Firefox. [ нужна цитация ] Например, хотя не существует общей корневой программы Linux, многие дистрибутивы Linux, такие как Debian, [10] включают пакет, который периодически копирует содержимое списка доверия Firefox, который затем используется приложениями.

Корневые программы обычно предоставляют набор действительных целей вместе с включенными в них сертификатами. Например, некоторые центры сертификации могут считаться доверенными для выдачи сертификатов сервера TLS, но не для сертификатов подписи кода. На это указывает набор битов доверия в системе хранения корневых сертификатов.

отзыв

Сертификат может быть отозван до истечения срока его действия, что означает, что он больше не действителен. Без отзыва злоумышленник сможет использовать такой скомпрометированный или неправильно выданный сертификат до истечения срока его действия. [11] Следовательно, отзыв является важной частью инфраструктуры открытых ключей . [12] Отзыв выполняется выдавшим сертификат центром , который выдает криптографически заверенное заявление об отзыве. [13]

При распространении информации об отзыве среди клиентов своевременность обнаружения отзыва (и, следовательно, возможность злоумышленнику использовать скомпрометированный сертификат) снижает использование ресурсов при запросе статусов отзыва и проблемы конфиденциальности. [14] Если информация об отзыве недоступна (либо из-за аварии, либо из-за атаки), клиенты должны решить, следует ли использовать отказоустойчивый сертификат и рассматривать сертификат как отозванный (и, таким образом, ухудшать доступность ) или отказоустойчивый и рассматривать его как неотозванным (и позволяет злоумышленникам обойти отзыв). [15]

Из-за стоимости проверок отзыва и влияния на доступность потенциально ненадежных удаленных служб веб-браузеры ограничивают выполняемые ими проверки отзыва и работают без сбоев там, где они это делают. [16] Списки отзыва сертификатов слишком затратны для повседневного использования, а протокол статуса онлайн-сертификатов создает проблемы с задержкой соединения и конфиденциальностью. Были предложены и другие схемы, позволяющие обеспечить отказоустойчивую проверку, но они еще не были успешно реализованы. [12]

Безопасность сайта

Чаще всего сертификаты используются для веб-сайтов на базе HTTPS . Веб -браузер проверяет подлинность веб-сервера HTTPS , чтобы пользователь мог чувствовать себя в безопасности, что его/ее взаимодействие с веб-сайтом не подслушивается и что веб-сайт является тем, за кого себя выдает. Эта безопасность важна для электронной коммерции . На практике оператор веб-сайта получает сертификат, обращаясь в центр сертификации с запросом на подпись сертификата . Запрос сертификата представляет собой электронный документ, содержащий название веб-сайта, информацию о компании и открытый ключ. Поставщик сертификата подписывает запрос, создавая таким образом общедоступный сертификат. Во время просмотра веб-страниц этот общедоступный сертификат передается любому веб-браузеру, который подключается к веб-сайту, и доказывает веб-браузеру, что провайдер считает, что он выдал сертификат владельцу веб-сайта.

Например, когда пользователь подключается к https://www.example.com/своему браузеру, и если браузер не выдает никакого предупреждающего сообщения о сертификате, то пользователь может быть теоретически уверен, что взаимодействие с https://www.example.com/эквивалентно взаимодействию с объектом, контактирующим с адресом электронной почты, указанным в общедоступному регистратору под именем «example.com», хотя этот адрес электронной почты может не отображаться нигде на веб-сайте. [ необходима цитата ] Никакие другие гарантии любого рода не подразумеваются. Кроме того, отношения между покупателем сертификата, оператором веб-сайта и создателем контента веб-сайта могут быть ненадежными и не гарантируются. [ нужна цитата ] В лучшем случае сертификат гарантирует уникальность веб-сайта при условии, что сам веб-сайт не был скомпрометирован (взломан) или процесс выдачи сертификата не нарушен.

Поставщик сертификатов может выбрать выдачу трех типов сертификатов, каждый из которых требует своей степени строгости проверки. В порядке возрастания строгости (и, естественно, стоимости) это: проверка домена, проверка организации и расширенная проверка. Эти требования в общих чертах согласованы между добровольными участниками CA/Browser Forum . [ нужна цитата ]

Уровни проверки

Проверка домена

Поставщик сертификатов выдаст покупателю сертификат с проверкой домена (DV), если покупатель сможет продемонстрировать один критерий проверки: право на административное управление затронутыми доменами DNS.

Проверка организации

Поставщик сертификатов выдаст покупателю сертификат класса проверки организации (OV), если покупатель может соответствовать двум критериям: право на административное управление рассматриваемым доменным именем и, возможно, фактическое существование организации как юридического лица. Поставщик сертификатов публикует критерии проверки OV в своей политике сертификатов .

Расширенная проверка

Чтобы получить сертификат расширенной проверки (EV), покупатель должен убедить поставщика сертификата в своей юридической идентичности, включая проверку вручную человеком. Как и в случае с сертификатами OV, поставщик сертификатов публикует свои критерии проверки EV через свою политику сертификатов .

До 2019 года основные браузеры, такие как Chrome и Firefox, обычно предлагали пользователям визуальное указание юридической личности, когда сайт предъявлял сертификат EV. Это было сделано путем отображения официального имени перед доменом и ярко-зеленого цвета, чтобы подчеркнуть изменение. В большинстве браузеров эта функция признана устаревшей [17] [18] , что не дает пользователю визуальной разницы в типе используемого сертификата. Это изменение последовало за проблемами безопасности, поднятыми экспертами-криминалистами, и успешными попытками приобрести сертификаты электромобилей, чтобы выдать себя за известные организации, доказав неэффективность этих визуальных индикаторов и выявив потенциальные злоупотребления. [19]

Недостатки

Веб -браузер не будет предупреждать пользователя, если веб-сайт внезапно представит другой сертификат, даже если этот сертификат имеет меньшее количество ключевых бит, даже если у него другой поставщик, и даже если у предыдущего сертификата была дата истечения срока действия. далеко в будущее. [ нужна цитата ] Если поставщики сертификатов находятся под юрисдикцией правительств, эти правительства могут иметь право приказать поставщику создать любой сертификат, например, для целей правоохранительных органов. Дочерние оптовые поставщики сертификатов также имеют право создавать любые сертификаты.

Все веб-браузеры имеют обширный встроенный список доверенных корневых сертификатов , многие из которых контролируются организациями, которые могут быть незнакомы пользователю. [1] Каждая из этих организаций имеет право выдавать любой сертификат для любого веб-сайта и иметь гарантию того, что веб-браузеры, включающие ее корневые сертификаты, примут его как подлинный. В этом случае конечные пользователи должны полагаться на разработчика программного обеспечения браузера, который будет управлять встроенным списком сертификатов, а также на то, что поставщики сертификатов будут вести себя правильно и информировать разработчика браузера о проблемных сертификатах. Хотя это и редкость, но бывали случаи выдачи поддельных сертификатов: в некоторых случаях мошенничество обнаруживали браузеры; в других прошло некоторое время, прежде чем разработчики браузеров удалили эти сертификаты из своего программного обеспечения. [20] [21]

Список встроенных сертификатов также не ограничивается сертификатами, предоставленными разработчиком браузера: пользователи (и в некоторой степени приложения) могут расширять список для специальных целей, например, для интрасетей компании. [22] Это означает, что если кто-то получит доступ к машине и сможет установить новый корневой сертификат в браузере, этот браузер распознает веб-сайты, использующие вставленный сертификат, как законные.

Для доказуемой безопасности такая зависимость от чего-то внешнего по отношению к системе приводит к тому, что любая схема сертификации открытых ключей должна опираться на некоторые специальные предположения, такие как существование центра сертификации . [23]

Полезность и незащищенные веб-сайты

Несмотря на описанные выше ограничения, TLS с проверкой сертификата считается обязательным согласно всем правилам безопасности, когда на веб-сайте размещается конфиденциальная информация или выполняются существенные транзакции. Это связано с тем, что на практике, несмотря на описанные выше недостатки, веб-сайты, защищенные сертификатами открытого ключа, по-прежнему более безопасны, чем незащищенные веб-сайты http:// . [24]

Стандарты

Отдел компьютерной безопасности Национального института стандартов и технологий ( NIST ) [25] предоставляет руководящие документы для сертификатов открытых ключей:

Смотрите также

Рекомендации

  1. ^ ab «Список сертификатов, включенных Mozilla». Мозилла.орг. Архивировано из оригинала 3 августа 2012 года . Проверено 30 июля 2012 г.
  2. ^ Альравайс, Арва; Альхотайли, Абдулрахман; Ченг, Сючжэнь ; Ху, Чунцян; Ю, Цзиго (01.06.2018). «SecureGuard: система проверки сертификатов в инфраструктуре открытых ключей». Транзакции IEEE по автомобильным технологиям . 67 (6): 5399–5408. дои :10.1109/TVT.2018.2805700. ISSN  0018-9545. S2CID  49270949. Архивировано из оригинала 26 августа 2022 г. Проверено 26 августа 2022 г.
  3. ^ Чедвик, Дэвид В.; Басден, Эндрю (31 октября 2001 г.). «Оценка доверия к центру сертификации открытых ключей». Компьютеры и безопасность . 20 (7): 592–611. дои : 10.1016/S0167-4048(01)00710-6. ISSN  0167-4048. Архивировано из оригинала 26 февраля 2022 г. Проверено 26 февраля 2022 г.
  4. ^ «Бесплатный SSL-сертификат | IONOS от 1&1» . www.ionos.co.uk . Архивировано из оригинала 18 июля 2022 г. Проверено 15 июля 2022 г.
  5. ^ "ЭМВ Калифорния". Центр сертификации EMV по всему миру. 2 декабря 2010 г. Архивировано из оригинала 4 июля 2020 г. . Проверено 20 января 2020 г.
  6. ^ «Политика сертификатов X.509 для Федерального центра сертификации мостов (FBCA)» (PDF) . Архивировано (PDF) из оригинала 18 марта 2021 г. Проверено 7 мая 2021 г.
  7. ^ «Политика сертификатов X.509 для Федерального центра сертификации мостов (FBCA)» (PDF) . Архивировано (PDF) из оригинала 18 марта 2021 г. Проверено 7 мая 2021 г.
  8. ^ «Статистика использования и рыночная доля центров сертификации SSL для веб-сайтов, май 2020 г.» . w3techs.com . Архивировано из оригинала 30 июня 2022 г. Проверено 1 мая 2020 г.
  9. ^ «Политика корневых сертификатов - Проекты Chromium» . www.chromium.org . Архивировано из оригинала 20 марта 2017 г. Проверено 19 марта 2017 г.
  10. ^ «CA-сертификаты в Launchpad» . launchpad.net . 30 апреля 2010 г. Архивировано из оригинала 20 марта 2017 г. Проверено 19 марта 2017 г.
  11. ^ Смит, Дикинсон и Симонс 2020, стр. 1.
  12. ^ Аб Шеффер, Сен-Андре и Фоссати, 2022, 7.5. Отзыв сертификата.
  13. ^ Чунг и др. 2018, с. 3.
  14. ^ Смит, Дикинсон и Симонс 2020, стр. 10.
  15. ^ Лариш и др. 2017, с. 542.
  16. ^ Смит, Дикинсон и Симонс 2020, стр. 1-2.
  17. ^ «Группа Google Firefox-dev – Намерение отправить: переместить информацию расширенной проверки из строки URL» . groups.google.com . Архивировано из оригинала 12 августа 2020 г. Проверено 3 августа 2020 г.
  18. ^ «Группа разработчиков безопасности Chrome в Google — предстоящие изменения в индикаторах идентификации Chrome» . groups.google.com . Архивировано из оригинала 07.06.2020 . Проверено 3 августа 2020 г.
  19. ^ «Сертификаты расширенной проверки (действительно, действительно) мертвы» . troyhunt.com . 12 августа 2019 г. Архивировано из оригинала 16 июля 2020 г. Проверено 3 августа 2020 г.
  20. ^ «Удаление DigiNotar компанией Mozilla» . Мозилла.орг. 2 сентября 2011 г. Архивировано из оригинала 3 июня 2012 г. Проверено 30 июля 2012 г.
  21. ^ «Удаление DigitNotar компанией Google» . Архивировано из оригинала 13 сентября 2011 года . Проверено 30 июля 2012 г.
  22. ^ «Статья об использовании сертификатов на Mozilla.org» . Мозилла.орг. Архивировано из оригинала 12 июля 2012 года . Проверено 30 июля 2012 г.
  23. ^ Ран Канетти: Универсальная составная подпись, сертификация и аутентификация. CSFW 2004, http://eprint.iacr.org/2003/239. Архивировано 28 августа 2009 г. в Wayback Machine.
  24. ↑ Бен Лори , Ян Голдберг (18 января 2014 г.). «Замена паролей в Интернете, известная как оппортунистическое шифрование после Сноудена» (PDF) . Архивировано (PDF) из оригинала 27 октября 2014 г. Проверено 15 ноября 2014 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  25. ^ «Публикации NIST по компьютерной безопасности - Специальные публикации NIST (SP)» . csrc.nist.gov . Архивировано из оригинала 17 сентября 2017 г. Проверено 19 июня 2016 г.
  26. ^ «SP 800-32 Введение в технологию открытых ключей и федеральную инфраструктуру PKI» (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 5 июня 2018 г. Проверено 19 июня 2016 г.
  27. ^ «SP 800-25 Использование технологии открытого ключа Федеральным агентством для цифровых подписей и аутентификации» (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 02 июня 2018 г. Проверено 19 июня 2016 г.

Цитируемые работы