Направления стандартизации
Направления стандартизации
Группа PKIX IETF разрабатывает документы для следующих направлений стандартизации:
1 профили сертификатов и списков аннулированных сертификатов;
2 протоколы управления ;
3 операционные протоколы ;
4 политики применения сертификатов и регламенты;
5 сервисы проставления меток времени и сертификации/валидации данных.
К первому направлению относятся стандарты RFC 3280 [167], RFC 3281 [168], RFC 3039 [164] и RFC 3279 [166]. Стандарт RFC 3280 (бывший RFC 2459) Certificate & CRL Profile предлагает форматы сертификатов версии X.509 v3 и списка аннулированных сертификатов версии X.509 v2 для использования в Интернете, детализирует информацию, относящуюся к формам имен и стандартным дополнениям. Документ описывает алгоритм проверки цепочек сертификатов и форматы открытых ключей и электронной цифровой подписи для алгоритмов шифрования ключей RSA, DSA и Диффи-Хэллмана.
Стандарт RFC 3281An Internet Attribute Certificate Profile for Authorization определяет профиль атрибутного сертификата для использования в Интернет-протоколах. Атрибутный сертификат подобен сертификату открытого ключа, но в отличие от него содержит не открытый ключ, а атрибуты, характеризующие его владельца: принадлежность к какой-либо группе, роль, полномочия, уровень прозрачности информации о владельце и т.п. Стандарт обеспечивает поддержку атрибутных сертификатов для электронной почты в Интернете, протокола IPsec, приложений безопасности World Wide Web.
Стандарт RFC 3039 Qualified Certificates Profile описывает формат сертификата ограниченного использования. Владельцем этого сертификата может быть только физическое лицо. Термин "ограниченное использование" трактуется в общепринятом для государственного права смысле. Пока стандарт определяет основной синтаксис сертификата ограниченного использования без учета особенностей законодательства разных стран.
Стандарт RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key In-frastructure Certificate and Certificate Revocation List (CRL) Profile определяет идентификаторы алгоритмов и форматы шифрования используемых в PKIX открытых ключей и цифровых подписей, односторонние хэш-функции для генерации ЭЦП сертификатов и САС. Стандарт описывает шифрование цифровых подписей, сгенерированных при помощи криптографических алгоритмов RSA, DSA и алгоритма эллиптических кривых (ECDSA), задает форматы шифрования открытых ключей, используемых в криптографических алгоритмах RSA, DSA, Диффи-Хеллмана и алгоритма шифрования ключей (KEA).
Второе направление представлено документами RFC 2510 [150], RFC 2511 [151], RFC 2560 [155] и RFC 2797 [160]. Стандарты RFC 2510 Certificate Management Protocols (CMP) и RFC2511 Certificate Request Protocol определяют соответственно сообщения протоколов для процессов создания и управления сертификатами и синтаксис запроса на выпуск сертификата формата X.509.
Стандарт RFC 2560 Online Certificate Status Protocol (OCSP) предлагает онлайновый протокол для определения статуса сертификата без использования САС. По замыслу разработчиков, этот протокол должен удовлетворять операционным требованиям более своевременного поступления информации об аннулировании, чем это возможно при помощи САС. Протокол управляет обменом данными между OCSP-клиентами, проверяющими статус сертификата, и OCSP-исполнителем, информирующим об этом статусе.
Стандарт RFC 2797 Certificate Management Messages over CMS определяет протокол управления сертификатами на основе сообщений управления сертификатами. Документ разрабатывался для решения двух важных проблем сообщества PKI в Интернете:
1 реализации интерфейса с продуктами и сервисами PKI, базирующимися на сообщениях управления сертификатами и стандарте синтаксиса запроса на сертификат - PKCS#10;
2 использования стандарта SMIME v3 в протоколе регистрации сертификатов открытых ключей (Диффи-Хеллмана), подписанных при помощи алгоритма DSA.
К третьему направлению можно отнести документы RFC 2559 [154], RFC 2587 [157] и RFC 2585 [156].
Стандарт RFC 2559 LDAP V2 Operational Protocols закрепляет использование протокола LDAP v2 для обеспечения доступа к репозиторию с целью поиска сертификатов и другой релевантной PKI информации и управления ими.
Стандарт RFC 2587 LDAP V2 Schema описывает минимально необходимую схему поддержки PKIX в среде LDAP v2 (как этого требует документ RFC 2559) и определяет только специфические PKIX-компоненты. В соответствии с этим документом серверы LDAP, действующие как хранилища (репозитории) PKIX, должны поддерживать вспомогательные классы объектов, определенные данным стандартом, и интегрировать эту схему с общими и специфическими для приложений схемами в зависимости от сервисов, предоставляемых сервером.
Документ RFC 2585 HTTP/FTP Operations описывает применение протоколов HTTP/FTP для получения сертификатов и списков аннулированных сертификатов из репозитория УЦ.
Четвертое направление представлено одним базовым стандартом RFC 2527 Certificate Policy and Certification Practices Framework [152], определяющим политику применения сертификатов и структуру регламента УЦ и подробно описанным в лекции 14.
К пятому направлению стандартизации относятся документы RFC 3029 [163], RFC 2875 [162], RFC 3161 [165]. Стандарт RFC 3029 Data Validation and Certification Server Protocols вводит понятие сервера сертификации и проверки достоверности данных для обеспечения надежности сервисов неотказуемости и предлагает протоколы для взаимодействия с этим сервером. На сервер возлагаются функции доверенной третьей стороны, проверяющей подлинность сертификатов открытых ключей и документов с цифровой подписью.
Стандарт RFC 2875 Diffie-Hellman Proof-of-Possession (POP) Algorithms описывает два метода получения значения проверки целостности на основе пары ключей Диффи-Хэллмана. В документе предлагаются два алгоритма доказывания владения, использующие процесс согласования ключей Диффи-Хеллмана для получения разделенного секрета на основе значения проверки целостности. В первом алгоритме значение формируется для конкретного получателя/верификатора при помощи открытого ключа этого верификатора. Во втором алгоритме значение формируется для произвольного верификатора. Документ RFC 3161 Time-Stamp Protocol (TSP) описывает протокол проставления метки времени.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
Приоритетные направления развития Yaffil
Приоритетные направления развития Yaffil Интеграция с платформой Windows NT Изначально InterBase разрабатывался на платформах Unix и только в начале 9()- годов в версии 4.0 был перенесен на Windows NT. К сожалению, при переносе кода мало внимания было уделено платформозависимой оптимизации
Направления токов
Направления токов Некоторые токи в распечатке приведены как положительные, другие — как отрицательные. Например, запись I(R1)=-9,704Е-02 означает ток IR1=-97,04 мА. Описание резистора R1 во входном файле имеет вид:R1 1 2 100Поскольку PSpice дает для тока I(R1) отрицательный знак, реальное
Направления исследования
Направления исследования Мы рассмотрим здесь восемь направлений исследования, связанных с программированием и организационной эффективностью. Удивительно, но все они свидетельствуют в пользу парного программирования. Итак, мы вели наши исследовали в следующих
ГЛАВА 5. БУДУЩИЕ НАПРАВЛЕНИЯ РАЗВИТИЯ СММ
ГЛАВА 5. БУДУЩИЕ НАПРАВЛЕНИЯ РАЗВИТИЯ СММ Достижение более высоких уровней зрелости производственного процесса является постепенным и требует от организации долгосрочных обязательств по непрерывному усовершенствованию процесса. На построение фундамента для
17.3. IETF и процесс RFC-стандартизации
17.3. IETF и процесс RFC-стандартизации Когда Unix-сообщество соединилось с культурой Internet-инженеров, в него также проникло мышление, сформированное процессом RFC-стандартизации IETF (Internet Engineering Task Force — Инженерная группа по решению конкретной задачи в Internet). Согласно традиции IETF,
17.3. IETF и процесс RFC-стандартизации
17.3. IETF и процесс RFC-стандартизации Когда Unix-сообщество соединилось с культурой Internet-инженеров, в него также проникло мышление, сформированное процессом RFC-стандартизации IETF (Internet Engineering Task Force — Инженерная группа по решению конкретной задачи в Internet). Согласно традиции IETF,
Установка направления взгляда
Установка направления взгляда Для установки направления взгляда удобно использовать плавающую панель инструментов View, содержащую целый ряд кнопок с типовыми видами на объекты (рис. 20.1). Назначение кнопок слева направо:• Named Views… – сохранение и восстановление
Установка направления взгляда
Установка направления взгляда Команда VPOINT устанавливает точку зрения в текущей системе координат и может использоваться для фиксации трехмерного вида относительно ПСК. Системная переменная WORLDVIEW определяет, какая система координат будет использована для данного вида
11.2. Основные направления защиты информации
11.2. Основные направления защиты информации Основные направления защиты информации – охрана государственной, коммерческой, служебной, банковской тайн, персональных данных и интеллектуальной собственности.Государственная тайна – защищаемые государством сведения в
Как Intel работает со студентами и при чём здесь «Open innovation» Вадим Сухомлинов, руководитель направления стратегического развития бизнеса Intel в России и странах СНГ
Как Intel работает со студентами и при чём здесь «Open innovation» Вадим Сухомлинов, руководитель направления стратегического развития бизнеса Intel в России и странах СНГ Опубликовано 02 апреля 2013Принуждение корпораций к инновациям со стороны государства вряд ли принесет
Как быть с корпоративным консерватизмом, если государство «принуждает» к инновациям Вадим Сухомлинов, руководитель направления стратегического развития бизнеса Intel в России и странах СНГ
Как быть с корпоративным консерватизмом, если государство «принуждает» к инновациям Вадим Сухомлинов, руководитель направления стратегического развития бизнеса Intel в России и странах СНГ Опубликовано 14 февраля 2013 Инновационное развитие
Топ-менеджмент крупных корпораций не хочет перемен. Заставим или простимулируем? Вадим Сухомлинов, руководитель направления стратегического развития бизнеса Intel в России и странах СНГ
Топ-менеджмент крупных корпораций не хочет перемен. Заставим или простимулируем? Вадим Сухомлинов, руководитель направления стратегического развития бизнеса Intel в России и странах СНГ Опубликовано 09 марта 2013На сегодняшний день технологическое развитие различных
Глава 8 Три возможных будущих направления
Глава 8 Три возможных будущих направления В этой главе я опишу три долгосрочных проекта, над которыми работал, пытаясь решить некоторые проблемы, описанные в гл. 4. Не знаю, сработает ли какая-нибудь из них, чтобы обеспечить в ходе цифровой революции усиление гуманизма, а не