#security #x509certificate #ssl #x509
#Безопасность #x509certificate #ssl #x509
Вопрос:
Я прочитал части RFC 2459 (Сертификат инфраструктуры открытых ключей Интернета X.509 и профиль CRL), которые, как я полагал, имеют отношение к этому вопросу. Однако мне не совсем ясно, какова цель периода действия (в частности, даты истечения срока действия) сертификата.
Насколько я понимаю, целью сертификата является привязка открытого ключа к удостоверению способом, который может быть проверен (в X.509 через центр сертификации или в OpenPGP через сеть доверия). Поэтому мне кажется, что сертификат будет действителен с момента его создания до момента компрометации соответствующего закрытого ключа (или увольнения сотрудника, или чего-то еще), и в этом случае он будет внесен в список отзыва сертификата (я полагаю).
При каких обстоятельствах это неверно? Почему привязка удостоверения к открытому ключу внезапно становится недействительной? Я знаю, что большинство центров сертификации являются коммерческими предприятиями, и поэтому было бы выгодно взимать регулярную плату, но я создаю проект с открытым исходным кодом, который просто генерирует сертификаты (бесплатно), которые привязывают имя пользователя на сервере к открытому ключу, а пароль пользователя используется для подтверждения его личности в CA (который, конечно, хранит его хэшированный пароль).
Ответ №1:
Идея состоит в том, чтобы сократить окно возможностей в случае, если закрытый ключ будет скомпрометирован. Отзыв возможен, только если скомпрометированная сторона знает об этом. Кроме того, существующие механизмы отзыва не совсем надежны, поэтому хорошо иметь фиксированную дату истечения срока действия.
Комментарии:
1. Не могли бы вы объяснить, почему существующие механизмы отзыва не являются полностью надежными? Если пользователь проверяет ключ в CA каждый раз, когда он используется, разве CA не сообщит ему, что он находится в CRL?
2. Например, большинство браузеров игнорируют проверки отзыва, когда сервер отзыва недоступен. Таким образом, если злоумышленник имеет доступ к вашему маршрутизатору, он может легко заблокировать их, чтобы избежать проверки отзыва.
3. @bowenl2: Адам здесь ни при чем. Неудачный аспект заключается в том, что центры сертификации не имеют инфраструктуры, необходимой для гарантии 100% (или близкой к этому) времени безотказной работы. Вот почему браузеры игнорируют сбои. В этом случае было сочтено более важным позволить людям продолжать совершать покупки, чем закрывать сайты, когда с центром сертификации невозможно связаться. Смотрите blog.spiderlabs.com/2011/04 /…
4. и @Chris: большое спасибо за эту информацию. Программное обеспечение, которое я пишу, будет проверять сертификат каждый раз. Я понятия не имел об этом, так что поднимайтесь.
Ответ №2:
Я почти уверен, что вы ответили на свой собственный вопрос относительно коммерческого аспекта. Но я добавлю сюда еще один.
Это, в частности, для защиты от потерь, когда вы понятия не имеете, что они вообще были утеряны. Другими словами, это будет отображаться в списке отзыва сертификата только в том случае, если кто-то узнает, что он был скомпрометирован. Есть много случаев, в которых вы не будете знать, что он был скомпрометирован, поэтому хорошо иметь способ принудительного обновления ключа.
Это похоже на старые времена, когда шпион использовал шифр, который менялся ежедневно. Не то чтобы они думали, что старые ключи были скомпрометированы, они изменили, потому что они понятия не имели, были ли ключи скомпрометированы.
Другим примером является то, что срок действия вашего пароля истекает примерно каждые 90 дней. Он истекает не потому, что известно, что он был утерян; он истекает в случае, когда он был утерян, а вы об этом не знаете.