RFC: 5280
Оригинал: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Предыдущие версии: RFC 2459, RFC 3280, RFC 4325, RFC 4630
Категория: Предложенный стандарт
Дата публикации: (с дополнениями из RFC 6818, Январь 2013)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич

8. Проблемы обеспечения информационной безопасности

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

Тем не менее, внешние факторы, влияющие на уровень защищённости, но не рассматриваемые в данном стандарте, могут повлиять на надёжное обслуживание пользователей сертификатов.

Процедуры, реализуемые УЦ и РЦ с цель подтверждения подлинности привязки параметра подлинности владельца сертификата к его открытому ключу, в значительной степени влияют на надёжность и точность того, что должно быть указано в сертификате. Взаимодействующие стороны могут запросить для просмотра официальный отчёт о деятельности УЦ в области сертификации. Это особенно важно, когда сертификаты издаются в интересах других УЦ.

Использование одной пары ключей для подписи и в других целях категорически не допустимо. Использование отдельных пар ключей для подписи и при обеспечении ключами даёт несколько преимуществ для пользователей. Последствия, вызванные потерей или вскрытием ключа, предназначенного для процедуры формирования подписи, отличаются от потери или вскрытия ключа, предназначенного для процедуры обеспечения ключами. Использование отдельных пар ключей позволяет получить сбалансированный и приемлемый ответ. Аналогичным образом, различные периоды действия или размеры для каждой пары ключей могут быть вполне допустимы в некоторых прикладных областях. К сожалению, некоторые реальные прикладные системы (например, уровень защищённых прикладных интерфейсов, Secure Sockets Layer — SSL) используют одну пару ключей для формирования подписи и процедур обеспечения ключами.

Защита, обеспечиваемая закрытыми ключами, является фактором риска. В малых масштабах, небрежность пользователей по защите своих закрытых ключей может предоставить нарушителю шанс для проведения атаки типа «маскарад» (под видом полномочных пользователей) или дешифровать их персональные данные. В больших масштабах, компрометация закрытого ключа УЦ, предназначенного для формирования подписи, может иметь катастрофические последствия.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.